1Enhance Context Management library for EL3 firmware 2=================================================== 3 4:Authors: Soby Mathew & Zelalem Aweke 5:Organization: Arm Limited 6:Contact: Soby Mathew <soby.mathew@arm.com> & Zelalem Aweke <zelalem.aweke@arm.com> 7:Status: RFC 8 9.. contents:: Table of Contents 10 11Introduction 12------------ 13The context management library in TF-A provides the basic CPU context 14initialization and management routines for use by different components 15in EL3 firmware. The original design of the library was done keeping in 16mind the 2 world switch and hence this design pattern has been extended to 17keep up with growing requirements of EL3 firmware. With the introduction 18of a new Realm world and a separate Root world for EL3 firmware, it is clear 19that this library needs to be refactored to cater for future enhancements and 20reduce chances of introducing error in code. This also aligns with the overall 21goal of reducing EL3 firmware complexity and footprint. 22 23It is expected that the suggestions below could have legacy implications and 24hence we are mainly targeting SPM/RMM based systems. It is expected that these 25legacy issues will need to be sorted out as part of implementation on a case 26by case basis. 27 28Design Principles 29----------------- 30The below section lays down the design principles for re-factoring the context 31management library : 32 33(1) **Decentralized model for context mgmt** 34 35 Both the Secure and Realm worlds have associated dispatcher component in 36 EL3 firmware to allow management of their respective worlds. Allowing the 37 dispatcher to own the context for their respective world and moving away 38 from a centralized policy management by context management library will 39 remove the world differentiation code in the library. This also means that 40 the library will not be responsible for CPU feature enablement for 41 Secure and Realm worlds. See point 3 and 4 for more details. 42 43 The Non Secure world does not have a dispatcher component and hence EL3 44 firmware (BL31)/context management library needs to have routines to help 45 initialize the Non Secure world context. 46 47(2) **EL3 should only initialize immediate used lower EL** 48 49 Due to the way TF-A evolved, from EL3 interacting with an S-EL1 payload to 50 SPM in S-EL2, there is some code initializing S-EL1 registers which is 51 probably redundant when SPM is present in S-EL2. As a principle, EL3 52 firmware should only initialize the next immediate lower EL in use. 53 If EL2 needs to be skipped and is not to be used at runtime, then 54 EL3 can do the bare minimal EL2 init and init EL1 to prepare for EL3 exit. 55 It is expected that this skip EL2 configuration is only needed for NS 56 world to support legacy Android deployments. It is worth removing this 57 `skip EL2 for Non Secure` config support if this is no longer used. 58 59(3) **Maintain EL3 sysregs which affect lower EL within CPU context** 60 61 The CPU context contains some EL3 sysregs and gets applied on a per-world 62 basis (eg: cptr_el3, scr_el3, zcr_el3 is part of the context 63 because different settings need to be applied between each world). 64 But this design pattern is not enforced in TF-A. It is possible to directly 65 modify EL3 sysreg dynamically during the transition between NS and Secure 66 worlds. Having multiple ways of manipulating EL3 sysregs for different 67 values between the worlds is flaky and error prone. The proposal is to 68 enforce the rule that any EL3 sysreg which can be different between worlds 69 is maintained in the CPU Context. Once the context is initialized the 70 EL3 sysreg values corresponding to the world being entered will be restored. 71 72(4) **Allow more flexibility for Dispatchers to select feature set to save and restore** 73 74 The current functions for EL2 CPU context save and restore is a single 75 function which takes care of saving and restoring all the registers for 76 EL2. This method is inflexible and it does not allow to dynamically detect 77 CPU features to select registers to save and restore. It also assumes that 78 both Realm and Secure world will have the same feature set enabled from 79 EL3 at runtime and makes it hard to enable different features for each 80 world. The framework should cater for selective save and restore of CPU 81 registers which can be controlled by the dispatcher. 82 83 For the implementation, this could mean that there is a separate assembly 84 save and restore routine corresponding to Arch feature. The memory allocation 85 within the CPU Context for each set of registers will be controlled by a 86 FEAT_xxx build option. It is a valid configuration to have 87 context memory allocated but not used at runtime based on feature detection 88 at runtime or the platform owner has decided not to enable the feature 89 for the particular world. 90 91Context Allocation and Initialization 92------------------------------------- 93 94|context_mgmt_abs| 95 96.. |context_mgmt_abs| image:: 97 ../resources/diagrams/context_management_abs.png 98 99The above figure shows how the CPU context is allocated within TF-A. The 100allocation for Secure and Realm world is by the respective dispatcher. In the case 101of NS world, the context is allocated by the PSCI lib. This scheme allows TF-A 102to be built in various configurations (with or without Secure/Realm worlds) and 103will result in optimal memory footprint. The Secure and Realm world contexts are 104initialized by invoking context management library APIs which then initialize 105each world based on conditional evaluation of the security state of the 106context. The proposal here is to move the conditional initialization 107of context for Secure and Realm worlds to their respective dispatchers and 108have the library do only the common init needed. The library can export 109helpers to initialize registers corresponding to certain features but 110should not try to do different initialization between the worlds. The library 111can also export helpers for initialization of NS CPU Context since there is no 112dispatcher for that world. 113 114This implies that any world specific code in context mgmt lib should now be 115migrated to the respective "owners". To maintain compatibility with legacy, the 116current functions can be retained in the lib and perhaps define new ones for 117use by SPMD and RMMD. The details of this can be worked out during 118implementation. 119 120Introducing Root Context 121------------------------ 122Till now, we have been ignoring the fact that Root world (or EL3) itself could 123have some settings which are distinct from NS/S/Realm worlds. In this case, 124Root world itself would need to maintain some sysregs settings for its own 125execution and would need to use sysregs of lower EL (eg: PAuth, pmcr) to enable 126some functionalities in EL3. The current sequence for context save and restore 127in TF-A is as given below: 128 129|context_mgmt_existing| 130 131.. |context_mgmt_existing| image:: 132 ../resources/diagrams/context_mgmt_existing.png 133 134Note1: The EL3 CPU context is not a homogenous collection of EL3 sysregs but 135a collection of EL3 and some other lower EL registers. The save and restore 136is also not done homogenously but based on the objective of using the 137particular register. 138 139Note2: The EL1 context save and restore can possibly be removed when switching 140to S-EL2 as SPM can take care of saving the incoming NS EL1 context. 141 142It can be seen that the EL3 sysreg values applied while the execution is in Root 143world corresponds to the world it came from (eg: if entering EL3 from NS world, 144the sysregs correspond to the values in NS context). There is a case that EL3 145itself may have some settings to apply for various reasons. A good example for 146this is the cptr_el3 regsiter. Although FPU traps need to be disabled for 147Non Secure, Secure and Realm worlds, the EL3 execution itself may keep the trap 148enabled for the sake of robustness. Another example is, if the MTE feature 149is enabled for a particular world, this feature will be enabled for Root world 150as well when entering EL3 from that world. The firmware at EL3 may not 151be expecting this feature to be enabled and may cause unwanted side-effects 152which could be problematic. Thus it would be more robust if Root world is not 153subject to EL3 sysreg values from other worlds but maintains its own values 154which is stable and predictable throughout root world execution. 155 156There is also the case that when EL3 would like to make use of some 157Architectural feature(s) or do some security hardening, it might need 158programming of some lower EL sysregs. For example, if EL3 needs to make 159use of Pointer Authentication (PAuth) feature, it needs to program 160its own PAuth Keys during execution at EL3. Hence EL3 needs its 161own copy of PAuth registers which needs to be restored on every 162entry to EL3. A similar case can be made for DIT bit in PSTATE, 163or use of SP_EL0 for C Runtime Stack at EL3. 164 165The proposal here is to maintain a separate root world CPU context 166which gets applied for Root world execution. This is not the full 167CPU_Context, but subset of EL3 sysregs (`el3_sysreg`) and lower EL 168sysregs (`root_exc_context`) used by EL3. The save and restore 169sequence for this Root context would need to be done in 170an optimal way. The `el3_sysreg` does not need to be saved 171on EL3 Exit and possibly only some registers in `root_exc_context` 172of Root world context would need to be saved on EL3 exit (eg: SP_EL0). 173 174The new sequence for world switch including Root world context would 175be as given below : 176 177|context_mgmt_proposed| 178 179.. |context_mgmt_proposed| image:: 180 ../resources/diagrams/context_mgmt_proposed.png 181 182Having this framework in place will allow Root world to make use of lower EL 183registers easily for its own purposes and also have a fixed EL3 sysreg setting 184which is not affected by the settings of other worlds. This will unify the 185Root world register usage pattern for its own execution and remove some 186of the adhoc usages in code. 187 188Conclusion 189---------- 190Of all the proposals, the introduction of Root world context would likely need 191further prototyping to confirm the design and we will need to measure the 192performance and memory impact of this change. Other changes are incremental 193improvements which are thought to have negligible impact on EL3 performance. 194 195-------------- 196 197*Copyright (c) 2022, Arm Limited and Contributors. All rights reserved.* 198
