You copied the Doc URL to your clipboard.

Switching between the Secure and Normal worlds

With the ARMv7 Security Extensions, Monitor mode is used by software to switch between the Secure and Non-secure state. This mode is a peer of the other privileged modes within the Secure state. In ARMv8-A processors, AArch32 is the equivalent of ARMv7-A.

For the ARMv8 architecture, when EL3 is using AArch32 the system behaves as ARMv7 to ensure full compatibility, with the result that all the privileged modes within the Secure state are treated as being at EL3.

The security model for AArch32 is shown in the figure below. In this scenario, EL3 is AArch32 to provide a Secure OS and monitor.

el3_is_aarch32.png

The following figure shows the security model when EL3 is executing AArch64 to provide a Secure monitor. EL1 is used for the secure OS. When EL3 is using AArch64, the EL3 level is used to execute the code responsible for switching between the Non-secure state and the Secure state.

el3_is_aarch64.png

In keeping with AArch32, the Secure state EL1 and EL0 have a different virtual address space from the Non-secure state EL1 and EL0. This permits secure side code from AArch32 32-bit architecture to be used in a system with a 64-bit operating system or hypervisor running on the Non-secure side.

As Normal world execution ceases and Secure world execution starts, context switching between them occurs through execution of the Secure Monitor (SMC) instruction or by hardware exception mechanisms, such as interrupts or asynchronous aborts. ARM processors have two interrupt types, FIQ, and IRQ.

nosecure_interrupts.png

There is explicit support for Secure interrupts in the form of controls for redirecting exceptions and interrupts to EL3, independently of the current DAIF fields. However, these controls only distinguish between the main interrupt types: IRQ, FIQ, and asynchronous aborts. More detailed control requires interrupts to be filtered into Secure and Non-secure groups. Doing this efficiently requires support from the GIC, which has explicit facilities for this purpose.

One typical use case is for FIQs to be used as Secure interrupts, by mapping Secure interrupt sources as FIQ within the interrupt controller. The relevant peripheral and interrupt controller registers must be marked as Secure access only, to prevent the Normal world from reconfiguring these interrupts. These Secure FIQ interrupts must be routed to handlers in the Secure Execution state.

secure_interrupts.png

Implementations that use Security Extensions typically have a light-weight trusted kernel that hosts secure services, such as encryption, in the Secure world. A full operating system runs in the Normal world and is able to access the Secure services using the SMC instruction. In this way, the Normal world gets access to service functions without risking exposure of secure assets, such as key material or other protected data, to arbitrary code executing in the Normal world.

Was this page helpful? Yes No