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 at itsentry
point during its initialization.
o Like registers r0-r12, sp etc.
Is it the responsibility of boot-loader (u-boot in my case)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#... 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.
Regards, Jens