ATF (or Secure-run-time firmware) flow during switch from tee-driver to tee-os on ARMv7 SoC
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 the opteep-design documentation can the references to SECURE MONITOR LAYER (see [1]) be assumed to be equivalent to a ATF like firmware.
Is this understanding correct or am I missing something here?
[1] https://github.com/OP-TEE/optee_os/blob/master/documentation/optee_design.md
Regards, Bhupesh
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/*.
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 the opteep-design documentation can the references to SECURE MONITOR LAYER (see [1]) be assumed to be equivalent to a ATF like firmware.
Is this understanding correct or am I missing something here?
[1] https://github.com/OP-TEE/optee_os/blob/master/documentation/optee_design.md
Regards, Bhupesh _______________________________________________ Tee-dev mailing list Tee-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/tee-dev
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.
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.
Regards, Jens
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.
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
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
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
Hi, Bhupesh,
Which SoC are you preparing optee-demo for? I have i.MX 6UL and 7D porting for optee os and optee support in U-Boot.
Regards, Peng.
-----Original Message----- From: Tee-dev [mailto:tee-dev-bounces@lists.linaro.org] On Behalf Of Sharma Bhupesh Sent: Thursday, July 23, 2015 12:30 PM To: tee-dev@lists.linaro.org Cc: Garg Sumit-B49020 Subject: [Tee-dev] ATF (or Secure-run-time firmware) flow during switch from tee-driver to tee-os on ARMv7 SoC
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 the opteep-design documentation can the references to SECURE MONITOR LAYER (see [1]) be assumed to be equivalent to a ATF like firmware.
Is this understanding correct or am I missing something here?
[1] https://github.com/OP-TEE/optee_os/blob/master/documentation/optee_design.md
Regards, Bhupesh _______________________________________________ Tee-dev mailing list Tee-dev@lists.linaro.org https://lists.linaro.org/mailman/listinfo/tee-dev
-
Fan Peng -
Jens Wiklander -
Sharma Bhupesh -
Victor Chong