diff options
Diffstat (limited to 'docs/components')
| -rw-r--r-- | docs/components/arm-sip-service.rst | 4 | ||||
| -rw-r--r-- | docs/components/cot-binding.rst | 332 | ||||
| -rw-r--r-- | docs/components/debugfs-design.rst | 25 | ||||
| -rw-r--r-- | docs/components/exception-handling.rst | 77 | ||||
| -rw-r--r-- | docs/components/fconf/fconf_properties.rst | 32 | ||||
| -rw-r--r-- | docs/components/fconf/index.rst | 147 | ||||
| -rw-r--r-- | docs/components/index.rst | 8 | ||||
| -rw-r--r-- | docs/components/measured_boot/event_log.rst | 35 | ||||
| -rw-r--r-- | docs/components/measured_boot/index.rst | 12 | ||||
| -rw-r--r-- | docs/components/platform-interrupt-controller-API.rst | 2 | ||||
| -rw-r--r-- | docs/components/psa-ffa-manifest-binding.rst | 247 | ||||
| -rw-r--r-- | docs/components/ras.rst | 44 | ||||
| -rw-r--r-- | docs/components/sdei.rst | 2 | ||||
| -rw-r--r-- | docs/components/secure-partition-manager-mm.rst (renamed from docs/components/secure-partition-manager-design.rst) | 23 | ||||
| -rw-r--r-- | docs/components/secure-partition-manager.rst | 873 |
15 files changed, 1772 insertions, 91 deletions
diff --git a/docs/components/arm-sip-service.rst b/docs/components/arm-sip-service.rst index 01bc04d71..b51a94dc7 100644 --- a/docs/components/arm-sip-service.rst +++ b/docs/components/arm-sip-service.rst @@ -430,6 +430,6 @@ uint32_t w1: On success, debugfs interface version, 32 bits -------------- -*Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.* +*Copyright (c) 2017-2020, Arm Limited and Contributors. All rights reserved.* -.. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html +.. _SMC Calling Convention: https://developer.arm.com/docs/den0028/latest diff --git a/docs/components/cot-binding.rst b/docs/components/cot-binding.rst new file mode 100644 index 000000000..4f8c8b725 --- /dev/null +++ b/docs/components/cot-binding.rst @@ -0,0 +1,332 @@ +Chain of trust bindings +======================= + +The device tree allows to describe the chain of trust with the help of +'cot' node which contain 'manifests' and 'images' as sub-nodes. +'manifests' and 'images' nodes contains number of sub-nodes (i.e. 'certificate' +and 'image' nodes) mentioning properties of the certificate and image respectively. + +Also, device tree describes 'non-volatile-counters' node which contains number of +sub-nodes mentioning properties of all non-volatile-counters used in the chain of trust. + +cot +------------------------------------------------------------------ +This is root node which contains 'manifests' and 'images' as sub-nodes + + +Manifests and Certificate node bindings definition +---------------------------------------------------------------- + +- Manifests node + Description: Container of certificate nodes. + + PROPERTIES + + - compatible: + Usage: required + + Value type: <string> + + Definition: must be "arm, cert-descs" + +- Certificate node + Description: + + Describes certificate properties which are used + during the authentication process. + + PROPERTIES + + - root-certificate + Usage: + + Required for the certificate with no parent. + In other words, certificates which are validated + using root of trust public key. + + Value type: <boolean> + + - image-id + Usage: Required for every certificate with unique id. + + Value type: <u32> + + - parent + Usage: + + It refers to their parent image, which typically contains + information to authenticate the certificate. + This property is required for all non-root certificates. + + This property is not required for root-certificates + as root-certificates are validated using root of trust + public key provided by platform. + + Value type: <phandle> + + - signing-key + Usage: + + This property is used to refer public key node present in + parent certificate node and it is required property for all + non-root certificates which are authenticated using public-key + present in parent certificate. + + This property is not required for root-certificates + as root-certificates are validated using root of trust + public key provided by platform. + + Value type: <phandle> + + - antirollback-counter + Usage: + + This property is used by all certificates which are + protected against rollback attacks using a non-volatile + counter and it is an optional property. + + This property is used to refer one of the non-volatile + counter sub-node present in 'non-volatile counters' node. + + Value type: <phandle> + + + SUBNODES + - Description: + + Hash and public key information present in the certificate + are shown by these nodes. + + - public key node + Description: Provide public key information in the certificate. + + PROPERTIES + + - oid + Usage: + + This property provides the Object ID of public key + provided in the certificate which the help of which + public key information can be extracted. + + Value type: <string> + + - hash node + Description: Provide the hash information in the certificate. + + PROPERTIES + + - oid + Usage: + + This property provides the Object ID of hash provided in + the certificate which the help of which hash information + can be extracted. + + Value type: <string> + +Example: + +.. code:: c + + cot { + manifests { + compatible = "arm, cert-descs” + + trusted-key-cert: trusted-key-cert { + root-certificate; + image-id = <TRUSTED_KEY_CERT_ID>; + antirollback-counter = <&trusted_nv_counter>; + + trusted-world-pk: trusted-world-pk { + oid = TRUSTED_WORLD_PK_OID; + }; + non-trusted-world-pk: non-trusted-world-pk { + oid = NON_TRUSTED_WORLD_PK_OID; + }; + }; + + scp_fw_key_cert: scp_fw_key_cert { + image-id = <SCP_FW_KEY_CERT_ID>; + parent = <&trusted-key-cert>; + signing-key = <&trusted_world_pk>; + antirollback-counter = <&trusted_nv_counter>; + + scp_fw_content_pk: scp_fw_content_pk { + oid = SCP_FW_CONTENT_CERT_PK_OID; + }; + }; + . + . + . + + next-certificate { + + }; + }; + }; + +Images and Image node bindings definition +----------------------------------------- + +- Images node + Description: Container of image nodes + + PROPERTIES + + - compatible: + Usage: required + + Value type: <string> + + Definition: must be "arm, img-descs" + +- Image node + Description: + + Describes image properties which will be used during + authentication process. + + PROPERTIES + + - image-id + Usage: Required for every image with unique id. + + Value type: <u32> + + - parent + Usage: + + Required for every image to provide a reference to + its parent image, which contains the necessary information + to authenticate it. + + Value type: <phandle> + + - hash + Usage: + + Required for all images which are validated using + hash method. This property is used to refer hash + node present in parent certificate node. + + Value type: <phandle> + + Note: + + Currently, all images are validated using 'hash' + method. In future, there may be multiple methods can + be used to validate the image. + +Example: + +.. code:: c + + cot { + images { + compatible = "arm, img-descs"; + + scp_bl2_image { + image-id = <SCP_BL2_IMAGE_ID>; + parent = <&scp_fw_content_cert>; + hash = <&scp_fw_hash>; + }; + + . + . + . + + next-img { + + }; + }; + }; + +non-volatile counter node binding definition +-------------------------------------------- + +- non-volatile counters node + Description: Contains properties for non-volatile counters. + + PROPERTIES + + - compatible: + Usage: required + + Value type: <string> + + Definition: must be "arm, non-volatile-counter" + + - #address-cells + Usage: required + + Value type: <u32> + + Definition: + + Must be set according to address size + of non-volatile counter register + + - #size-cells + Usage: required + + Value type: <u32> + + Definition: must be set to 0 + + SUBNODE + - counters node + Description: Contains various non-volatile counters present in the platform. + + PROPERTIES + - id + Usage: Required for every nv-counter with unique id. + + Value type: <u32> + + - reg + Usage: + + Register base address of non-volatile counter and it is required + property. + + Value type: <u32> + + - oid + Usage: + + This property provides the Object ID of non-volatile counter + provided in the certificate and it is required property. + + Value type: <string> + +Example: +Below is non-volatile counters example for ARM platform + +.. code:: c + + non_volatile_counters: non_volatile_counters { + compatible = "arm, non-volatile-counter"; + #address-cells = <1>; + #size-cells = <0>; + + trusted-nv-counter: trusted_nv_counter { + id = <TRUSTED_NV_CTR_ID>; + reg = <TFW_NVCTR_BASE>; + oid = TRUSTED_FW_NVCOUNTER_OID; + }; + + non_trusted_nv_counter: non_trusted_nv_counter { + id = <NON_TRUSTED_NV_CTR_ID>; + reg = <NTFW_CTR_BASE>; + oid = NON_TRUSTED_FW_NVCOUNTER_OID; + }; + }; + +Future update to chain of trust binding +--------------------------------------- + +This binding document needs to be revisited to generalise some terminologies +which are currently specific to X.509 certificates for e.g. Object IDs. + +*Copyright (c) 2020, Arm Limited. All rights reserved.* diff --git a/docs/components/debugfs-design.rst b/docs/components/debugfs-design.rst index 06916f3d9..253651513 100644 --- a/docs/components/debugfs-design.rst +++ b/docs/components/debugfs-design.rst @@ -15,8 +15,9 @@ Virtual filesystem ------------------ The core functionality lies in a virtual file system based on a 9p file server -interface (`Notes on the Plan 9 Kernel Source`_). The implementation permits -exposing virtual files, firmware drivers, and file blobs. +interface (`Notes on the Plan 9 Kernel Source`_ and +`Linux 9p remote filesystem protocol`_). +The implementation permits exposing virtual files, firmware drivers, and file blobs. Namespace ~~~~~~~~~ @@ -77,10 +78,10 @@ SMC interface ------------- The communication with the 9p layer in BL31 is made through an SMC conduit -(`SMC Calling Convention PDD`_), using a specific SiP Function Id. An NS shared -buffer is used to pass path string parameters, or e.g. to exchange data on a -read operation. Refer to `ARM SiP Services`_ for a description of the SMC -interface. +(`SMC Calling Convention`_), using a specific SiP Function Id. An NS +shared buffer is used to pass path string parameters, or e.g. to exchange +data on a read operation. Refer to :ref:`ARM SiP Services <arm sip services>` +for a description of the SMC interface. Security considerations ----------------------- @@ -114,19 +115,11 @@ The SMC interface is accessible from an NS environment, that is: - a Linux kernel driver running at NS-EL1 - a Linux userspace application through the kernel driver -References ----------- - -.. [#] `SMC Calling Convention PDD`_ -.. [#] `Notes on the Plan 9 Kernel Source`_ -.. [#] `Linux 9p remote filesystem protocol`_ -.. [#] `ARM SiP Services`_ - -------------- -*Copyright (c) 2019, Arm Limited and Contributors. All rights reserved.* +*Copyright (c) 2019-2020, Arm Limited and Contributors. All rights reserved.* -.. _SMC Calling Convention PDD: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ +.. _SMC Calling Convention: https://developer.arm.com/docs/den0028/latest .. _Notes on the Plan 9 Kernel Source: http://lsub.org/who/nemo/9.pdf .. _Linux 9p remote filesystem protocol: https://www.kernel.org/doc/Documentation/filesystems/9p.txt .. _ARM SiP Services: arm-sip-service.rst diff --git a/docs/components/exception-handling.rst b/docs/components/exception-handling.rst index 3f386854f..6f223c675 100644 --- a/docs/components/exception-handling.rst +++ b/docs/components/exception-handling.rst @@ -10,13 +10,9 @@ of the following exceptions when targeted at EL3: - Asynchronous External Aborts |TF-A|'s handling of synchronous ``SMC`` exceptions raised from lower ELs is -described in the `Firmware Design document`__. However, the |EHF| changes the -semantics of `interrupt handling`__ and `synchronous exceptions`__ other than -SMCs. - -.. __: firmware-design.rst#handling-an-smc -.. __: `Interrupt handling`_ -.. __: `Effect on SMC calls`_ +described in the :ref:`Firmware Design document <handling-an-smc>`. However, the +|EHF| changes the semantics of `Interrupt handling`_ and :ref:`synchronous +exceptions <Effect on SMC calls>` other than SMCs. The |EHF| is selected by setting the build option ``EL3_EXCEPTION_HANDLING`` to ``1``, and is only available for AArch64 systems. @@ -77,10 +73,9 @@ On any given system, all of the above handling models may be employed independently depending on platform choice and the nature of the exception received. -.. [#spd] Not to be confused with `Secure Payload Dispatcher`__, which is an - EL3 component that operates in EL3 on behalf of Secure OS. - -.. __: firmware-design.rst#secure-el1-payloads-and-dispatchers +.. [#spd] Not to be confused with :ref:`Secure Payload Dispatcher + <firmware_design_sel1_spd>`, which is an EL3 component that operates in EL3 + on behalf of Secure OS. The role of Exception Handling Framework ---------------------------------------- @@ -139,6 +134,8 @@ unstacked in strictly the reverse order. For interrupts, the GIC ensures this is the case; for non-interrupts, the |EHF| monitors and asserts this. See `Transition of priority levels`_. +.. _interrupt-handling: + Interrupt handling ------------------ @@ -151,15 +148,12 @@ implications: sufficient priority are signalled as FIQs, and therefore will be routed to EL3. As a result, S-EL1 software cannot expect to handle Non-secure interrupts at S-EL1. Essentially, this deprecates the routing mode described - as `CSS=0, TEL3=0`__. - - .. __: interrupt-framework-design.rst#el3-interrupts + as :ref:`CSS=0, TEL3=0 <EL3 interrupts>`. In order for S-EL1 software to handle Non-secure interrupts while having |EHF| enabled, the dispatcher must adopt a model where Non-secure interrupts - are received at EL3, but are then `synchronously`__ handled over to S-EL1. - - .. __: interrupt-framework-design.rst#secure-payload + are received at EL3, but are then :ref:`synchronously <sp-synchronous-int>` + handled over to S-EL1. - On GICv2 systems, it's required that the build option ``GICV2_G0_FOR_EL3`` is set to ``1`` so that *Group 0* interrupts target EL3. @@ -176,6 +170,8 @@ dispatcher may register more than one priority level. Dispatchers are assigned interrupt priority levels in two steps: +.. _Partitioning priority levels: + Partitioning priority levels ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -237,12 +233,11 @@ The text in `Partitioning priority levels`_ only describes how the platform expresses the required levels of priority. It however doesn't choose interrupts nor program the required priority in GIC. -The `Firmware Design guide`__ explains methods for configuring secure -interrupts. |EHF| requires the platform to enumerate interrupt properties (as -opposed to just numbers) of Secure interrupts. The priority of secure interrupts -must match that as determined in the `Partitioning priority levels`_ section above. - -.. __: firmware-design.rst#configuring-secure-interrupts +The :ref:`Firmware Design guide<configuring-secure-interrupts>` explains methods +for configuring secure interrupts. |EHF| requires the platform to enumerate +interrupt properties (as opposed to just numbers) of Secure interrupts. The +priority of secure interrupts must match that as determined in the +`Partitioning priority levels`_ section above. See `Limitations`_, and also refer to `Interrupt handling example`_ for illustration. @@ -281,15 +276,13 @@ The interrupt handler should have the following signature: typedef int (*ehf_handler_t)(uint32_t intr_raw, uint32_t flags, void *handle, void *cookie); -The parameters are as obtained from the top-level `EL3 interrupt handler`__. +The parameters are as obtained from the top-level :ref:`EL3 interrupt handler +<el3-runtime-firmware>`. -.. __: interrupt-framework-design.rst#el3-runtime-firmware - -The `SDEI dispatcher`__, for example, expects the platform to allocate two -different priority levels—``PLAT_SDEI_CRITICAL_PRI``, and -``PLAT_SDEI_NORMAL_PRI``—and registers the same handler to handle both levels. - -.. __: sdei.rst +The :ref:`SDEI dispatcher<SDEI: Software Delegated Exception Interface>`, for +example, expects the platform to allocate two different priority levels— +``PLAT_SDEI_CRITICAL_PRI``, and ``PLAT_SDEI_NORMAL_PRI`` —and registers the +same handler to handle both levels. Interrupt handling example -------------------------- @@ -365,16 +358,16 @@ assign interrupts to fictitious dispatchers: See also the `Build-time flow`_ and the `Run-time flow`_. +.. _Activating and Deactivating priorities: + Activating and Deactivating priorities -------------------------------------- A priority level is said to be *active* when an exception of that priority is being handled: for interrupts, this is implied when the interrupt is -acknowledged; for non-interrupt exceptions, such as SErrors or `SDEI explicit -dispatches`__, this has to be done via calling ``ehf_activate_priority()``. See -`Run-time flow`_. - -.. __: sdei.rst#explicit-dispatch-of-events +acknowledged; for non-interrupt exceptions, such as SErrors or :ref:`SDEI +explicit dispatches <explicit-dispatch-of-events>`, this has to be done via +calling ``ehf_activate_priority()``. See `Run-time flow`_. Conversely, when the dispatcher has reached a logical resolution for the cause of the exception, the corresponding priority level ought to be deactivated. As @@ -453,6 +446,8 @@ calls to these APIs are subject to the following conditions: If these are violated, a panic will result. +.. _Effect on SMC calls: + Effect on SMC calls ------------------- @@ -467,7 +462,7 @@ SMCs from Non-secure world are synchronous exceptions, and are mechanisms for Non-secure world to request Secure services. They're broadly classified as *Fast* or *Yielding* (see `SMCCC`__). -.. __: `http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html` +.. __: https://developer.arm.com/docs/den0028/latest - *Fast* SMCs are atomic from the caller's point of view. I.e., they return to the caller only when the Secure world has finished serving the request. @@ -538,10 +533,8 @@ The following is an example flow for interrupts: interrupts belonging to different dispatchers. #. The |EHF|, during its initialisation, registers a top-level interrupt handler - with the `Interrupt Management Framework`__ for EL3 interrupts. This also - results in setting the routing bits in ``SCR_EL3``. - - .. __: interrupt-framework-design.rst#el3-runtime-firmware + with the :ref:`Interrupt Management Framework<el3-runtime-firmware>` for EL3 + interrupts. This also results in setting the routing bits in ``SCR_EL3``. #. When an interrupt belonging to a dispatcher fires, GIC raises an EL3/Group 0 interrupt, and is taken to EL3. @@ -621,6 +614,6 @@ The |EHF| has the following limitations: -------------- -*Copyright (c) 2018-2019, Arm Limited and Contributors. All rights reserved.* +*Copyright (c) 2018-2020, Arm Limited and Contributors. All rights reserved.* .. _SDEI specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf diff --git a/docs/components/fconf/fconf_properties.rst b/docs/components/fconf/fconf_properties.rst new file mode 100644 index 000000000..5c28a7ae5 --- /dev/null +++ b/docs/components/fconf/fconf_properties.rst @@ -0,0 +1,32 @@ +DTB binding for FCONF properties +================================ + +This document describes the device tree format of |FCONF| properties. These +properties are not related to a specific platform and can be queried from +common code. + +Dynamic configuration +~~~~~~~~~~~~~~~~~~~~~ + +The |FCONF| framework expects a *dtb-registry* node with the following field: + +- compatible [mandatory] + - value type: <string> + - Must be the string "fconf,dyn_cfg-dtb_registry". + +Then a list of subnodes representing a configuration |DTB|, which can be used +by |FCONF|. Each subnode should be named according to the information it +contains, and must be formed with the following fields: + +- load-address [mandatory] + - value type: <u64> + - Physical loading base address of the configuration. + +- max-size [mandatory] + - value type: <u32> + - Maximum size of the configuration. + +- id [mandatory] + - value type: <u32> + - Image ID of the configuration. + diff --git a/docs/components/fconf/index.rst b/docs/components/fconf/index.rst new file mode 100644 index 000000000..902063356 --- /dev/null +++ b/docs/components/fconf/index.rst @@ -0,0 +1,147 @@ +Firmware Configuration Framework +================================ + +This document provides an overview of the |FCONF| framework. + +Introduction +~~~~~~~~~~~~ + +The Firmware CONfiguration Framework (|FCONF|) is an abstraction layer for +platform specific data, allowing a "property" to be queried and a value +retrieved without the requesting entity knowing what backing store is being used +to hold the data. + +It is used to bridge new and old ways of providing platform-specific data. +Today, information like the Chain of Trust is held within several, nested +platform-defined tables. In the future, it may be provided as part of a device +blob, along with the rest of the information about images to load. +Introducing this abstraction layer will make migration easier and will preserve +functionality for platforms that cannot / don't want to use device tree. + +Accessing properties +~~~~~~~~~~~~~~~~~~~~ + +Properties defined in the |FCONF| are grouped around namespaces and +sub-namespaces: a.b.property. +Examples namespace can be: + +- (|TBBR|) Chain of Trust data: tbbr.cot.trusted_boot_fw_cert +- (|TBBR|) dynamic configuration info: tbbr.dyn_config.disable_auth +- Arm io policies: arm.io_policies.bl2_image +- GICv3 properties: hw_config.gicv3_config.gicr_base + +Properties can be accessed with the ``FCONF_GET_PROPERTY(a,b,property)`` macro. + +Defining properties +~~~~~~~~~~~~~~~~~~~ + +Properties composing the |FCONF| have to be stored in C structures. If +properties originate from a different backend source such as a device tree, +then the platform has to provide a ``populate()`` function which essentially +captures the property and stores them into a corresponding |FCONF| based C +structure. + +Such a ``populate()`` function is usually platform specific and is associated +with a specific backend source. For example, a populator function which +captures the hardware topology of the platform from the HW_CONFIG device tree. +Hence each ``populate()`` function must be registered with a specific +``config_type`` identifier. It broadly represents a logical grouping of +configuration properties which is usually a device tree file. + +Example: + - FW_CONFIG: properties related to base address, maximum size and image id + of other DTBs etc. + - TB_FW: properties related to trusted firmware such as IO policies, + mbedtls heap info etc. + - HW_CONFIG: properties related to hardware configuration of the SoC + such as topology, GIC controller, PSCI hooks, CPU ID etc. + +Hence the ``populate()`` callback must be registered to the (|FCONF|) framework +with the ``FCONF_REGISTER_POPULATOR()`` macro. This ensures that the function +would be called inside the generic ``fconf_populate()`` function during +initialization. + +:: + + int fconf_populate_topology(uintptr_t config) + { + /* read hw config dtb and fill soc_topology struct */ + } + + FCONF_REGISTER_POPULATOR(HW_CONFIG, topology, fconf_populate_topology); + +Then, a wrapper has to be provided to match the ``FCONF_GET_PROPERTY()`` macro: + +:: + + /* generic getter */ + #define FCONF_GET_PROPERTY(a,b,property) a##__##b##_getter(property) + + /* my specific getter */ + #define hw_config__topology_getter(prop) soc_topology.prop + +This second level wrapper can be used to remap the ``FCONF_GET_PROPERTY()`` to +anything appropriate: structure, array, function, etc.. + +To ensure a good interpretation of the properties, this documentation must +explain how the properties are described for a specific backend. Refer to the +:ref:`binding-document` section for more information and example. + +Loading the property device tree +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The ``fconf_load_config(image_id)`` must be called to load fw_config and +tb_fw_config devices tree containing the properties' values. This must be done +after the io layer is initialized, as the |DTB| is stored on an external +device (FIP). + +.. uml:: ../../resources/diagrams/plantuml/fconf_bl1_load_config.puml + +Populating the properties +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Once a valid device tree is available, the ``fconf_populate(config)`` function +can be used to fill the C data structure with the data from the config |DTB|. +This function will call all the ``populate()`` callbacks which have been +registered with ``FCONF_REGISTER_POPULATOR()`` as described above. + +.. uml:: ../../resources/diagrams/plantuml/fconf_bl2_populate.puml + +Namespace guidance +~~~~~~~~~~~~~~~~~~ + +As mentioned above, properties are logically grouped around namespaces and +sub-namespaces. The following concepts should be considered when adding new +properties/namespaces. +The framework differentiates two types of properties: + + - Properties used inside common code. + - Properties used inside platform specific code. + +The first category applies to properties being part of the firmware and shared +across multiple platforms. They should be globally accessible and defined +inside the ``lib/fconf`` directory. The namespace must be chosen to reflect the +feature/data abstracted. + +Example: + - |TBBR| related properties: tbbr.cot.bl2_id + - Dynamic configuration information: dyn_cfg.dtb_info.hw_config_id + +The second category should represent the majority of the properties defined +within the framework: Platform specific properties. They must be accessed only +within the platform API and are defined only inside the platform scope. The +namespace must contain the platform name under which the properties defined +belong. + +Example: + - Arm io framework: arm.io_policies.bl31_id + +.. _binding-document: + +Properties binding information +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. toctree:: + :maxdepth: 1 + + fconf_properties diff --git a/docs/components/index.rst b/docs/components/index.rst index f1904c004..ffeef80e6 100644 --- a/docs/components/index.rst +++ b/docs/components/index.rst @@ -8,11 +8,17 @@ Components spd/index arm-sip-service + debugfs-design exception-handling + fconf/index firmware-update + measured_boot/index platform-interrupt-controller-API ras romlib-design sdei - secure-partition-manager-design + secure-partition-manager + secure-partition-manager-mm + psa-ffa-manifest-binding xlat-tables-lib-v2-design + cot-binding diff --git a/docs/components/measured_boot/event_log.rst b/docs/components/measured_boot/event_log.rst new file mode 100644 index 000000000..5347dcc19 --- /dev/null +++ b/docs/components/measured_boot/event_log.rst @@ -0,0 +1,35 @@ +DTB binding for Event Log properties +==================================== + +This document describes the device tree format of Event Log properties. +These properties are not related to a specific platform and can be queried +from common code. + +Dynamic configuration for Event Log +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Measured Boot driver expects a *tpm_event_log* node with the following field +in 'nt_fw_config' and 'tsp_fw_config' DTS files: + +- compatible [mandatory] + - value type: <string> + - Must be the string "arm,tpm_event_log". + +Then a list of properties representing Event Log configuration, which +can be used by Measured Boot driver. Each property is named according +to the information it contains: + +- tpm_event_log_sm_addr [fvp_nt_fw_config.dts with OP-TEE] + - value type: <u64> + - Event Log base address in secure memory. + +Note. Currently OP-TEE does not support reading DTBs from Secure memory +and this property should be removed when this feature is supported. + +- tpm_event_log_addr [mandatory] + - value type: <u64> + - Event Log base address in non-secure memory. + +- tpm_event_log_size [mandatory] + - value type: <u32> + - Event Log size. diff --git a/docs/components/measured_boot/index.rst b/docs/components/measured_boot/index.rst new file mode 100644 index 000000000..e7f2634bb --- /dev/null +++ b/docs/components/measured_boot/index.rst @@ -0,0 +1,12 @@ +Measured Boot Driver (MBD) +========================== + +.. _measured-boot-document: + +Properties binding information +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +.. toctree:: + :maxdepth: 1 + + event_log diff --git a/docs/components/platform-interrupt-controller-API.rst b/docs/components/platform-interrupt-controller-API.rst index 9d02f45c0..069c87b84 100644 --- a/docs/components/platform-interrupt-controller-API.rst +++ b/docs/components/platform-interrupt-controller-API.rst @@ -286,6 +286,8 @@ inserts to order memory updates before updating mask, then writes to the GIC *Priority Mask Register*, and make sure memory updates are visible before potential trigger due to mask update. +.. _plat_ic_get_interrupt_id: + Function: unsigned int plat_ic_get_interrupt_id(unsigned int raw); [optional] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/components/psa-ffa-manifest-binding.rst b/docs/components/psa-ffa-manifest-binding.rst new file mode 100644 index 000000000..af79074af --- /dev/null +++ b/docs/components/psa-ffa-manifest-binding.rst @@ -0,0 +1,247 @@ +PSA FF-A manifest binding to device tree +======================================== + +This document defines the nodes and properties used to define a partition, +according to the PSA FF-A specification. + +Version 1.0 +----------- + +Partition Properties +^^^^^^^^^^^^^^^^^^^^ + +- compatible [mandatory] + - value type: <string> + - Must be the string "arm,ffa-manifest-X.Y" which specifies the major and + minor versions of the device tree binding for the FFA manifest represented + by this node. The minor number is incremented if the binding changes in a + backwards compatible manner. + + - X is an integer representing the major version number of this document. + - Y is an integer representing the minor version number of this document. + +- ffa-version [mandatory] + - value type: <u32> + - Must be two 16 bits values (X, Y), concatenated as 31:16 -> X, + 15:0 -> Y, where: + + - X is the major version of PSA-FF-A expected by the partition at the FFA + instance it will execute. + - Y is the minor version of PSA-FF-A expected by the partition at the FFA + instance it will execute. + +- uuid [mandatory] + - value type: <prop-encoded-array> + - An array consisting of 4 <u32> values, identifying the UUID of the service + implemented by this partition. The UUID format is described in RFC 4122. + +- id + - value type: <u32> + - Pre-allocated partition ID. + +- auxiliary-id + - value type: <u32> + - Pre-allocated ID that could be used in memory management transactions. + +- description + - value type: <string> + - Name of the partition e.g. for debugging purposes. + +- execution-ctx-count [mandatory] + - value type: <u32> + - Number of vCPUs that a VM or SP wants to instantiate. + + - In the absence of virtualization, this is the number of execution + contexts that a partition implements. + - If value of this field = 1 and number of PEs > 1 then the partition is + treated as UP & migrate capable. + - If the value of this field > 1 then the partition is treated as a MP + capable partition irrespective of the number of PEs. + +- exception-level [mandatory] + - value type: <u32> + - The target exception level for the partition: + + - 0x0: EL1 + - 0x1: S_EL0 + - 0x2: S_EL1 + +- execution-state [mandatory] + - value type: <u32> + - The target execution state of the partition: + + - 0: AArch64 + - 1: AArch32 + +- load-address + - value type: <u64> + - Physical base address of the partition in memory. Absence of this field + indicates that the partition is position independent and can be loaded at + any address chosen at boot time. + +- entrypoint-offset + - value type: <u64> + - Offset from the base of the partition's binary image to the entry point of + the partition. Absence of this field indicates that the entry point is at + offset 0x0 from the base of the partition's binary. + +- xlat-granule [mandatory] + - value type: <u32> + - Translation granule used with the partition: + + - 0x0: 4k + - 0x1: 16k + - 0x2: 64k + +- boot-order + - value type: <u32> + - A unique number amongst all partitions that specifies if this partition + must be booted before others. The partition with the smaller number will be + booted first. + +- rx-tx-buffer + - value type: "memory-regions" node + - Specific "memory-regions" nodes that describe the RX/TX buffers expected + by the partition. + The "compatible" must be the string "arm,ffa-manifest-rx_tx-buffer". + +- messaging-method [mandatory] + - value type: <u32> + - Specifies which messaging methods are supported by the partition: + + - 0x0: direct messaging method + - 0x1: indirect messaging method + - 0x2: both direct and indirect messaging methods + +- has-primary-scheduler + - value type: <empty> + - Presence of this field indicates that the partition implements the primary + scheduler. If so, run-time EL must be EL1. + +- run-time-model + - value type: <u32> + - Run time model that the SPM must enforce for this SP: + + - 0x0: Run to completion + - 0x1: Preemptible + +- time-slice-mem + - value type: <empty> + - Presence of this field indicates that the partition doesn't expect the + partition manager to time slice long running memory management functions. + +- gp-register-num + - value type: <u32> + - Presence of this field indicates that the partition expects the + ffa_init_info structure to be passed in via the specified general purpose + register. + The field specifies the general purpose register number but not its width. + The width is derived from the partition's execution state, as specified in + the partition properties. For example, if the number value is 1 then the + general-purpose register used will be x1 in AArch64 state and w1 in AArch32 + state. + +- stream-endpoint-ids + - value type: <prop-encoded-array> + - List of <u32> tuples, identifying the IDs this partition is acting as + proxy for. + +Memory Regions +-------------- + +- compatible [mandatory] + - value type: <string> + - Must be the string "arm,ffa-manifest-memory-regions". + +- description + - value type: <string> + - Name of the memory region e.g. for debugging purposes. + +- pages-count [mandatory] + - value type: <u32> + - Count of pages of memory region as a multiple of the translation granule + size + +- attributes [mandatory] + - value type: <u32> + - Mapping modes: ORed to get required permission + + - 0x1: Read + - 0x2: Write + - 0x4: Execute + +- base-address + - value type: <u64> + - Base address of the region. The address must be aligned to the translation + granule size. + The address given may be a Physical Address (PA), Virtual Address (VA), or + Intermediate Physical Address (IPA). Refer to the FFA specification for + more information on the restrictions around the address type. + If the base address is omitted then the partition manager must map a memory + region of the specified size into the partition's translation regime and + then communicate the region properties (including the base address chosen + by the partition manager) to the partition. + +Device Regions +-------------- + +- compatible [mandatory] + - value type: <string> + - Must be the string "arm,ffa-manifest-device-regions". + +- description + - value type: <string> + - Name of the device region e.g. for debugging purposes. + +- reg [mandatory] + - value type: <prop-encoded-array> + - A (address, num-pages) pair describing the device, where: + + - address: The physical base address <u64> value of the device MMIO + region. + - num-pages: The <u32> number of pages of the region. The total size of + the region is this value multiplied by the translation granule size. + +- attributes [mandatory] + - value type: <u32> + - Mapping modes: ORed to get required permission + + - 0x1: Read + - 0x2: Write + - 0x4: Execute + +- smmu-id + - value type: <u32> + - On systems with multiple System Memory Management Units (SMMUs) this + identifier is used to inform the partition manager which SMMU the device is + upstream of. If the field is omitted then it is assumed that the device is + not upstream of any SMMU. + +- stream-ids + - value type: <prop-encoded-array> + - A list of (id, mem-manage) pair, where: + + - id: A unique <u32> value amongst all devices assigned to the partition. + +- interrupts [mandatory] + - value type: <prop-encoded-array> + - A list of (id, attributes) pair describing the device interrupts, where: + + - id: The <u32> interrupt IDs. + - attributes: A <u32> value, + containing the attributes for each interrupt ID: + + - Interrupt type: SPI, PPI, SGI + - Interrupt configuration: Edge triggered, Level triggered + - Interrupt security state: Secure, Non-secure + - Interrupt priority value + - Target execution context/vCPU for each SPI + +- exclusive-access + - value type: <empty> + - Presence of this field implies that this endpoint must be granted exclusive + access and ownership of this device's MMIO region. + +-------------- + +*Copyright (c) 2019-2020, Arm Limited and Contributors. All rights reserved.* diff --git a/docs/components/ras.rst b/docs/components/ras.rst index 3d81f17e9..02207d8b7 100644 --- a/docs/components/ras.rst +++ b/docs/components/ras.rst @@ -9,10 +9,8 @@ In conjunction with the |EHF|, support for RAS extension enables firmware-first paradigm for handling platform errors: exceptions resulting from errors are routed to and handled in EL3. Said errors are Synchronous External Abort (SEA), Asynchronous External Abort (signalled as SErrors), Fault Handling and Error -Recovery interrupts. The |EHF| document mentions various `error handling -use-cases`__. - -.. __: exception-handling.rst#delegation-use-cases +Recovery interrupts. The |EHF| document mentions various :ref:`error handling +use-cases <delegation-use-cases>` . For the description of Arm RAS extensions, Standard Error Records, and the precise definition of RAS terminology, please refer to the Arm Architecture @@ -32,7 +30,8 @@ introduced by the RAS extensions. The build option ``RAS_EXTENSION`` when set to ``1`` includes the RAS in run time firmware; ``EL3_EXCEPTION_HANDLING`` and ``HANDLE_EA_EL3_FIRST`` must also -be set ``1``. +be set ``1``. ``RAS_TRAP_LOWER_EL_ERR_ACCESS`` controls the access to the RAS +error record registers from lower ELs. .. _ras-figure: @@ -45,9 +44,7 @@ Platform APIs The RAS framework allows the platform to define handlers for External Abort, Uncontainable Errors, Double Fault, and errors rising from EL3 execution. Please -refer to the porting guide for the `RAS platform API descriptions`__. - -.. __: ../getting_started/porting-guide.rst#external-abort-handling-and-ras-support +refer to :ref:`RAS Porting Guide <External Abort handling and RAS Support>`. Registering RAS error records ----------------------------- @@ -113,9 +110,8 @@ The error handler must have the following prototype: The ``data`` constant parameter describes the various properties of the error, including the reason for the error, exception syndrome, and also ``flags``, -``cookie``, and ``handle`` parameters from the `top-level exception handler`__. - -.. __: interrupt-framework-design.rst#el3-interrupts +``cookie``, and ``handle`` parameters from the :ref:`top-level exception handler +<EL3 interrupts>`. The platform is expected populate an array using the macros above, and register the it with the RAS framework using the macro ``REGISTER_ERR_RECORD_INFO()``, @@ -228,21 +224,17 @@ Interaction with Exception Handling Framework As mentioned in earlier sections, RAS framework interacts with the |EHF| to arbitrate handling of RAS exceptions with others that are routed to EL3. This -means that the platform must partition a `priority level`__ for handling RAS -exceptions. The platform must then define the macro ``PLAT_RAS_PRI`` to the -priority level used for RAS exceptions. Platforms would typically want to -allocate the highest secure priority for RAS handling. - -.. __: exception-handling.rst#partitioning-priority-levels - -Handling of both `interrupt`__ and `non-interrupt`__ exceptions follow the -sequences outlined in the |EHF| documentation. I.e., for interrupts, the -priority management is implicit; but for non-interrupt exceptions, they're -explicit using `EHF APIs`__. - -.. __: exception-handling.rst#interrupt-flow -.. __: exception-handling.rst#non-interrupt-flow -.. __: exception-handling.rst#activating-and-deactivating-priorities +means that the platform must partition a :ref:`priority level <Partitioning +priority levels>` for handling RAS exceptions. The platform must then define +the macro ``PLAT_RAS_PRI`` to the priority level used for RAS exceptions. +Platforms would typically want to allocate the highest secure priority for +RAS handling. + +Handling of both :ref:`interrupt <interrupt-flow>` and :ref:`non-interrupt +<non-interrupt-flow>` exceptions follow the sequences outlined in the |EHF| +documentation. I.e., for interrupts, the priority management is implicit; but +for non-interrupt exceptions, they're explicit using :ref:`EHF APIs +<Activating and Deactivating priorities>`. -------------- diff --git a/docs/components/sdei.rst b/docs/components/sdei.rst index c5275a0b7..60259c830 100644 --- a/docs/components/sdei.rst +++ b/docs/components/sdei.rst @@ -205,6 +205,8 @@ will only allow SDEI calls to be made from: See the function ``sdei_client_el()`` in ``sdei_private.h``. +.. _explicit-dispatch-of-events: + Explicit dispatch of events --------------------------- diff --git a/docs/components/secure-partition-manager-design.rst b/docs/components/secure-partition-manager-mm.rst index 52b1c03e8..d53290102 100644 --- a/docs/components/secure-partition-manager-design.rst +++ b/docs/components/secure-partition-manager-mm.rst @@ -1,5 +1,20 @@ -Secure Partition Manager -************************ +Secure Partition Manager (MM) +***************************** + +Foreword +======== + +Two implementations of a Secure Partition Manager co-exist in the TF-A codebase: + +- SPM based on the PSA FF-A specification (:ref:`Secure Partition Manager`). +- SPM based on the MM interface. + +Both implementations differ in their architectures and only one can be selected +at build time. + +This document describes the latter implementation where the Secure Partition Manager +resides at EL3 and management services run from isolated Secure Partitions at S-EL0. +The communication protocol is established through the Management Mode (MM) interface. Background ========== @@ -807,13 +822,13 @@ Error Codes -------------- -*Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.* +*Copyright (c) 2017-2020, Arm Limited and Contributors. All rights reserved.* .. _Armv8-A ARM: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile .. _instructions in the EDK2 repository: https://github.com/tianocore/edk2-staging/blob/AArch64StandaloneMm/HowtoBuild.MD .. _Management Mode Interface Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf .. _SDEI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf -.. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf +.. _SMC Calling Convention: https://developer.arm.com/docs/den0028/latest .. |Image 1| image:: ../resources/diagrams/secure_sw_stack_tos.png .. |Image 2| image:: ../resources/diagrams/secure_sw_stack_sp.png diff --git a/docs/components/secure-partition-manager.rst b/docs/components/secure-partition-manager.rst new file mode 100644 index 000000000..9a65e6400 --- /dev/null +++ b/docs/components/secure-partition-manager.rst @@ -0,0 +1,873 @@ +Secure Partition Manager +************************ + +.. contents:: + +Acronyms +======== + ++--------+-----------------------------------+ +| DTB | Device Tree Blob | ++--------+-----------------------------------+ +| DTS | Device Tree Source | ++--------+-----------------------------------+ +| EC | Execution Context | ++--------+-----------------------------------+ +| FIP | Firmware Image Package | ++--------+-----------------------------------+ +| FF-A | Firmware Framework for A-class | ++--------+-----------------------------------+ +| IPA | Intermediate Physical Address | ++--------+-----------------------------------+ +| NWd | Normal World | ++--------+-----------------------------------+ +| ODM | Original Design Manufacturer | ++--------+-----------------------------------+ +| OEM | Original Equipment Manufacturer | ++--------+-----------------------------------+ +| PA | Physical Address | ++--------+-----------------------------------+ +| PE | Processing Element | ++--------+-----------------------------------+ +| PVM | Primary VM | ++--------+-----------------------------------+ +| PSA | Platform Security Architecture | ++--------+-----------------------------------+ +| SP | Secure Partition | ++--------+-----------------------------------+ +| SPM | Secure Partition Manager | ++--------+-----------------------------------+ +| SPMC | SPM Core | ++--------+-----------------------------------+ +| SPMD | SPM Dispatcher | ++--------+-----------------------------------+ +| SiP | Silicon Provider | ++--------+-----------------------------------+ +| SWd | Secure World | ++--------+-----------------------------------+ +| TLV | Tag-Length-Value | ++--------+-----------------------------------+ +| TOS | Trusted Operating System | ++--------+-----------------------------------+ +| VM | Virtual Machine | ++--------+-----------------------------------+ + +Foreword +======== + +Two implementations of a Secure Partition Manager co-exist in the TF-A codebase: + +- SPM based on the PSA FF-A specification `[1]`_. +- SPM based on the MM interface to communicate with an S-EL0 partition `[2]`_. + +Both implementations differ in their architectures and only one can be selected +at build time. + +This document: + +- describes the PSA FF-A implementation where the Secure Partition Manager + resides at EL3 and S-EL2 (or EL3 and S-EL1). +- is not an architecture specification and it might provide assumptions + on sections mandated as implementation-defined in the specification. +- covers the implications to TF-A used as a bootloader, and Hafnium + used as a reference code base for an S-EL2 secure firmware on + platforms implementing Armv8.4-SecEL2. + +Terminology +----------- + +- Hypervisor refers to the NS-EL2 component managing Virtual Machines (or + partitions) in the Normal World. +- SPMC refers to the S-EL2 component managing Virtual Machines (or Secure + Partitions) in the Secure World when Armv8.4-SecEL2 extension is implemented. +- Alternatively, SPMC can refer to an S-EL1 component, itself being a Secure + Partition and implementing the FF-A ABI on pre-Armv8.4 platforms. +- VM refers to a Normal World Virtual Machine managed by an Hypervisor. +- SP refers to a Secure World "Virtual Machine" managed by the SPMC component. + +Support for legacy platforms +---------------------------- + +In the implementation, the SPM is split into SPMD and SPMC components +(although not strictly mandated by the specification). SPMD is located +at EL3 and principally relays FF-A messages from NWd (Hypervisor or OS +kernel) to SPMC located either at S-EL1 or S-EL2. + +Hence TF-A must support both cases where SPMC is either located at: + +- S-EL1 supporting pre-Armv8.4 platforms. SPMD conveys FF-A protocol + from EL3 to S-EL1. +- S-EL2 supporting platforms implementing Armv8.4-SecEL2 extension. + SPMD conveys FF-A protocol from EL3 to S-EL2. + +The same SPMD component is used to support both configurations. The SPMC +execution level is a build time choice. + +Sample reference stack +====================== + +The following diagram illustrates a possible configuration with SPMD and SPMC, +one or multiple Secure Partitions, with or without an optional Hypervisor: + +.. image:: ../resources/diagrams/ff-a-spm-sel2.png + +TF-A build options +================== + +The following TF-A build options are provisioned: + +- **SPD=spmd**: this option selects the SPMD component to relay FF-A + protocol from NWd to SWd back and forth. It is not possible to + enable another Secure Payload Dispatcher when this option is chosen. +- **SPMD_SPM_AT_SEL2**: this option adjusts the SPMC execution + level to being S-EL1 or S-EL2. It defaults to enabled (value 1) when + SPD=spmd is chosen. +- **CTX_INCLUDE_EL2_REGS**: this option permits saving (resp. + restoring) the EL2 system register context before entering (resp. + after leaving) the SPMC. It is mandatory when ``SPMD_SPM_AT_SEL2`` is + enabled. The context save/restore routine and exhaustive list of + registers is visible at `[4]`_. +- **SP_LAYOUT_FILE**: this option provides a text description file + providing paths to SP binary images and DTS format manifests + (see `Specifying partition binary image and DT`_). It + is required when ``SPMD_SPM_AT_SEL2`` is enabled hence when multiple + secure partitions are to be loaded on behalf of SPMC. + ++------------------------------+----------------------+------------------+ +| | CTX_INCLUDE_EL2_REGS | SPMD_SPM_AT_SEL2 | ++------------------------------+----------------------+------------------+ +| SPMC at S-EL1 (e.g. OP-TEE) | 0 | 0 | ++------------------------------+----------------------+------------------+ +| SPMC at S-EL2 (e.g. Hafnium) | 1 | 1 (default when | +| | | SPD=spmd) | ++------------------------------+----------------------+------------------+ + +Other combinations of such build options either break the build or are not +supported. + +Note, the ``CTX_INCLUDE_EL2_REGS`` option provides the generic support for +barely saving/restoring EL2 registers from an Arm arch perspective. As such +it is decoupled from the ``SPD=spmd`` option. + +BL32 option is re-purposed to specify the SPMC image. It can specify either the +Hafnium binary path (built for the secure world) or the path to a TEE binary +implementing the FF-A protocol. + +BL33 option can specify either: + +- the TFTF binary or +- the Hafnium binary path (built for the normal world) if VMs were loaded by + TF-A beforehand or +- a minimal loader performing the loading of VMs and Hafnium. + +Sample TF-A build command line when SPMC is located at S-EL1 +(typically pre-Armv8.4): + +.. code:: shell + + make \ + CROSS_COMPILE=aarch64-none-elf- \ + SPD=spmd \ + SPMD_SPM_AT_SEL2=0 \ + BL32=<path-to-tee-binary> \ + BL33=<path-to-nwd-binary> \ + PLAT=fvp \ + all fip + +Sample TF-A build command line for an Armv8.4-SecEL2 enabled system +where SPMC is located at S-EL2: + +.. code:: shell + + make \ + CROSS_COMPILE=aarch64-none-elf- \ + SPD=spmd \ + CTX_INCLUDE_EL2_REGS=1 \ + ARM_ARCH_MINOR=4 \ + BL32=<path-to-swd-hafnium-binary> + BL33=<path-to-nwd-binary> \ + SP_LAYOUT_FILE=sp_layout.json \ + PLAT=fvp \ + all fip + +Build options to enable secure boot: + +.. code:: shell + + make \ + CROSS_COMPILE=aarch64-none-elf- \ + SPD=spmd \ + CTX_INCLUDE_EL2_REGS=1 \ + ARM_ARCH_MINOR=4 \ + BL32=<path-to-swd-hafnium-binary> + BL33=<path-to-nwd-binary> \ + SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json \ + MBEDTLS_DIR=<path-to-mbedtls-lib> \ + TRUSTED_BOARD_BOOT=1 \ + COT=dualroot \ + ARM_ROTPK_LOCATION=devel_rsa \ + ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem \ + GENERATE_COT=1 \ + PLAT=fvp \ + all fip + +Boot process +============ + +Loading Hafnium and Secure Partitions in the secure world +--------------------------------------------------------- + +The Hafnium implementation in normal world requires VMs to be loaded in +memory prior to booting. The mechanism upon which VMs are loaded and +exposed to Hafnium are either: + +- by supplying a ramdisk image where VM images are concatenated (1) +- or by providing VM load addresses within Hafnium manifest (2) + +TF-A is the bootlader for the Hafnium and SPs in the secure world. TF-A +does not provide tooling or libraries manipulating ramdisks as required +by (1). Thus BL2 loads SPs payloads independently. +SPs may be signed by different parties (SiP, OEM/ODM, TOS vendor, etc.). +Thus they are supplied as distinct “self-contained” signed entities within +the FIP flash image. The FIP image itself is not signed hence providing +ability to upgrade SPs in the field. + +Booting through TF-A +-------------------- + +SP manifests +~~~~~~~~~~~~ + +An SP manifest describes SP attributes as defined in `[1]`_ +section 3.1 (partition manifest at virtual FF-A instance) in DTS text format. It +is represented as a single file associated with the SP. A sample is +provided by `[5]`_. A binding document is provided by `[6]`_. + +Secure Partition packages +~~~~~~~~~~~~~~~~~~~~~~~~~ + +Secure Partitions are bundled as independent package files consisting +of: + +- a header +- a DTB +- an image payload + +The header starts with a magic value and offset values to SP DTB and +image payload. Each SP package is loaded independently by BL2 loader +and verified for authenticity and integrity. + +The SP package identified by its UUID (matching FF-A uuid) is inserted +as a single entry into the FIP at end of the TF-A build flow as shown: + +.. code:: shell + + Trusted Boot Firmware BL2: offset=0x1F0, size=0x8AE1, cmdline="--tb-fw" + EL3 Runtime Firmware BL31: offset=0x8CD1, size=0x13000, cmdline="--soc-fw" + Secure Payload BL32 (Trusted OS): offset=0x1BCD1, size=0x15270, cmdline="--tos-fw" + Non-Trusted Firmware BL33: offset=0x30F41, size=0x92E0, cmdline="--nt-fw" + HW_CONFIG: offset=0x3A221, size=0x2348, cmdline="--hw-config" + TB_FW_CONFIG: offset=0x3C569, size=0x37A, cmdline="--tb-fw-config" + SOC_FW_CONFIG: offset=0x3C8E3, size=0x48, cmdline="--soc-fw-config" + TOS_FW_CONFIG: offset=0x3C92B, size=0x427, cmdline="--tos-fw-config" + NT_FW_CONFIG: offset=0x3CD52, size=0x48, cmdline="--nt-fw-config" + B4B5671E-4A90-4FE1-B81F-FB13DAE1DACB: offset=0x3CD9A, size=0xC168, cmdline="--blob" + D1582309-F023-47B9-827C-4464F5578FC8: offset=0x48F02, size=0xC168, cmdline="--blob" + +.. uml:: ../resources/diagrams/plantuml/fip-secure-partitions.puml + +Specifying partition binary image and DT +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +A description file (json format) is passed to the build flow specifying +paths to the SP binary image and associated DTS partition manifest file. +The latter is going through the dtc compiler to generate the dtb fed into +the SP package. +This file also specifies the owner of the SP, which is an optional field and +identifies the signing domain in case of dualroot CoT. +The possible owner of an SP could either be Silicon Provider or Platform, and +the corresponding "owner" field value could either be "SiP" or "Plat". +In absence of "owner" field, it defaults to "SiP". + +.. code:: shell + + { + "tee1" : { + "image": "tee1.bin", + "pm": "tee1.dts", + "owner": "SiP" + }, + + "tee2" : { + "image": "tee2.bin", + "pm": "tee2.dts", + "owner": "Plat" + } + } + +SPMC manifest +~~~~~~~~~~~~~ + +This manifest contains an SPMC attributes node consumed by SPMD at boot time. It +is implementing the description from `[1]`_ section 3.2 (SP manifest at physical +FF-A instance). The SP manifest at physical FF-A instance is used by the SPMD to +setup a SP that co-resides with the SPMC and executes at S-EL1 or Secure +Supervisor mode. + +In this implementation its usage is extended to the secure physical FF-A +instance where SPMC executes at S-EL2. + +.. code:: shell + + attribute { + spmc_id = <0x8000>; + maj_ver = <0x1>; + min_ver = <0x0>; + exec_state = <0x0>; + load_address = <0x0 0x6000000>; + entrypoint = <0x0 0x6000000>; + binary_size = <0x60000>; + }; + +- *spmc_id* defines the endpoint ID value that SPMC can query through + ``FFA_ID_GET``. +- *maj_ver/min_ver*. SPMD checks provided version versus its internal + version and aborts if not matching. +- *exec_state* defines SPMC execution state (can be AArch64 for + Hafnium, or AArch64/AArch32 for OP-TEE at S-EL1). +- *load_address* and *binary_size* are mostly used to verify secondary + entry points fit into the loaded binary image. +- *entrypoint* defines the cold boot primary core entry point used by + SPMD (currently matches ``BL32_BASE``) + +Other nodes in the manifest are consumed by Hafnium in the secure world. +A sample can be found at [7]: + +- The *chosen* node is currently unused in SWd. It is meant for NWd to + specify the init ramdisk image. +- The *hypervisor* node describes SPs. *is_ffa_partition* boolean + attribute indicates an SP. Load-addr field specifies the load address + at which TF-A loaded the SP package. +- *cpus* node provide the platform topology and allows MPIDR to VMPIDR + mapping. Notice with current implementation primary cpu is declared + first, then secondary cpus must be declared in reverse order. + +SPMC boot +~~~~~~~~~ + +The SPMC is loaded by BL2 as the BL32 image. + +The SPMC manifest is loaded by BL2 as the ``TOS_FW_CONFIG`` image. + +BL2 passes the SPMC manifest address to BL31 through a register. + +BL31(SPMD) runs from primary core, initializes the core contexts and +launches BL32 passing the SPMC manifest address through a register. + +Loading of SPs +~~~~~~~~~~~~~~ + +.. uml:: ../resources/diagrams/plantuml/bl2-loading-sp.puml + + +Notice this boot flow is an implementation sample on Arm's FVP platform. Platforms +not using FW_CONFIG would adjust to a different implementation. + +Secure boot +~~~~~~~~~~~ + +The SP content certificate is inserted as a separate FIP item so that BL2 loads SPMC, +SPMC manifest and Secure Partitions and verifies them for authenticity and integrity. +Refer to TBBR specification `[3]`_. + +The multiple-signing domain feature (in current state dual signing domain) allows +the use of two root keys namely S-ROTPK and NS-ROTPK (see `[8]`_): + +- SPMC (BL32) and SPMC manifest are signed by the SiP using the S-ROTPK. +- BL33 may be signed by the OEM using NS-ROTPK. +- An SP may be signed either by SiP (using S-ROTPK) or by OEM (using NS-ROTPK). + +Longer term multiple signing domain will allow additional signing keys, e.g. +if SPs originate from different parties. + +See `TF-A build options`_ for a sample build command line. + +Hafnium in the secure world +=========================== + +**NOTE: this section is work in progress. Descriptions and implementation choices +are subject to evolve.** + +General considerations +---------------------- + +Build platform for the secure world +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The implementation might add specific code parts only relevant to the +secure world. Such code parts might be isolated into different files +and/or conditional code enclosed by a ``SECURE_WORLD`` macro. + +Secure Partitions CPU scheduling +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the normal world, VMs are scheduled by the FFA_RUN ABI invoked from the +primary scheduler (in the primary VM), or by a direct message request or +response. + +With the FF-A EAC specification, Secure Partitions are scheduled by direct +message invocations from a NWd VM or another SP. + +Platform topology +~~~~~~~~~~~~~~~~~ + +As stated in `[1]`_ section 4.4.1 the SPMC implementation assumes the +following SP types: + +- Pinned MP SPs: an Execution Context id matches a physical PE id. MP + SPs must implement the same number of ECs as the number of PEs in the + platform. Hence the *execution-ctx-count* as defined by + `[1]`_ (or NWd-Hafnium *vcpu_count*) can only take the + value of one or the number of physical PEs. +- Migratable UP SPs: a single execution context can run and be migrated + on any physical PE. It declares a single EC in its SP manifest. An UP + SP can receive a direct message request on any physical core. + +Usage of PSCI services in the secure world +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +- The normal world Hypervisor (optional) or OS kernel issues PSCI service + invocations e.g. to request PSCI version, wake-up a secondary core, or request + core suspend. This happens at the non-secure physical FF-A instance. In the + example case of Hafnium in the normal world, it boots on the primary core and + one of the first initialization step is to request the PSCI version. It then + launches the primary VM. The primary VM upon initializing performs PSCI service + calls (at non-secure virtual FF-A instance) which are trapped by the + Hypervisor. Invocation from OS Kernel ends straight at EL3. The PVM issues + ``PSCI_CPU_ON`` service calls to wake-up secondary cores by passing an + ``MPIDR``, entry point address and a CPU context address. The EL3 PSCI layer + then performs an exception return to the secondary core entry point on the + targeted core. Other PSCI calls can happen at run-time from the PVM e.g. to + request core suspend. +- In the existing TF-A PSCI standard library, PSCI service calls are filtered at + EL3 to only originate from the NWd. Thus concerning the SPMC (at secure + physical FF-A instance) the PSCI service invocations cannot happen as in the + normal world. For example, a ``PSCI_CPU_ON`` service invocation from the SPMC + does not reach the PSCI layer. + +Parsing SP partition manifests +------------------------------ + +Hafnium must be able to consume SP manifests as defined in +`[1]`_ section 3.1, at least for the mandatory fields. + +The SP manifest may contain memory and device regions nodes. + +- Memory regions shall be mapped in the SP Stage-2 translation regime at + load time. A memory region node can specify RX/TX buffer regions in which + case it is not necessary for an SP to explicitly call the ``FFA_RXTX_MAP`` + service. +- Device regions shall be mapped in SP Stage-2 translation regime as + peripherals and possibly allocate additional resources (e.g. interrupts) + +Base addresses for memory and device region nodes are IPAs provided SPMC +identity maps IPAs to PAs within SP Stage-2 translation regime. + +Note: currently both VTTBR_EL2 and VSTTBR_EL2 resolve to the same set of page +tables. It is still open whether two sets of page tables shall be provided per +SP. The memory region node as defined in the spec (section 3.1 Table 10) +provides a memory security attribute hinting to map either to the secure or +non-secure stage-2 table. + +Passing boot data to the SP +--------------------------- + +`[1]`_ Section 3.4.2 “Protocol for passing data” defines a +method to passing boot data to SPs (not currently implemented). + +Provided that the whole Secure Partition package image (see `Secure +Partition packages`_) is mapped to the SP's secure Stage-2 translation +regime, an SP can access its own manifest DTB blob and extract its partition +manifest properties. + +SP Boot order +------------- + +SP manifests provide an optional boot order attribute meant to resolve +dependencies such as an SP providing a service required to properly boot +another SP. + +Boot phases +----------- + +Primary core boot-up +~~~~~~~~~~~~~~~~~~~~ + +The SPMC performs its platform initializations then loads and creates +secure partitions based on SP packages and manifests. Then each secure +partition is launched in sequence (see `SP Boot order`_) on their primary +Execution Context. + +Notice the primary physical core may not be core 0. Hence if the primary +core linear id is N, the 1:1 mapping requires MP SPs are launched using +EC[N] on PE[N] (see `Platform topology`_). + +The SP's primary Execution Context (or the EC used when the partition is booted) +exits through ``FFA_MSG_WAIT`` to indicate successful initialization. + +Secondary physical core boot-up +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Upon boot-up, the SPMC running on the primary core performs +implementation-defined SPMD service calls at secure physical FF-A instance +to register the secondary physical cores entry points and context information: + +- This is done through a direct message request invocation to the SPMD + (``SET_ENTRY_POINT``). This service call does not wake-up the targeted + core immediately. The secondary core is woken up later by a NWd + ``PSCI_CPU_ON`` service invocation. A notification is passed from EL3 + PSCI layer to the SPMD, and then to SPMC through an implementation-defined + interface. +- The SPMC/SPMD interface can consist of FF-A direct message requests/responses + transporting PM events. + +If there is no Hypervisor in the normal world, the OS Kernel issues +``PSCI_CPU_ON`` calls that are directly trapped to EL3. + +When a secondary physical core wakes-up the SPMD notifies the SPMC which updates +its internal states reflecting current physical core is being turned on. +It might then return straight to the SPMD and then to the NWd. + +*(under discussion)* There may be possibility that an SP registers "PM events" +(during primary EC boot stage) through an ad-hoc interface. Such events would +be relayed by SPMC to one or more registered SPs on need basis +(see `Power management`_). + +Secondary virtual core boot-up +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In the example case where Hafnium exists in the normal world, secondary VMs +issue a ``PSCI_CPU_ON`` service call which is trapped to the Hypervisor. The +latter then enables the vCPU context for the targeted core, and switches to +the PVM down to the kernel driver with an ``HF_WAKE_UP`` message. The NWd +driver in PVM can then schedule the newly woken up vCPU context. + +In the secure world the primary EC of a given SP passes the secondary EC entry +point and context. The SMC service call is trapped into the SPMC. This can be +either *(under discussion)*: + +- a specific interface registering the secondary EC entry point, + similarly to above ``SET_ENTRY_POINT`` service. +- Re-purposing the ``PSCI_CPU_ON`` function id. It is + assumed that even if the input arguments are the same as the ones defined in + the PSCI standard, the usage deviates by the fact the secondary EC is not + woken up immediately. At least for the PSA-FF-A EAC where only + direct messaging is allowed, it is only after the first direct + message invocation that the secondary EC is entered. This option + might be preferred when the same code base is re-used for a VM or + an SP. The ABI to wake-up a secondary EC can remain similar. + +SPs are always scheduled from the NWd, this paradigm did not change from legacy +TEEs. There must always be some logic (or driver) in the NWd to relinquish CPU +cycles to the SWd. If primary core is 0, an SP EC[x>0] entry point is supplied +by the SP EC[0] when the system boots in SWd. But this EC[x] is not immediately +entered at boot. Later in the boot process when NWd is up, a direct message +request issued from physical core 1 ends up in SP EC[1], and only at this stage +this context is effectively scheduled. + +It should be possible for an SP to call into another SP through direct message +provided the latter SP has been booted already. The "boot-order" field in +partition manifests (`SP Boot order`_) fulfills the dependency towards availability +of a service within an SP offered to another SP. + +Mandatory interfaces +-------------------- + +The following interfaces must be exposed to any VM or SP: + +- ``FFA_STATUS`` +- ``FFA_ERROR`` +- ``FFA_INTERRUPT`` +- ``FFA_VERSION`` +- ``FFA_FEATURES`` +- ``FFA_RX_RELEASE`` +- ``FFA_RXTX_MAP`` +- ``FFA_RXTX_UNMAP`` +- ``FFA_PARTITION_INFO_GET`` +- ``FFA_ID_GET`` + +FFA_VERSION +~~~~~~~~~~~ + +Per `[1]`_ section 8.1 ``FFA_VERSION`` requires a +*requested_version* parameter from the caller. + +In the current implementation when ``FFA_VERSION`` is invoked from: + +- Hypervisor in NS-EL2: the SPMD returns the SPMC version specified + in the SPMC manifest. +- OS kernel in NS-EL1 when NS-EL2 is not present: the SPMD returns the + SPMC version specified in the SPMC manifest. +- VM in NWd: the Hypervisor returns its implemented version. +- SP in SWd: the SPMC returns its implemented version. +- SPMC at S-EL1/S-EL2: the SPMD returns its implemented version. + +FFA_FEATURES +~~~~~~~~~~~~ + +FF-A features may be discovered by Secure Partitions while booting +through the SPMC. However, SPMC cannot get features from Hypervisor +early at boot time as NS world is not setup yet. + +The Hypervisor may decide to gather FF-A features from SPMC through SPMD +once at boot time and store the result. Later when a VM requests FF-A +features, the Hypervisor can adjust its own set of features with what +SPMC advertised, if necessary. Another approach is to always forward FF-A +features to the SPMC when a VM requests it to the Hypervisor. Although +the result is not supposed to change over time so there may not be added +value doing the systematic forwarding. + +FFA_RXTX_MAP/FFA_RXTX_UNMAP +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +VM mailboxes are re-purposed to serve as SP RX/TX buffers. The RX/TX +map API maps the send and receive buffer IPAs to the SP Stage-2 translation regime. + +Hafnium in the normal world defines VMs and their attributes as logical structures, +including a mailbox used for FF-A indirect messaging, memory sharing, or the +`FFA_PARTITION_INFO_GET`_ ABI. +This same mailbox structure is re-used in the SPMC. `[1]`_ states only direct +messaging is allowed to SPs. Thus mailbox usage is restricted to implementing +`FFA_PARTITION_INFO_GET`_ and memory sharing ABIs. + +FFA_PARTITION_INFO_GET +~~~~~~~~~~~~~~~~~~~~~~ + +Partition info get service call can originate: + +- from SP to SPM +- from VM to Hypervisor +- from Hypervisor to SPM + +For the latter case, the service call must be forwarded through the SPMD. + +FFA_ID_GET +~~~~~~~~~~ + +The SPMD returns: + +- a default zero value on invocation from the Hypervisor. +- The ``spmc_id`` value specified in the SPMC manifest on invocation from + the SPMC (see `SPMC manifest`_) + +The FF-A id space is split into a non-secure space and secure space: + +- FF-A id with bit 15 clear refer to normal world VMs. +- FF-A id with bit 15 set refer to secure world SPs + +Such convention helps the SPMC discriminating the origin and destination worlds +in an FF-A service invocation. In particular the SPMC shall filter unauthorized +transactions in its world switch routine. It must not be permitted for a VM to +use a secure FF-A id as origin world through spoofing: + +- A VM-to-SP messaging passing shall have an origin world being non-secure + (FF-A id bit 15 clear) and destination world being secure (FF-A id bit 15 + set). +- Similarly, an SP-to-SP message shall have FF-A id bit 15 set for both origin + and destination ids. + +An incoming direct message request arriving at SPMD from NWd is forwarded to +SPMC without a specific check. The SPMC is resumed through eret and "knows" the +message is coming from normal world in this specific code path. Thus the origin +endpoint id must be checked by SPMC for being a normal world id. + +An SP sending a direct message request must have bit 15 set in its origin +endpoint id and this can be checked by the SPMC when the SP invokes the ABI. + +The SPMC shall reject the direct message if the claimed world in origin endpoint +id is not consistent: + +- It is either forwarded by SPMD and thus origin endpoint id must be a "normal + world id", +- or initiated by an SP and thus origin endpoint id must be a "secure world id". + +Direct messaging +---------------- + +This is a mandatory interface for Secure Partitions consisting in direct +message request and responses. + +The ``ffa_handler`` Hafnium function may: + +- trigger a world change e.g. when an SP invokes the direct message + response ABI to a VM. +- handle multiple requests from the NWd without resuming an SP. + +SP-to-SP +~~~~~~~~ + +- An SP can send a direct message request to another SP +- An SP can receive a direct message response from another SP. + +VM-to-SP +~~~~~~~~ + +- A VM can send a direct message request to an SP +- An SP can send a direct message response to a VM + +SPMC-SPMD messaging +~~~~~~~~~~~~~~~~~~~ + +Specific implementation-defined endpoint IDs are allocated to the SPMC and SPMD. +Referring those IDs in source/destination fields of a direct message +request/response permits SPMD to SPMC messaging back and forth. + +Per `[1]`_ Table 114 Config No. 1 (physical FF-A instance): + +- SPMC=>SPMD direct message request uses SMC conduit +- SPMD=>SPMC direct message request uses ERET conduit + +Per `[1]`_ Table 118 Config No. 1 (physical FF-A instance): + +- SPMC=>SPMD direct message response uses SMC conduit +- SPMD=>SPMC direct message response uses ERET conduit + +Memory management +----------------- + +This section only deals with the PE MMU configuration. + +Hafnium in the normal world deals with NS buffers only and provisions +a single root page table directory to VMs. In context of S-EL2 enabled +firmware, two IPA spaces are output from Stage-1 translation (secure +and non-secure). The Stage-2 translation handles: + +- A single secure IPA space when an SP Stage-1 MMU is disabled. +- Two IPA spaces (secure and non-secure) when Stage-1 MMU is enabled. + +``VTCR_EL2`` and ``VSTCR_EL2`` provide additional bits for controlling the +NS/S IPA translations (``VSTCR_EL2.SW``, ``VSTCR_EL2.SA``, ``VTCR_EL2.NSW``, +``VTCR_EL2.NSA``). There may be two approaches: + +- secure and non-secure mappings are rooted as two separate root page + tables +- secure and non-secure mappings use the same root page table. Access + from S-EL1 to an NS region translates to a secure physical address + space access. + +Interrupt management +-------------------- + +Road to a para-virtualized interface +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Current Hafnium implementation uses an ad-hoc mechanism for a VM to get +a pending interrupt number through an hypercall. The PVM injects +interrupts to VMs by delegation from the Hypervisor. The PVM probes a +pending interrupt directly from the GIC distributor. + +The short-term plan is to have Hafnium/SPMC in the secure world owner +of the GIC configuration. + +The SPMC fully owns the GIC configuration at S-EL2. The SPMC manages +interrupt resources and allocates interrupt ID based on SP manifests. +The SPMC acknowledges physical interrupts and injects virtual interrupts +by setting the vIRQ bit when resuming an SP. A Secure Partition gathers +the interrupt number through an hypercall. + +Notice the SPMC/SPMD has to handle Group0 secure interrupts in addition +to Group1 S/NS interrupts. + +Power management +---------------- + +Assumption on the Nwd: + +- NWd is the best candidate to own the platform Power Management + policy. It is master to invoking PSCI service calls from physical + CPUs. +- EL3 monitor is in charge of the PM control part (its PSCI layer + actually writing to platform registers). +- It is fine for the Hypervisor to trap PSCI calls and relay to EL3, or + OS kernel driver to emit PSCI service calls. + +PSCI notification are relayed through the SPMD/SPD PM hooks to the SPMC. +This can either be through re-use of PSCI FIDs or an FF-A direct message +from SPMD to SPMC. + +The SPMD performs an exception return to the SPMC which is resumed to +its ``eret_handler`` routine. It is then either consuming a PSCI FID or +an FF-A FID. Depending on the servicing, the SPMC may return directly to +the SPMD (and then NWd) without resuming an SP at this stage. An example +of this is invocation of ``FFA_PARTITION_INFO_GET`` from NWd relayed by +the SPMD to the SPMC. The SPMC returns the needed partition information +to the SPMD (then NWd) without actually resuming a partition in secure world. + +*(under discussion)* +About using PSCI FIDs from SPMD to SPMC to notify of PM events, it is still +questioned what to use as the return code from the SPMC. +If the function ID used by the SPMC is not an FF-A ID when doing SMC, then the +EL3 std svc handler won't route the response to the SPMD. That's where comes the +idea to embed the notification into an FF-A message. The SPMC can discriminate +this message as being a PSCI event, process it, and reply with an FF-A return +message that the SPMD receives as an acknowledgement. + +SP notification +--------------- + +Power management notifications are conveyed from PSCI library to the +SPMD / SPD hooks. A range of events can be relayed to SPMC. + +SPs may need to be notified about specific PM events. + +- SPs might register PM events to the SPMC +- On SPMD to SPMC notification, a limited range of SPs may be notified + through a direct message. +- This assumes the mentioned SPs supports managed exit. + +The SPMC is the first to be notified about PM events from the SPMD. It is up +to the SPMC to arbitrate to which SP it needs to send PM events. +An SP explicitly registers to receive notifications to specific PM events. +The register operation can either be an implementation-defined service call +to the SPMC when the primary SP EC boots, or be supplied through the SP +manifest. + +References +========== + +.. _[1]: + +[1] `Platform Security Architecture Firmware Framework for Arm® v8-A 1.0 Platform Design Document <https://developer.arm.com/docs/den0077/latest>`__ + +.. _[2]: + +[2] :ref:`Secure Partition Manager using MM interface<Secure Partition Manager (MM)>` + +.. _[3]: + +[3] `Trusted Boot Board Requirements +Client <https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a>`__ + +.. _[4]: + +[4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/el3_runtime/aarch64/context.S#n45 + +.. _[5]: + +[5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus.dts + +.. _[6]: + +[6] https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manifest-binding.html + +.. _[7]: + +[7] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/board/fvp/fdts/fvp_spmc_manifest.dts + +.. _[8]: + +[8] https://developer.trustedfirmware.org/w/tf_a/poc-multiple-signing-domains/ + +-------------- + +*Copyright (c) 2020, Arm Limited and Contributors. All rights reserved.* |