From 624c9a0b387aa35005b9655e224d664a96d4ca67 Mon Sep 17 00:00:00 2001 From: Tamas Ban Date: Wed, 21 Feb 2024 13:55:31 +0100 Subject: [PATCH] docs: change all occurrences of RSS to RSE Changes all occurrences of "RSS" and "rss" in the documentation to "RSE" and "rse". Signed-off-by: Tamas Ban Change-Id: Ia42078f5faa1db331b1e5a35f01faeaf1afacb5f --- docs/about/features.rst | 2 +- docs/about/maintainers.rst | 8 +- docs/design_documents/index.rst | 2 +- docs/design_documents/measured_boot.rst | 10 +- docs/design_documents/rse.rst | 148 +++++++++--------- docs/porting-guide.rst | 6 +- .../plantuml/rse_attestation_flow.puml | 2 +- .../plantuml/rse_measured_boot_flow.puml | 96 ++++++------ .../diagrams/plantuml/tfa_rse_dfd.puml | 12 +- .../diagrams/rse_attestation_flow.svg | 4 +- .../diagrams/rse_measured_boot_flow.svg | 98 ++++++------ .../firmware_threat_model/index.rst | 2 +- .../threat_model_rse_interface.rst | 28 ++-- .../supply_chain_threat_model.rst | 2 +- 14 files changed, 210 insertions(+), 210 deletions(-) diff --git a/docs/about/features.rst b/docs/about/features.rst index c12509d9d..9b7bdf9da 100644 --- a/docs/about/features.rst +++ b/docs/about/features.rst @@ -128,7 +128,7 @@ Additionally the following libraries are marked experimental when included in a platform: - MPU translation library ``lib/xlat_mpu`` -- RSS comms driver ``drivers/arm/rss`` +- RSE comms driver ``drivers/arm/rse`` Still to come ------------- diff --git a/docs/about/maintainers.rst b/docs/about/maintainers.rst index 6d34339d2..0fade3efb 100644 --- a/docs/about/maintainers.rst +++ b/docs/about/maintainers.rst @@ -337,12 +337,12 @@ Message Handling Unit (MHU) driver :|F|: include/drivers/arm/mhu.h :|F|: drivers/arm/mhu -Runtime Security Subsystem (RSS) comms driver -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ +Runtime Security Engine (RSE) comms driver +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :|M|: David Vincze :|G|: `davidvincze`_ -:|F|: include/drivers/arm/rss_comms.h -:|F|: drivers/arm/rss +:|F|: include/drivers/arm/rse_comms.h +:|F|: drivers/arm/rse Libfdt wrappers ^^^^^^^^^^^^^^^ diff --git a/docs/design_documents/index.rst b/docs/design_documents/index.rst index ecc68b237..ac982e098 100644 --- a/docs/design_documents/index.rst +++ b/docs/design_documents/index.rst @@ -9,7 +9,7 @@ Design Documents context_mgmt_rework measured_boot_poc drtm_poc - rss + rse psci_osi_mode measured_boot diff --git a/docs/design_documents/measured_boot.rst b/docs/design_documents/measured_boot.rst index 8a2ab2df8..9dfe49415 100644 --- a/docs/design_documents/measured_boot.rst +++ b/docs/design_documents/measured_boot.rst @@ -91,10 +91,10 @@ The Measured Boot implementation in TF-A supports: and the variable length crypto agile structure called TCG_PCR_EVENT2. Event Log driver implemented in TF-A covers later part. -#. RSS +#. RSE It is one of physical backend to extend the measurements. Please refer this - document :ref:`Runtime Security Subsystem (RSS)` for more details. + document :ref:`Runtime Security Engine (RSE)` for more details. Platform Interface ------------------ @@ -121,7 +121,7 @@ Responsibilities of these platform interfaces are - void bl2_plat_mboot_init(void); Initialise all Measured Boot backends supported by the platform - (e.g. Event Log buffer, RSS). As these functions do not return any value, + (e.g. Event Log buffer, RSE). As these functions do not return any value, the platform should deal with error management, such as logging the error somewhere, or panicking the system if this is considered a fatal error. @@ -147,7 +147,7 @@ Responsibilities of these platform interfaces are - - If it is Event Log backend, then record the measurement in TCG Event Log format. - - If it is a secure crypto-processor (like RSS), then extend the designated + - If it is a secure crypto-processor (like RSE), then extend the designated PCR (or slot) with the given measurement. - This function must return 0 on success, a signed integer error code otherwise. @@ -223,7 +223,7 @@ Responsibilities of these platform interfaces are - - This function must return 0 on success, a signed integer error code otherwise. - In TC2 platform, this function is used to calculate the hash of the given - key and forward this hash to RSS alongside the measurement of the image + key and forward this hash to RSE alongside the measurement of the image which the key signs. -------------- diff --git a/docs/design_documents/rse.rst b/docs/design_documents/rse.rst index 18d543683..7296a453e 100644 --- a/docs/design_documents/rse.rst +++ b/docs/design_documents/rse.rst @@ -1,45 +1,45 @@ -Runtime Security Subsystem (RSS) -================================ +Runtime Security Engine (RSE) +============================= -This document focuses on the relationship between the Runtime Security Subsystem -(RSS) and the application processor (AP). According to the ARM reference design -the RSS is an independent core next to the AP and the SCP on the same die. It +This document focuses on the relationship between the Runtime Security Engine +(RSE) and the application processor (AP). According to the ARM reference design +the RSE is an independent core next to the AP and the SCP on the same die. It provides fundamental security guarantees and runtime services for the rest of the system (e.g.: trusted boot, measured boot, platform attestation, key management, and key derivation). -At power up RSS boots first from its private ROM code. It validates and loads +At power up RSE boots first from its private ROM code. It validates and loads its own images and the initial images of SCP and AP. When AP and SCP are released from reset and their initial code is loaded then they continue their -own boot process, which is the same as on non-RSS systems. Please refer to the -``RSS documentation`` [1]_ for more details about the RSS boot flow. +own boot process, which is the same as on non-RSE systems. Please refer to the +``RSE documentation`` [1]_ for more details about the RSE boot flow. -The last stage of the RSS firmware is a persistent, runtime component. Much +The last stage of the RSE firmware is a persistent, runtime component. Much like AP_BL31, this is a passive entity which has no periodical task to do and -just waits for external requests from other subsystems. RSS and other -subsystems can communicate with each other over message exchange. RSS waits +just waits for external requests from other subsystems. RSE and other +subsystems can communicate with each other over message exchange. RSE waits in idle for the incoming request, handles them, and sends a response then goes back to idle. -RSS communication layer +RSE communication layer ----------------------- -The communication between RSS and other subsystems are primarily relying on the -Message Handling Unit (MHU) module. The number of MHU interfaces between RSS +The communication between RSE and other subsystems are primarily relying on the +Message Handling Unit (MHU) module. The number of MHU interfaces between RSE and other cores is IMPDEF. Besides MHU other modules also could take part in -the communication. RSS is capable of mapping the AP memory to its address space. -Thereby either RSS core itself or a DMA engine if it is present, can move the -data between memory belonging to RSS or AP. In this way, a bigger amount of data +the communication. RSE is capable of mapping the AP memory to its address space. +Thereby either RSE core itself or a DMA engine if it is present, can move the +data between memory belonging to RSE or AP. In this way, a bigger amount of data can be transferred in a short time. The MHU comes in pairs. There is a sender and receiver side. They are connected to each other. An MHU interface consists of two pairs of MHUs, one sender and one receiver on both sides. Bidirectional communication is possible over an -interface. One pair provides message sending from AP to RSS and the other pair -from RSS to AP. The sender and receiver are connected via channels. There is an +interface. One pair provides message sending from AP to RSE and the other pair +from RSE to AP. The sender and receiver are connected via channels. There is an IMPDEF number of channels (e.g: 4-16) between a sender and a receiver module. -The RSS communication layer provides two ways for message exchange: +The RSE communication layer provides two ways for message exchange: - ``Embedded messaging``: The full message, including header and payload, are exchanged over the MHU channels. A channel is capable of delivering a single @@ -55,16 +55,16 @@ The RSS communication layer provides two ways for message exchange: - ``Pointer-access messaging``: The message header and the payload are separated and they are conveyed in different ways. The header is sent over the channels, similar to the embedded messaging but the payload is - copied over by RSS core (or by DMA) between the sender and the receiver. This + copied over by RSE core (or by DMA) between the sender and the receiver. This could be useful in the case of long messages because transaction time is less - compared to the embedded messaging mode. Small payloads are copied by the RSS + compared to the embedded messaging mode. Small payloads are copied by the RSE core because setting up DMA would require more CPU cycles. The payload is - either copied into an internal buffer or directly read-written by RSS. Actual - behavior depends on RSS setup, whether the partition supports memory-mapped + either copied into an internal buffer or directly read-written by RSE. Actual + behavior depends on RSE setup, whether the partition supports memory-mapped ``iovec``. Therefore, the sender must handle both cases and prevent access to - the memory, where payload data lives, while the RSS handles the request. + the memory, where payload data lives, while the RSE handles the request. -The RSS communication layer supports both ways of messaging in parallel. It is +The RSE communication layer supports both ways of messaging in parallel. It is decided at runtime based on the message size which way to transfer the message. .. code-block:: bash @@ -93,25 +93,25 @@ decided at runtime based on the message size which way to transfer the message. V | | | V V +----------------------------------------------+ | | +-------------------+ | |--+-+ | | - | RSS | | SRAM | + | RSE | | SRAM | | | | | +----------------------------------------------+ +-------------------+ .. Note:: - The RSS communication layer is not prepared for concurrent execution. The + The RSE communication layer is not prepared for concurrent execution. The current use case only requires message exchange during the boot phase. In the boot phase, only a single core is running and the rest of the cores are in reset. Message structure ^^^^^^^^^^^^^^^^^ -A description of the message format can be found in the ``RSS communication +A description of the message format can be found in the ``RSE communication design`` [2]_ document. Source files ^^^^^^^^^^^^ -- RSS comms: ``drivers/arm/rss`` +- RSE comms: ``drivers/arm/rse`` - MHU driver: ``drivers/arm/mhu`` @@ -119,29 +119,29 @@ API for communication over MHU ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The API is defined in these header files: -- ``include/drivers/arm/rss_comms.h`` +- ``include/drivers/arm/rse_comms.h`` - ``include/drivers/arm/mhu.h`` -RSS provided runtime services +RSE provided runtime services ----------------------------- -RSS provides the following runtime services: +RSE provides the following runtime services: - ``Measured boot``: Securely store the firmware measurements which were computed during the boot process and the associated metadata (image description, measurement algorithm, etc.). More info on measured boot service - in RSS can be found in the ``measured_boot_integration_guide`` [3]_ . + in RSE can be found in the ``measured_boot_integration_guide`` [3]_ . - ``Delegated attestation``: Query the platform attestation token and derive a delegated attestation key. More info on the delegated attestation service - in RSS can be found in the ``delegated_attestation_integration_guide`` [4]_ . + in RSE can be found in the ``delegated_attestation_integration_guide`` [4]_ . - ``OTP assets management``: Public keys used by AP during the trusted boot - process can be requested from RSS. Furthermore, AP can request RSS to + process can be requested from RSE. Furthermore, AP can request RSE to increase a non-volatile counter. Please refer to the - ``RSS key management`` [5]_ document for more details. + ``RSE key management`` [5]_ document for more details. Runtime service API ^^^^^^^^^^^^^^^^^^^ -The RSS provided runtime services implement a PSA aligned API. The parameter +The RSE provided runtime services implement a PSA aligned API. The parameter encoding follows the PSA client protocol described in the ``Firmware Framework for M`` [6]_ document in chapter 4.4. The implementation is restricted to the static handle use case therefore only the ``psa_call`` API is @@ -168,7 +168,7 @@ Software and API layers | | V V +------------------------------------------------+ - | RSS communication protocol | + | RSE communication protocol | +------------------------------------------------+ | ^ | mhu_send_data() | mhu_receive_data() @@ -188,7 +188,7 @@ Software and API layers | V +------------------------------------------------+ - | MHU HW on RSS side | + | MHU HW on RSE side | +------------------------------------------------+ | ^ | IRQ | Register access @@ -204,17 +204,17 @@ Software and API layers +---------------+ +------------------------+ -RSS based Measured Boot +RSE based Measured Boot ----------------------- Measured Boot is the process of cryptographically measuring (computing the hash value of a binary) the code and critical data used at boot time. The measurement must be stored in a tamper-resistant way, so the security state -of the device can be attested later to an external party. RSS provides a runtime +of the device can be attested later to an external party. RSE provides a runtime service which is meant to store measurements and associated metadata alongside. Data is stored in internal SRAM which is only accessible by the secure runtime -firmware of RSS. Data is stored in so-called measurement slots. A platform has +firmware of RSE. Data is stored in so-called measurement slots. A platform has IMPDEF number of measurement slots. The measurement storage follows extend semantics. This means that measurements are not stored directly (as it was taken) instead they contribute to the current value of the measurement slot. @@ -236,7 +236,7 @@ Defined here: .. code-block:: c psa_status_t - rss_measured_boot_extend_measurement(uint8_t index, + rse_measured_boot_extend_measurement(uint8_t index, const uint8_t *signer_id, size_t signer_id_size, const uint8_t *version, @@ -291,27 +291,27 @@ multiple times: .. Note:: Extending multiple measurements in the same slot leads to some metadata - information loss. Since RSS is not constrained on special HW resources to + information loss. Since RSE is not constrained on special HW resources to store the measurements and metadata, therefore it is worth considering to store all of them one by one in distinct slots. However, they are one-by-one included in the platform attestation token. So, the number of distinct firmware image measurements has an impact on the size of the attestation token. -The allocation of the measurement slot among RSS, Root and Realm worlds is +The allocation of the measurement slot among RSE, Root and Realm worlds is platform dependent. The platform must provide an allocation of the measurement slot at build time. An example can be found in ``tf-a/plat/arm/board/tc/tc_bl1_measured_boot.c`` Furthermore, the memory, which holds the metadata is also statically allocated -in RSS memory. Some of the fields have a static value (measurement algorithm), +in RSE memory. Some of the fields have a static value (measurement algorithm), and some of the values have a dynamic value (measurement value) which is updated by the bootloaders when the firmware image is loaded and measured. The metadata structure is defined in -``include/drivers/measured_boot/rss/rss_measured_boot.h``. +``include/drivers/measured_boot/rse/rse_measured_boot.h``. .. code-block:: c - struct rss_mboot_metadata { + struct rse_mboot_metadata { unsigned int id; uint8_t slot; uint8_t signer_id[SIGNER_ID_MAX_SIZE]; @@ -328,24 +328,24 @@ Signer-ID API ^^^^^^^^^^^^^ This function calculates the hash of a public key (signer-ID) using the -``Measurement algorithm`` and stores it in the ``rss_mboot_metadata`` field +``Measurement algorithm`` and stores it in the ``rse_mboot_metadata`` field named ``signer_id``. Prior to calling this function, the caller must ensure that the ``signer_id`` field points to the zero-filled buffer. Defined here: -- ``include/drivers/measured_boot/rss/rss_measured_boot.h`` +- ``include/drivers/measured_boot/rse/rse_measured_boot.h`` .. code-block:: c - int rss_mboot_set_signer_id(struct rss_mboot_metadata *metadata_ptr, + int rse_mboot_set_signer_id(struct rse_mboot_metadata *metadata_ptr, const void *pk_oid, const void *pk_ptr, size_t pk_len) -- First parameter is the pointer to the ``rss_mboot_metadata`` structure. +- First parameter is the pointer to the ``rse_mboot_metadata`` structure. - Second parameter is the pointer to the key-OID of the public key. - Third parameter is the pointer to the public key buffer. - Fourth parameter is the size of public key buffer. @@ -356,15 +356,15 @@ Build time config options ^^^^^^^^^^^^^^^^^^^^^^^^^ - ``MEASURED_BOOT``: Enable measured boot. It depends on the platform - implementation whether RSS or TPM (or both) backend based measured boot is + implementation whether RSE or TPM (or both) backend based measured boot is enabled. -- ``MBOOT_RSS_HASH_ALG``: Determine the hash algorithm to measure the images. +- ``MBOOT_RSE_HASH_ALG``: Determine the hash algorithm to measure the images. The default value is sha-256. Measured boot flow ^^^^^^^^^^^^^^^^^^ -.. figure:: ../resources/diagrams/rss_measured_boot_flow.svg +.. figure:: ../resources/diagrams/rse_measured_boot_flow.svg :align: center Sample console log @@ -425,15 +425,15 @@ The detailed description of the delegated attestation service can be found in the ``Delegated Attestation Service Integration Guide`` [4]_ document. In the CCA use case, the Realm Management Monitor (RMM) relies on the delegated -attestation service of the RSS to get a realm attestation key and the CCA +attestation service of the RSE to get a realm attestation key and the CCA platform token. BL31 does not use the service for its own purpose, only calls -it on behalf of RMM. The access to MHU interface and thereby to RSS is +it on behalf of RMM. The access to MHU interface and thereby to RSE is restricted to BL31 only. Therefore, RMM does not have direct access, all calls need to go through BL31. The RMM dispatcher module of the BL31 is responsible for delivering the calls between the two parties. .. Note:: - Currently the connection between the RMM dispatcher and the PSA/RSS layer + Currently the connection between the RMM dispatcher and the PSA/RSE layer is not yet implemented. RMM dispatcher just returns hard coded data. Delegated Attestation API @@ -445,7 +445,7 @@ Defined here: .. code-block:: c psa_status_t - rss_delegated_attest_get_delegated_key(uint8_t ecc_curve, + rse_delegated_attest_get_delegated_key(uint8_t ecc_curve, uint32_t key_bits, uint8_t *key_buf, size_t key_buf_size, @@ -453,7 +453,7 @@ Defined here: uint32_t hash_algo); psa_status_t - rss_delegated_attest_get_token(const uint8_t *dak_pub_hash, + rse_delegated_attest_get_token(const uint8_t *dak_pub_hash, size_t dak_pub_hash_size, uint8_t *token_buf, size_t token_buf_size, @@ -462,7 +462,7 @@ Defined here: Attestation flow ^^^^^^^^^^^^^^^^ -.. figure:: ../resources/diagrams/rss_attestation_flow.svg +.. figure:: ../resources/diagrams/rse_attestation_flow.svg :align: center Sample attestation token @@ -623,27 +623,27 @@ JSON format: "CCA_PLATFORM_VERIFICATION_SERVICE": "www.trustedfirmware.org" } -RSS OTP Assets Management +RSE OTP Assets Management ------------------------- -RSS provides access for AP to assets in OTP, which include keys for image +RSE provides access for AP to assets in OTP, which include keys for image signature verification and non-volatile counters for anti-rollback protection. Non-Volatile Counter API ^^^^^^^^^^^^^^^^^^^^^^^^ -AP/RSS interface for retrieving and incrementing non-volatile counters API is +AP/RSE interface for retrieving and incrementing non-volatile counters API is as follows. Defined here: -- ``include/lib/psa/rss_platform_api.h`` +- ``include/lib/psa/rse_platform_api.h`` .. code-block:: c - psa_status_t rss_platform_nv_counter_increment(uint32_t counter_id) + psa_status_t rse_platform_nv_counter_increment(uint32_t counter_id) - psa_status_t rss_platform_nv_counter_read(uint32_t counter_id, + psa_status_t rse_platform_nv_counter_read(uint32_t counter_id, uint32_t size, uint8_t *val) Through this service, we can read/increment any of the 3 non-volatile @@ -656,15 +656,15 @@ counters used on an Arm CCA platform: Public Key API ^^^^^^^^^^^^^^ -AP/RSS interface for reading the ROTPK is as follows. +AP/RSE interface for reading the ROTPK is as follows. Defined here: -- ``include/lib/psa/rss_platform_api.h`` +- ``include/lib/psa/rse_platform_api.h`` .. code-block:: c - psa_status_t rss_platform_key_read(enum rss_key_id_builtin_t key, + psa_status_t rse_platform_key_read(enum rse_key_id_builtin_t key, uint8_t *data, size_t data_size, size_t *data_length) Through this service, we can read any of the 3 ROTPKs used on an @@ -677,11 +677,11 @@ Arm CCA platform: References ---------- -.. [1] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/readme.html -.. [2] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/rss_comms.html +.. [1] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/readme.html +.. [2] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_comms.html .. [3] https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/partitions/measured_boot/measured_boot_integration_guide.rst .. [4] https://git.trustedfirmware.org/TF-M/tf-m-extras.git/tree/partitions/delegated_attestation/delegated_attest_integration_guide.rst -.. [5] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rss/rss_key_management.html +.. [5] https://tf-m-user-guide.trustedfirmware.org/platform/arm/rse/rse_key_management.html .. [6] https://developer.arm.com/-/media/Files/pdf/PlatformSecurityArchitecture/Architect/DEN0063-PSA_Firmware_Framework-1.0.0-2.pdf?revision=2d1429fa-4b5b-461a-a60e-4ef3d8f7f4b4&hash=3BFD6F3E687F324672F18E5BE9F08EDC48087C93 .. [7] https://developer.arm.com/documentation/DEN0096/A_a/?lang=en diff --git a/docs/porting-guide.rst b/docs/porting-guide.rst index 7c66d1118..fdd434081 100644 --- a/docs/porting-guide.rst +++ b/docs/porting-guide.rst @@ -256,10 +256,10 @@ likely to be suitable for all platform ports. Defines the maximum address in secure RAM that the BL31 image can occupy. -- **#define : PLAT_RSS_COMMS_PAYLOAD_MAX_SIZE** +- **#define : PLAT_RSE_COMMS_PAYLOAD_MAX_SIZE** - Defines the maximum message size between AP and RSS. Need to define if - platform supports RSS. + Defines the maximum message size between AP and RSE. Need to define if + platform supports RSE. For every image, the platform must define individual identifiers that will be used by BL1 or BL2 to load the corresponding image into memory from non-volatile diff --git a/docs/resources/diagrams/plantuml/rse_attestation_flow.puml b/docs/resources/diagrams/plantuml/rse_attestation_flow.puml index aca5c01f3..9d7d78029 100644 --- a/docs/resources/diagrams/plantuml/rse_attestation_flow.puml +++ b/docs/resources/diagrams/plantuml/rse_attestation_flow.puml @@ -5,7 +5,7 @@ box AP participant RMM participant BL31 endbox -box RSS +box RSE participant DelegAttest participant InitAttest participant MeasuredBoot diff --git a/docs/resources/diagrams/plantuml/rse_measured_boot_flow.puml b/docs/resources/diagrams/plantuml/rse_measured_boot_flow.puml index 1aeb1a9f3..97af56270 100644 --- a/docs/resources/diagrams/plantuml/rse_measured_boot_flow.puml +++ b/docs/resources/diagrams/plantuml/rse_measured_boot_flow.puml @@ -1,11 +1,11 @@ @startuml skinparam ParticipantPadding 10 skinparam BoxPadding 10 -box RSS -participant RSS_BL1_1 -participant RSS_BL1_2 -participant RSS_BL2 -participant RSS_S +box RSE +participant RSE_BL1_1 +participant RSE_BL1_2 +participant RSE_BL2 +participant RSE_S endbox box SCP participant SCP_BL1 @@ -16,64 +16,64 @@ participant AP_BL2 participant AP_BL31 endbox -== RSS Boot phase == --> RSS_BL1_1: Reset -Rnote over RSS_BL1_1: ROM code, XIP -Rnote over RSS_BL1_2: OTP code, XIP -Rnote over RSS_BL2, AP_BL31: Stored in flash, loaded and executed in RAM -activate RSS_BL1_1 #Green -RSS_BL1_1 -->> RSS_BL1_2: Validate, measure -Rnote over RSS_BL1_1: BL1_2 measurement\n\ saved to a shared buffer -RSS_BL1_1 -> RSS_BL1_2: Pass execution -deactivate RSS_BL1_1 -activate RSS_BL1_2 #Green -RSS_BL1_2 -->> RSS_BL2: Validate, measure, load -Rnote over RSS_BL1_2: RSS_BL2 measurement\n\ saved to a shared buffer -RSS_BL1_2 -> RSS_BL2: Pass execution -deactivate RSS_BL1_2 -activate RSS_BL2 #Green -RSS_BL2 -->> RSS_S: Validate, measure, load -RSS_BL2 -->> SCP_BL1: Validate, measure, load -Rnote over RSS_BL2: RSS_S and SCP_BL1\n\ measurements saved\n\ to a shared buffer -RSS_BL2 -> SCP_BL1: Release from reset +== RSE Boot phase == +-> RSE_BL1_1: Reset +Rnote over RSE_BL1_1: ROM code, XIP +Rnote over RSE_BL1_2: OTP code, XIP +Rnote over RSE_BL2, AP_BL31: Stored in flash, loaded and executed in RAM +activate RSE_BL1_1 #Green +RSE_BL1_1 -->> RSE_BL1_2: Validate, measure +Rnote over RSE_BL1_1: BL1_2 measurement\n\ saved to a shared buffer +RSE_BL1_1 -> RSE_BL1_2: Pass execution +deactivate RSE_BL1_1 +activate RSE_BL1_2 #Green +RSE_BL1_2 -->> RSE_BL2: Validate, measure, load +Rnote over RSE_BL1_2: RSE_BL2 measurement\n\ saved to a shared buffer +RSE_BL1_2 -> RSE_BL2: Pass execution +deactivate RSE_BL1_2 +activate RSE_BL2 #Green +RSE_BL2 -->> RSE_S: Validate, measure, load +RSE_BL2 -->> SCP_BL1: Validate, measure, load +Rnote over RSE_BL2: RSE_S and SCP_BL1\n\ measurements saved\n\ to a shared buffer +RSE_BL2 -> SCP_BL1: Release from reset activate SCP_BL1 #Green -Rnote over RSS_BL2, SCP_BL1: MHU init between RSS and SCP +Rnote over RSE_BL2, SCP_BL1: MHU init between RSE and SCP Rnote over SCP_BL1: Configure memory -Rnote over RSS_BL2: Waits for SCP -SCP_BL1 --> RSS_BL2: Done -RSS_BL2 -->> AP_BL1: Validate, measure, load -Rnote over RSS_BL2: AP_BL1 measurement\n\ saved to a shared buffer -RSS_BL2 -> AP_BL1: Release from reset +Rnote over RSE_BL2: Waits for SCP +SCP_BL1 --> RSE_BL2: Done +RSE_BL2 -->> AP_BL1: Validate, measure, load +Rnote over RSE_BL2: AP_BL1 measurement\n\ saved to a shared buffer +RSE_BL2 -> AP_BL1: Release from reset activate AP_BL1 #Green -RSS_BL2 -> RSS_S: Pass execution -deactivate RSS_BL2 -activate RSS_S #Green -Rnote over RSS_S: Measurements read from\n\ shared buffer and saved by\n\ +RSE_BL2 -> RSE_S: Pass execution +deactivate RSE_BL2 +activate RSE_S #Green +Rnote over RSE_S: Measurements read from\n\ shared buffer and saved by\n\ Measured Boot service to\n\ measurement slots. -== RSS Runtime / AP Boot phase == -Rnote over RSS_S, AP_BL1: MHU init between RSS and AP +== RSE Runtime / AP Boot phase == +Rnote over RSE_S, AP_BL1: MHU init between RSE and AP Rnote over AP_BL1: Measure and load:\n\ FW_CONFIG\n\ TB_FW_CONFIG -AP_BL1 -> RSS_S: Extend measurement -Rnote over RSS_S: Measured Boot:\n\ store measurement +AP_BL1 -> RSE_S: Extend measurement +Rnote over RSE_S: Measured Boot:\n\ store measurement AP_BL1 -->> AP_BL2: Validate, measure,load -AP_BL1 -> RSS_S: Extend measurement -Rnote over RSS_S: Measured Boot:\n\ store measurement +AP_BL1 -> RSE_S: Extend measurement +Rnote over RSE_S: Measured Boot:\n\ store measurement AP_BL1 -> AP_BL2: Pass execution deactivate AP_BL1 activate AP_BL2 #Green Rnote over AP_BL2: Measure and load:\n\ HW_CONFIG -AP_BL2 -> RSS_S: Extend measurement -Rnote over RSS_S: Measured Boot:\n\ store measurement +AP_BL2 -> RSE_S: Extend measurement +Rnote over RSE_S: Measured Boot:\n\ store measurement AP_BL2 -->> AP_BL31: Validate, measure,load Rnote over AP_BL2: Measure and load:\n\ BL31 -AP_BL2 -> RSS_S: Extend measurement -Rnote over RSS_S: Measured Boot:\n\ store measurement +AP_BL2 -> RSE_S: Extend measurement +Rnote over RSE_S: Measured Boot:\n\ store measurement Rnote over AP_BL2: Measure and load:\n\ RMM -AP_BL2 -> RSS_S: Extend measurement -Rnote over RSS_S: Measured Boot:\n\ store measurement +AP_BL2 -> RSE_S: Extend measurement +Rnote over RSE_S: Measured Boot:\n\ store measurement AP_BL2 -> AP_BL31: Pass execution deactivate AP_BL2 activate AP_BL31 #Green -== RSS / AP Runtime == +== RSE / AP Runtime == @enduml diff --git a/docs/resources/diagrams/plantuml/tfa_rse_dfd.puml b/docs/resources/diagrams/plantuml/tfa_rse_dfd.puml index a7e0ce576..68a80bfde 100644 --- a/docs/resources/diagrams/plantuml/tfa_rse_dfd.puml +++ b/docs/resources/diagrams/plantuml/tfa_rse_dfd.puml @@ -5,7 +5,7 @@ '/ /' -TF-A Data Flow Diagram including RSS +TF-A Data Flow Diagram including RSE '/ @startuml @@ -54,12 +54,12 @@ digraph tfa_dfd { bl31 [label="TF-A Runtime\n(BL31)" fillcolor="#ddffb3"] } - # RSS cluster - subgraph cluster_rss{ - label ="RSS"; + # RSE cluster + subgraph cluster_rse{ + label ="RSE"; graph [style=filled color="#000000" fillcolor="#faf9cd"] - rss [label="Runtime Security\n\ Subsystem\n\ (RSS)" fillcolor="#ddffb3"] + rse [label="Runtime Security\n\ Subsystem\n\ (RSE)" fillcolor="#ddffb3"] } } @@ -70,7 +70,7 @@ digraph tfa_dfd { sec -> bl2 [dir="both" lhead=cluster_tfa label="DF4"] nsec -> bl1 [dir="both" lhead=cluster_tfa, label="DF5"] bl2 -> tzc [dir="both" ltail=cluster_tfa lhead=cluster_ip label="DF6" minlen=1] - bl31 -> rss [dir="both" ltail=cluster_tfa lhead=cluster_rss label="DF7" minlen=1] + bl31 -> rse [dir="both" ltail=cluster_tfa lhead=cluster_rse label="DF7" minlen=1] } diff --git a/docs/resources/diagrams/rse_attestation_flow.svg b/docs/resources/diagrams/rse_attestation_flow.svg index 3728c6fb7..7257576c3 100644 --- a/docs/resources/diagrams/rse_attestation_flow.svg +++ b/docs/resources/diagrams/rse_attestation_flow.svg @@ -1,4 +1,4 @@ -APRSSRMMRMMBL31BL31DelegAttestDelegAttestInitAttestInitAttestMeasuredBootMeasuredBootCryptoCryptoRMM Boot phaseget_realm_key(hash_algo, ...)get_delegated_keyread_measurementCompute inputfor key derivation(hash of measurements)derive_keyCompute public keyhash withhash_algo.Seed is provisionedin the factory.get_delegated_keyget_realm_keyOnly private keyis returned. Publickey and its hashmust be computed.Public key is includedin the realm token.Its hash is the inputfor get_platform_tokenget_platform_token(pub_key_hash, ...)get_delegated_tokenCheckpub_key_hashagainst derived key.get_initial_tokenCreate the token includingthepub_key_hashas thechallenge claimread_measurementsign_tokenget_initial_tokenget_delegated_tokenget_platform_tokenPlatform token iscached. It is notchanging withina power cycle. RSS_BL1_1: Reset -Rnote over RSS_BL1_1: ROM code, XIP -Rnote over RSS_BL1_2: OTP code, XIP -Rnote over RSS_BL2, AP_BL31: Stored in flash, loaded and executed in RAM -activate RSS_BL1_1 #Green -RSS_BL1_1 - ->> RSS_BL1_2: Validate, measure -Rnote over RSS_BL1_1: BL1_2 measurement\n\ saved to a shared buffer -RSS_BL1_1 -> RSS_BL1_2: Pass execution -deactivate RSS_BL1_1 -activate RSS_BL1_2 #Green -RSS_BL1_2 - ->> RSS_BL2: Validate, measure, load -Rnote over RSS_BL1_2: RSS_BL2 measurement\n\ saved to a shared buffer -RSS_BL1_2 -> RSS_BL2: Pass execution -deactivate RSS_BL1_2 -activate RSS_BL2 #Green -RSS_BL2 - ->> RSS_S: Validate, measure, load -RSS_BL2 - ->> SCP_BL1: Validate, measure, load -Rnote over RSS_BL2: RSS_S and SCP_BL1\n\ measurements saved\n\ to a shared buffer -RSS_BL2 -> SCP_BL1: Release from reset +== RSE Boot phase == +-> RSE_BL1_1: Reset +Rnote over RSE_BL1_1: ROM code, XIP +Rnote over RSE_BL1_2: OTP code, XIP +Rnote over RSE_BL2, AP_BL31: Stored in flash, loaded and executed in RAM +activate RSE_BL1_1 #Green +RSE_BL1_1 - ->> RSE_BL1_2: Validate, measure +Rnote over RSE_BL1_1: BL1_2 measurement\n\ saved to a shared buffer +RSE_BL1_1 -> RSE_BL1_2: Pass execution +deactivate RSE_BL1_1 +activate RSE_BL1_2 #Green +RSE_BL1_2 - ->> RSE_BL2: Validate, measure, load +Rnote over RSE_BL1_2: RSE_BL2 measurement\n\ saved to a shared buffer +RSE_BL1_2 -> RSE_BL2: Pass execution +deactivate RSE_BL1_2 +activate RSE_BL2 #Green +RSE_BL2 - ->> RSE_S: Validate, measure, load +RSE_BL2 - ->> SCP_BL1: Validate, measure, load +Rnote over RSE_BL2: RSE_S and SCP_BL1\n\ measurements saved\n\ to a shared buffer +RSE_BL2 -> SCP_BL1: Release from reset activate SCP_BL1 #Green -Rnote over RSS_BL2, SCP_BL1: MHU init between RSS and SCP +Rnote over RSE_BL2, SCP_BL1: MHU init between RSE and SCP Rnote over SCP_BL1: Configure memory -Rnote over RSS_BL2: Waits for SCP -SCP_BL1 - -> RSS_BL2: Done -RSS_BL2 - ->> AP_BL1: Validate, measure, load -Rnote over RSS_BL2: AP_BL1 measurement\n\ saved to a shared buffer -RSS_BL2 -> AP_BL1: Release from reset +Rnote over RSE_BL2: Waits for SCP +SCP_BL1 - -> RSE_BL2: Done +RSE_BL2 - ->> AP_BL1: Validate, measure, load +Rnote over RSE_BL2: AP_BL1 measurement\n\ saved to a shared buffer +RSE_BL2 -> AP_BL1: Release from reset activate AP_BL1 #Green -RSS_BL2 -> RSS_S: Pass execution -deactivate RSS_BL2 -activate RSS_S #Green -Rnote over RSS_S: Measurements read from\n\ shared buffer and saved by\nMeasured Boot service to\n\ measurement slots. +RSE_BL2 -> RSE_S: Pass execution +deactivate RSE_BL2 +activate RSE_S #Green +Rnote over RSE_S: Measurements read from\n\ shared buffer and saved by\nMeasured Boot service to\n\ measurement slots. -== RSS Runtime / AP Boot phase == -Rnote over RSS_S, AP_BL1: MHU init between RSS and AP +== RSE Runtime / AP Boot phase == +Rnote over RSE_S, AP_BL1: MHU init between RSE and AP Rnote over AP_BL1: Measure and load:\n\ FW_CONFIG\n\ TB_FW_CONFIG -AP_BL1 -> RSS_S: Extend measurement -Rnote over RSS_S: Measured Boot:\n\ store measurement +AP_BL1 -> RSE_S: Extend measurement +Rnote over RSE_S: Measured Boot:\n\ store measurement AP_BL1 - ->> AP_BL2: Validate, measure,load -AP_BL1 -> RSS_S: Extend measurement -Rnote over RSS_S: Measured Boot:\n\ store measurement +AP_BL1 -> RSE_S: Extend measurement +Rnote over RSE_S: Measured Boot:\n\ store measurement AP_BL1 -> AP_BL2: Pass execution deactivate AP_BL1 activate AP_BL2 #Green Rnote over AP_BL2: Measure and load:\n\ HW_CONFIG -AP_BL2 -> RSS_S: Extend measurement -Rnote over RSS_S: Measured Boot:\n\ store measurement +AP_BL2 -> RSE_S: Extend measurement +Rnote over RSE_S: Measured Boot:\n\ store measurement AP_BL2 - ->> AP_BL31: Validate, measure,load Rnote over AP_BL2: Measure and load:\n\ BL31 -AP_BL2 -> RSS_S: Extend measurement -Rnote over RSS_S: Measured Boot:\n\ store measurement +AP_BL2 -> RSE_S: Extend measurement +Rnote over RSE_S: Measured Boot:\n\ store measurement Rnote over AP_BL2: Measure and load:\n\ RMM -AP_BL2 -> RSS_S: Extend measurement -Rnote over RSS_S: Measured Boot:\n\ store measurement +AP_BL2 -> RSE_S: Extend measurement +Rnote over RSE_S: Measured Boot:\n\ store measurement AP_BL2 -> AP_BL31: Pass execution deactivate AP_BL2 activate AP_BL31 #Green -== RSS / AP Runtime == +== RSE / AP Runtime == @enduml PlantUML version 1.2022.7(Mon Aug 22 19:01:30 CEST 2022) diff --git a/docs/threat_model/firmware_threat_model/index.rst b/docs/threat_model/firmware_threat_model/index.rst index 05b671096..ce1752fdc 100644 --- a/docs/threat_model/firmware_threat_model/index.rst +++ b/docs/threat_model/firmware_threat_model/index.rst @@ -30,7 +30,7 @@ data flow diagram, as well as a list of threats we have identified using the threat_model threat_model_el3_spm threat_model_fvp_r - threat_model_rss_interface + threat_model_rse_interface threat_model_arm_cca threat_model_fw_update_and_recovery diff --git a/docs/threat_model/firmware_threat_model/threat_model_rse_interface.rst b/docs/threat_model/firmware_threat_model/threat_model_rse_interface.rst index 025d2d9be..3b391c145 100644 --- a/docs/threat_model/firmware_threat_model/threat_model_rse_interface.rst +++ b/docs/threat_model/firmware_threat_model/threat_model_rse_interface.rst @@ -1,41 +1,41 @@ -Threat Model for RSS - AP interface +Threat Model for RSE - AP interface *********************************** ************ Introduction ************ This document is an extension for the general TF-A threat-model. It considers -those platforms where a Runtime Security Subsystem (RSS) is included in the SoC +those platforms where a Runtime Security Engine (RSE) is included in the SoC next to the Application Processor (AP). ******************** Target of Evaluation ******************** -The scope of this threat model only includes the interface between the RSS and +The scope of this threat model only includes the interface between the RSE and AP. Otherwise, the TF-A :ref:`Generic Threat Model` document is applicable for -the AP core. The threat model for the RSS firmware will be provided by the RSS +the AP core. The threat model for the RSE firmware will be provided by the RSE firmware project in the future. Data Flow Diagram ================= This diagram is different only from the general TF-A data flow diagram in that -it includes the RSS and highlights the interface between the AP and the RSS -cores. The interface description only focuses on the AP-RSS interface the rest +it includes the RSE and highlights the interface between the AP and the RSE +cores. The interface description only focuses on the AP-RSE interface the rest is the same as in the general TF-A threat-model document. -.. uml:: ../../resources/diagrams/plantuml/tfa_rss_dfd.puml - :caption: Figure 1: TF-A Data Flow Diagram including RSS +.. uml:: ../../resources/diagrams/plantuml/tfa_rse_dfd.puml + :caption: Figure 1: TF-A Data Flow Diagram including RSE -.. table:: Table 1: TF-A - RSS data flow diagram +.. table:: Table 1: TF-A - RSE data flow diagram +-----------------+--------------------------------------------------------+ | Diagram Element | Description | +=================+========================================================+ - | DF7 | | Boot images interact with RSS over a communication | + | DF7 | | Boot images interact with RSE over a communication | | | channel to record boot measurements and get image | | | verification keys. At runtime, BL31 obtains the | - | | realm world attestation signing key from RSS. | + | | realm world attestation signing key from RSE. | +-----------------+--------------------------------------------------------+ Threat Assessment @@ -44,12 +44,12 @@ For this section, please reference the Threat Assessment under the general TF-A threat-model document, :ref:`Generic Threat Model`. All the threats listed there are applicable for the AP core, here only the differences are highlighted. - - ID 11: The access to the communication interface between AP and RSS is + - ID 11: The access to the communication interface between AP and RSE is allowed only for firmware running at EL3. Accidentally exposing this - interface to NSCode can allow malicious code to interact with RSS and + interface to NSCode can allow malicious code to interact with RSE and gain access to sensitive data. - ID 13: Relevant in the context of the realm attestation key, which can be - retrieved by BL31 through DF7. The RSS communication protocol layer + retrieved by BL31 through DF7. The RSE communication protocol layer mitigates against this by clearing its internal buffer when reply is received. The caller of the API must do the same if data is not needed anymore. diff --git a/docs/threat_model/supply_chain_threat_model.rst b/docs/threat_model/supply_chain_threat_model.rst index 386a4b00c..a0fed5c89 100644 --- a/docs/threat_model/supply_chain_threat_model.rst +++ b/docs/threat_model/supply_chain_threat_model.rst @@ -115,7 +115,7 @@ description of each component and where they are sourced from. - *EDK2 UEFI*: Normal world bootloader from the EDK2 project [7]_. We use EDK2 UEFI binaries hosted on tf.org servers for testing [8]_. -Other software components used to test TF-A include U-Boot, Linux kernel, RSS, +Other software components used to test TF-A include U-Boot, Linux kernel, RSE, MCP, and file systems, all sourced from the Arm Reference Platforms teams. TF-A Toolchain