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