1############################ 2Cooperative Scheduling Rules 3############################ 4 5:Author: Ashutosh Singh 6:Organization: Arm Limited 7:Contact: Ashutosh Singh <ashutosh.singh@arm.com> 8 9TF-M Scheduler - Rules 10====================== 11 12On ArmV8-M CPUs, NSPE and SPE share the same physical processing element(PE). A 13TF-M enabled system need to be able to handle asynchronous events (interrupts) 14regardless of current security state of the PE, and that may lead to scheduling 15decisions. This introduces significant complexity into TF-M. To keep the 16integrity of (NSPE and SPE) schedulers and call paths between NSPE and SPE, 17following set of rules are imposed on the TF-M scheduler design. 18 19Objectives and Requirements 20=========================== 21 221. Decoupling of scheduling decisions between NSPE and SPE 232. Efficient interrupt handling by SPE as well as NSPE 243. Reduce critical sections on the secure side to not block interrupts 25 unnecessarily 264. Scalability to allow simplification/reduction of overheads to scale down the 27 design for constrained devices 285. Reduce impact on NSPE software design 29 30 a. NSPE interrupt handling implementation should be independent 31 b. Impact on the NSPE scheduler should be minimal 32 c. No assumptions should be made about NSPE's scheduling capabilities 33 34Scheduler Rules for context switching between SPE and NSPE 35========================================================== 36 37To allow coherent cooperative scheduling, following set of rules are imposed on 38security state changes. 39The switching between SPE and NSPE can be triggered in multiple ways. 40 41`Involuntary security state switch`; when the software has no control over the 42switch: 43 44- A NSPE interrupt take control into NSPE from SPE 45- A SPE interrupt takes control into SPE from NSPE 46 47`Voluntary security state switch`; when software programmatically makes the 48switch: 49 50- A NSPE exception handler returns from NSPE to pre-empted SPE context 51- A SPE exception handler returns from SPE to pre-empted NSPE context 52- NSPE makes a function call into SPE 53- SPE returns a call from NSPE 54- SPE makes a function call into NSPE (not covered in current design) 55- NSPE returns a call from SPE (not covered in current design) 56 57In order to maintain the call stack integrity across NSPE and SPE, following 58rules are imposed on all security state switches. 59 60Rules for NSPE Exception handling 61--------------------------------- 62 631. **The NSPE exception handler is allowed to trigger a NSPE context switch** 64 **(regardless of security state of the preempted context.** 65 66This is expected behaviour of any (RT)OS. 67 682. **The NSPE scheduler must eventually 'restore' the preempted (by** 69 **exception) context.** 70 71This is expected behaviour of any (RT)OS. 72 733. **If NSPE exception results in a NSPE context switch, SPM must be informed** 74 **of the scheduling decision; this must be done BEFORE the execution of** 75 **newly scheduled-in context.** 76 77This is to ensures integrity of the call stack when SPE is ready to return a 78previous function call from NSPE. 79 80Rules for SPE Exception handling 81-------------------------------- 82 831. **All of the SPE interrupts must have higher priority than NSPE interrupts** 84 85This is rule is primarily for simplifying the SPM design. 86 872. **The SPE interrupt handler is allowed to trigger a SPE context switch** 88 **(regardless of security state of the pre-empted context)** 89 90If the SPE context targeted by the interrupt is not same as current SPE context, 91the SPM may choose to switch the current running SPE context based on priority. 92 933. **SPE scheduler must treat pre-empted context as one of the SPE contexts** 94 95 a. If the pre-empted SPE context is SP1, the TCB for SP1 should be used for 96 saving the context. i.e. the context of SP1 should be saved before 97 scheduling anything other secure partition. 98 b. If SP1 was pre-empted by a NSPE interrupt, and subsequent NSPE execution is 99 pre-empted by SPE exception (before NSPE scheduling decision is communicated 100 back to SPM) -- SP1 TCB must be used for saving the context 101 In this case SPM is not yet aware of the NSPE context switch, from SPM's 102 standpoint SP1 is still executing, so SPM assumes that the preempted context 103 is SP1. 104 c. If SP1 was pre-empted by a NSPE interrupt, and subsequent NSPE execution is 105 pre-empted by SPE exception `after` NSPE scheduling decision is 106 communicated back to SPM) - a TCB dedicated to NSPE should be used for 107 saving the context. 108 109 When NSPE scheduler communicates the scheduling decision to SPM, SPM must save 110 the SP1 context, if a SPE interrupt preempts the currently running NSPE context, 111 SPM should save the context to a dedicated NSPE TCB. 112 113 d. The SPE scheduler must eventually 'restore' the pre-empted context. 114 This is an expected behaviour of any scheduler. 115 1164. **All of the interrupts belonging to a partition must have same priority.** 117 118This serializes ISR execution targeted for same partition. 119 1205. **In case of nested interrupts, all of the ISRs must run to finish before** 121 **any service code is allowed to run** 122 123This is an expected behaviour of any scheduler. 124 1256. **If the previously preempted context was a NSPE ISR context, SPE ISR** 126 **handler must return to preempted NSPE context.** 127 128This is an expected behaviour of any scheduler to return to preempted context. 129 130Rules for NSPE to SPM function call (and NSPE scheduler) 131-------------------------------------------------------- 132 1331. Current NSPE context must have been communicated to SPM, otherwise SPM cannot 134 guarantee NSPE function calling stack integrity. 135 136Rules for Function Return from SPE to NSPE with result 137------------------------------------------------------ 138 1391. **The result available on SPE side are for currently active NSPE context.** 140 141To maintain call stack integrity, if SPE is ready to return to NSPE, it can do 142function return only if the SPE return path corresponds to currently active NSPE 143context. 144 1452. **Last entry into secure world happened programmatically (Voluntary** 146 **security state switch into SPE)** 147 148i.e. control is voluntarily given back by NSPE, either through a function call, 149or a context restore via 'return to SPE from NSPE'. As opposed to a SPE 150interrupt bringing back the execution into SPE. 151 1523. **The current NSPE call stack has not already been returned with SPM_IDLE.** 153 154This rule applies if following optional feature is enabled. 155 156Rules for Return from SPE to NSPE with SPM_IDLE 157----------------------------------------------- 158 159This is optional part of the design as it introduces significant complexity on 160both sides of the security boundary. 161It allows yielding of the CPU to NSPE when SPE has not CPU execution to do but 162it has not yet finished the previous request(s) from NSPE; i.e. SPE is waiting 163on arrival of a SPE interrupt. 164 1651. **Last entry into secure world happens programmatically (Voluntary** 166 **security context switch into SPE)** 167 168i.e. control is voluntarily given back by NSPE, either through a function call, 169or a context restore via 'return to SPE from NSPE'. As opposed to a SPE 170interrupt bringing back the execution into SPE. 171 1722. **The result for the currently active NSPE entity is not yet available,** 173 **the called service is waiting (on interrupt/event).** 174 175SPE request corresponding to currently active NSPE caller is not yet completed 176and is waiting on an ISR. 177 1783. **The current NSPE call stack has not already been returned with SPM_IDLE.** 179 180Rules for NSPE pend irq based return from SPE to NSPE 181----------------------------------------------------- 182 183This is optional part of the design as it introduces significant complexity on 184both sides. This works in conjunction with [Rules for Return from SPE to NSPE 185with SPM_IDLE](#rules-for-return-from-spe-to-nspe-with-spm_idle). 186In this scenario, when SPE is ready with result for a previous call from NSPE, 187it raises a pended IRQ to NSPE instead of returning the function call path. 188 1891. **The SPE has finished a NSPE request.** 190 1912. **The corresponding NSPE context has already been returned with SPM_IDLE.** 192 193Rules for ISR pre-emption 194------------------------- 195 1961. **A higher priority NSPE interrupt is allowed to preempt a lower priority** 197 **NSPE ISR** 198 1992. **A higher priority SPE interrupt is allowed to preempt a lower priority** 200 **SPE ISR** 201 2023. **A SPE interrupt is allowed to preempt NSPE ISR** 203 2044. **A NSPE interrupt is not allowed to preempt SPE ISR** 205 2065. **All interrupts belonging to a service must have same priority** 207 208-------------- 209 210*Copyright (c) 2019, Arm Limited. All rights reserved.* 211
