Hi Sergey,
On Mon, Aug 10, 2015 at 09:15:40PM +0000, Blotsky, Sergey wrote:
Hi OP-TEE experts,
I'm looking at OP-TEE Secure OS and came across number of questions that I need to clarify:
It seems OP-TEE is using only L1 page tables
It has one large L1 page table for kernel which maps flat 4 GB space (referenced by TTBR1); every thread has another L1 translation table(s) referenced by TTBR0 which map 32 MB of virtual addresses
Yes, that's correct for the v7 translation tables except that we map the TEE Core memory with L2 tables when the pager is enabled. For LPAE it's slightly different.
Does this mean that the smallest unit of memory that it can map is 1 MB?
Yes
If Trusted Application code/data/stack is 16 KB total, does it still consume 1 MB of DRAM?
Yes, but long term this is something we'd like to address with more fine grained mapping.
TA Memory usage
Browsing through OP-TEE source (tee_ta_load_user_ta() function) we noticed that heap/stack for all TAs seems to be allocated from the same pool, is this correct?
They use the same virtual address range, but as each TA instance maps virtual memory to different physical memory they don't share memory.
If yes, then can different TAs see heap/stack of each other? If this is possible, then what is security model of OP-TEE? Does it assume that all TAs are trusted and don't need isolation from each other? Any high level design description would be very helpful
TAs are isolated from each other. There's currently no support for shared secure memory.
Access to HW resources
If TA needs to access some HW resources, how can this be done? Does OP-TEE has concept of loadable secure Drivers?
We don't have a concept of loadable secure drivers. To expose a generic driver to a TA I would recomend defining a Static TA (see examples in core/arch/arm/sta) which can provide an interface to the driver to be used by a TA. It's currently not possible to check if the calls to the Static TA comes from a TA of from normal world, but adding that is very easy as that information is availble in tee_ta_open_session().
Suspend/Resume
Does OP-TEE support saving/restoring its state for CPU suspend/resume cycle?
Currently not, in the ARMv8 case ARM Trusted Firmware all that's needed.
For ARMv7 we haven't had to deal with that yet. OP-TEE current doesn't have any state that need to be saved so the CPU just need to be reinitialized with reset_secondary() in core/arch/arm/kernel/generic_entry_a32.S. The function can probably not be used directly as we may need to deal differently with synchronization between CPUs.
Scheduling of TA threads
Does OP-TEE Swd kernel have periodic timer interrupt handler that causes the task switch or does it rely on Nwd making some sort of SMC call for that?
OP-TEE is scheduled from normal world so we don't use any timer interrupts in secure world for that. If we're executing in secure world when a normal world timer interrupt (or any other for that matter) is triggered we save the secure thread state and exit to normal world. Normal world will get the interrupt as soon as we've switched to normal world as we haven't done anything with the interrupt in secure world. Once the normal world interrupt handler returns we'll switch back to secure world and resume the secure world thread again.
You can find details on interrupt handling at https://docs.google.com/document/d/1-GthGR5alcaJQxzjs76ocI3FldXU4wYalw13VHtR...
Regards, Jens