Hi,
-----Original Message----- From: Jens Wiklander [mailto:jens.wiklander@linaro.org] Sent: Thursday, July 23, 2015 4:56 PM
Hi,
On Thu, Jul 23, 2015 at 09:42:22AM +0000, Sharma Bhupesh wrote: [...]
I was thinking that just like the ARMv8 flow, where the SMC handling should ideally be done by a Arm Trusted Firmware (or an equivalent secure-run-time firmware) agent running in EL3 privilege level, on ARMv7 too, if we have a resident ATF (or secure firmware) installed the SMC calls should be handled there.
In a v7 system monitor mode (corresponing to EL3 in v8) shares memory mapping etc with the rest of the secure code it's coupled more tight with the rest of the secure code. A v7 system resets into
secure SVC mode.
On the other hand in a V8 system the EL3 code has its own memory mapping and can be more indepentent from secure EL1. A v8 system
resets into EL3.
In a v7 system it makes sense to have monitor code and secure kernel code in the same binary as they need to agree on many system registers any way. This also leads to more efficient memory usage. In a v8 system EL3 and secure EL1 doesn't have to agree on that many registers and are more suitable to keep as separate binaries.
I was wondering if modifying optee_os for adding platform support code (including the SMC support interface) for each platform would be the correct approach in the longer run? I mean with additional platforms targeting optee support, will keeping the SMC interface separate from the optee_os, make the optee_os footprint smaller.
Currently OP-TEE is built for a specific platform so only what's needed by the particular platform is included in the build. This minimizes memory consumption.
Also considering if we have a choice of picking a trusted OS to act as a optee_os in the future for commercial products, will it make sense to
seperate the two.
If you're not too memory constrained it could be a convenient approach, but if you at the same time want to minimize memory usage it will be hard to not waste some memory at least.
Currently we're trying to make OP-TEE as small as possible to be useful in systems with not much secure memory available.
That said, since we support an external secure monitor in the v8 case it's not that difficult to do the same thing for v7. An external secure monitor would need to be added too though. The best would probably be to have it in a separate tree to best take advantage of the separation.
BTW have you read this: https://github.com/ARM-software/tf-issues/issues/270
No, I didn't read this before.
Thanks for this link and the thorough description. Now it's much more clearer.
Regards, Bhupesh
Also how do the rest of the SMC interfaces - like the ARM PSCI interface SMC calls for turning-on/off secondary CPUs (see [1]) work then, are these handled by the SMC handlers in the optee_os, or do we
need to handle them via a separate SMC implementation.
PSCI would be handled by the fast-call handler in OP-TEE, either by some #ifdef'ed code in some big switch or perhaps more sophisticated as in ARM-TF. That's a small implementation detail. The PSCI code would be used as a library and only enabled for platforms that need it.
Regards, Jens