Hi Jens,
From: Jens Wiklander [mailto:jens.wiklander@linaro.org] Sent: Thursday, September 24, 2015 12:30 AM
On Wed, Sep 23, 2015 at 08:12:47AM +0000, Sharma Bhupesh wrote:
Hi Peng, Jens
From: Tee-dev [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Peng Fan Sent: Wednesday, September 23, 2015 7:45 AM On Tue, Sep 22, 2015 at 12:49:21PM -0700, Jens Wiklander wrote:
Hi Sumit,
On Thu, Sep 17, 2015 at 4:41 AM, SUMIT GARG sumit.garg@freescale.com
wrote:
Hi OP-TEE experts,
I am working on to integrate OP-TEE secure OS with u-boot on ARMv7 and came across following question
that I need to clarify:
It seems that optee-os doesn’t save u-boot context atits
entry
point during its initialization.
o Like registers r0-r12, sp etc.
Is it the responsibility of boot-loader (u-boot in mycase)
to
save its context, pass
control to optee-os and then retrieve context after optee-os returns control back to boot-loader?
You can take this as a reference:http://sw- stash.freescale.net/users/b51431/repos/uboot- optee/browse/arch/arm/cpu/armv7/nonsec_virt.S
Before u-boot has entered OP-TEE it runs in secure mode (ns-bit = 0), but once OP-TEE has initialized and returns it returns to non-nsecure mode (ns-bit = 1). Preserving the context could potentially leak secrets to non-secure software.
I think before initialize optee, uboot should save the context and optee do the initialization flow, then optee switch to non-sec world. uboot restore the context that saved. Then uboot boot linux.
If uboot does not save the context, uboot will crash when optee back to uboot, and there is no way to boot linux.
I implement the flow for i.MX6. U-Boot(load optee to RAM, save current context)->jumps the optee ADDR-
optee back to uboot-> uboot restore the context->uboot boot linux
I think the op-tee os init call from u-boot should be like any other subroutine call for u-boot. Since u-boot does not know about the op-tee os internal implementation details and what will be called from there (for e.g. a SMC call to shift to non-secure world), so the op-tee os init call should create a stack at on the system DDR and
allow its access from both secure/non-secure software before calling the SMC monitor.
The init call to OP-TEE can't behave as another subroutine call as it among other things initialize memory mapping and enables MMU. The memory location where OP-TEE was called from is likely not mapped any longer as OP-TEE expects to be alone in secure world.
Perhaps we should look to standardize and document the op-tee init requirements from any Bootloader, like Linux specifies for a bootloader: http://lxr.free-electrons.com/source/Documentation/arm64/booting.txt
Yes, that's sounds good. But we need a couple of good v7 examples first to pick from. I like the approach in https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat- ti/main.c#L118 where the CPU state when exiting is supplied. When done like that OP-TEE can even exit directly into the entry of the normal world Linux kernel. We should perhaps try to limit the number of registers a bit and there's also the issue of where in the memory the register values can be stored.
I agree. This seems to be a better approach. Usually some ARM based SoCs (like the Layerscape family from Freescale) has a TZ-ASC (Trust Zone Address Space Controller) block sitting in front of the system DDR (see the TRM of the same here: [1]).
This block allows system DDR to be partitioned into non-secure and secure regions. Thus allowing secure memory blocks to be accessed only by the secure software.
Since these register sets need to be accessed by the non-secure software before invoking linux, it would probably make sense to store them in a region which is marked as non-secure. Since the non-secure software cannot access the secure DDR regions, this should prevent the secure secrets from getting leaked to the non-secure world.
However, as I mentioned before, I am not sure if that can be used as a generic solution.
Regards, Bhupesh