Lines Matching refs:in
7 Two implementations of a Secure Partition Manager co-exist in the TF-A codebase:
12 Both implementations differ in their architectures and only one can be selected
30 in the system, i.e. EL3 in Trusted Firmware-A (TF-A). The service requirements are
42 Placement of management and security functions with diverse requirements in a
50 A **Secure Partition** is a software execution environment instantiated in
54 resources. Essentially, it is a software sandbox in the Secure world that runs
58 - Memory and device regions in the system address map.
67 services in EL3 and instantiate the rest in a partition in S-EL0.
71 The following diagram illustrates the place of a Secure Partition in a typical
73 services to software components in the Non-secure world and other Secure
79 in the FIP. During boot, BL2 includes support to authenticate and load the
112 made in the current implementation of this software architecture. Subsequent
120 implementation supports inclusion of only a single Secure Partition in which a
131 and tools, leveraging the concept of the *Standalone Management Mode (MM)* in
133 Interface). This will be referred to as the *Standalone MM Secure Partition* in
136 To enable SPM support in TF-A, the source code must be compiled with the build
143 `instructions in the EDK2 repository`_.
146 image in the FIP:
171 defines in ``include/plat/arm/common/arm_spm_def.h``.
181 For an example of all the changes in context, you may refer to commit
182 ``e29efeb1b4``, in which the port for FVP was introduced.
188 accessing services implemented in the Secure world. The ``MM_COMMUNICATE``
189 interface defined in the `Management Mode Interface Specification`_ (*Arm DEN
197 used to identify a management mode service. A client populates the GUID in the
198 ``EFI_MM_COMMUNICATE_HEADER``. The header is populated in the communication
203 ``MM_COMMUNICATE`` SMC will run to completion in the partition on a given CPU.
205 can only be a single outstanding Fast Call in a partition on a given CPU.
211 through a shared memory region. The location of data in the shared memory area
216 exchange data with a partition only if it has been populated in this shared
218 specified in Section 3.2.3 of the `Management Mode Interface Specification`_
221 The format of data structures used to encapsulate data in the shared memory is
222 agreed between the Non-secure world and the Secure Partition. For example, in
225 the Management Mode (MM) in the Secure world must be of the type
226 ``EFI_MM_COMMUNICATE_HEADER``. This data structure is defined in *Volume 4:
239 In order to instantiate one or more secure services in the Secure Partition in
244 amongst multiple software components in the Secure world or cannot be directly
251 Secure Partition to initialise itself and export its services in S-EL0. These
261 software to make a request for an operation implemented in privileged software.
266 and installs a simple exception vector table in S-EL1 that relays a SVC request
267 from a Secure Partition as a SMC request to the SPM in EL3. Upon servicing the
300 partition (e.g. management of memory attributes in the translation tables for
306 The current implementation reserves function IDs for Fast Calls in the Standard
368 minor revision value of revision A, then every function in revision A must
369 work in a compatible way with revision B. However, it is possible for
385 enable initialisation of a service in S-EL0. The responsibilities of the SPM are
401 At cold boot, system registers accessible from S-EL0 will be in their reset
403 architectural setup to enable execution in S-EL0
434 System registers that influence software execution in S-EL0 are setup by the SPM
468 This transition into S-EL0 is special since it is not in response to a previous
470 general purpose register usage at the time of entry will be as specified in the
471 "Return State" column of Table 3-1 in Section 3.1 "Register use in AArch64 SMC
491 buffer will be mapped in the Secure EL1&0 translation regime with read-only
494 - ``X1``: Size of the buffer in bytes.
533 code in response to a runtime event.
547 event has been delegated to it in response to an ``MM_COMMUNICATE`` request
560 event specific information. The format of the data populated in the buffer
563 The buffer is mapped in the Secure EL1&0 translation regime with read-only
582 A return from this function is in response to the next event that will be
594 instruction, to the instruction immediately after the call in the Secure
600 specify the properties of the event and be populated in ``X0-X3/W0-W3``
607 The SPM is responsible for enabling access to regions of memory in the system
608 address map from a Secure Partition. This is done by mapping these regions in
611 attributes used in the Translation tables. The definitions of these attributes
612 and their usage can be found in the `Armv8-A ARM`_ (*Arm DDI 0487*).
614 All memory required by the Secure Partition is allocated upfront in the SPM,
625 a part of the Secure Partition image. The location of various sections in an
660 attributes of the translation granule it lies in are returned.
687 memory region the Base Address lies in.
701 region is equal to the Translation Granule size used in the Secure EL1&0
733 of the Translation Granule Size used in the Secure EL1&0 translation
768 memory region that overlaps with the region specified in this request.
773 specified in the call.
776 attributes of the memory region in the translation tables.
790 region is equal to the Translation Granule size used in the Secure EL1&0
806 memory in case of an unsuccessful call. The SPM must preserve the consistency
828 .. _instructions in the EDK2 repository: https://github.com/tianocore/edk2-staging/blob/AArch64Stan…