Hi,
From: Jens Wiklander [mailto:jens.wiklander@linaro.org] Sent: Thursday, July 23, 2015 2:14 PM
Hi,
On Thu, Jul 23, 2015 at 01:42:50PM +0900, Victor Chong wrote:
I'm not an expert but optee-os comes with its own secure monitor that handles the SMC calls when compiled for ARMv7, so you don't really need to install anything extra. Both the os and the monitor run in the same privilege level. See optee_os/core/arch/arm/sm/*.
Yes, more or less. Monitor code runs in MON mode while the rest of the code runs in secure SVC/SYS/IRQ/FIQ/ABT/USR mode.
MON mode is always secure (using banked secure system registers) regardless of the NS-bit, while the rest of the modes (excluding HYP) depend on the NS-bit.
hth
On Thu, Jul 23, 2015 at 1:29 PM, Sharma Bhupesh < bhupesh.sharma@freescale.com> wrote:
Hi TEE Experts,
We are trying to setup the optee-demo on a ARMv7 based Freescale SoC.
During the same, I noticed that the SMC calls from the optee-linux-driver directly land up on the optee-os side.
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.
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.
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.
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.den0022c/index.h...
Regards, Bhupesh
In the opteep-design documentation can the references to SECURE MONITOR LAYER (see [1]) be assumed to be equivalent to a ATF like firmware.
The secure monitor layer is a software architecture layer it's still part of the OP-TEE binary. This layer corresponds to the Dispatcher in v8 ARM-TF.