ARM TrustZone - Behaviour of the scheduler in Secure and Non-Secure OS

Question

Can some one please explain to me that after the CPU is taken to secured mode, (Monitor program sets the NS = 0), how does the secure OS gets scheduled? Is it that now that the CPU is in secured mode, the timer tick interrupt would be handled by the Secured OS and not the Non-Secured world?

Answer 1

The monitor mode setting NS=0 will set CP15 registers visible from monitor mode. See: monitor mode IFAR/IFSR.... When the monitor mode switches to another mode and NS=0, then the mode is the secure world version; meaning the banked CP15 registers are the secure version. Also the NS bit is clear on bus cycles.

If NS=1 is set, then when monitor mode switches, the banked CP15 registers are the normal version; mainly the normal world MMU will be active. Also, the NS bit is set on bus cycles. ^{TZ vs hypervisor}

How does the secure OS gets scheduled?

Monitor mode does this. The SCR (cp15 c1, c1, 0) has bits which determine whether the monitor vector table is used or the current CPU world (secure or normal). If you are in a normal world and you wish for a timer to interrupt that world, you need monitor mode to handle it.

You can setup the monitor mode in two possible ways,

1. Have all secure interrupts as FIQ.
2. Trap all interrupts to monitor.

The first choice is recommended. In this mode, the monitor code must ensure that SCR#FIQ (bit 2) is set in the normal world, but clear in the secure world. The SCR#IRQ (bit 1) will be set when running the secure OS (if you want normal interrupts to interrupt the secure OS) and clear in the normal world.

So when the secure timer has a FIQ interrupt, it traps to monitor mode which does a world switch^ref1 and runs the secure OS timer code. This secure timer may cause the secure world to reschedule. The way the normal and secure world schedulers interact is up to software. Ie, there is no generic answer. It depends on,

1. Monitor mode
2. The secure OS.
3. The normal world OS.

Mainly the ARM TrustZone does not handle the secure OS scheduling by itself. You need to write software that uses the primitives provided to implement this. ARM TrustZone only facilitates different ways of implementing it. ^{TrustZone Whitepaper}

See: How to develop programs for TrustZone for some alternative setups.
Ref1: A world switch saves/restores all general purpose CPU registers for all used modes. Ie, on a normal to secure world switch, the R0-R15 (and all banked copies) plus possibly NEON/VFP must be saved to a normal world store. Similarly, the registers must be reloaded for the secure world. Monitor mode sp provides a good anchor for accessing these world contexts. Monitor mode sp should be setup during secure boot, before the normal world initializes. This is much like a traditional OS context switch. The SCR#NS (bit 0) is set appropriately; you may do this before or after the register switching, depending on how you save the registers (Ie, by mode switch or by srs).