Lines Matching refs:security

12 software running in various security states (Secure/Non-Secure/Realm).
14 are not banked per world. When moving between the security states it is the
28 security state and save enough EL3 metadata to be able to return to that exception
29 level and security state. The memory for the context data structures are allocated
33 security states (Non-Secure, Secure, Realm). Each world must have its
34 configuration of system registers independent of other security states to access
37 If the CPU switches across security states (for example: from Non-secure to Secure
41 the architectural features enabled in the former security state will be unconditionally
42 accessible in the latter security state as well. This can be a major concern when
43 dealing with security-specific bits, as they need to be explicitly enabled or
50 This will help ensure the integrity and security of the system, preventing any
51 unauthorized access or data corruption between the different security states.
69 RME isolates EL3 from all other Security states and moves it into its own security
156    context for different security states alongside high level feature enablement
179    utilisation across the security states.
213 the Non-Secure, Realm and Secure security state context structures as listed below.
255 state of CPU across exception levels for a given security state are listed below.
326 The CPU has been assigned context structures for every security state, which include
328 during the bootup of every CPU before they enter any security state for the
413 Depending on the security state that the CPU needs to enter, the respective
471 each security state. These functions are invoked from the top-level setup APIs