blob: f0caf89f7d68700b8f36cb8e25beaf79ca9a18db [file] [log] [blame]
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001Secure Partition Manager
2************************
3
4.. contents::
5
Olivier Deprez3de57e32022-04-28 18:18:36 +02006.. toctree::
7 ffa-manifest-binding
8
Olivier Deprezecb2fe52020-04-02 15:38:02 +02009Acronyms
10========
11
Olivier Deprez2b0be752021-09-01 10:25:21 +020012+--------+--------------------------------------+
13| CoT | Chain of Trust |
14+--------+--------------------------------------+
15| DMA | Direct Memory Access |
16+--------+--------------------------------------+
17| DTB | Device Tree Blob |
18+--------+--------------------------------------+
19| DTS | Device Tree Source |
20+--------+--------------------------------------+
21| EC | Execution Context |
22+--------+--------------------------------------+
23| FIP | Firmware Image Package |
24+--------+--------------------------------------+
25| FF-A | Firmware Framework for Arm A-profile |
26+--------+--------------------------------------+
27| IPA | Intermediate Physical Address |
28+--------+--------------------------------------+
Olivier Deprez3de57e32022-04-28 18:18:36 +020029| JOP | Jump-Oriented Programming |
30+--------+--------------------------------------+
Olivier Deprez2b0be752021-09-01 10:25:21 +020031| NWd | Normal World |
32+--------+--------------------------------------+
33| ODM | Original Design Manufacturer |
34+--------+--------------------------------------+
35| OEM | Original Equipment Manufacturer |
36+--------+--------------------------------------+
37| PA | Physical Address |
38+--------+--------------------------------------+
39| PE | Processing Element |
40+--------+--------------------------------------+
41| PM | Power Management |
42+--------+--------------------------------------+
43| PVM | Primary VM |
44+--------+--------------------------------------+
Olivier Deprez3de57e32022-04-28 18:18:36 +020045| ROP | Return-Oriented Programming |
46+--------+--------------------------------------+
Olivier Deprez2b0be752021-09-01 10:25:21 +020047| SMMU | System Memory Management Unit |
48+--------+--------------------------------------+
49| SP | Secure Partition |
50+--------+--------------------------------------+
51| SPD | Secure Payload Dispatcher |
52+--------+--------------------------------------+
53| SPM | Secure Partition Manager |
54+--------+--------------------------------------+
55| SPMC | SPM Core |
56+--------+--------------------------------------+
57| SPMD | SPM Dispatcher |
58+--------+--------------------------------------+
59| SiP | Silicon Provider |
60+--------+--------------------------------------+
61| SWd | Secure World |
62+--------+--------------------------------------+
63| TLV | Tag-Length-Value |
64+--------+--------------------------------------+
65| TOS | Trusted Operating System |
66+--------+--------------------------------------+
67| VM | Virtual Machine |
68+--------+--------------------------------------+
Olivier Deprezecb2fe52020-04-02 15:38:02 +020069
70Foreword
71========
72
Olivier Deprez3de57e32022-04-28 18:18:36 +020073Three implementations of a Secure Partition Manager co-exist in the TF-A
74codebase:
Olivier Deprezecb2fe52020-04-02 15:38:02 +020075
Olivier Deprez3de57e32022-04-28 18:18:36 +020076#. S-EL2 SPMC based on the FF-A specification `[1]`_, enabling virtualization in
77 the secure world, managing multiple S-EL1 or S-EL0 partitions.
78#. EL3 SPMC based on the FF-A specification, managing a single S-EL1 partition
79 without virtualization in the secure world.
80#. EL3 SPM based on the MM specification, legacy implementation managing a
81 single S-EL0 partition `[2]`_.
Olivier Deprezecb2fe52020-04-02 15:38:02 +020082
Olivier Deprez3de57e32022-04-28 18:18:36 +020083These implementations differ in their respective SW architecture and only one
84can be selected at build time. This document:
Olivier Deprezecb2fe52020-04-02 15:38:02 +020085
Olivier Deprez3de57e32022-04-28 18:18:36 +020086- describes the implementation from bullet 1. when the SPMC resides at S-EL2.
Olivier Deprez5e0a73f2021-04-30 14:42:24 +020087- is not an architecture specification and it might provide assumptions
88 on sections mandated as implementation-defined in the specification.
Olivier Deprez3de57e32022-04-28 18:18:36 +020089- covers the implications to TF-A used as a bootloader, and Hafnium used as a
90 reference code base for an S-EL2/SPMC secure firmware on platforms
91 implementing the FEAT_SEL2 architecture extension.
Olivier Deprezecb2fe52020-04-02 15:38:02 +020092
93Terminology
94-----------
95
Olivier Deprez5e0a73f2021-04-30 14:42:24 +020096- The term Hypervisor refers to the NS-EL2 component managing Virtual Machines
97 (or partitions) in the normal world.
98- The term SPMC refers to the S-EL2 component managing secure partitions in
99 the secure world when the FEAT_SEL2 architecture extension is implemented.
100- Alternatively, SPMC can refer to an S-EL1 component, itself being a secure
101 partition and implementing the FF-A ABI on platforms not implementing the
102 FEAT_SEL2 architecture extension.
103- The term VM refers to a normal world Virtual Machine managed by an Hypervisor.
104- The term SP refers to a secure world "Virtual Machine" managed by an SPMC.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200105
106Support for legacy platforms
107----------------------------
108
Olivier Deprez3de57e32022-04-28 18:18:36 +0200109The SPM is split into a dispatcher and a core component (respectively SPMD and
110SPMC) residing at different exception levels. To permit the FF-A specification
111adoption and a smooth migration, the SPMD supports an SPMC residing either at
112S-EL1 or S-EL2:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200113
Olivier Deprez3de57e32022-04-28 18:18:36 +0200114- The SPMD is located at EL3 and mainly relays the FF-A protocol from NWd
115 (Hypervisor or OS kernel) to the SPMC.
116- The same SPMD component is used for both S-EL1 and S-EL2 SPMC configurations.
117- The SPMC exception level is a build time choice.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200118
Olivier Deprez3de57e32022-04-28 18:18:36 +0200119TF-A supports both cases:
120
121- S-EL1 SPMC for platforms not supporting the FEAT_SEL2 architecture
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200122 extension. The SPMD relays the FF-A protocol from EL3 to S-EL1.
Olivier Deprez3de57e32022-04-28 18:18:36 +0200123- S-EL2 SPMC for platforms implementing the FEAT_SEL2 architecture
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200124 extension. The SPMD relays the FF-A protocol from EL3 to S-EL2.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200125
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200126Sample reference stack
127======================
128
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200129The following diagram illustrates a possible configuration when the
130FEAT_SEL2 architecture extension is implemented, showing the SPMD
131and SPMC, one or multiple secure partitions, with an optional
132Hypervisor:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200133
134.. image:: ../resources/diagrams/ff-a-spm-sel2.png
135
136TF-A build options
137==================
138
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200139This section explains the TF-A build options involved in building with
140support for an FF-A based SPM where the SPMD is located at EL3 and the
Marc Bonniciabaac162021-12-01 18:00:40 +0000141SPMC located at S-EL1, S-EL2 or EL3:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200142
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200143- **SPD=spmd**: this option selects the SPMD component to relay the FF-A
144 protocol from NWd to SWd back and forth. It is not possible to
145 enable another Secure Payload Dispatcher when this option is chosen.
146- **SPMD_SPM_AT_SEL2**: this option adjusts the SPMC exception
Marc Bonniciabaac162021-12-01 18:00:40 +0000147 level to being at S-EL2. It defaults to enabled (value 1) when
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200148 SPD=spmd is chosen.
Marc Bonniciabaac162021-12-01 18:00:40 +0000149- **SPMC_AT_EL3**: this option adjusts the SPMC exception level to being
150 at EL3.
Olivier Deprez3de57e32022-04-28 18:18:36 +0200151- If neither ``SPMD_SPM_AT_SEL2`` or ``SPMC_AT_EL3`` are enabled the SPMC
Marc Bonniciabaac162021-12-01 18:00:40 +0000152 exception level is set to S-EL1.
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200153 ``SPMD_SPM_AT_SEL2`` is enabled. The context save/restore routine
154 and exhaustive list of registers is visible at `[4]`_.
155- **SP_LAYOUT_FILE**: this option specifies a text description file
156 providing paths to SP binary images and manifests in DTS format
157 (see `Describing secure partitions`_). It
158 is required when ``SPMD_SPM_AT_SEL2`` is enabled hence when multiple
Olivier Deprez3de57e32022-04-28 18:18:36 +0200159 secure partitions are to be loaded by BL2 on behalf of the SPMC.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200160
Govindraj Raja0264d6c2022-11-21 13:10:40 +0000161+---------------+------------------+-------------+-------------------------+
162| | SPMD_SPM_AT_SEL2 | SPMC_AT_EL3 | CTX_INCLUDE_EL2_REGS(*) |
163+---------------+------------------+-------------+-------------------------+
164| SPMC at S-EL1 | 0 | 0 | 0 |
165+---------------+------------------+-------------+-------------------------+
166| SPMC at S-EL2 | 1 (default when | 0 | 1 |
167| | SPD=spmd) | | |
168+---------------+------------------+-------------+-------------------------+
169| SPMC at EL3 | 0 | 1 | 0 |
170+---------------+------------------+-------------+-------------------------+
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200171
172Other combinations of such build options either break the build or are not
173supported.
174
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200175Notes:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200176
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200177- Only Arm's FVP platform is supported to use with the TF-A reference software
178 stack.
Olivier Deprez3de57e32022-04-28 18:18:36 +0200179- When ``SPMD_SPM_AT_SEL2=1``, the reference software stack assumes enablement
180 of FEAT_PAuth, FEAT_BTI and FEAT_MTE architecture extensions.
Govindraj Raja0264d6c2022-11-21 13:10:40 +0000181- ``(*) CTX_INCLUDE_EL2_REGS``, this flag is |TF-A| internal and informational
182 in this table. When set, it provides the generic support for saving/restoring
183 EL2 registers required when S-EL2 firmware is present.
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200184- BL32 option is re-purposed to specify the SPMC image. It can specify either
185 the Hafnium binary path (built for the secure world) or the path to a TEE
186 binary implementing FF-A interfaces.
187- BL33 option can specify the TFTF binary or a normal world loader
Olivier Deprez3de57e32022-04-28 18:18:36 +0200188 such as U-Boot or the UEFI framework payload.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200189
Olivier Deprez3de57e32022-04-28 18:18:36 +0200190Sample TF-A build command line when the SPMC is located at S-EL1
191(e.g. when the FEAT_SEL2 architecture extension is not implemented):
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200192
193.. code:: shell
194
195 make \
196 CROSS_COMPILE=aarch64-none-elf- \
197 SPD=spmd \
198 SPMD_SPM_AT_SEL2=0 \
199 BL32=<path-to-tee-binary> \
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200200 BL33=<path-to-bl33-binary> \
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200201 PLAT=fvp \
202 all fip
203
Olivier Deprez3de57e32022-04-28 18:18:36 +0200204Sample TF-A build command line when FEAT_SEL2 architecture extension is
205implemented and the SPMC is located at S-EL2:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200206.. code:: shell
207
208 make \
209 CROSS_COMPILE=aarch64-none-elf- \
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200210 PLAT=fvp \
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200211 SPD=spmd \
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200212 ARM_ARCH_MINOR=5 \
213 BRANCH_PROTECTION=1 \
214 CTX_INCLUDE_PAUTH_REGS=1 \
Olivier Deprez3de57e32022-04-28 18:18:36 +0200215 CTX_INCLUDE_MTE_REGS=1 \
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200216 BL32=<path-to-hafnium-binary> \
217 BL33=<path-to-bl33-binary> \
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200218 SP_LAYOUT_FILE=sp_layout.json \
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200219 all fip
220
Olivier Deprez3de57e32022-04-28 18:18:36 +0200221Sample TF-A build command line when FEAT_SEL2 architecture extension is
222implemented, the SPMC is located at S-EL2, and enabling secure boot:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200223.. code:: shell
224
225 make \
226 CROSS_COMPILE=aarch64-none-elf- \
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200227 PLAT=fvp \
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200228 SPD=spmd \
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200229 ARM_ARCH_MINOR=5 \
230 BRANCH_PROTECTION=1 \
231 CTX_INCLUDE_PAUTH_REGS=1 \
Olivier Deprez3de57e32022-04-28 18:18:36 +0200232 CTX_INCLUDE_MTE_REGS=1 \
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200233 BL32=<path-to-hafnium-binary> \
234 BL33=<path-to-bl33-binary> \
235 SP_LAYOUT_FILE=sp_layout.json \
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200236 MBEDTLS_DIR=<path-to-mbedtls-lib> \
237 TRUSTED_BOARD_BOOT=1 \
238 COT=dualroot \
239 ARM_ROTPK_LOCATION=devel_rsa \
240 ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem \
241 GENERATE_COT=1 \
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200242 all fip
243
Olivier Deprez3de57e32022-04-28 18:18:36 +0200244Sample TF-A build command line when the SPMC is located at EL3:
Marc Bonniciabaac162021-12-01 18:00:40 +0000245
246.. code:: shell
247
248 make \
249 CROSS_COMPILE=aarch64-none-elf- \
250 SPD=spmd \
251 SPMD_SPM_AT_SEL2=0 \
252 SPMC_AT_EL3=1 \
253 BL32=<path-to-tee-binary> \
254 BL33=<path-to-bl33-binary> \
255 PLAT=fvp \
256 all fip
257
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200258FVP model invocation
259====================
260
261The FVP command line needs the following options to exercise the S-EL2 SPMC:
262
263+---------------------------------------------------+------------------------------------+
264| - cluster0.has_arm_v8-5=1 | Implements FEAT_SEL2, FEAT_PAuth, |
265| - cluster1.has_arm_v8-5=1 | and FEAT_BTI. |
266+---------------------------------------------------+------------------------------------+
267| - pci.pci_smmuv3.mmu.SMMU_AIDR=2 | Parameters required for the |
268| - pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B | SMMUv3.2 modeling. |
269| - pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 | |
270| - pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 | |
271| - pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0472 | |
272| - pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 | |
273| - pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 | |
274| - pci.pci_smmuv3.mmu.SMMU_S_IDR3=0 | |
275+---------------------------------------------------+------------------------------------+
276| - cluster0.has_branch_target_exception=1 | Implements FEAT_BTI. |
277| - cluster1.has_branch_target_exception=1 | |
278+---------------------------------------------------+------------------------------------+
Olivier Deprez3de57e32022-04-28 18:18:36 +0200279| - cluster0.has_pointer_authentication=2 | Implements FEAT_PAuth |
280| - cluster1.has_pointer_authentication=2 | |
281+---------------------------------------------------+------------------------------------+
282| - cluster0.memory_tagging_support_level=2 | Implements FEAT_MTE2 |
283| - cluster1.memory_tagging_support_level=2 | |
284| - bp.dram_metadata.is_enabled=1 | |
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200285+---------------------------------------------------+------------------------------------+
286
287Sample FVP command line invocation:
288
289.. code:: shell
290
Olivier Deprez3de57e32022-04-28 18:18:36 +0200291 <path-to-fvp-model>/FVP_Base_RevC-2xAEMvA -C pctl.startup=0.0.0.0 \
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200292 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 \
293 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin \
294 -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin \
295 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log \
296 -C bp.pl011_uart2.out_file=fvp-uart2.log \
Olivier Deprez3de57e32022-04-28 18:18:36 +0200297 -C cluster0.has_arm_v8-5=1 -C cluster1.has_arm_v8-5=1 \
298 -C cluster0.has_pointer_authentication=2 -C cluster1.has_pointer_authentication=2 \
299 -C cluster0.has_branch_target_exception=1 -C cluster1.has_branch_target_exception=1 \
300 -C cluster0.memory_tagging_support_level=2 -C cluster1.memory_tagging_support_level=2 \
301 -C bp.dram_metadata.is_enabled=1 \
302 -C pci.pci_smmuv3.mmu.SMMU_AIDR=2 -C pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B \
303 -C pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 -C pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 \
304 -C pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0472 -C pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 \
305 -C pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 -C pci.pci_smmuv3.mmu.SMMU_S_IDR3=0
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200306
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200307Boot process
308============
309
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200310Loading Hafnium and secure partitions in the secure world
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200311---------------------------------------------------------
312
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200313TF-A BL2 is the bootlader for the SPMC and SPs in the secure world.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200314
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200315SPs may be signed by different parties (SiP, OEM/ODM, TOS vendor, etc.).
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200316Thus they are supplied as distinct signed entities within the FIP flash
317image. The FIP image itself is not signed hence this provides the ability
318to upgrade SPs in the field.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200319
320Booting through TF-A
321--------------------
322
323SP manifests
324~~~~~~~~~~~~
325
326An SP manifest describes SP attributes as defined in `[1]`_
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200327(partition manifest at virtual FF-A instance) in DTS format. It is
328represented as a single file associated with the SP. A sample is
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200329provided by `[5]`_. A binding document is provided by `[6]`_.
330
331Secure Partition packages
332~~~~~~~~~~~~~~~~~~~~~~~~~
333
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200334Secure partitions are bundled as independent package files consisting
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200335of:
336
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200337- a header
338- a DTB
339- an image payload
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200340
341The header starts with a magic value and offset values to SP DTB and
342image payload. Each SP package is loaded independently by BL2 loader
343and verified for authenticity and integrity.
344
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200345The SP package identified by its UUID (matching FF-A uuid property) is
346inserted as a single entry into the FIP at end of the TF-A build flow
347as shown:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200348
349.. code:: shell
350
351 Trusted Boot Firmware BL2: offset=0x1F0, size=0x8AE1, cmdline="--tb-fw"
352 EL3 Runtime Firmware BL31: offset=0x8CD1, size=0x13000, cmdline="--soc-fw"
353 Secure Payload BL32 (Trusted OS): offset=0x1BCD1, size=0x15270, cmdline="--tos-fw"
354 Non-Trusted Firmware BL33: offset=0x30F41, size=0x92E0, cmdline="--nt-fw"
355 HW_CONFIG: offset=0x3A221, size=0x2348, cmdline="--hw-config"
356 TB_FW_CONFIG: offset=0x3C569, size=0x37A, cmdline="--tb-fw-config"
357 SOC_FW_CONFIG: offset=0x3C8E3, size=0x48, cmdline="--soc-fw-config"
358 TOS_FW_CONFIG: offset=0x3C92B, size=0x427, cmdline="--tos-fw-config"
359 NT_FW_CONFIG: offset=0x3CD52, size=0x48, cmdline="--nt-fw-config"
360 B4B5671E-4A90-4FE1-B81F-FB13DAE1DACB: offset=0x3CD9A, size=0xC168, cmdline="--blob"
361 D1582309-F023-47B9-827C-4464F5578FC8: offset=0x48F02, size=0xC168, cmdline="--blob"
362
363.. uml:: ../resources/diagrams/plantuml/fip-secure-partitions.puml
364
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200365Describing secure partitions
366~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200367
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200368A json-formatted description file is passed to the build flow specifying paths
369to the SP binary image and associated DTS partition manifest file. The latter
370is processed by the dtc compiler to generate a DTB fed into the SP package.
J-Alvescfc6e232022-05-24 12:13:08 +0100371Optionally, the partition's json description can contain offsets for both
372the image and partition manifest within the SP package. Both offsets need to be
3734KB aligned, because it is the translation granule supported by Hafnium SPMC.
374These fields can be leveraged to support SPs with S1 translation granules that
375differ from 4KB, and to configure the regions allocated within the SP package,
376as well as to comply with the requirements for the implementation of the boot
377information protocol (see `Passing boot data to the SP`_ for more details). In
378case the offsets are absent in their json node, they default to 0x1000 and
3790x4000 for the manifest offset and image offset respectively.
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200380This file also specifies the SP owner (as an optional field) identifying the
381signing domain in case of dual root CoT.
382The SP owner can either be the silicon or the platform provider. The
383corresponding "owner" field value can either take the value of "SiP" or "Plat".
384In absence of "owner" field, it defaults to "SiP" owner.
Imre Kis3f370fd2022-02-08 18:06:18 +0100385The UUID of the partition can be specified as a field in the description file or
386if it does not exist there the UUID is extracted from the DTS partition
387manifest.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200388
389.. code:: shell
390
391 {
392 "tee1" : {
393 "image": "tee1.bin",
Manish Pandey77870962020-08-12 17:06:25 +0100394 "pm": "tee1.dts",
Imre Kis3f370fd2022-02-08 18:06:18 +0100395 "owner": "SiP",
396 "uuid": "1b1820fe-48f7-4175-8999-d51da00b7c9f"
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200397 },
398
399 "tee2" : {
400 "image": "tee2.bin",
Manish Pandey77870962020-08-12 17:06:25 +0100401 "pm": "tee2.dts",
402 "owner": "Plat"
J-Alvescfc6e232022-05-24 12:13:08 +0100403 },
404
405 "tee3" : {
406 "image": {
407 "file": "tee3.bin",
408 "offset":"0x2000"
409 },
410 "pm": {
411 "file": "tee3.dts",
412 "offset":"0x6000"
413 },
414 "owner": "Plat"
415 },
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200416 }
417
418SPMC manifest
419~~~~~~~~~~~~~
420
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200421This manifest contains the SPMC *attribute* node consumed by the SPMD at boot
422time. It implements `[1]`_ (SP manifest at physical FF-A instance) and serves
423two different cases:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200424
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200425- The SPMC resides at S-EL1: the SPMC manifest is used by the SPMD to setup a
426 SP that co-resides with the SPMC and executes at S-EL1 or Secure Supervisor
427 mode.
428- The SPMC resides at S-EL2: the SPMC manifest is used by the SPMD to setup
429 the environment required by the SPMC to run at S-EL2. SPs run at S-EL1 or
430 S-EL0.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200431
432.. code:: shell
433
434 attribute {
435 spmc_id = <0x8000>;
436 maj_ver = <0x1>;
Olivier Deprez3de57e32022-04-28 18:18:36 +0200437 min_ver = <0x1>;
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200438 exec_state = <0x0>;
439 load_address = <0x0 0x6000000>;
440 entrypoint = <0x0 0x6000000>;
441 binary_size = <0x60000>;
442 };
443
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200444- *spmc_id* defines the endpoint ID value that SPMC can query through
445 ``FFA_ID_GET``.
446- *maj_ver/min_ver*. SPMD checks provided version versus its internal
447 version and aborts if not matching.
448- *exec_state* defines the SPMC execution state (AArch64 or AArch32).
449 Notice Hafnium used as a SPMC only supports AArch64.
450- *load_address* and *binary_size* are mostly used to verify secondary
451 entry points fit into the loaded binary image.
452- *entrypoint* defines the cold boot primary core entry point used by
453 SPMD (currently matches ``BL32_BASE``) to enter the SPMC.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200454
455Other nodes in the manifest are consumed by Hafnium in the secure world.
Olivier Deprez3de57e32022-04-28 18:18:36 +0200456A sample can be found at `[7]`_:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200457
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200458- The *hypervisor* node describes SPs. *is_ffa_partition* boolean attribute
459 indicates a FF-A compliant SP. The *load_address* field specifies the load
Olivier Deprez3de57e32022-04-28 18:18:36 +0200460 address at which BL2 loaded the SP package.
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200461- *cpus* node provide the platform topology and allows MPIDR to VMPIDR mapping.
Olivier Deprez3de57e32022-04-28 18:18:36 +0200462 Note the primary core is declared first, then secondary cores are declared
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200463 in reverse order.
464- The *memory* node provides platform information on the ranges of memory
465 available to the SPMC.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200466
467SPMC boot
468~~~~~~~~~
469
470The SPMC is loaded by BL2 as the BL32 image.
471
Olivier Deprez4ab7a4a2021-06-21 09:47:13 +0200472The SPMC manifest is loaded by BL2 as the ``TOS_FW_CONFIG`` image `[9]`_.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200473
474BL2 passes the SPMC manifest address to BL31 through a register.
475
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200476At boot time, the SPMD in BL31 runs from the primary core, initializes the core
Olivier Deprez4ab7a4a2021-06-21 09:47:13 +0200477contexts and launches the SPMC (BL32) passing the following information through
478registers:
479
480- X0 holds the ``TOS_FW_CONFIG`` physical address (or SPMC manifest blob).
481- X1 holds the ``HW_CONFIG`` physical address.
482- X4 holds the currently running core linear id.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200483
484Loading of SPs
485~~~~~~~~~~~~~~
486
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200487At boot time, BL2 loads SPs sequentially in addition to the SPMC as depicted
488below:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200489
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200490.. uml:: ../resources/diagrams/plantuml/bl2-loading-sp.puml
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200491
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200492Note this boot flow is an implementation sample on Arm's FVP platform.
493Platforms not using TF-A's *Firmware CONFiguration* framework would adjust to a
Olivier Deprez3de57e32022-04-28 18:18:36 +0200494different boot flow. The flow restricts to a maximum of 8 secure partitions.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200495
496Secure boot
497~~~~~~~~~~~
498
499The SP content certificate is inserted as a separate FIP item so that BL2 loads SPMC,
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200500SPMC manifest, secure partitions and verifies them for authenticity and integrity.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200501Refer to TBBR specification `[3]`_.
502
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200503The multiple-signing domain feature (in current state dual signing domain `[8]`_) allows
504the use of two root keys namely S-ROTPK and NS-ROTPK:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200505
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200506- SPMC (BL32) and SPMC manifest are signed by the SiP using the S-ROTPK.
507- BL33 may be signed by the OEM using NS-ROTPK.
508- An SP may be signed either by SiP (using S-ROTPK) or by OEM (using NS-ROTPK).
Olivier Deprez3de57e32022-04-28 18:18:36 +0200509- A maximum of 4 partitions can be signed with the S-ROTPK key and 4 partitions
510 signed with the NS-ROTPK key.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200511
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200512Also refer to `Describing secure partitions`_ and `TF-A build options`_ sections.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200513
514Hafnium in the secure world
515===========================
516
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200517General considerations
518----------------------
519
520Build platform for the secure world
521~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
522
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200523In the Hafnium reference implementation specific code parts are only relevant to
524the secure world. Such portions are isolated in architecture specific files
525and/or enclosed by a ``SECURE_WORLD`` macro.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200526
Olivier Deprez3de57e32022-04-28 18:18:36 +0200527Secure partitions scheduling
528~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200529
Olivier Deprez3de57e32022-04-28 18:18:36 +0200530The FF-A specification `[1]`_ provides two ways to relinquinsh CPU time to
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200531secure partitions. For this a VM (Hypervisor or OS kernel), or SP invokes one of:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200532
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200533- the FFA_MSG_SEND_DIRECT_REQ interface.
534- the FFA_RUN interface.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200535
Olivier Deprez3de57e32022-04-28 18:18:36 +0200536Additionally a secure interrupt can pre-empt the normal world execution and give
537CPU cycles by transitioning to EL3 and S-EL2.
538
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200539Platform topology
540~~~~~~~~~~~~~~~~~
541
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200542The *execution-ctx-count* SP manifest field can take the value of one or the
Olivier Deprez3de57e32022-04-28 18:18:36 +0200543total number of PEs. The FF-A specification `[1]`_ recommends the
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200544following SP types:
545
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200546- Pinned MP SPs: an execution context matches a physical PE. MP SPs must
547 implement the same number of ECs as the number of PEs in the platform.
548- Migratable UP SPs: a single execution context can run and be migrated on any
549 physical PE. Such SP declares a single EC in its SP manifest. An UP SP can
550 receive a direct message request originating from any physical core targeting
551 the single execution context.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200552
553Parsing SP partition manifests
554------------------------------
555
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200556Hafnium consumes SP manifests as defined in `[1]`_ and `SP manifests`_.
557Note the current implementation may not implement all optional fields.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200558
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200559The SP manifest may contain memory and device regions nodes. In case of
560an S-EL2 SPMC:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200561
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200562- Memory regions are mapped in the SP EL1&0 Stage-2 translation regime at
563 load time (or EL1&0 Stage-1 for an S-EL1 SPMC). A memory region node can
564 specify RX/TX buffer regions in which case it is not necessary for an SP
565 to explicitly invoke the ``FFA_RXTX_MAP`` interface.
566- Device regions are mapped in the SP EL1&0 Stage-2 translation regime (or
567 EL1&0 Stage-1 for an S-EL1 SPMC) as peripherals and possibly allocate
568 additional resources (e.g. interrupts).
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200569
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200570For the S-EL2 SPMC, base addresses for memory and device region nodes are IPAs
571provided the SPMC identity maps IPAs to PAs within SP EL1&0 Stage-2 translation
572regime.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200573
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200574Note: in the current implementation both VTTBR_EL2 and VSTTBR_EL2 point to the
575same set of page tables. It is still open whether two sets of page tables shall
576be provided per SP. The memory region node as defined in the specification
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200577provides a memory security attribute hinting to map either to the secure or
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200578non-secure EL1&0 Stage-2 table if it exists.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200579
580Passing boot data to the SP
581---------------------------
582
J-Alvescfc6e232022-05-24 12:13:08 +0100583In `[1]`_ , the section "Boot information protocol" defines a method for passing
584data to the SPs at boot time. It specifies the format for the boot information
585descriptor and boot information header structures, which describe the data to be
586exchanged between SPMC and SP.
587The specification also defines the types of data that can be passed.
588The aggregate of both the boot info structures and the data itself is designated
589the boot information blob, and is passed to a Partition as a contiguous memory
590region.
591
592Currently, the SPM implementation supports the FDT type which is used to pass the
593partition's DTB manifest.
594
595The region for the boot information blob is allocated through the SP package.
596
597.. image:: ../resources/diagrams/partition-package.png
598
599To adjust the space allocated for the boot information blob, the json description
600of the SP (see section `Describing secure partitions`_) shall be updated to contain
601the manifest offset. If no offset is provided the manifest offset defaults to 0x1000,
602which is the page size in the Hafnium SPMC.
603
604The configuration of the boot protocol is done in the SPs manifest. As defined by
605the specification, the manifest field 'gp-register-num' configures the GP register
606which shall be used to pass the address to the partitions boot information blob when
607booting the partition.
608In addition, the Hafnium SPMC implementation requires the boot information arguments
609to be listed in a designated DT node:
610
611.. code:: shell
612
613 boot-info {
614 compatible = "arm,ffa-manifest-boot-info";
615 ffa_manifest;
616 };
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200617
J-Alvescfc6e232022-05-24 12:13:08 +0100618The whole secure partition package image (see `Secure Partition packages`_) is
619mapped to the SP secure EL1&0 Stage-2 translation regime. As such, the SP can
620retrieve the address for the boot information blob in the designated GP register,
621process the boot information header and descriptors, access its own manifest
622DTB blob and extract its partition manifest properties.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200623
624SP Boot order
625-------------
626
627SP manifests provide an optional boot order attribute meant to resolve
628dependencies such as an SP providing a service required to properly boot
J-Alves855fc882021-12-14 16:02:27 +0000629another SP. SPMC boots the SPs in accordance to the boot order attribute,
630lowest to the highest value. If the boot order attribute is absent from the FF-A
631manifest, the SP is treated as if it had the highest boot order value
632(i.e. lowest booting priority).
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200633
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200634It is possible for an SP to call into another SP through a direct request
635provided the latter SP has already been booted.
636
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200637Boot phases
638-----------
639
640Primary core boot-up
641~~~~~~~~~~~~~~~~~~~~
642
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200643Upon boot-up, BL31 hands over to the SPMC (BL32) on the primary boot physical
644core. The SPMC performs its platform initializations and registers the SPMC
645secondary physical core entry point physical address by the use of the
J-Alvesc9ca31c2021-10-04 14:33:51 +0100646`FFA_SECONDARY_EP_REGISTER`_ interface (SMC invocation from the SPMC to the SPMD
647at secure physical FF-A instance).
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200648
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200649The SPMC then creates secure partitions based on SP packages and manifests. Each
650secure partition is launched in sequence (`SP Boot order`_) on their "primary"
651execution context. If the primary boot physical core linear id is N, an MP SP is
652started using EC[N] on PE[N] (see `Platform topology`_). If the partition is a
653UP SP, it is started using its unique EC0 on PE[N].
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200654
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200655The SP primary EC (or the EC used when the partition is booted as described
656above):
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200657
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200658- Performs the overall SP boot time initialization, and in case of a MP SP,
659 prepares the SP environment for other execution contexts.
660- In the case of a MP SP, it invokes the FFA_SECONDARY_EP_REGISTER at secure
661 virtual FF-A instance (SMC invocation from SP to SPMC) to provide the IPA
662 entry point for other execution contexts.
663- Exits through ``FFA_MSG_WAIT`` to indicate successful initialization or
664 ``FFA_ERROR`` in case of failure.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200665
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200666Secondary cores boot-up
667~~~~~~~~~~~~~~~~~~~~~~~
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200668
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200669Once the system is started and NWd brought up, a secondary physical core is
670woken up by the ``PSCI_CPU_ON`` service invocation. The TF-A SPD hook mechanism
671calls into the SPMD on the newly woken up physical core. Then the SPMC is
672entered at the secondary physical core entry point.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200673
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200674In the current implementation, the first SP is resumed on the coresponding EC
675(the virtual CPU which matches the physical core). The implication is that the
676first SP must be a MP SP.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200677
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200678In a linux based system, once secure and normal worlds are booted but prior to
679a NWd FF-A driver has been loaded:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200680
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200681- The first SP has initialized all its ECs in response to primary core boot up
682 (at system initialization) and secondary core boot up (as a result of linux
683 invoking PSCI_CPU_ON for all secondary cores).
684- Other SPs have their first execution context initialized as a result of secure
685 world initialization on the primary boot core. Other ECs for those SPs have to
686 be run first through ffa_run to complete their initialization (which results
687 in the EC completing with FFA_MSG_WAIT).
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200688
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200689Refer to `Power management`_ for further details.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200690
J-Alvesc9ca31c2021-10-04 14:33:51 +0100691Notifications
692-------------
693
694The FF-A v1.1 specification `[1]`_ defines notifications as an asynchronous
695communication mechanism with non-blocking semantics. It allows for one FF-A
696endpoint to signal another for service provision, without hindering its current
697progress.
698
699Hafnium currently supports 64 notifications. The IDs of each notification define
700a position in a 64-bit bitmap.
701
702The signaling of notifications can interchangeably happen between NWd and SWd
703FF-A endpoints.
704
705The SPMC is in charge of managing notifications from SPs to SPs, from SPs to
706VMs, and from VMs to SPs. An hypervisor component would only manage
707notifications from VMs to VMs. Given the SPMC has no visibility of the endpoints
708deployed in NWd, the Hypervisor or OS kernel must invoke the interface
709FFA_NOTIFICATION_BITMAP_CREATE to allocate the notifications bitmap per FF-A
710endpoint in the NWd that supports it.
711
712A sender can signal notifications once the receiver has provided it with
713permissions. Permissions are provided by invoking the interface
714FFA_NOTIFICATION_BIND.
715
716Notifications are signaled by invoking FFA_NOTIFICATION_SET. Henceforth
717they are considered to be in a pending sate. The receiver can retrieve its
718pending notifications invoking FFA_NOTIFICATION_GET, which, from that moment,
719are considered to be handled.
720
721Per the FF-A v1.1 spec, each FF-A endpoint must be associated with a scheduler
722that is in charge of donating CPU cycles for notifications handling. The
723FF-A driver calls FFA_NOTIFICATION_INFO_GET to retrieve the information about
724which FF-A endpoints have pending notifications. The receiver scheduler is
725called and informed by the FF-A driver, and it should allocate CPU cycles to the
726receiver.
727
728There are two types of notifications supported:
Olivier Deprez3de57e32022-04-28 18:18:36 +0200729
J-Alvesc9ca31c2021-10-04 14:33:51 +0100730- Global, which are targeted to a FF-A endpoint and can be handled within any of
Olivier Deprez3de57e32022-04-28 18:18:36 +0200731 its execution contexts, as determined by the scheduler of the system.
J-Alvesc9ca31c2021-10-04 14:33:51 +0100732- Per-vCPU, which are targeted to a FF-A endpoint and to be handled within a
Olivier Deprez3de57e32022-04-28 18:18:36 +0200733 a specific execution context, as determined by the sender.
J-Alvesc9ca31c2021-10-04 14:33:51 +0100734
735The type of a notification is set when invoking FFA_NOTIFICATION_BIND to give
736permissions to the sender.
737
738Notification signaling resorts to two interrupts:
J-Alvesc9ca31c2021-10-04 14:33:51 +0100739
Olivier Deprez3de57e32022-04-28 18:18:36 +0200740- Schedule Receiver Interrupt: non-secure physical interrupt to be handled by
741 the FF-A driver within the receiver scheduler. At initialization the SPMC
742 donates a SGI ID chosen from the secure SGI IDs range and configures it as
743 non-secure. The SPMC triggers this SGI on the currently running core when
744 there are pending notifications, and the respective receivers need CPU cycles
745 to handle them.
746- Notifications Pending Interrupt: virtual interrupt to be handled by the
747 receiver of the notification. Set when there are pending notifications for the
748 given secure partition. The NPI is pended when the NWd relinquishes CPU cycles
749 to an SP.
J-Alvesc9ca31c2021-10-04 14:33:51 +0100750
Olivier Deprez3de57e32022-04-28 18:18:36 +0200751The notifications receipt support is enabled in the partition FF-A manifest.
J-Alvesc9ca31c2021-10-04 14:33:51 +0100752
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200753Mandatory interfaces
754--------------------
755
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200756The following interfaces are exposed to SPs:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200757
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200758- ``FFA_VERSION``
759- ``FFA_FEATURES``
760- ``FFA_RX_RELEASE``
761- ``FFA_RXTX_MAP``
J-Alvesc9ca31c2021-10-04 14:33:51 +0100762- ``FFA_RXTX_UNMAP``
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200763- ``FFA_PARTITION_INFO_GET``
764- ``FFA_ID_GET``
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200765- ``FFA_MSG_WAIT``
766- ``FFA_MSG_SEND_DIRECT_REQ``
767- ``FFA_MSG_SEND_DIRECT_RESP``
768- ``FFA_MEM_DONATE``
769- ``FFA_MEM_LEND``
770- ``FFA_MEM_SHARE``
771- ``FFA_MEM_RETRIEVE_REQ``
772- ``FFA_MEM_RETRIEVE_RESP``
773- ``FFA_MEM_RELINQUISH``
Olivier Deprez3de57e32022-04-28 18:18:36 +0200774- ``FFA_MEM_FRAG_RX``
775- ``FFA_MEM_FRAG_TX``
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200776- ``FFA_MEM_RECLAIM``
Olivier Deprez3de57e32022-04-28 18:18:36 +0200777- ``FFA_RUN``
J-Alvesc9ca31c2021-10-04 14:33:51 +0100778
Olivier Deprez3de57e32022-04-28 18:18:36 +0200779As part of the FF-A v1.1 support, the following interfaces were added:
J-Alvesc9ca31c2021-10-04 14:33:51 +0100780
781 - ``FFA_NOTIFICATION_BITMAP_CREATE``
782 - ``FFA_NOTIFICATION_BITMAP_DESTROY``
783 - ``FFA_NOTIFICATION_BIND``
784 - ``FFA_NOTIFICATION_UNBIND``
785 - ``FFA_NOTIFICATION_SET``
786 - ``FFA_NOTIFICATION_GET``
787 - ``FFA_NOTIFICATION_INFO_GET``
788 - ``FFA_SPM_ID_GET``
789 - ``FFA_SECONDARY_EP_REGISTER``
Olivier Deprez3de57e32022-04-28 18:18:36 +0200790 - ``FFA_MEM_PERM_GET``
791 - ``FFA_MEM_PERM_SET``
J-Alves4256a272022-10-26 13:46:37 +0100792 - ``FFA_MSG_SEND2``
793 - ``FFA_RX_ACQUIRE``
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200794
795FFA_VERSION
796~~~~~~~~~~~
797
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200798``FFA_VERSION`` requires a *requested_version* parameter from the caller.
799The returned value depends on the caller:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200800
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200801- Hypervisor or OS kernel in NS-EL1/EL2: the SPMD returns the SPMC version
802 specified in the SPMC manifest.
803- SP: the SPMC returns its own implemented version.
804- SPMC at S-EL1/S-EL2: the SPMD returns its own implemented version.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200805
806FFA_FEATURES
807~~~~~~~~~~~~
808
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200809FF-A features supported by the SPMC may be discovered by secure partitions at
810boot (that is prior to NWd is booted) or run-time.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200811
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200812The SPMC calling FFA_FEATURES at secure physical FF-A instance always get
813FFA_SUCCESS from the SPMD.
814
815The request made by an Hypervisor or OS kernel is forwarded to the SPMC and
816the response relayed back to the NWd.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200817
818FFA_RXTX_MAP/FFA_RXTX_UNMAP
819~~~~~~~~~~~~~~~~~~~~~~~~~~~
820
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200821When invoked from a secure partition FFA_RXTX_MAP maps the provided send and
822receive buffers described by their IPAs to the SP EL1&0 Stage-2 translation
823regime as secure buffers in the MMU descriptors.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200824
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200825When invoked from the Hypervisor or OS kernel, the buffers are mapped into the
826SPMC EL2 Stage-1 translation regime and marked as NS buffers in the MMU
J-Alves4256a272022-10-26 13:46:37 +0100827descriptors. The provided addresses may be owned by a VM in the normal world,
828which is expected to receive messages from the secure world. The SPMC will in
829this case allocate internal state structures to facilitate RX buffer access
830synchronization (through FFA_RX_ACQUIRE interface), and to permit SPs to send
831messages.
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200832
J-Alvesc9ca31c2021-10-04 14:33:51 +0100833The FFA_RXTX_UNMAP unmaps the RX/TX pair from the translation regime of the
834caller, either it being the Hypervisor or OS kernel, as well as a secure
835partition.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200836
837FFA_PARTITION_INFO_GET
838~~~~~~~~~~~~~~~~~~~~~~
839
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200840Partition info get call can originate:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200841
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200842- from SP to SPMC
843- from Hypervisor or OS kernel to SPMC. The request is relayed by the SPMD.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200844
845FFA_ID_GET
846~~~~~~~~~~
847
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200848The FF-A id space is split into a non-secure space and secure space:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200849
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200850- FF-A ID with bit 15 clear relates to VMs.
851- FF-A ID with bit 15 set related to SPs.
852- FF-A IDs 0, 0xffff, 0x8000 are assigned respectively to the Hypervisor, SPMD
853 and SPMC.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200854
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200855The SPMD returns:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200856
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200857- The default zero value on invocation from the Hypervisor.
858- The ``spmc_id`` value specified in the SPMC manifest on invocation from
859 the SPMC (see `SPMC manifest`_)
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200860
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200861This convention helps the SPMC to determine the origin and destination worlds in
862an FF-A ABI invocation. In particular the SPMC shall filter unauthorized
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200863transactions in its world switch routine. It must not be permitted for a VM to
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200864use a secure FF-A ID as origin world by spoofing:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200865
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200866- A VM-to-SP direct request/response shall set the origin world to be non-secure
867 (FF-A ID bit 15 clear) and destination world to be secure (FF-A ID bit 15
868 set).
869- Similarly, an SP-to-SP direct request/response shall set the FF-A ID bit 15
870 for both origin and destination IDs.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200871
872An incoming direct message request arriving at SPMD from NWd is forwarded to
873SPMC without a specific check. The SPMC is resumed through eret and "knows" the
874message is coming from normal world in this specific code path. Thus the origin
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200875endpoint ID must be checked by SPMC for being a normal world ID.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200876
877An SP sending a direct message request must have bit 15 set in its origin
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200878endpoint ID and this can be checked by the SPMC when the SP invokes the ABI.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200879
880The SPMC shall reject the direct message if the claimed world in origin endpoint
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200881ID is not consistent:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200882
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200883- It is either forwarded by SPMD and thus origin endpoint ID must be a "normal
884 world ID",
885- or initiated by an SP and thus origin endpoint ID must be a "secure world ID".
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200886
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200887
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200888FFA_MSG_SEND_DIRECT_REQ/FFA_MSG_SEND_DIRECT_RESP
889~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200890
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200891This is a mandatory interface for secure partitions consisting in direct request
892and responses with the following rules:
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200893
Olivier Deprez5e0a73f2021-04-30 14:42:24 +0200894- An SP can send a direct request to another SP.
895- An SP can receive a direct request from another SP.
896- An SP can send a direct response to another SP.
897- An SP cannot send a direct request to an Hypervisor or OS kernel.
898- An Hypervisor or OS kernel can send a direct request to an SP.
899- An SP can send a direct response to an Hypervisor or OS kernel.
Olivier Deprezecb2fe52020-04-02 15:38:02 +0200900
J-Alvesc9ca31c2021-10-04 14:33:51 +0100901FFA_NOTIFICATION_BITMAP_CREATE/FFA_NOTIFICATION_BITMAP_DESTROY
902~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
903
904The secure partitions notifications bitmap are statically allocated by the SPMC.
905Hence, this interface is not to be issued by secure partitions.
906
907At initialization, the SPMC is not aware of VMs/partitions deployed in the
908normal world. Hence, the Hypervisor or OS kernel must use both ABIs for SPMC
909to be prepared to handle notifications for the provided VM ID.
910
911FFA_NOTIFICATION_BIND/FFA_NOTIFICATION_UNBIND
912~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
913
914Pair of interfaces to manage permissions to signal notifications. Prior to
915handling notifications, an FF-A endpoint must allow a given sender to signal a
916bitmap of notifications.
917
918If the receiver doesn't have notification support enabled in its FF-A manifest,
919it won't be able to bind notifications, hence forbidding it to receive any
920notifications.
921
922FFA_NOTIFICATION_SET/FFA_NOTIFICATION_GET
923~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
924
Olivier Deprez3de57e32022-04-28 18:18:36 +0200925FFA_NOTIFICATION_GET retrieves all pending global notifications and
926per-vCPU notifications targeted to the current vCPU.
J-Alvesc9ca31c2021-10-04 14:33:51 +0100927
Olivier Deprez3de57e32022-04-28 18:18:36 +0200928Hafnium maintains a global count of pending notifications which gets incremented
929and decremented when handling FFA_NOTIFICATION_SET and FFA_NOTIFICATION_GET
930respectively. A delayed SRI is triggered if the counter is non-zero when the
931SPMC returns to normal world.
J-Alvesc9ca31c2021-10-04 14:33:51 +0100932
933FFA_NOTIFICATION_INFO_GET
934~~~~~~~~~~~~~~~~~~~~~~~~~
935
Olivier Deprez3de57e32022-04-28 18:18:36 +0200936Hafnium maintains a global count of pending notifications whose information
937has been retrieved by this interface. The count is incremented and decremented
938when handling FFA_NOTIFICATION_INFO_GET and FFA_NOTIFICATION_GET respectively.
939It also tracks notifications whose information has been retrieved individually,
J-Alvesc9ca31c2021-10-04 14:33:51 +0100940such that it avoids duplicating returned information for subsequent calls to
941FFA_NOTIFICATION_INFO_GET. For each notification, this state information is
942reset when receiver called FFA_NOTIFICATION_GET to retrieve them.
943
944FFA_SPM_ID_GET
945~~~~~~~~~~~~~~
946
Olivier Deprez3de57e32022-04-28 18:18:36 +0200947Returns the FF-A ID allocated to an SPM component which can be one of SPMD
948or SPMC.
J-Alvesc9ca31c2021-10-04 14:33:51 +0100949
Olivier Deprez3de57e32022-04-28 18:18:36 +0200950At initialization, the SPMC queries the SPMD for the SPMC ID, using the
951FFA_ID_GET interface, and records it. The SPMC can also query the SPMD ID using
952the FFA_SPM_ID_GET interface at the secure physical FF-A instance.
J-Alvesc9ca31c2021-10-04 14:33:51 +0100953
Olivier Deprez3de57e32022-04-28 18:18:36 +0200954Secure partitions call this interface at the virtual FF-A instance, to which
955the SPMC returns the priorly retrieved SPMC ID.
J-Alvesc9ca31c2021-10-04 14:33:51 +0100956
Olivier Deprez3de57e32022-04-28 18:18:36 +0200957The Hypervisor or OS kernel can issue the FFA_SPM_ID_GET call handled by the
958SPMD, which returns the SPMC ID.
J-Alvesc9ca31c2021-10-04 14:33:51 +0100959
960FFA_SECONDARY_EP_REGISTER
961~~~~~~~~~~~~~~~~~~~~~~~~~
962
963When the SPMC boots, all secure partitions are initialized on their primary
964Execution Context.
965
Olivier Deprez3de57e32022-04-28 18:18:36 +0200966The FFA_SECONDARY_EP_REGISTER interface is to be used by a secure partition
J-Alvesc9ca31c2021-10-04 14:33:51 +0100967from its first execution context, to provide the entry point address for
968secondary execution contexts.
969
970A secondary EC is first resumed either upon invocation of PSCI_CPU_ON from
971the NWd or by invocation of FFA_RUN.
972
J-Alves4256a272022-10-26 13:46:37 +0100973FFA_RX_ACQUIRE/FFA_RX_RELEASE
974~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
975
976The RX buffers can be used to pass information to an FF-A endpoint in the
977following scenarios:
978
979 - When it was targetted by a FFA_MSG_SEND2 invokation from another endpoint.
980 - Return the result of calling ``FFA_PARTITION_INFO_GET``.
981 - In a memory share operation, as part of the ``FFA_MEM_RETRIEVE_RESP``,
982 with the memory descriptor of the shared memory.
983
984If a normal world VM is expected to exchange messages with secure world,
985its RX/TX buffer addresses are forwarded to the SPMC via FFA_RXTX_MAP ABI,
986and are from this moment owned by the SPMC.
987The hypervisor must call the FFA_RX_ACQUIRE interface before attempting
988to use the RX buffer, in any of the aforementioned scenarios. A successful
989call to FFA_RX_ACQUIRE transfers ownership of RX buffer to hypervisor, such
990that it can be safely used.
991
992The FFA_RX_RELEASE interface is used after the FF-A endpoint is done with
993processing the data received in its RX buffer. If the RX buffer has been
994acquired by the hypervisor, the FFA_RX_RELEASE call must be forwarded to
995the SPMC to reestablish SPMC's RX ownership.
996
997An attempt from an SP to send a message to a normal world VM whose RX buffer
998was acquired by the hypervisor fails with error code FFA_BUSY, to preserve
999the RX buffer integrity.
1000The operation could then be conducted after FFA_RX_RELEASE.
1001
1002FFA_MSG_SEND2
1003~~~~~~~~~~~~~
1004
1005Hafnium copies a message from the sender TX buffer into receiver's RX buffer.
1006For messages from SPs to VMs, operation is only possible if the SPMC owns
1007the receiver's RX buffer.
1008
1009Both receiver and sender need to enable support for indirect messaging,
1010in their respective partition manifest. The discovery of support
1011of such feature can be done via FFA_PARTITION_INFO_GET.
1012
1013On a successful message send, Hafnium pends an RX buffer full framework
1014notification for the receiver, to inform it about a message in the RX buffer.
1015
1016The handling of framework notifications is similar to that of
1017global notifications. Binding of these is not necessary, as these are
1018reserved to be used by the hypervisor or SPMC.
1019
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001020SPMC-SPMD direct requests/responses
1021-----------------------------------
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001022
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001023Implementation-defined FF-A IDs are allocated to the SPMC and SPMD.
1024Using those IDs in source/destination fields of a direct request/response
1025permits SPMD to SPMC communication and either way.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001026
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001027- SPMC to SPMD direct request/response uses SMC conduit.
1028- SPMD to SPMC direct request/response uses ERET conduit.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001029
Olivier Deprez3de57e32022-04-28 18:18:36 +02001030This is used in particular to convey power management messages.
1031
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001032PE MMU configuration
1033--------------------
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001034
Olivier Deprez3de57e32022-04-28 18:18:36 +02001035With secure virtualization enabled (``HCR_EL2.VM = 1``) and for S-EL1
1036partitions, two IPA spaces (secure and non-secure) are output from the
1037secure EL1&0 Stage-1 translation.
1038The EL1&0 Stage-2 translation hardware is fed by:
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001039
Olivier Deprez3de57e32022-04-28 18:18:36 +02001040- A secure IPA when the SP EL1&0 Stage-1 MMU is disabled.
1041- One of secure or non-secure IPA when the secure EL1&0 Stage-1 MMU is enabled.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001042
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001043``VTCR_EL2`` and ``VSTCR_EL2`` provide configuration bits for controlling the
Olivier Deprez3de57e32022-04-28 18:18:36 +02001044NS/S IPA translations. The following controls are set up:
1045``VSTCR_EL2.SW = 0`` , ``VSTCR_EL2.SA = 0``, ``VTCR_EL2.NSW = 0``,
1046``VTCR_EL2.NSA = 1``:
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001047
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001048- Stage-2 translations for the NS IPA space access the NS PA space.
1049- Stage-2 translation table walks for the NS IPA space are to the secure PA space.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001050
Olivier Deprez3de57e32022-04-28 18:18:36 +02001051Secure and non-secure IPA regions (rooted to by ``VTTBR_EL2`` and ``VSTTBR_EL2``)
1052use the same set of Stage-2 page tables within a SP.
1053
1054The ``VTCR_EL2/VSTCR_EL2/VTTBR_EL2/VSTTBR_EL2`` virtual address space
1055configuration is made part of a vCPU context.
1056
1057For S-EL0 partitions with VHE enabled, a single secure EL2&0 Stage-1 translation
1058regime is used for both Hafnium and the partition.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001059
Madhukar Pappireddyd0889a32022-10-03 14:26:48 -05001060Schedule modes and SP Call chains
1061---------------------------------
1062
1063An SP execution context is said to be in SPMC scheduled mode if CPU cycles are
1064allocated to it by SPMC. Correspondingly, an SP execution context is said to be
1065in Normal world scheduled mode if CPU cycles are allocated by the normal world.
1066
1067A call chain represents all SPs in a sequence of invocations of a direct message
1068request. When execution on a PE is in the secure state, only a single call chain
1069that runs in the Normal World scheduled mode can exist. FF-A v1.1 spec allows
1070any number of call chains to run in the SPMC scheduled mode but the Hafnium
1071SPMC restricts the number of call chains in SPMC scheduled mode to only one for
1072keeping the implementation simple.
1073
1074Partition runtime models
1075------------------------
1076
1077The runtime model of an endpoint describes the transitions permitted for an
1078execution context between various states. These are the four partition runtime
1079models supported (refer to `[1]`_ section 7):
1080
1081 - RTM_FFA_RUN: runtime model presented to an execution context that is
1082 allocated CPU cycles through FFA_RUN interface.
1083 - RTM_FFA_DIR_REQ: runtime model presented to an execution context that is
1084 allocated CPU cycles through FFA_MSG_SEND_DIRECT_REQ interface.
1085 - RTM_SEC_INTERRUPT: runtime model presented to an execution context that is
1086 allocated CPU cycles by SPMC to handle a secure interrupt.
1087 - RTM_SP_INIT: runtime model presented to an execution context that is
1088 allocated CPU cycles by SPMC to initialize its state.
1089
1090If an endpoint execution context attempts to make an invalid transition or a
1091valid transition that could lead to a loop in the call chain, SPMC denies the
1092transition with the help of above runtime models.
1093
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001094Interrupt management
1095--------------------
1096
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001097GIC ownership
1098~~~~~~~~~~~~~
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001099
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001100The SPMC owns the GIC configuration. Secure and non-secure interrupts are
1101trapped at S-EL2. The SPMC manages interrupt resources and allocates interrupt
1102IDs based on SP manifests. The SPMC acknowledges physical interrupts and injects
1103virtual interrupts by setting the use of vIRQ/vFIQ bits before resuming a SP.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001104
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001105Abbreviations:
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001106
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001107 - NS-Int: A non-secure physical interrupt. It requires a switch to the normal
1108 world to be handled if it triggers while execution is in secure world.
1109 - Other S-Int: A secure physical interrupt targeted to an SP different from
1110 the one that is currently running.
1111 - Self S-Int: A secure physical interrupt targeted to the SP that is currently
1112 running.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001113
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001114Non-secure interrupt handling
1115~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001116
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001117This section documents the actions supported in SPMC in response to a non-secure
1118interrupt as per the guidance provided by FF-A v1.1 EAC0 specification.
1119An SP specifies one of the following actions in its partition manifest:
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001120
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001121 - Non-secure interrupt is signaled.
1122 - Non-secure interrupt is signaled after a managed exit.
1123 - Non-secure interrupt is queued.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001124
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001125An SP execution context in a call chain could specify a less permissive action
1126than subsequent SP execution contexts in the same call chain. The less
1127permissive action takes precedence over the more permissive actions specified
1128by the subsequent execution contexts. Please refer to FF-A v1.1 EAC0 section
11298.3.1 for further explanation.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001130
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001131Secure interrupt handling
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001132~~~~~~~~~~~~~~~~~~~~~~~~~
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001133
1134This section documents the support implemented for secure interrupt handling in
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001135SPMC as per the guidance provided by FF-A v1.1 EAC0 specification.
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001136The following assumptions are made about the system configuration:
1137
1138 - In the current implementation, S-EL1 SPs are expected to use the para
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001139 virtualized ABIs for interrupt management rather than accessing the virtual
1140 GIC interface.
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001141 - Unless explicitly stated otherwise, this support is applicable only for
1142 S-EL1 SPs managed by SPMC.
1143 - Secure interrupts are configured as G1S or G0 interrupts.
1144 - All physical interrupts are routed to SPMC when running a secure partition
1145 execution context.
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001146 - All endpoints with multiple execution contexts have their contexts pinned
1147 to corresponding CPUs. Hence, a secure virtual interrupt cannot be signaled
1148 to a target vCPU that is currently running or blocked on a different
1149 physical CPU.
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001150
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001151A physical secure interrupt could trigger while CPU is executing in normal world
1152or secure world.
1153The action of SPMC for a secure interrupt depends on: the state of the target
1154execution context of the SP that is responsible for handling the interrupt;
1155whether the interrupt triggered while execution was in normal world or secure
1156world.
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001157
1158Secure interrupt signaling mechanisms
1159~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1160
1161Signaling refers to the mechanisms used by SPMC to indicate to the SP execution
1162context that it has a pending virtual interrupt and to further run the SP
1163execution context, such that it can handle the virtual interrupt. SPMC uses
1164either the FFA_INTERRUPT interface with ERET conduit or vIRQ signal for signaling
1165to S-EL1 SPs. When normal world execution is preempted by a secure interrupt,
1166the SPMD uses the FFA_INTERRUPT ABI with ERET conduit to signal interrupt to SPMC
1167running in S-EL2.
1168
1169+-----------+---------+---------------+---------------------------------------+
1170| SP State | Conduit | Interface and | Description |
1171| | | parameters | |
1172+-----------+---------+---------------+---------------------------------------+
1173| WAITING | ERET, | FFA_INTERRUPT,| SPMC signals to SP the ID of pending |
1174| | vIRQ | Interrupt ID | interrupt. It pends vIRQ signal and |
1175| | | | resumes execution context of SP |
1176| | | | through ERET. |
1177+-----------+---------+---------------+---------------------------------------+
1178| BLOCKED | ERET, | FFA_INTERRUPT | SPMC signals to SP that an interrupt |
1179| | vIRQ | | is pending. It pends vIRQ signal and |
1180| | | | resumes execution context of SP |
1181| | | | through ERET. |
1182+-----------+---------+---------------+---------------------------------------+
1183| PREEMPTED | vIRQ | NA | SPMC pends the vIRQ signal but does |
1184| | | | not resume execution context of SP. |
1185+-----------+---------+---------------+---------------------------------------+
1186| RUNNING | ERET, | NA | SPMC pends the vIRQ signal and resumes|
1187| | vIRQ | | execution context of SP through ERET. |
1188+-----------+---------+---------------+---------------------------------------+
1189
1190Secure interrupt completion mechanisms
1191~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1192
1193A SP signals secure interrupt handling completion to the SPMC through the
1194following mechanisms:
1195
1196 - ``FFA_MSG_WAIT`` ABI if it was in WAITING state.
1197 - ``FFA_RUN`` ABI if its was in BLOCKED state.
1198
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001199This is a remnant of SPMC implementation based on the FF-A v1.0 specification.
1200In the current implementation, S-EL1 SPs use the para-virtualized HVC interface
1201implemented by SPMC to perform priority drop and interrupt deactivation (SPMC
1202configures EOImode = 0, i.e. priority drop and deactivation are done together).
1203The SPMC performs checks to deny the state transition upon invocation of
1204either FFA_MSG_WAIT or FFA_RUN interface if the SP didn't perform the
1205deactivation of the secure virtual interrupt.
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001206
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001207If the current SP execution context was preempted by a secure interrupt to be
1208handled by execution context of target SP, SPMC resumes current SP after signal
1209completion by target SP execution context.
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001210
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001211Actions for a secure interrupt triggered while execution is in normal world
1212~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001213
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001214+-------------------+----------+-----------------------------------------------+
1215| State of target | Action | Description |
1216| execution context | | |
1217+-------------------+----------+-----------------------------------------------+
1218| WAITING | Signaled | This starts a new call chain in SPMC scheduled|
1219| | | mode. |
1220+-------------------+----------+-----------------------------------------------+
1221| PREEMPTED | Queued | The target execution must have been preempted |
1222| | | by a non-secure interrupt. SPMC queues the |
1223| | | secure virtual interrupt now. It is signaled |
1224| | | when the target execution context next enters |
1225| | | the RUNNING state. |
1226+-------------------+----------+-----------------------------------------------+
1227| BLOCKED, RUNNING | NA | The target execution context is blocked or |
1228| | | running on a different CPU. This is not |
1229| | | supported by current SPMC implementation and |
1230| | | execution hits panic. |
1231+-------------------+----------+-----------------------------------------------+
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001232
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001233If normal world execution was preempted by a secure interrupt, SPMC uses
1234FFA_NORMAL_WORLD_RESUME ABI to indicate completion of secure interrupt handling
1235and further returns execution to normal world.
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001236
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001237The following figure describes interrupt handling flow when a secure interrupt
1238triggers while execution is in normal world:
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001239
1240.. image:: ../resources/diagrams/ffa-secure-interrupt-handling-nwd.png
1241
1242A brief description of the events:
1243
1244 - 1) Secure interrupt triggers while normal world is running.
1245 - 2) FIQ gets trapped to EL3.
1246 - 3) SPMD signals secure interrupt to SPMC at S-EL2 using FFA_INTERRUPT ABI.
1247 - 4) SPMC identifies target vCPU of SP and injects virtual interrupt (pends
1248 vIRQ).
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001249 - 5) Assuming SP1 vCPU is in WAITING state, SPMC signals virtual interrupt
1250 using FFA_INTERRUPT with interrupt id as an argument and resumes the SP1
1251 vCPU using ERET in SPMC scheduled mode.
1252 - 6) Execution traps to vIRQ handler in SP1 provided that the virtual
1253 interrupt is not masked i.e., PSTATE.I = 0
1254 - 7) SP1 queries for the pending virtual interrupt id using a paravirtualized
1255 HVC call. SPMC clears the pending virtual interrupt state management
1256 and returns the pending virtual interrupt id.
1257 - 8) SP1 services the virtual interrupt and invokes the paravirtualized
1258 de-activation HVC call. SPMC de-activates the physical interrupt,
1259 clears the fields tracking the secure interrupt and resumes SP1 vCPU.
1260 - 9) SP1 performs secure interrupt completion through FFA_MSG_WAIT ABI.
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001261 - 10) SPMC returns control to EL3 using FFA_NORMAL_WORLD_RESUME.
1262 - 11) EL3 resumes normal world execution.
1263
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001264Actions for a secure interrupt triggered while execution is in secure world
1265~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1266
1267+-------------------+----------+------------------------------------------------+
1268| State of target | Action | Description |
1269| execution context | | |
1270+-------------------+----------+------------------------------------------------+
1271| WAITING | Signaled | This starts a new call chain in SPMC scheduled |
1272| | | mode. |
1273+-------------------+----------+------------------------------------------------+
1274| PREEMPTED by Self | Signaled | The target execution context reenters the |
1275| S-Int | | RUNNING state to handle the secure virtual |
1276| | | interrupt. |
1277+-------------------+----------+------------------------------------------------+
1278| PREEMPTED by | Queued | SPMC queues the secure virtual interrupt now. |
1279| NS-Int | | It is signaled when the target execution |
1280| | | context next enters the RUNNING state. |
1281+-------------------+----------+------------------------------------------------+
1282| BLOCKED | Signaled | Both preempted and target execution contexts |
1283| | | must have been part of the Normal world |
1284| | | scheduled call chain. Refer scenario 1 of |
1285| | | Table 8.4 in the FF-A v1.1 EAC0 spec. |
1286+-------------------+----------+------------------------------------------------+
1287| RUNNING | NA | The target execution context is running on a |
1288| | | different CPU. This scenario is not supported |
1289| | | by current SPMC implementation and execution |
1290| | | hits panic. |
1291+-------------------+----------+------------------------------------------------+
1292
1293The following figure describes interrupt handling flow when a secure interrupt
1294triggers while execution is in secure world. We assume OS kernel sends a direct
1295request message to SP1. Further, SP1 sends a direct request message to SP2. SP1
1296enters BLOCKED state and SPMC resumes SP2.
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001297
1298.. image:: ../resources/diagrams/ffa-secure-interrupt-handling-swd.png
1299
1300A brief description of the events:
1301
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001302 - 1) Secure interrupt triggers while SP2 is running.
1303 - 2) SP2 gets preempted and execution traps to SPMC as IRQ.
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001304 - 3) SPMC finds the target vCPU of secure partition responsible for handling
1305 this secure interrupt. In this scenario, it is SP1.
1306 - 4) SPMC pends vIRQ for SP1 and signals through FFA_INTERRUPT interface.
Madhukar Pappireddy262d7b12022-10-03 18:09:32 -05001307 SPMC further resumes SP1 through ERET conduit. Note that SP1 remains in
1308 Normal world schedule mode.
1309 - 6) Execution traps to vIRQ handler in SP1 provided that the virtual
1310 interrupt is not masked i.e., PSTATE.I = 0
1311 - 7) SP1 queries for the pending virtual interrupt id using a paravirtualized
1312 HVC call. SPMC clears the pending virtual interrupt state management
1313 and returns the pending virtual interrupt id.
1314 - 8) SP1 services the virtual interrupt and invokes the paravirtualized
1315 de-activation HVC call. SPMC de-activates the physical interrupt and
1316 clears the fields tracking the secure interrupt and resumes SP1 vCPU.
1317 - 9) Since SP1 direct request completed with FFA_INTERRUPT, it resumes the
1318 direct request to SP2 by invoking FFA_RUN.
Madhukar Pappireddyb3d37b12021-09-23 14:29:05 -05001319 - 9) SPMC resumes the pre-empted vCPU of SP2.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001320
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001321Power management
1322----------------
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001323
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001324In platforms with or without secure virtualization:
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001325
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001326- The NWd owns the platform PM policy.
1327- The Hypervisor or OS kernel is the component initiating PSCI service calls.
1328- The EL3 PSCI library is in charge of the PM coordination and control
1329 (eventually writing to platform registers).
1330- While coordinating PM events, the PSCI library calls backs into the Secure
1331 Payload Dispatcher for events the latter has statically registered to.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001332
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001333When using the SPMD as a Secure Payload Dispatcher:
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001334
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001335- A power management event is relayed through the SPD hook to the SPMC.
1336- In the current implementation only cpu on (svc_on_finish) and cpu off
1337 (svc_off) hooks are registered.
1338- The behavior for the cpu on event is described in `Secondary cores boot-up`_.
1339 The SPMC is entered through its secondary physical core entry point.
Olivier Deprez3de57e32022-04-28 18:18:36 +02001340- The cpu off event occurs when the NWd calls PSCI_CPU_OFF. The PM event is
1341 signaled to the SPMC through a power management framework message.
1342 It consists in a SPMD-to-SPMC direct request/response (`SPMC-SPMD direct
1343 requests/responses`_) conveying the event details and SPMC response.
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001344 The SPMD performs a synchronous entry into the SPMC. The SPMC is entered and
1345 updates its internal state to reflect the physical core is being turned off.
1346 In the current implementation no SP is resumed as a consequence. This behavior
1347 ensures a minimal support for CPU hotplug e.g. when initiated by the NWd linux
1348 userspace.
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001349
Olivier Deprez3de57e32022-04-28 18:18:36 +02001350Arm architecture extensions for security hardening
1351==================================================
1352
1353Hafnium supports the following architecture extensions for security hardening:
1354
1355- Pointer authentication (FEAT_PAuth): the extension permits detection of forged
1356 pointers used by ROP type of attacks through the signing of the pointer
1357 value. Hafnium is built with the compiler branch protection option to permit
1358 generation of a pointer authentication code for return addresses (pointer
1359 authentication for instructions). The APIA key is used while Hafnium runs.
1360 A random key is generated at boot time and restored upon entry into Hafnium
1361 at run-time. APIA and other keys (APIB, APDA, APDB, APGA) are saved/restored
1362 in vCPU contexts permitting to enable pointer authentication in VMs/SPs.
1363- Branch Target Identification (FEAT_BTI): the extension permits detection of
1364 unexpected indirect branches used by JOP type of attacks. Hafnium is built
1365 with the compiler branch protection option, inserting land pads at function
1366 prologues that are reached by indirect branch instructions (BR/BLR).
1367 Hafnium code pages are marked as guarded in the EL2 Stage-1 MMU descriptors
1368 such that an indirect branch must always target a landpad. A fault is
1369 triggered otherwise. VMs/SPs can (independently) mark their code pages as
1370 guarded in the EL1&0 Stage-1 translation regime.
1371- Memory Tagging Extension (FEAT_MTE): the option permits detection of out of
1372 bound memory array accesses or re-use of an already freed memory region.
1373 Hafnium enables the compiler option permitting to leverage MTE stack tagging
1374 applied to core stacks. Core stacks are marked as normal tagged memory in the
1375 EL2 Stage-1 translation regime. A synchronous data abort is generated upon tag
1376 check failure on load/stores. A random seed is generated at boot time and
1377 restored upon entry into Hafnium. MTE system registers are saved/restored in
1378 vCPU contexts permitting MTE usage from VMs/SPs.
1379
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001380SMMUv3 support in Hafnium
1381=========================
Madhukar Pappireddya9859062021-02-28 14:01:34 -06001382
1383An SMMU is analogous to an MMU in a CPU. It performs address translations for
1384Direct Memory Access (DMA) requests from system I/O devices.
1385The responsibilities of an SMMU include:
1386
1387- Translation: Incoming DMA requests are translated from bus address space to
1388 system physical address space using translation tables compliant to
1389 Armv8/Armv7 VMSA descriptor format.
1390- Protection: An I/O device can be prohibited from read, write access to a
1391 memory region or allowed.
1392- Isolation: Traffic from each individial device can be independently managed.
1393 The devices are differentiated from each other using unique translation
1394 tables.
1395
1396The following diagram illustrates a typical SMMU IP integrated in a SoC with
1397several I/O devices along with Interconnect and Memory system.
1398
1399.. image:: ../resources/diagrams/MMU-600.png
1400
1401SMMU has several versions including SMMUv1, SMMUv2 and SMMUv3. Hafnium provides
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001402support for SMMUv3 driver in both normal and secure world. A brief introduction
Madhukar Pappireddya9859062021-02-28 14:01:34 -06001403of SMMUv3 functionality and the corresponding software support in Hafnium is
1404provided here.
1405
1406SMMUv3 features
1407---------------
1408
1409- SMMUv3 provides Stage1, Stage2 translation as well as nested (Stage1 + Stage2)
1410 translation support. It can either bypass or abort incoming translations as
1411 well.
1412- Traffic (memory transactions) from each upstream I/O peripheral device,
1413 referred to as Stream, can be independently managed using a combination of
1414 several memory based configuration structures. This allows the SMMUv3 to
1415 support a large number of streams with each stream assigned to a unique
1416 translation context.
1417- Support for Armv8.1 VMSA where the SMMU shares the translation tables with
1418 a Processing Element. AArch32(LPAE) and AArch64 translation table format
1419 are supported by SMMUv3.
1420- SMMUv3 offers non-secure stream support with secure stream support being
1421 optional. Logically, SMMUv3 behaves as if there is an indepdendent SMMU
1422 instance for secure and non-secure stream support.
1423- It also supports sub-streams to differentiate traffic from a virtualized
1424 peripheral associated with a VM/SP.
1425- Additionally, SMMUv3.2 provides support for PEs implementing Armv8.4-A
1426 extensions. Consequently, SPM depends on Secure EL2 support in SMMUv3.2
1427 for providing Secure Stage2 translation support to upstream peripheral
1428 devices.
1429
1430SMMUv3 Programming Interfaces
1431-----------------------------
1432
1433SMMUv3 has three software interfaces that are used by the Hafnium driver to
1434configure the behaviour of SMMUv3 and manage the streams.
1435
1436- Memory based data strutures that provide unique translation context for
1437 each stream.
1438- Memory based circular buffers for command queue and event queue.
1439- A large number of SMMU configuration registers that are memory mapped during
1440 boot time by Hafnium driver. Except a few registers, all configuration
1441 registers have independent secure and non-secure versions to configure the
1442 behaviour of SMMUv3 for translation of secure and non-secure streams
1443 respectively.
1444
1445Peripheral device manifest
1446--------------------------
1447
1448Currently, SMMUv3 driver in Hafnium only supports dependent peripheral devices.
1449These devices are dependent on PE endpoint to initiate and receive memory
1450management transactions on their behalf. The acccess to the MMIO regions of
1451any such device is assigned to the endpoint during boot. Moreover, SMMUv3 driver
1452uses the same stage 2 translations for the device as those used by partition
1453manager on behalf of the PE endpoint. This ensures that the peripheral device
1454has the same visibility of the physical address space as the endpoint. The
1455device node of the corresponding partition manifest (refer to `[1]`_ section 3.2
1456) must specify these additional properties for each peripheral device in the
1457system :
1458
1459- smmu-id: This field helps to identify the SMMU instance that this device is
1460 upstream of.
1461- stream-ids: List of stream IDs assigned to this device.
1462
1463.. code:: shell
1464
1465 smmuv3-testengine {
1466 base-address = <0x00000000 0x2bfe0000>;
1467 pages-count = <32>;
1468 attributes = <0x3>;
1469 smmu-id = <0>;
1470 stream-ids = <0x0 0x1>;
1471 interrupts = <0x2 0x3>, <0x4 0x5>;
1472 exclusive-access;
1473 };
1474
1475SMMUv3 driver limitations
1476-------------------------
1477
1478The primary design goal for the Hafnium SMMU driver is to support secure
1479streams.
1480
1481- Currently, the driver only supports Stage2 translations. No support for
1482 Stage1 or nested translations.
1483- Supports only AArch64 translation format.
1484- No support for features such as PCI Express (PASIDs, ATS, PRI), MSI, RAS,
1485 Fault handling, Performance Monitor Extensions, Event Handling, MPAM.
1486- No support for independent peripheral devices.
1487
Raghu Krishnamurthy7f3f7ce2021-10-17 16:48:29 -07001488S-EL0 Partition support
Olivier Deprez3de57e32022-04-28 18:18:36 +02001489=======================
Raghu Krishnamurthy7f3f7ce2021-10-17 16:48:29 -07001490The SPMC (Hafnium) has limited capability to run S-EL0 FF-A partitions using
1491FEAT_VHE (mandatory with ARMv8.1 in non-secure state, and in secure world
1492with ARMv8.4 and FEAT_SEL2).
1493
1494S-EL0 partitions are useful for simple partitions that don't require full
1495Trusted OS functionality. It is also useful to reduce jitter and cycle
1496stealing from normal world since they are more lightweight than VMs.
1497
1498S-EL0 partitions are presented, loaded and initialized the same as S-EL1 VMs by
1499the SPMC. They are differentiated primarily by the 'exception-level' property
1500and the 'execution-ctx-count' property in the SP manifest. They are host apps
1501under the single EL2&0 Stage-1 translation regime controlled by the SPMC and
1502call into the SPMC through SVCs as opposed to HVCs and SMCs. These partitions
1503can use FF-A defined services (FFA_MEM_PERM_*) to update or change permissions
1504for memory regions.
1505
1506S-EL0 partitions are required by the FF-A specification to be UP endpoints,
1507capable of migrating, and the SPMC enforces this requirement. The SPMC allows
1508a S-EL0 partition to accept a direct message from secure world and normal world,
1509and generate direct responses to them.
J-Alves56ac0972022-10-26 11:00:28 +01001510All S-EL0 partitions must use AArch64. AArch32 S-EL0 partitions are not supported.
Raghu Krishnamurthy7f3f7ce2021-10-17 16:48:29 -07001511
J-Alves56ac0972022-10-26 11:00:28 +01001512Memory sharing, indirect messaging, and notifications functionality with S-EL0
1513partitions is supported.
Raghu Krishnamurthy7f3f7ce2021-10-17 16:48:29 -07001514
J-Alves56ac0972022-10-26 11:00:28 +01001515Interrupt handling is not supported with S-EL0 partitions and is work in
1516progress.
Raghu Krishnamurthy7f3f7ce2021-10-17 16:48:29 -07001517
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001518References
1519==========
1520
1521.. _[1]:
1522
Olivier Deprez2b0be752021-09-01 10:25:21 +02001523[1] `Arm Firmware Framework for Arm A-profile <https://developer.arm.com/docs/den0077/latest>`__
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001524
1525.. _[2]:
1526
Madhukar Pappireddy86350ae2020-07-29 09:37:25 -05001527[2] :ref:`Secure Partition Manager using MM interface<Secure Partition Manager (MM)>`
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001528
1529.. _[3]:
1530
1531[3] `Trusted Boot Board Requirements
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001532Client <https://developer.arm.com/documentation/den0006/d/>`__
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001533
1534.. _[4]:
1535
1536[4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/el3_runtime/aarch64/context.S#n45
1537
1538.. _[5]:
1539
Olivier Deprez5e0a73f2021-04-30 14:42:24 +02001540[5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/plat/arm/fvp/fdts/cactus.dts
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001541
1542.. _[6]:
1543
Olivier Deprez9938c132021-04-21 11:22:23 +02001544[6] https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001545
1546.. _[7]:
1547
1548[7] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/board/fvp/fdts/fvp_spmc_manifest.dts
1549
1550.. _[8]:
1551
Sandrine Bailleux1a4efb12022-04-21 10:17:22 +02001552[8] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/thread/CFQFGU6H2D5GZYMUYGTGUSXIU3OYZP6U/
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001553
Olivier Deprez4ab7a4a2021-06-21 09:47:13 +02001554.. _[9]:
1555
1556[9] https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html#dynamic-configuration-during-cold-boot
1557
Olivier Deprezecb2fe52020-04-02 15:38:02 +02001558--------------
1559
Imre Kis3f370fd2022-02-08 18:06:18 +01001560*Copyright (c) 2020-2022, Arm Limited and Contributors. All rights reserved.*