xref: /rk3399_ARM-atf/docs/threat_model/firmware_threat_model/threat_model_firmware_handoff.rst (revision aa2cb429a8c14c6c85fd14c4f0eddb3257418611)
1Threat Model for Firmware Handoff
2~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
3
4Introduction
5************
6
7This document provides a threat model of TF-A firmware for platforms that make
8use of the `Firmware Handoff` framework, which is implemented via the Transfer
9List library (libTL).
10
11Target of Evaluation
12********************
13
14The target of evaluation is the `Transfer List library` implementation of the
15Firmware Handoff specification. This library is a generic implementation shared
16by A class firmware components. It is used to transfer state/metadata (e.g.,
17Device Trees, entrypoint information) between boot stages in TF-A. This includes
18the boot ROM (BL1), trusted boot firmware (BL2), and runtime EL3 firmware
19(BL31).
20
21Assumptions
22===========
23
24The following assumptions are made about the TF-A Firmware Handoff framework
25implementation in TF-A:
26
27- Within the context of Trusted Board Boot (|TBB|), the Transfer List (TL) producer is
28  considered integrity checked.
29- The shared buffer containing the TL is retained until it's consumed, and all
30  necessary cache/coherency operations are performed to ensure the TL is visible to
31  the receiver.
32- Handoff between stages is atomic; that is, there aren't incremental updates or
33  partial reads.
34
35Data Flow Diagram
36=================
37
38From a system perspective, we re-use the :ref:`Generic TF-A threat model
39<tfa_dfd>` Data Flow Diagram (DFD). A generalized DFD showing information flow
40between a TL producer and receiver is presented below. The dataflow DF7 in this
41diagram is representative of dataflows in TF-A where Firmware Handoff might be
42used (e.g., ``DF4``, and ``DF5`` in the generic model).
43
44.. uml:: ../../resources/diagrams/plantuml/firmware_handoff_dfd.puml
45  :caption: Figure 1: Generalized Firmware Handoff Data Flow Diagram
46
47.. table:: Table 1: TF-A Data Flow Diagram Description
48
49  +-----------------+--------------------------------------------------------+
50  | Diagram Element | Description                                            |
51  +=================+========================================================+
52  |       DF7       | | Information produced during any stage of the AP boot |
53  |                 |   process must be stored in or referenced by the       |
54  |                 |   TL so that later stages can access                   |
55  |                 |   and use it.                                          |
56  +-----------------+--------------------------------------------------------+
57
58Threat Assessment
59=================
60
61This analysis follows the same methodology as the :ref:`Generic TF-A threat
62model <threat_analysis>`, adopting the STRIDE framework to categorize and assess
63threats.
64
65From the library’s perspective, the primary asset is the sensitive data conveyed
66through the TL — including platform configuration data, firmware metadata, and
67potentially security-critical values exchanged between boot stages or execution
68environments.
69
70The library’s main security responsibility is to manage the TL safely
71and correctly, ensuring that:
72
73- Sensitive data is not corrupted, tampered with, or misrouted during processing.
74- Confidential information within the TL is not exposed to unauthorized entities
75  or domains.
76- All data handling operations preserve integrity, confidentiality, and
77  availability across trust boundaries (e.g., secure vs. non-secure world).
78
79This includes protection against both malicious manipulation and accidental
80faults, as well as validation of inputs and outputs to prevent memory corruption
81or data leakage.
82
83The following table analyses the :ref:`General Threats` in the context of the
84Firmware Handoff library.
85
86  +----+--------------------------------------------------------+
87  | ID | Comments                                               |
88  +====+========================================================+
89  | 05 | | As in the general case, it’s common to use logging   |
90  |    |   to print information about a TL to the console.      |
91  |    |   Because a TL can include sensitive data, the         |
92  |    |   implementation must prevent said content from being  |
93  |    |   written to the console.                              |
94  |    |                                                        |
95  |    | | Do not log the contents of Transfer Entries when     |
96  |    |   logging is enabled. In production releases only      |
97  |    |   print diagnostic error messages and ensure they do   |
98  |    |   not contain sensitive information.                   |
99  |    |                                                        |
100  |    | | Disable logging by default, and ensure users         |
101  |    |   explicitly opt in and configure their preferred      |
102  |    |   logging setup.                                       |
103  +----+--------------------------------------------------------+
104  | 08 | | A producer typically performs various out-of-band    |
105  |    |   memory operations on the TL. Common scenarios        |
106  |    |   include authentication and loading of the platform   |
107  |    |   |FDT|, and relocation of the TL from one buffer to   |
108  |    |   another.                                             |
109  |    |                                                        |
110  |    | | Any of these operations may corrupt the TL due to    |
111  |    |   copy-related bugs  (e.g., errors in ``memcpy`` or    |
112  |    |   similar  memory manipulation functions).             |
113  |    |                                                        |
114  |    | | Verify the checksum before consuming a TL.           |
115  |    |                                                        |
116  |    | | Note that this mitigation does not stop an           |
117  |    |   attacker from altering the data and                  |
118  |    |   and recalculating the checksum; checksums            |
119  |    |   only help detect data corruption.                    |
120  +----+--------------------------------------------------------+
121  | 13 | | A producer may use a TL to convey sensitive data     |
122  |    |   between stages. If the same TL is used in successive |
123  |    |   stages (e.g., between TF-A  boot stages), sensitive  |
124  |    |   data might be  leaked to later stages.               |
125  |    |                                                        |
126  |    | | This can occur when information is not properly      |
127  |    |   scrubbed during remove operations; or, when one      |
128  |    |   stage relocates a  TL from one location to another   |
129  |    |   (e.g., on-chip SRAM to non-secure DRAM) without      |
130  |    |   removing sensitive data.                             |
131  |    |                                                        |
132  |    | | On TE remove, provide a mechanism for scrubbing an   |
133  |    |   entire transfer entry.                               |
134  +----+--------------------------------------------------------+
135
136*Copyright (c) 2025, Arm Limited. All rights reserved.*
137
138.. _Firmware Handoff: https://firmwarehandoff.github.io/firmware_handoff/main/index.html
139.. _Transfer List library: https://review.trustedfirmware.org/plugins/gitiles/shared/transfer-list-library
140