Threat Model for Firmware Handoff ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Target of Evaluation ******************** The target of this evaluation is the `Transfer List library` implementation of the Firmware Handoff specification. This library is a generic implementation shared by A-class firmware components. It is used to transfer state/metadata (e.g., Device Trees, entrypoint information) between boot stages in TF-A. This includes the boot ROM (BL1), trusted boot firmware (BL2), and runtime EL3 firmware (BL31). It considers the generic case of handing off from more trusted component to a less trusted one (e.g. BL31 to BL33). It does not specifically consider the narrower case where the handoff is confined to TF-A stages only. Relationship to the Generic TF-A Threat Model ********************************************* This document focuses on the Transfer List (TL) library itself and should be read in conjunction with the :ref:`Generic Threat Model`, which covers TF-A as a whole. Within the narrower TF-A context of BL1, BL2, and BL31, the TL producer and consumer are typically TF-A stages that remain within the same broader TF-A security boundary. In that context, some threats from this library-focused analysis do not necessarily need to be considered, especially where they depend on the TL being handed to a less-trusted stage outside TF-A. Even so, it is safer to handle those threats in the same way. Doing so keeps the library robust when it is reused in other handoff paths, preserves defence-in-depth, and avoids relying on platform-specific assumptions about which stages may consume a TL. Assumptions =========== The following assumptions are made about the TF-A Firmware Handoff framework implementation in TF-A: - Within the context of Trusted Board Boot (|TBB|), the Transfer List (TL) producer is considered integrity checked. - The shared buffer containing the TL is retained until it's consumed, and all necessary cache/coherency operations are performed to ensure the TL is visible to the receiver. - Handoff between stages is atomic; that is, there aren't incremental updates or partial reads. Data Flow Diagram ================= A generalized DFD showing information flow between a TL producer and receiver is presented below. The dataflow DF1 in this diagram is representative of dataflows in TF-A where Firmware Handoff might be used (e.g., ``DF4``, and ``DF5`` in the generic model). .. uml:: ../../resources/diagrams/plantuml/firmware_handoff_dfd.puml :caption: Figure 1: Generalized Firmware Handoff Data Flow Diagram .. table:: Table 1: TF-A Data Flow Diagram Description +-----------------+--------------------------------------------------------+ | Diagram Element | Description | +=================+========================================================+ | DF1 | | Input data generated by a TL producer. | +-----------------+--------------------------------------------------------+ Threat Assessment ================= This analysis adopts the STRIDE framework to categorize and assess threats. The primary asset is the sensitive data conveyed through the TL — including platform configuration data, firmware metadata, and potentially security-critical values exchanged between boot stages or execution environments. Its main security responsibility is to manage the TL safely and correctly, ensuring that: - Sensitive data is not corrupted, tampered with, or misrouted during processing. - Confidential information within the TL is not exposed to unauthorized entities or domains. - All data handling operations preserve integrity, confidentiality, and availability across trust boundaries (e.g., secure vs. non-secure world). This includes protection against both malicious manipulation and accidental faults, as well as validation of inputs and outputs to prevent memory corruption or data leakage. +----+--------------------------------------------------------+ | ID | Comments | +====+========================================================+ | 05 | | **Information leak via UART logs** | | | | | | | As in the general case, it’s common to use logging | | | to print information about a TL to the console. | | | Because a TL can include sensitive data, the | | | implementation must prevent said content from being | | | written to the console. | | | | | | | This happens when directly logging sensitive | | | information and more subtly when logging | | | side-channel information that can be used by an | | | attacker to learn about sensitive information. | | | | | | | Do not log the contents of Transfer Entries when | | | logging is enabled. In production releases only | | | print diagnostic error messages and ensure they do | | | not contain sensitive information. | | | | | | | Disable logging by default, and ensure users | | | explicitly opt in and configure their preferred | | | logging setup. | +----+--------------------------------------------------------+ | 08 | | **Transfer List corruption via out-of-band copies** | | | | | | | A producer typically performs various out-of-band | | | memory operations on the TL. Common scenarios | | | include authentication and loading of the platform | | | |FDT|, and relocation of the TL from one buffer to | | | another. | | | | | | | Any of these operations may corrupt the TL due to | | | copy-related bugs (e.g., errors in ``memcpy`` or | | | similar memory manipulation functions). | | | | | | | Verify the checksum before consuming a TL. | | | | | | | Note that this mitigation does not stop an | | | attacker from altering the data and recalculating | | | the checksum; checksums only help detect data | | | corruption. | +----+--------------------------------------------------------+ | 13 | | **Sensitive data exposure from reused TLs** | | | | | | | A producer may use a TL to convey sensitive data | | | between stages. If the same TL is reused across | | | successive interfaces, there is a risk that | | | sensitive data could be exposed to later consumers | | | | | | | This can occur when information is not properly | | | scrubbed during remove operations; or, when one | | | stage relocates a TL from one location to another | | | (e.g., on-chip SRAM to non-secure DRAM) without | | | removing sensitive data. | | | | | | | On TE remove, provide a mechanism for scrubbing an | | | entire transfer entry. | +----+--------------------------------------------------------+ *Copyright (c) 2025-2026, Arm Limited. All rights reserved.* .. _Firmware Handoff: https://firmwarehandoff.github.io/firmware_handoff/main/index.html .. _Transfer List library: https://review.trustedfirmware.org/plugins/gitiles/shared/transfer-list-library