Lines Matching refs:in
23 in the system, i.e. EL3 in Trusted Firmware-A (TF-A). The service requirements are
35 Placement of management and security functions with diverse requirements in a
43 A **Secure Partition** is a software execution environment instantiated in
47 resources. Essentially, it is a software sandbox in the Secure world that runs
51 - Memory and device regions in the system address map.
60 services in EL3 and instantiate the rest in a partition in S-EL0.
64 The following diagram illustrates the place of a Secure Partition in a typical
66 services to software components in the Non-secure world and other Secure
72 in the FIP. During boot, BL2 includes support to authenticate and load the
105 made in the current implementation of this software architecture. Subsequent
113 implementation supports inclusion of only a single Secure Partition in which a
124 and tools, leveraging the concept of the *Standalone Management Mode (MM)* in
126 Interface). This will be referred to as the *Standalone MM Secure Partition* in
129 To enable SPM support in TF-A, the source code must be compiled with the build
136 `instructions in the EDK2 repository`_.
139 image in the FIP:
164 defines in ``include/plat/arm/common/arm_spm_def.h``.
174 For an example of all the changes in context, you may refer to commit
175 ``e29efeb1b4``, in which the port for FVP was introduced.
181 accessing services implemented in the Secure world. The ``MM_COMMUNICATE``
182 interface defined in the `Management Mode Interface Specification`_ (*Arm DEN
190 used to identify a management mode service. A client populates the GUID in the
191 ``EFI_MM_COMMUNICATE_HEADER``. The header is populated in the communication
196 ``MM_COMMUNICATE`` SMC will run to completion in the partition on a given CPU.
198 can only be a single outstanding Fast Call in a partition on a given CPU.
204 through a shared memory region. The location of data in the shared memory area
209 exchange data with a partition only if it has been populated in this shared
211 specified in Section 3.2.3 of the `Management Mode Interface Specification`_
214 The format of data structures used to encapsulate data in the shared memory is
215 agreed between the Non-secure world and the Secure Partition. For example, in
218 the Management Mode (MM) in the Secure world must be of the type
219 ``EFI_MM_COMMUNICATE_HEADER``. This data structure is defined in *Volume 4:
232 In order to instantiate one or more secure services in the Secure Partition in
237 amongst multiple software components in the Secure world or cannot be directly
244 Secure Partition to initialise itself and export its services in S-EL0. These
254 software to make a request for an operation implemented in privileged software.
259 and installs a simple exception vector table in S-EL1 that relays a SVC request
260 from a Secure Partition as a SMC request to the SPM in EL3. Upon servicing the
293 partition (e.g. management of memory attributes in the translation tables for
299 The current implementation reserves function IDs for Fast Calls in the Standard
361 minor revision value of revision A, then every function in revision A must
362 work in a compatible way with revision B. However, it is possible for
378 enable initialisation of a service in S-EL0. The responsibilities of the SPM are
394 At cold boot, system registers accessible from S-EL0 will be in their reset
396 architectural setup to enable execution in S-EL0
427 System registers that influence software execution in S-EL0 are setup by the SPM
461 This transition into S-EL0 is special since it is not in response to a previous
463 general purpose register usage at the time of entry will be as specified in the
464 "Return State" column of Table 3-1 in Section 3.1 "Register use in AArch64 SMC
484 buffer will be mapped in the Secure EL1&0 translation regime with read-only
487 - ``X1``: Size of the buffer in bytes.
526 code in response to a runtime event.
540 event has been delegated to it in response to an ``MM_COMMUNICATE`` request
553 event specific information. The format of the data populated in the buffer
556 The buffer is mapped in the Secure EL1&0 translation regime with read-only
575 A return from this function is in response to the next event that will be
587 instruction, to the instruction immediately after the call in the Secure
593 specify the properties of the event and be populated in ``X0-X3/W0-W3``
600 The SPM is responsible for enabling access to regions of memory in the system
601 address map from a Secure Partition. This is done by mapping these regions in
604 attributes used in the Translation tables. The definitions of these attributes
605 and their usage can be found in the `Armv8-A ARM`_ (*Arm DDI 0487*).
607 All memory required by the Secure Partition is allocated upfront in the SPM,
618 a part of the Secure Partition image. The location of various sections in an
653 attributes of the translation granule it lies in are returned.
680 memory region the Base Address lies in.
694 region is equal to the Translation Granule size used in the Secure EL1&0
726 of the Translation Granule Size used in the Secure EL1&0 translation
761 memory region that overlaps with the region specified in this request.
766 specified in the call.
769 attributes of the memory region in the translation tables.
783 region is equal to the Translation Granule size used in the Secure EL1&0
799 memory in case of an unsuccessful call. The SPM must preserve the consistency
821 .. _instructions in the EDK2 repository: https://github.com/tianocore/edk2-staging/blob/AArch64Stan…