11.1.6. Threat Model for Firmware Handoff

11.1.6.1. 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.

11.1.6.2. 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 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.

11.1.6.2.1. 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.

11.1.6.2.2. 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).

Figure 1: Generalized Firmware Handoff Data Flow Diagram

Table 1: TF-A Data Flow Diagram Description

Diagram Element	Description
DF1	Input data generated by a TL producer.

11.1.6.2.3. 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.