As mentioned previously, the primary role of the monitor is to context switch resources that are needed in both worlds. Any secure state saved by the monitor should be saved into a region of Secure memory, so that the Normal world cannot tamper with it.
Exactly what needs to be saved and restored for each switch depends on the hardware design, and the software model used for inter-world communications. The list typically includes:
All general purpose ARM registers.
Any coprocessor registers, such as NEON or VFP.
Note: Only required if coprocessor is used in both worlds.
Any world-dependant processor configuration state in CP15.
When the processor hardware is configured to trap exceptions (IRQ, FIQ and external abort) to monitor, the state of the interrupted context is arbitrary.
This means a full context switch of all state is required, unless some can be lazily context switched. See Lazy context switching for more details.
In many circumstances a design will use an SMC instruction as an simple inter-world yield, which causes a full context switch in a similar manner to the hardware exceptions described above. However, in some circumstances it is beneficial for an SMC driven world switch to carry a message payload in some of the processor registers. In these circumstances a full context switch is not desirable.
Efficient software communications protocols can be built between the two worlds using SMC initiated context switches and World-shared memory.
Some of the hardware coprocessors connected to the ARM coprocessor interface, such as the ARM VFP and NEON execution units, can support a mechanism called lazy context switching. This allows the context of the coprocessor to be saved only when necessary, rather than on every operating system context switch or TrustZone world switch. The state associated with the VFP and NEON units can be quite large, so lazy context switching can result in a significant decrease in average switch overheads.
To implement lazy context switching in a TrustZone system the Secure world can block Normal world access to each of the coprocessor interfaces using bit settings in the CP15 Non-Secure Access Control Register (NSACR). When Normal world or user-mode software tries to use a coprocessor configured as Secure in NSACR an undefined instruction exception will be raised. The exception must be trapped by the Normal world kernel, and a handler must issue an SMC to the monitor to request the required coprocessor context switch. As soon as the coprocessor context has been swapped, the monitor can make the coprocessor accessible to Non-secure software using the NSACR configuration, and return to the Normal world handler.
Many Secure world implementations will not require floating point or SIMD operations. In a design where the Secure world does not use the coprocessors, the system boot code can make all coprocessors accessible to Non-secure software. In these cases there is no sensitive data in the coprocessors, and the monitor code does not need to context switch their state.