1Secure Partition Manager 2************************ 3 4.. contents:: 5 6.. toctree:: 7 ffa-manifest-binding 8 9Acronyms 10======== 11 12+--------+--------------------------------------+ 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+--------+--------------------------------------+ 29| JOP | Jump-Oriented Programming | 30+--------+--------------------------------------+ 31| 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+--------+--------------------------------------+ 45| ROP | Return-Oriented Programming | 46+--------+--------------------------------------+ 47| 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+--------+--------------------------------------+ 69 70Foreword 71======== 72 73Three implementations of a Secure Partition Manager co-exist in the TF-A 74codebase: 75 76#. 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]`_. 82 83These implementations differ in their respective SW architecture and only one 84can be selected at build time. This document: 85 86- describes the implementation from bullet 1. when the SPMC resides at S-EL2. 87- is not an architecture specification and it might provide assumptions 88 on sections mandated as implementation-defined in the specification. 89- 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. 92 93Terminology 94----------- 95 96- 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. 105 106Support for legacy platforms 107---------------------------- 108 109The 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: 113 114- 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. 118 119TF-A supports both cases: 120 121- S-EL1 SPMC for platforms not supporting the FEAT_SEL2 architecture 122 extension. The SPMD relays the FF-A protocol from EL3 to S-EL1. 123- S-EL2 SPMC for platforms implementing the FEAT_SEL2 architecture 124 extension. The SPMD relays the FF-A protocol from EL3 to S-EL2. 125 126Sample reference stack 127====================== 128 129The 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: 133 134.. image:: ../resources/diagrams/ff-a-spm-sel2.png 135 136TF-A build options 137================== 138 139This 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 141SPMC located at S-EL1, S-EL2 or EL3: 142 143- **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 147 level to being at S-EL2. It defaults to enabled (value 1) when 148 SPD=spmd is chosen. 149- **SPMC_AT_EL3**: this option adjusts the SPMC exception level to being 150 at EL3. 151- If neither ``SPMD_SPM_AT_SEL2`` or ``SPMC_AT_EL3`` are enabled the SPMC 152 exception level is set to S-EL1. 153 ``SPMD_SPM_AT_SEL2`` is enabled. The context save/restore routine 154 and exhaustive list of registers is visible at `[4]`_. 155- **SPMC_AT_EL3_SEL0_SP**: this option enables the support to load SEL0 SP 156 when SPMC at EL3 support is enabled. 157- **SP_LAYOUT_FILE**: this option specifies a text description file 158 providing paths to SP binary images and manifests in DTS format 159 (see `Describing secure partitions`_). It 160 is required when ``SPMD_SPM_AT_SEL2`` is enabled hence when multiple 161 secure partitions are to be loaded by BL2 on behalf of the SPMC. 162 163+---------------+------------------+-------------+-------------------------+ 164| | SPMD_SPM_AT_SEL2 | SPMC_AT_EL3 | CTX_INCLUDE_EL2_REGS(*) | 165+---------------+------------------+-------------+-------------------------+ 166| SPMC at S-EL1 | 0 | 0 | 0 | 167+---------------+------------------+-------------+-------------------------+ 168| SPMC at S-EL2 | 1 (default when | 0 | 1 | 169| | SPD=spmd) | | | 170+---------------+------------------+-------------+-------------------------+ 171| SPMC at EL3 | 0 | 1 | 0 | 172+---------------+------------------+-------------+-------------------------+ 173 174Other combinations of such build options either break the build or are not 175supported. 176 177Notes: 178 179- Only Arm's FVP platform is supported to use with the TF-A reference software 180 stack. 181- When ``SPMD_SPM_AT_SEL2=1``, the reference software stack assumes enablement 182 of FEAT_PAuth, FEAT_BTI and FEAT_MTE architecture extensions. 183- ``(*) CTX_INCLUDE_EL2_REGS``, this flag is |TF-A| internal and informational 184 in this table. When set, it provides the generic support for saving/restoring 185 EL2 registers required when S-EL2 firmware is present. 186- BL32 option is re-purposed to specify the SPMC image. It can specify either 187 the Hafnium binary path (built for the secure world) or the path to a TEE 188 binary implementing FF-A interfaces. 189- BL33 option can specify the TFTF binary or a normal world loader 190 such as U-Boot or the UEFI framework payload. 191 192Sample TF-A build command line when the SPMC is located at S-EL1 193(e.g. when the FEAT_SEL2 architecture extension is not implemented): 194 195.. code:: shell 196 197 make \ 198 CROSS_COMPILE=aarch64-none-elf- \ 199 SPD=spmd \ 200 SPMD_SPM_AT_SEL2=0 \ 201 BL32=<path-to-tee-binary> \ 202 BL33=<path-to-bl33-binary> \ 203 PLAT=fvp \ 204 all fip 205 206Sample TF-A build command line when FEAT_SEL2 architecture extension is 207implemented and the SPMC is located at S-EL2: 208 209.. code:: shell 210 211 make \ 212 CROSS_COMPILE=aarch64-none-elf- \ 213 PLAT=fvp \ 214 SPD=spmd \ 215 ARM_ARCH_MINOR=5 \ 216 BRANCH_PROTECTION=1 \ 217 CTX_INCLUDE_PAUTH_REGS=1 \ 218 ENABLE_FEAT_MTE2=1 \ 219 BL32=<path-to-hafnium-binary> \ 220 BL33=<path-to-bl33-binary> \ 221 SP_LAYOUT_FILE=sp_layout.json \ 222 all fip 223 224Sample TF-A build command line when FEAT_SEL2 architecture extension is 225implemented, the SPMC is located at S-EL2, and enabling secure boot: 226 227.. code:: shell 228 229 make \ 230 CROSS_COMPILE=aarch64-none-elf- \ 231 PLAT=fvp \ 232 SPD=spmd \ 233 ARM_ARCH_MINOR=5 \ 234 BRANCH_PROTECTION=1 \ 235 CTX_INCLUDE_PAUTH_REGS=1 \ 236 ENABLE_FEAT_MTE2=1 \ 237 BL32=<path-to-hafnium-binary> \ 238 BL33=<path-to-bl33-binary> \ 239 SP_LAYOUT_FILE=sp_layout.json \ 240 MBEDTLS_DIR=<path-to-mbedtls-lib> \ 241 TRUSTED_BOARD_BOOT=1 \ 242 COT=dualroot \ 243 ARM_ROTPK_LOCATION=devel_rsa \ 244 ROT_KEY=plat/arm/board/common/rotpk/arm_rotprivk_rsa.pem \ 245 GENERATE_COT=1 \ 246 all fip 247 248Sample TF-A build command line when the SPMC is located at EL3: 249 250.. code:: shell 251 252 make \ 253 CROSS_COMPILE=aarch64-none-elf- \ 254 SPD=spmd \ 255 SPMD_SPM_AT_SEL2=0 \ 256 SPMC_AT_EL3=1 \ 257 BL32=<path-to-tee-binary> \ 258 BL33=<path-to-bl33-binary> \ 259 PLAT=fvp \ 260 all fip 261 262Sample TF-A build command line when the SPMC is located at EL3 and SEL0 SP is 263enabled: 264 265.. code:: shell 266 267 make \ 268 CROSS_COMPILE=aarch64-none-elf- \ 269 SPD=spmd \ 270 SPMD_SPM_AT_SEL2=0 \ 271 SPMC_AT_EL3=1 \ 272 SPMC_AT_EL3_SEL0_SP=1 \ 273 BL32=<path-to-tee-binary> \ 274 BL33=<path-to-bl33-binary> \ 275 PLAT=fvp \ 276 all fip 277 278FVP model invocation 279==================== 280 281The FVP command line needs the following options to exercise the S-EL2 SPMC: 282 283+---------------------------------------------------+------------------------------------+ 284| - cluster0.has_arm_v8-5=1 | Implements FEAT_SEL2, FEAT_PAuth, | 285| - cluster1.has_arm_v8-5=1 | and FEAT_BTI. | 286+---------------------------------------------------+------------------------------------+ 287| - pci.pci_smmuv3.mmu.SMMU_AIDR=2 | Parameters required for the | 288| - pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B | SMMUv3.2 modeling. | 289| - pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 | | 290| - pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 | | 291| - pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0472 | | 292| - pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 | | 293| - pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 | | 294| - pci.pci_smmuv3.mmu.SMMU_S_IDR3=0 | | 295+---------------------------------------------------+------------------------------------+ 296| - cluster0.has_branch_target_exception=1 | Implements FEAT_BTI. | 297| - cluster1.has_branch_target_exception=1 | | 298+---------------------------------------------------+------------------------------------+ 299| - cluster0.has_pointer_authentication=2 | Implements FEAT_PAuth | 300| - cluster1.has_pointer_authentication=2 | | 301+---------------------------------------------------+------------------------------------+ 302| - cluster0.memory_tagging_support_level=2 | Implements FEAT_MTE2 | 303| - cluster1.memory_tagging_support_level=2 | | 304| - bp.dram_metadata.is_enabled=1 | | 305+---------------------------------------------------+------------------------------------+ 306 307Sample FVP command line invocation: 308 309.. code:: shell 310 311 <path-to-fvp-model>/FVP_Base_RevC-2xAEMvA -C pctl.startup=0.0.0.0 \ 312 -C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 \ 313 -C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin \ 314 -C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin \ 315 -C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log \ 316 -C bp.pl011_uart2.out_file=fvp-uart2.log \ 317 -C cluster0.has_arm_v8-5=1 -C cluster1.has_arm_v8-5=1 \ 318 -C cluster0.has_pointer_authentication=2 -C cluster1.has_pointer_authentication=2 \ 319 -C cluster0.has_branch_target_exception=1 -C cluster1.has_branch_target_exception=1 \ 320 -C cluster0.memory_tagging_support_level=2 -C cluster1.memory_tagging_support_level=2 \ 321 -C bp.dram_metadata.is_enabled=1 \ 322 -C pci.pci_smmuv3.mmu.SMMU_AIDR=2 -C pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B \ 323 -C pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 -C pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 \ 324 -C pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0472 -C pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 \ 325 -C pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 -C pci.pci_smmuv3.mmu.SMMU_S_IDR3=0 326 327Boot process 328============ 329 330Loading Hafnium and secure partitions in the secure world 331--------------------------------------------------------- 332 333TF-A BL2 is the bootlader for the SPMC and SPs in the secure world. 334 335SPs may be signed by different parties (SiP, OEM/ODM, TOS vendor, etc.). 336Thus they are supplied as distinct signed entities within the FIP flash 337image. The FIP image itself is not signed hence this provides the ability 338to upgrade SPs in the field. 339 340Booting through TF-A 341-------------------- 342 343SP manifests 344~~~~~~~~~~~~ 345 346An SP manifest describes SP attributes as defined in `[1]`_ 347(partition manifest at virtual FF-A instance) in DTS format. It is 348represented as a single file associated with the SP. A sample is 349provided by `[5]`_. A binding document is provided by `[6]`_. 350 351Secure Partition packages 352~~~~~~~~~~~~~~~~~~~~~~~~~ 353 354Secure partitions are bundled as independent package files consisting 355of: 356 357- a header 358- a DTB 359- an image payload 360 361The header starts with a magic value and offset values to SP DTB and 362image payload. Each SP package is loaded independently by BL2 loader 363and verified for authenticity and integrity. 364 365The SP package identified by its UUID (matching FF-A uuid property) is 366inserted as a single entry into the FIP at end of the TF-A build flow 367as shown: 368 369.. code:: shell 370 371 Trusted Boot Firmware BL2: offset=0x1F0, size=0x8AE1, cmdline="--tb-fw" 372 EL3 Runtime Firmware BL31: offset=0x8CD1, size=0x13000, cmdline="--soc-fw" 373 Secure Payload BL32 (Trusted OS): offset=0x1BCD1, size=0x15270, cmdline="--tos-fw" 374 Non-Trusted Firmware BL33: offset=0x30F41, size=0x92E0, cmdline="--nt-fw" 375 HW_CONFIG: offset=0x3A221, size=0x2348, cmdline="--hw-config" 376 TB_FW_CONFIG: offset=0x3C569, size=0x37A, cmdline="--tb-fw-config" 377 SOC_FW_CONFIG: offset=0x3C8E3, size=0x48, cmdline="--soc-fw-config" 378 TOS_FW_CONFIG: offset=0x3C92B, size=0x427, cmdline="--tos-fw-config" 379 NT_FW_CONFIG: offset=0x3CD52, size=0x48, cmdline="--nt-fw-config" 380 B4B5671E-4A90-4FE1-B81F-FB13DAE1DACB: offset=0x3CD9A, size=0xC168, cmdline="--blob" 381 D1582309-F023-47B9-827C-4464F5578FC8: offset=0x48F02, size=0xC168, cmdline="--blob" 382 383.. uml:: ../resources/diagrams/plantuml/fip-secure-partitions.puml 384 385Describing secure partitions 386~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 387 388A json-formatted description file is passed to the build flow specifying paths 389to the SP binary image and associated DTS partition manifest file. The latter 390is processed by the dtc compiler to generate a DTB fed into the SP package. 391Optionally, the partition's json description can contain offsets for both 392the image and partition manifest within the SP package. Both offsets need to be 3934KB aligned, because it is the translation granule supported by Hafnium SPMC. 394These fields can be leveraged to support SPs with S1 translation granules that 395differ from 4KB, and to configure the regions allocated within the SP package, 396as well as to comply with the requirements for the implementation of the boot 397information protocol (see `Passing boot data to the SP`_ for more details). In 398case the offsets are absent in their json node, they default to 0x1000 and 3990x4000 for the manifest offset and image offset respectively. 400This file also specifies the SP owner (as an optional field) identifying the 401signing domain in case of dual root CoT. 402The SP owner can either be the silicon or the platform provider. The 403corresponding "owner" field value can either take the value of "SiP" or "Plat". 404In absence of "owner" field, it defaults to "SiP" owner. 405The UUID of the partition can be specified as a field in the description file or 406if it does not exist there the UUID is extracted from the DTS partition 407manifest. 408 409.. code:: shell 410 411 { 412 "tee1" : { 413 "image": "tee1.bin", 414 "pm": "tee1.dts", 415 "owner": "SiP", 416 "uuid": "1b1820fe-48f7-4175-8999-d51da00b7c9f" 417 }, 418 419 "tee2" : { 420 "image": "tee2.bin", 421 "pm": "tee2.dts", 422 "owner": "Plat" 423 }, 424 425 "tee3" : { 426 "image": { 427 "file": "tee3.bin", 428 "offset":"0x2000" 429 }, 430 "pm": { 431 "file": "tee3.dts", 432 "offset":"0x6000" 433 }, 434 "owner": "Plat" 435 }, 436 } 437 438SPMC manifest 439~~~~~~~~~~~~~ 440 441This manifest contains the SPMC *attribute* node consumed by the SPMD at boot 442time. It implements `[1]`_ (SP manifest at physical FF-A instance) and serves 443two different cases: 444 445- The SPMC resides at S-EL1: the SPMC manifest is used by the SPMD to setup a 446 SP that co-resides with the SPMC and executes at S-EL1 or Secure Supervisor 447 mode. 448- The SPMC resides at S-EL2: the SPMC manifest is used by the SPMD to setup 449 the environment required by the SPMC to run at S-EL2. SPs run at S-EL1 or 450 S-EL0. 451 452.. code:: shell 453 454 attribute { 455 spmc_id = <0x8000>; 456 maj_ver = <0x1>; 457 min_ver = <0x1>; 458 exec_state = <0x0>; 459 load_address = <0x0 0x6000000>; 460 entrypoint = <0x0 0x6000000>; 461 binary_size = <0x60000>; 462 }; 463 464- *spmc_id* defines the endpoint ID value that SPMC can query through 465 ``FFA_ID_GET``. 466- *maj_ver/min_ver*. SPMD checks provided version versus its internal 467 version and aborts if not matching. 468- *exec_state* defines the SPMC execution state (AArch64 or AArch32). 469 Notice Hafnium used as a SPMC only supports AArch64. 470- *load_address* and *binary_size* are mostly used to verify secondary 471 entry points fit into the loaded binary image. 472- *entrypoint* defines the cold boot primary core entry point used by 473 SPMD (currently matches ``BL32_BASE``) to enter the SPMC. 474 475Other nodes in the manifest are consumed by Hafnium in the secure world. 476A sample can be found at `[7]`_: 477 478- The *hypervisor* node describes SPs. *is_ffa_partition* boolean attribute 479 indicates a FF-A compliant SP. The *load_address* field specifies the load 480 address at which BL2 loaded the SP package. 481- *cpus* node provide the platform topology and allows MPIDR to VMPIDR mapping. 482 Note the primary core is declared first, then secondary cores are declared 483 in reverse order. 484- The *memory* nodes provide platform information on the ranges of memory 485 available for use by SPs at runtime. These ranges relate to either 486 secure or non-secure memory, depending on the *device_type* field. 487 If the field specifies "memory" the range is secure, else if it specifies 488 "ns-memory" the memory is non-secure. The system integrator must exclude 489 the memory used by other components that are not SPs, such as the monitor, 490 or the SPMC itself, the OS Kernel/Hypervisor, or other NWd VMs. The SPMC 491 limits the SP's address space such that they do not access memory outside 492 of those ranges. 493 494SPMC boot 495~~~~~~~~~ 496 497The SPMC is loaded by BL2 as the BL32 image. 498 499The SPMC manifest is loaded by BL2 as the ``TOS_FW_CONFIG`` image `[9]`_. 500 501BL2 passes the SPMC manifest address to BL31 through a register. 502 503At boot time, the SPMD in BL31 runs from the primary core, initializes the core 504contexts and launches the SPMC (BL32) passing the following information through 505registers: 506 507- X0 holds the ``TOS_FW_CONFIG`` physical address (or SPMC manifest blob). 508- X1 holds the ``HW_CONFIG`` physical address. 509- X4 holds the currently running core linear id. 510 511Loading of SPs 512~~~~~~~~~~~~~~ 513 514At boot time, BL2 loads SPs sequentially in addition to the SPMC as depicted 515below: 516 517.. uml:: ../resources/diagrams/plantuml/bl2-loading-sp.puml 518 519Note this boot flow is an implementation sample on Arm's FVP platform. 520Platforms not using TF-A's *Firmware CONFiguration* framework would adjust to a 521different boot flow. The flow restricts to a maximum of 8 secure partitions. 522 523Secure boot 524~~~~~~~~~~~ 525 526The SP content certificate is inserted as a separate FIP item so that BL2 loads SPMC, 527SPMC manifest, secure partitions and verifies them for authenticity and integrity. 528Refer to TBBR specification `[3]`_. 529 530The multiple-signing domain feature (in current state dual signing domain `[8]`_) allows 531the use of two root keys namely S-ROTPK and NS-ROTPK: 532 533- SPMC (BL32) and SPMC manifest are signed by the SiP using the S-ROTPK. 534- BL33 may be signed by the OEM using NS-ROTPK. 535- An SP may be signed either by SiP (using S-ROTPK) or by OEM (using NS-ROTPK). 536- A maximum of 4 partitions can be signed with the S-ROTPK key and 4 partitions 537 signed with the NS-ROTPK key. 538 539Also refer to `Describing secure partitions`_ and `TF-A build options`_ sections. 540 541Hafnium in the secure world 542=========================== 543 544General considerations 545---------------------- 546 547Build platform for the secure world 548~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 549 550In the Hafnium reference implementation specific code parts are only relevant to 551the secure world. Such portions are isolated in architecture specific files 552and/or enclosed by a ``SECURE_WORLD`` macro. 553 554Secure partitions scheduling 555~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 556 557The FF-A specification `[1]`_ provides two ways to relinquinsh CPU time to 558secure partitions. For this a VM (Hypervisor or OS kernel), or SP invokes one of: 559 560- the FFA_MSG_SEND_DIRECT_REQ interface. 561- the FFA_RUN interface. 562 563Additionally a secure interrupt can pre-empt the normal world execution and give 564CPU cycles by transitioning to EL3 and S-EL2. 565 566Platform topology 567~~~~~~~~~~~~~~~~~ 568 569The *execution-ctx-count* SP manifest field can take the value of one or the 570total number of PEs. The FF-A specification `[1]`_ recommends the 571following SP types: 572 573- Pinned MP SPs: an execution context matches a physical PE. MP SPs must 574 implement the same number of ECs as the number of PEs in the platform. 575- Migratable UP SPs: a single execution context can run and be migrated on any 576 physical PE. Such SP declares a single EC in its SP manifest. An UP SP can 577 receive a direct message request originating from any physical core targeting 578 the single execution context. 579 580Parsing SP partition manifests 581------------------------------ 582 583Hafnium consumes SP manifests as defined in `[1]`_ and `SP manifests`_. 584Note the current implementation may not implement all optional fields. 585 586The SP manifest may contain memory and device regions nodes. In case of 587an S-EL2 SPMC: 588 589- Memory regions are mapped in the SP EL1&0 Stage-2 translation regime at 590 load time (or EL1&0 Stage-1 for an S-EL1 SPMC). A memory region node can 591 specify RX/TX buffer regions in which case it is not necessary for an SP 592 to explicitly invoke the ``FFA_RXTX_MAP`` interface. The memory referred 593 shall be contained within the memory ranges defined in SPMC manifest. The 594 NS bit in the attributes field should be consistent with the security 595 state of the range that it relates to. I.e. non-secure memory shall be 596 part of a non-secure memory range, and secure memory shall be contained 597 in a secure memory range of a given platform. 598- Device regions are mapped in the SP EL1&0 Stage-2 translation regime (or 599 EL1&0 Stage-1 for an S-EL1 SPMC) as peripherals and possibly allocate 600 additional resources (e.g. interrupts). 601 602For the S-EL2 SPMC, base addresses for memory and device region nodes are IPAs 603provided the SPMC identity maps IPAs to PAs within SP EL1&0 Stage-2 translation 604regime. 605 606Note: in the current implementation both VTTBR_EL2 and VSTTBR_EL2 point to the 607same set of page tables. It is still open whether two sets of page tables shall 608be provided per SP. The memory region node as defined in the specification 609provides a memory security attribute hinting to map either to the secure or 610non-secure EL1&0 Stage-2 table if it exists. 611 612Passing boot data to the SP 613--------------------------- 614 615In `[1]`_ , the section "Boot information protocol" defines a method for passing 616data to the SPs at boot time. It specifies the format for the boot information 617descriptor and boot information header structures, which describe the data to be 618exchanged between SPMC and SP. 619The specification also defines the types of data that can be passed. 620The aggregate of both the boot info structures and the data itself is designated 621the boot information blob, and is passed to a Partition as a contiguous memory 622region. 623 624Currently, the SPM implementation supports the FDT type which is used to pass the 625partition's DTB manifest. 626 627The region for the boot information blob is allocated through the SP package. 628 629.. image:: ../resources/diagrams/partition-package.png 630 631To adjust the space allocated for the boot information blob, the json description 632of the SP (see section `Describing secure partitions`_) shall be updated to contain 633the manifest offset. If no offset is provided the manifest offset defaults to 0x1000, 634which is the page size in the Hafnium SPMC. 635 636The configuration of the boot protocol is done in the SPs manifest. As defined by 637the specification, the manifest field 'gp-register-num' configures the GP register 638which shall be used to pass the address to the partitions boot information blob when 639booting the partition. 640In addition, the Hafnium SPMC implementation requires the boot information arguments 641to be listed in a designated DT node: 642 643.. code:: shell 644 645 boot-info { 646 compatible = "arm,ffa-manifest-boot-info"; 647 ffa_manifest; 648 }; 649 650The whole secure partition package image (see `Secure Partition packages`_) is 651mapped to the SP secure EL1&0 Stage-2 translation regime. As such, the SP can 652retrieve the address for the boot information blob in the designated GP register, 653process the boot information header and descriptors, access its own manifest 654DTB blob and extract its partition manifest properties. 655 656SP Boot order 657------------- 658 659SP manifests provide an optional boot order attribute meant to resolve 660dependencies such as an SP providing a service required to properly boot 661another SP. SPMC boots the SPs in accordance to the boot order attribute, 662lowest to the highest value. If the boot order attribute is absent from the FF-A 663manifest, the SP is treated as if it had the highest boot order value 664(i.e. lowest booting priority). 665 666It is possible for an SP to call into another SP through a direct request 667provided the latter SP has already been booted. 668 669Boot phases 670----------- 671 672Primary core boot-up 673~~~~~~~~~~~~~~~~~~~~ 674 675Upon boot-up, BL31 hands over to the SPMC (BL32) on the primary boot physical 676core. The SPMC performs its platform initializations and registers the SPMC 677secondary physical core entry point physical address by the use of the 678`FFA_SECONDARY_EP_REGISTER`_ interface (SMC invocation from the SPMC to the SPMD 679at secure physical FF-A instance). 680 681The SPMC then creates secure partitions based on SP packages and manifests. Each 682secure partition is launched in sequence (`SP Boot order`_) on their "primary" 683execution context. If the primary boot physical core linear id is N, an MP SP is 684started using EC[N] on PE[N] (see `Platform topology`_). If the partition is a 685UP SP, it is started using its unique EC0 on PE[N]. 686 687The SP primary EC (or the EC used when the partition is booted as described 688above): 689 690- Performs the overall SP boot time initialization, and in case of a MP SP, 691 prepares the SP environment for other execution contexts. 692- In the case of a MP SP, it invokes the FFA_SECONDARY_EP_REGISTER at secure 693 virtual FF-A instance (SMC invocation from SP to SPMC) to provide the IPA 694 entry point for other execution contexts. 695- Exits through ``FFA_MSG_WAIT`` to indicate successful initialization or 696 ``FFA_ERROR`` in case of failure. 697 698Secondary cores boot-up 699~~~~~~~~~~~~~~~~~~~~~~~ 700 701Once the system is started and NWd brought up, a secondary physical core is 702woken up by the ``PSCI_CPU_ON`` service invocation. The TF-A SPD hook mechanism 703calls into the SPMD on the newly woken up physical core. Then the SPMC is 704entered at the secondary physical core entry point. 705 706In the current implementation, the first SP is resumed on the coresponding EC 707(the virtual CPU which matches the physical core). The implication is that the 708first SP must be a MP SP. 709 710In a linux based system, once secure and normal worlds are booted but prior to 711a NWd FF-A driver has been loaded: 712 713- The first SP has initialized all its ECs in response to primary core boot up 714 (at system initialization) and secondary core boot up (as a result of linux 715 invoking PSCI_CPU_ON for all secondary cores). 716- Other SPs have their first execution context initialized as a result of secure 717 world initialization on the primary boot core. Other ECs for those SPs have to 718 be run first through ffa_run to complete their initialization (which results 719 in the EC completing with FFA_MSG_WAIT). 720 721Refer to `Power management`_ for further details. 722 723Notifications 724------------- 725 726The FF-A v1.1 specification `[1]`_ defines notifications as an asynchronous 727communication mechanism with non-blocking semantics. It allows for one FF-A 728endpoint to signal another for service provision, without hindering its current 729progress. 730 731Hafnium currently supports 64 notifications. The IDs of each notification define 732a position in a 64-bit bitmap. 733 734The signaling of notifications can interchangeably happen between NWd and SWd 735FF-A endpoints. 736 737The SPMC is in charge of managing notifications from SPs to SPs, from SPs to 738VMs, and from VMs to SPs. An hypervisor component would only manage 739notifications from VMs to VMs. Given the SPMC has no visibility of the endpoints 740deployed in NWd, the Hypervisor or OS kernel must invoke the interface 741FFA_NOTIFICATION_BITMAP_CREATE to allocate the notifications bitmap per FF-A 742endpoint in the NWd that supports it. 743 744A sender can signal notifications once the receiver has provided it with 745permissions. Permissions are provided by invoking the interface 746FFA_NOTIFICATION_BIND. 747 748Notifications are signaled by invoking FFA_NOTIFICATION_SET. Henceforth 749they are considered to be in a pending sate. The receiver can retrieve its 750pending notifications invoking FFA_NOTIFICATION_GET, which, from that moment, 751are considered to be handled. 752 753Per the FF-A v1.1 spec, each FF-A endpoint must be associated with a scheduler 754that is in charge of donating CPU cycles for notifications handling. The 755FF-A driver calls FFA_NOTIFICATION_INFO_GET to retrieve the information about 756which FF-A endpoints have pending notifications. The receiver scheduler is 757called and informed by the FF-A driver, and it should allocate CPU cycles to the 758receiver. 759 760There are two types of notifications supported: 761 762- Global, which are targeted to a FF-A endpoint and can be handled within any of 763 its execution contexts, as determined by the scheduler of the system. 764- Per-vCPU, which are targeted to a FF-A endpoint and to be handled within a 765 a specific execution context, as determined by the sender. 766 767The type of a notification is set when invoking FFA_NOTIFICATION_BIND to give 768permissions to the sender. 769 770Notification signaling resorts to two interrupts: 771 772- Schedule Receiver Interrupt: non-secure physical interrupt to be handled by 773 the FF-A driver within the receiver scheduler. At initialization the SPMC 774 donates a SGI ID chosen from the secure SGI IDs range and configures it as 775 non-secure. The SPMC triggers this SGI on the currently running core when 776 there are pending notifications, and the respective receivers need CPU cycles 777 to handle them. 778- Notifications Pending Interrupt: virtual interrupt to be handled by the 779 receiver of the notification. Set when there are pending notifications for the 780 given secure partition. The NPI is pended when the NWd relinquishes CPU cycles 781 to an SP. 782 783The notifications receipt support is enabled in the partition FF-A manifest. 784 785Mandatory interfaces 786-------------------- 787 788The following interfaces are exposed to SPs: 789 790- ``FFA_VERSION`` 791- ``FFA_FEATURES`` 792- ``FFA_RX_RELEASE`` 793- ``FFA_RXTX_MAP`` 794- ``FFA_RXTX_UNMAP`` 795- ``FFA_PARTITION_INFO_GET`` 796- ``FFA_ID_GET`` 797- ``FFA_MSG_WAIT`` 798- ``FFA_MSG_SEND_DIRECT_REQ`` 799- ``FFA_MSG_SEND_DIRECT_RESP`` 800- ``FFA_MEM_DONATE`` 801- ``FFA_MEM_LEND`` 802- ``FFA_MEM_SHARE`` 803- ``FFA_MEM_RETRIEVE_REQ`` 804- ``FFA_MEM_RETRIEVE_RESP`` 805- ``FFA_MEM_RELINQUISH`` 806- ``FFA_MEM_FRAG_RX`` 807- ``FFA_MEM_FRAG_TX`` 808- ``FFA_MEM_RECLAIM`` 809- ``FFA_RUN`` 810 811As part of the FF-A v1.1 support, the following interfaces were added: 812 813 - ``FFA_NOTIFICATION_BITMAP_CREATE`` 814 - ``FFA_NOTIFICATION_BITMAP_DESTROY`` 815 - ``FFA_NOTIFICATION_BIND`` 816 - ``FFA_NOTIFICATION_UNBIND`` 817 - ``FFA_NOTIFICATION_SET`` 818 - ``FFA_NOTIFICATION_GET`` 819 - ``FFA_NOTIFICATION_INFO_GET`` 820 - ``FFA_SPM_ID_GET`` 821 - ``FFA_SECONDARY_EP_REGISTER`` 822 - ``FFA_MEM_PERM_GET`` 823 - ``FFA_MEM_PERM_SET`` 824 - ``FFA_MSG_SEND2`` 825 - ``FFA_RX_ACQUIRE`` 826 827FFA_VERSION 828~~~~~~~~~~~ 829 830``FFA_VERSION`` requires a *requested_version* parameter from the caller. 831The returned value depends on the caller: 832 833- Hypervisor or OS kernel in NS-EL1/EL2: the SPMD returns the SPMC version 834 specified in the SPMC manifest. 835- SP: the SPMC returns its own implemented version. 836- SPMC at S-EL1/S-EL2: the SPMD returns its own implemented version. 837 838FFA_FEATURES 839~~~~~~~~~~~~ 840 841FF-A features supported by the SPMC may be discovered by secure partitions at 842boot (that is prior to NWd is booted) or run-time. 843 844The SPMC calling FFA_FEATURES at secure physical FF-A instance always get 845FFA_SUCCESS from the SPMD. 846 847The request made by an Hypervisor or OS kernel is forwarded to the SPMC and 848the response relayed back to the NWd. 849 850FFA_RXTX_MAP/FFA_RXTX_UNMAP 851~~~~~~~~~~~~~~~~~~~~~~~~~~~ 852 853When invoked from a secure partition FFA_RXTX_MAP maps the provided send and 854receive buffers described by their IPAs to the SP EL1&0 Stage-2 translation 855regime as secure buffers in the MMU descriptors. 856 857When invoked from the Hypervisor or OS kernel, the buffers are mapped into the 858SPMC EL2 Stage-1 translation regime and marked as NS buffers in the MMU 859descriptors. The provided addresses may be owned by a VM in the normal world, 860which is expected to receive messages from the secure world. The SPMC will in 861this case allocate internal state structures to facilitate RX buffer access 862synchronization (through FFA_RX_ACQUIRE interface), and to permit SPs to send 863messages. 864 865The FFA_RXTX_UNMAP unmaps the RX/TX pair from the translation regime of the 866caller, either it being the Hypervisor or OS kernel, as well as a secure 867partition. 868 869FFA_PARTITION_INFO_GET 870~~~~~~~~~~~~~~~~~~~~~~ 871 872Partition info get call can originate: 873 874- from SP to SPMC 875- from Hypervisor or OS kernel to SPMC. The request is relayed by the SPMD. 876 877FFA_ID_GET 878~~~~~~~~~~ 879 880The FF-A id space is split into a non-secure space and secure space: 881 882- FF-A ID with bit 15 clear relates to VMs. 883- FF-A ID with bit 15 set related to SPs. 884- FF-A IDs 0, 0xffff, 0x8000 are assigned respectively to the Hypervisor, SPMD 885 and SPMC. 886 887The SPMD returns: 888 889- The default zero value on invocation from the Hypervisor. 890- The ``spmc_id`` value specified in the SPMC manifest on invocation from 891 the SPMC (see `SPMC manifest`_) 892 893This convention helps the SPMC to determine the origin and destination worlds in 894an FF-A ABI invocation. In particular the SPMC shall filter unauthorized 895transactions in its world switch routine. It must not be permitted for a VM to 896use a secure FF-A ID as origin world by spoofing: 897 898- A VM-to-SP direct request/response shall set the origin world to be non-secure 899 (FF-A ID bit 15 clear) and destination world to be secure (FF-A ID bit 15 900 set). 901- Similarly, an SP-to-SP direct request/response shall set the FF-A ID bit 15 902 for both origin and destination IDs. 903 904An incoming direct message request arriving at SPMD from NWd is forwarded to 905SPMC without a specific check. The SPMC is resumed through eret and "knows" the 906message is coming from normal world in this specific code path. Thus the origin 907endpoint ID must be checked by SPMC for being a normal world ID. 908 909An SP sending a direct message request must have bit 15 set in its origin 910endpoint ID and this can be checked by the SPMC when the SP invokes the ABI. 911 912The SPMC shall reject the direct message if the claimed world in origin endpoint 913ID is not consistent: 914 915- It is either forwarded by SPMD and thus origin endpoint ID must be a "normal 916 world ID", 917- or initiated by an SP and thus origin endpoint ID must be a "secure world ID". 918 919 920FFA_MSG_SEND_DIRECT_REQ/FFA_MSG_SEND_DIRECT_RESP 921~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 922 923This is a mandatory interface for secure partitions consisting in direct request 924and responses with the following rules: 925 926- An SP can send a direct request to another SP. 927- An SP can receive a direct request from another SP. 928- An SP can send a direct response to another SP. 929- An SP cannot send a direct request to an Hypervisor or OS kernel. 930- An Hypervisor or OS kernel can send a direct request to an SP. 931- An SP can send a direct response to an Hypervisor or OS kernel. 932 933FFA_NOTIFICATION_BITMAP_CREATE/FFA_NOTIFICATION_BITMAP_DESTROY 934~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 935 936The secure partitions notifications bitmap are statically allocated by the SPMC. 937Hence, this interface is not to be issued by secure partitions. 938 939At initialization, the SPMC is not aware of VMs/partitions deployed in the 940normal world. Hence, the Hypervisor or OS kernel must use both ABIs for SPMC 941to be prepared to handle notifications for the provided VM ID. 942 943FFA_NOTIFICATION_BIND/FFA_NOTIFICATION_UNBIND 944~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 945 946Pair of interfaces to manage permissions to signal notifications. Prior to 947handling notifications, an FF-A endpoint must allow a given sender to signal a 948bitmap of notifications. 949 950If the receiver doesn't have notification support enabled in its FF-A manifest, 951it won't be able to bind notifications, hence forbidding it to receive any 952notifications. 953 954FFA_NOTIFICATION_SET/FFA_NOTIFICATION_GET 955~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 956 957FFA_NOTIFICATION_GET retrieves all pending global notifications and 958per-vCPU notifications targeted to the current vCPU. 959 960Hafnium maintains a global count of pending notifications which gets incremented 961and decremented when handling FFA_NOTIFICATION_SET and FFA_NOTIFICATION_GET 962respectively. A delayed SRI is triggered if the counter is non-zero when the 963SPMC returns to normal world. 964 965FFA_NOTIFICATION_INFO_GET 966~~~~~~~~~~~~~~~~~~~~~~~~~ 967 968Hafnium maintains a global count of pending notifications whose information 969has been retrieved by this interface. The count is incremented and decremented 970when handling FFA_NOTIFICATION_INFO_GET and FFA_NOTIFICATION_GET respectively. 971It also tracks notifications whose information has been retrieved individually, 972such that it avoids duplicating returned information for subsequent calls to 973FFA_NOTIFICATION_INFO_GET. For each notification, this state information is 974reset when receiver called FFA_NOTIFICATION_GET to retrieve them. 975 976FFA_SPM_ID_GET 977~~~~~~~~~~~~~~ 978 979Returns the FF-A ID allocated to an SPM component which can be one of SPMD 980or SPMC. 981 982At initialization, the SPMC queries the SPMD for the SPMC ID, using the 983FFA_ID_GET interface, and records it. The SPMC can also query the SPMD ID using 984the FFA_SPM_ID_GET interface at the secure physical FF-A instance. 985 986Secure partitions call this interface at the virtual FF-A instance, to which 987the SPMC returns the priorly retrieved SPMC ID. 988 989The Hypervisor or OS kernel can issue the FFA_SPM_ID_GET call handled by the 990SPMD, which returns the SPMC ID. 991 992FFA_SECONDARY_EP_REGISTER 993~~~~~~~~~~~~~~~~~~~~~~~~~ 994 995When the SPMC boots, all secure partitions are initialized on their primary 996Execution Context. 997 998The FFA_SECONDARY_EP_REGISTER interface is to be used by a secure partition 999from its first execution context, to provide the entry point address for 1000secondary execution contexts. 1001 1002A secondary EC is first resumed either upon invocation of PSCI_CPU_ON from 1003the NWd or by invocation of FFA_RUN. 1004 1005FFA_RX_ACQUIRE/FFA_RX_RELEASE 1006~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1007 1008The RX buffers can be used to pass information to an FF-A endpoint in the 1009following scenarios: 1010 1011 - When it was targetted by a FFA_MSG_SEND2 invokation from another endpoint. 1012 - Return the result of calling ``FFA_PARTITION_INFO_GET``. 1013 - In a memory share operation, as part of the ``FFA_MEM_RETRIEVE_RESP``, 1014 with the memory descriptor of the shared memory. 1015 1016If a normal world VM is expected to exchange messages with secure world, 1017its RX/TX buffer addresses are forwarded to the SPMC via FFA_RXTX_MAP ABI, 1018and are from this moment owned by the SPMC. 1019The hypervisor must call the FFA_RX_ACQUIRE interface before attempting 1020to use the RX buffer, in any of the aforementioned scenarios. A successful 1021call to FFA_RX_ACQUIRE transfers ownership of RX buffer to hypervisor, such 1022that it can be safely used. 1023 1024The FFA_RX_RELEASE interface is used after the FF-A endpoint is done with 1025processing the data received in its RX buffer. If the RX buffer has been 1026acquired by the hypervisor, the FFA_RX_RELEASE call must be forwarded to 1027the SPMC to reestablish SPMC's RX ownership. 1028 1029An attempt from an SP to send a message to a normal world VM whose RX buffer 1030was acquired by the hypervisor fails with error code FFA_BUSY, to preserve 1031the RX buffer integrity. 1032The operation could then be conducted after FFA_RX_RELEASE. 1033 1034FFA_MSG_SEND2 1035~~~~~~~~~~~~~ 1036 1037Hafnium copies a message from the sender TX buffer into receiver's RX buffer. 1038For messages from SPs to VMs, operation is only possible if the SPMC owns 1039the receiver's RX buffer. 1040 1041Both receiver and sender need to enable support for indirect messaging, 1042in their respective partition manifest. The discovery of support 1043of such feature can be done via FFA_PARTITION_INFO_GET. 1044 1045On a successful message send, Hafnium pends an RX buffer full framework 1046notification for the receiver, to inform it about a message in the RX buffer. 1047 1048The handling of framework notifications is similar to that of 1049global notifications. Binding of these is not necessary, as these are 1050reserved to be used by the hypervisor or SPMC. 1051 1052SPMC-SPMD direct requests/responses 1053----------------------------------- 1054 1055Implementation-defined FF-A IDs are allocated to the SPMC and SPMD. 1056Using those IDs in source/destination fields of a direct request/response 1057permits SPMD to SPMC communication and either way. 1058 1059- SPMC to SPMD direct request/response uses SMC conduit. 1060- SPMD to SPMC direct request/response uses ERET conduit. 1061 1062This is used in particular to convey power management messages. 1063 1064Memory Sharing 1065-------------- 1066 1067Hafnium implements the following memory sharing interfaces: 1068 1069 - ``FFA_MEM_SHARE`` - for shared access between lender and borrower. 1070 - ``FFA_MEM_LEND`` - borrower to obtain exclusive access, though lender 1071 retains ownership of the memory. 1072 - ``FFA_MEM_DONATE`` - lender permanently relinquishes ownership of memory 1073 to the borrower. 1074 1075The ``FFA_MEM_RETRIEVE_REQ`` interface is for the borrower to request the 1076memory to be mapped into its address space: for S-EL1 partitions the SPM updates 1077their stage 2 translation regime; for S-EL0 partitions the SPM updates their 1078stage 1 translation regime. On a successful call, the SPMC responds back with 1079``FFA_MEM_RETRIEVE_RESP``. 1080 1081The ``FFA_MEM_RELINQUISH`` interface is for when the borrower is done with using 1082a memory region. 1083 1084The ``FFA_MEM_RECLAIM`` interface is for the owner of the memory to reestablish 1085its ownership and exclusive access to the memory shared. 1086 1087The memory transaction descriptors are transmitted via RX/TX buffers. In 1088situations where the size of the memory transaction descriptor exceeds the 1089size of the RX/TX buffers, Hafnium provides support for fragmented transmission 1090of the full transaction descriptor. The ``FFA_MEM_FRAG_RX`` and ``FFA_MEM_FRAG_TX`` 1091interfaces are for receiving and transmitting the next fragment, respectively. 1092 1093If lender and borrower(s) are SPs, all memory sharing operations are supported. 1094 1095Hafnium also supports memory sharing operations between the normal world and the 1096secure world. If there is an SP involved, the SPMC allocates data to track the 1097state of the operation. 1098 1099The SPMC is also the designated allocator for the memory handle. The hypervisor 1100or OS kernel has the possibility to rely on the SPMC to maintain the state 1101of the operation, thus saving memory. 1102A lender SP can only donate NS memory to a borrower from the normal world. 1103 1104The SPMC supports the hypervisor retrieve request, as defined by the FF-A 1105v1.1 EAC0 specification, in section 16.4.3. The intent is to aid with operations 1106that the hypervisor must do for a VM retriever. For example, when handling 1107an FFA_MEM_RECLAIM, if the hypervisor relies on SPMC to keep the state 1108of the operation, the hypervisor retrieve request can be used to obtain 1109that state information, do the necessary validations, and update stage 2 1110memory translation. 1111 1112Hafnium also supports memory lend and share targetting multiple borrowers. 1113This is the case for a lender SP to multiple SPs, and for a lender VM to 1114multiple endpoints (from both secure world and normal world). If there is 1115at least one borrower VM, the hypervisor is in charge of managing its 1116stage 2 translation on a successful memory retrieve. 1117The semantics of ``FFA_MEM_DONATE`` implies ownership transmission, 1118which should target only one partition. 1119 1120The memory share interfaces are backwards compatible with memory transaction 1121descriptors from FF-A v1.0. These get translated to FF-A v1.1 descriptors for 1122Hafnium's internal processing of the operation. If the FF-A version of a 1123borrower is v1.0, Hafnium provides FF-A v1.0 compliant memory transaction 1124descriptors on memory retrieve response. 1125 1126PE MMU configuration 1127-------------------- 1128 1129With secure virtualization enabled (``HCR_EL2.VM = 1``) and for S-EL1 1130partitions, two IPA spaces (secure and non-secure) are output from the 1131secure EL1&0 Stage-1 translation. 1132The EL1&0 Stage-2 translation hardware is fed by: 1133 1134- A secure IPA when the SP EL1&0 Stage-1 MMU is disabled. 1135- One of secure or non-secure IPA when the secure EL1&0 Stage-1 MMU is enabled. 1136 1137``VTCR_EL2`` and ``VSTCR_EL2`` provide configuration bits for controlling the 1138NS/S IPA translations. The following controls are set up: 1139``VSTCR_EL2.SW = 0`` , ``VSTCR_EL2.SA = 0``, ``VTCR_EL2.NSW = 0``, 1140``VTCR_EL2.NSA = 1``: 1141 1142- Stage-2 translations for the NS IPA space access the NS PA space. 1143- Stage-2 translation table walks for the NS IPA space are to the secure PA space. 1144 1145Secure and non-secure IPA regions (rooted to by ``VTTBR_EL2`` and ``VSTTBR_EL2``) 1146use the same set of Stage-2 page tables within a SP. 1147 1148The ``VTCR_EL2/VSTCR_EL2/VTTBR_EL2/VSTTBR_EL2`` virtual address space 1149configuration is made part of a vCPU context. 1150 1151For S-EL0 partitions with VHE enabled, a single secure EL2&0 Stage-1 translation 1152regime is used for both Hafnium and the partition. 1153 1154Schedule modes and SP Call chains 1155--------------------------------- 1156 1157An SP execution context is said to be in SPMC scheduled mode if CPU cycles are 1158allocated to it by SPMC. Correspondingly, an SP execution context is said to be 1159in Normal world scheduled mode if CPU cycles are allocated by the normal world. 1160 1161A call chain represents all SPs in a sequence of invocations of a direct message 1162request. When execution on a PE is in the secure state, only a single call chain 1163that runs in the Normal World scheduled mode can exist. FF-A v1.1 spec allows 1164any number of call chains to run in the SPMC scheduled mode but the Hafnium 1165SPMC restricts the number of call chains in SPMC scheduled mode to only one for 1166keeping the implementation simple. 1167 1168Partition runtime models 1169------------------------ 1170 1171The runtime model of an endpoint describes the transitions permitted for an 1172execution context between various states. These are the four partition runtime 1173models supported (refer to `[1]`_ section 7): 1174 1175 - RTM_FFA_RUN: runtime model presented to an execution context that is 1176 allocated CPU cycles through FFA_RUN interface. 1177 - RTM_FFA_DIR_REQ: runtime model presented to an execution context that is 1178 allocated CPU cycles through FFA_MSG_SEND_DIRECT_REQ interface. 1179 - RTM_SEC_INTERRUPT: runtime model presented to an execution context that is 1180 allocated CPU cycles by SPMC to handle a secure interrupt. 1181 - RTM_SP_INIT: runtime model presented to an execution context that is 1182 allocated CPU cycles by SPMC to initialize its state. 1183 1184If an endpoint execution context attempts to make an invalid transition or a 1185valid transition that could lead to a loop in the call chain, SPMC denies the 1186transition with the help of above runtime models. 1187 1188Interrupt management 1189-------------------- 1190 1191GIC ownership 1192~~~~~~~~~~~~~ 1193 1194The SPMC owns the GIC configuration. Secure and non-secure interrupts are 1195trapped at S-EL2. The SPMC manages interrupt resources and allocates interrupt 1196IDs based on SP manifests. The SPMC acknowledges physical interrupts and injects 1197virtual interrupts by setting the use of vIRQ/vFIQ bits before resuming a SP. 1198 1199Abbreviations: 1200 1201 - NS-Int: A non-secure physical interrupt. It requires a switch to the normal 1202 world to be handled if it triggers while execution is in secure world. 1203 - Other S-Int: A secure physical interrupt targeted to an SP different from 1204 the one that is currently running. 1205 - Self S-Int: A secure physical interrupt targeted to the SP that is currently 1206 running. 1207 1208Non-secure interrupt handling 1209~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1210 1211This section documents the actions supported in SPMC in response to a non-secure 1212interrupt as per the guidance provided by FF-A v1.1 EAC0 specification. 1213An SP specifies one of the following actions in its partition manifest: 1214 1215 - Non-secure interrupt is signaled. 1216 - Non-secure interrupt is signaled after a managed exit. 1217 - Non-secure interrupt is queued. 1218 1219An SP execution context in a call chain could specify a less permissive action 1220than subsequent SP execution contexts in the same call chain. The less 1221permissive action takes precedence over the more permissive actions specified 1222by the subsequent execution contexts. Please refer to FF-A v1.1 EAC0 section 12238.3.1 for further explanation. 1224 1225Secure interrupt handling 1226~~~~~~~~~~~~~~~~~~~~~~~~~ 1227 1228This section documents the support implemented for secure interrupt handling in 1229SPMC as per the guidance provided by FF-A v1.1 EAC0 specification. 1230The following assumptions are made about the system configuration: 1231 1232 - In the current implementation, S-EL1 SPs are expected to use the para 1233 virtualized ABIs for interrupt management rather than accessing the virtual 1234 GIC interface. 1235 - Unless explicitly stated otherwise, this support is applicable only for 1236 S-EL1 SPs managed by SPMC. 1237 - Secure interrupts are configured as G1S or G0 interrupts. 1238 - All physical interrupts are routed to SPMC when running a secure partition 1239 execution context. 1240 - All endpoints with multiple execution contexts have their contexts pinned 1241 to corresponding CPUs. Hence, a secure virtual interrupt cannot be signaled 1242 to a target vCPU that is currently running or blocked on a different 1243 physical CPU. 1244 1245A physical secure interrupt could trigger while CPU is executing in normal world 1246or secure world. 1247The action of SPMC for a secure interrupt depends on: the state of the target 1248execution context of the SP that is responsible for handling the interrupt; 1249whether the interrupt triggered while execution was in normal world or secure 1250world. 1251 1252Secure interrupt signaling mechanisms 1253~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1254 1255Signaling refers to the mechanisms used by SPMC to indicate to the SP execution 1256context that it has a pending virtual interrupt and to further run the SP 1257execution context, such that it can handle the virtual interrupt. SPMC uses 1258either the FFA_INTERRUPT interface with ERET conduit or vIRQ signal for signaling 1259to S-EL1 SPs. When normal world execution is preempted by a secure interrupt, 1260the SPMD uses the FFA_INTERRUPT ABI with ERET conduit to signal interrupt to SPMC 1261running in S-EL2. 1262 1263+-----------+---------+---------------+---------------------------------------+ 1264| SP State | Conduit | Interface and | Description | 1265| | | parameters | | 1266+-----------+---------+---------------+---------------------------------------+ 1267| WAITING | ERET, | FFA_INTERRUPT,| SPMC signals to SP the ID of pending | 1268| | vIRQ | Interrupt ID | interrupt. It pends vIRQ signal and | 1269| | | | resumes execution context of SP | 1270| | | | through ERET. | 1271+-----------+---------+---------------+---------------------------------------+ 1272| BLOCKED | ERET, | FFA_INTERRUPT | SPMC signals to SP that an interrupt | 1273| | vIRQ | | is pending. It pends vIRQ signal and | 1274| | | | resumes execution context of SP | 1275| | | | through ERET. | 1276+-----------+---------+---------------+---------------------------------------+ 1277| PREEMPTED | vIRQ | NA | SPMC pends the vIRQ signal but does | 1278| | | | not resume execution context of SP. | 1279+-----------+---------+---------------+---------------------------------------+ 1280| RUNNING | ERET, | NA | SPMC pends the vIRQ signal and resumes| 1281| | vIRQ | | execution context of SP through ERET. | 1282+-----------+---------+---------------+---------------------------------------+ 1283 1284Secure interrupt completion mechanisms 1285~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1286 1287A SP signals secure interrupt handling completion to the SPMC through the 1288following mechanisms: 1289 1290 - ``FFA_MSG_WAIT`` ABI if it was in WAITING state. 1291 - ``FFA_RUN`` ABI if its was in BLOCKED state. 1292 1293This is a remnant of SPMC implementation based on the FF-A v1.0 specification. 1294In the current implementation, S-EL1 SPs use the para-virtualized HVC interface 1295implemented by SPMC to perform priority drop and interrupt deactivation (SPMC 1296configures EOImode = 0, i.e. priority drop and deactivation are done together). 1297The SPMC performs checks to deny the state transition upon invocation of 1298either FFA_MSG_WAIT or FFA_RUN interface if the SP didn't perform the 1299deactivation of the secure virtual interrupt. 1300 1301If the current SP execution context was preempted by a secure interrupt to be 1302handled by execution context of target SP, SPMC resumes current SP after signal 1303completion by target SP execution context. 1304 1305Actions for a secure interrupt triggered while execution is in normal world 1306~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1307 1308+-------------------+----------+-----------------------------------------------+ 1309| State of target | Action | Description | 1310| execution context | | | 1311+-------------------+----------+-----------------------------------------------+ 1312| WAITING | Signaled | This starts a new call chain in SPMC scheduled| 1313| | | mode. | 1314+-------------------+----------+-----------------------------------------------+ 1315| PREEMPTED | Queued | The target execution must have been preempted | 1316| | | by a non-secure interrupt. SPMC queues the | 1317| | | secure virtual interrupt now. It is signaled | 1318| | | when the target execution context next enters | 1319| | | the RUNNING state. | 1320+-------------------+----------+-----------------------------------------------+ 1321| BLOCKED, RUNNING | NA | The target execution context is blocked or | 1322| | | running on a different CPU. This is not | 1323| | | supported by current SPMC implementation and | 1324| | | execution hits panic. | 1325+-------------------+----------+-----------------------------------------------+ 1326 1327If normal world execution was preempted by a secure interrupt, SPMC uses 1328FFA_NORMAL_WORLD_RESUME ABI to indicate completion of secure interrupt handling 1329and further returns execution to normal world. 1330 1331The following figure describes interrupt handling flow when a secure interrupt 1332triggers while execution is in normal world: 1333 1334.. image:: ../resources/diagrams/ffa-secure-interrupt-handling-nwd.png 1335 1336A brief description of the events: 1337 1338 - 1) Secure interrupt triggers while normal world is running. 1339 - 2) FIQ gets trapped to EL3. 1340 - 3) SPMD signals secure interrupt to SPMC at S-EL2 using FFA_INTERRUPT ABI. 1341 - 4) SPMC identifies target vCPU of SP and injects virtual interrupt (pends 1342 vIRQ). 1343 - 5) Assuming SP1 vCPU is in WAITING state, SPMC signals virtual interrupt 1344 using FFA_INTERRUPT with interrupt id as an argument and resumes the SP1 1345 vCPU using ERET in SPMC scheduled mode. 1346 - 6) Execution traps to vIRQ handler in SP1 provided that the virtual 1347 interrupt is not masked i.e., PSTATE.I = 0 1348 - 7) SP1 queries for the pending virtual interrupt id using a paravirtualized 1349 HVC call. SPMC clears the pending virtual interrupt state management 1350 and returns the pending virtual interrupt id. 1351 - 8) SP1 services the virtual interrupt and invokes the paravirtualized 1352 de-activation HVC call. SPMC de-activates the physical interrupt, 1353 clears the fields tracking the secure interrupt and resumes SP1 vCPU. 1354 - 9) SP1 performs secure interrupt completion through FFA_MSG_WAIT ABI. 1355 - 10) SPMC returns control to EL3 using FFA_NORMAL_WORLD_RESUME. 1356 - 11) EL3 resumes normal world execution. 1357 1358Actions for a secure interrupt triggered while execution is in secure world 1359~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 1360 1361+-------------------+----------+------------------------------------------------+ 1362| State of target | Action | Description | 1363| execution context | | | 1364+-------------------+----------+------------------------------------------------+ 1365| WAITING | Signaled | This starts a new call chain in SPMC scheduled | 1366| | | mode. | 1367+-------------------+----------+------------------------------------------------+ 1368| PREEMPTED by Self | Signaled | The target execution context reenters the | 1369| S-Int | | RUNNING state to handle the secure virtual | 1370| | | interrupt. | 1371+-------------------+----------+------------------------------------------------+ 1372| PREEMPTED by | Queued | SPMC queues the secure virtual interrupt now. | 1373| NS-Int | | It is signaled when the target execution | 1374| | | context next enters the RUNNING state. | 1375+-------------------+----------+------------------------------------------------+ 1376| BLOCKED | Signaled | Both preempted and target execution contexts | 1377| | | must have been part of the Normal world | 1378| | | scheduled call chain. Refer scenario 1 of | 1379| | | Table 8.4 in the FF-A v1.1 EAC0 spec. | 1380+-------------------+----------+------------------------------------------------+ 1381| RUNNING | NA | The target execution context is running on a | 1382| | | different CPU. This scenario is not supported | 1383| | | by current SPMC implementation and execution | 1384| | | hits panic. | 1385+-------------------+----------+------------------------------------------------+ 1386 1387The following figure describes interrupt handling flow when a secure interrupt 1388triggers while execution is in secure world. We assume OS kernel sends a direct 1389request message to SP1. Further, SP1 sends a direct request message to SP2. SP1 1390enters BLOCKED state and SPMC resumes SP2. 1391 1392.. image:: ../resources/diagrams/ffa-secure-interrupt-handling-swd.png 1393 1394A brief description of the events: 1395 1396 - 1) Secure interrupt triggers while SP2 is running. 1397 - 2) SP2 gets preempted and execution traps to SPMC as IRQ. 1398 - 3) SPMC finds the target vCPU of secure partition responsible for handling 1399 this secure interrupt. In this scenario, it is SP1. 1400 - 4) SPMC pends vIRQ for SP1 and signals through FFA_INTERRUPT interface. 1401 SPMC further resumes SP1 through ERET conduit. Note that SP1 remains in 1402 Normal world schedule mode. 1403 - 6) Execution traps to vIRQ handler in SP1 provided that the virtual 1404 interrupt is not masked i.e., PSTATE.I = 0 1405 - 7) SP1 queries for the pending virtual interrupt id using a paravirtualized 1406 HVC call. SPMC clears the pending virtual interrupt state management 1407 and returns the pending virtual interrupt id. 1408 - 8) SP1 services the virtual interrupt and invokes the paravirtualized 1409 de-activation HVC call. SPMC de-activates the physical interrupt and 1410 clears the fields tracking the secure interrupt and resumes SP1 vCPU. 1411 - 9) Since SP1 direct request completed with FFA_INTERRUPT, it resumes the 1412 direct request to SP2 by invoking FFA_RUN. 1413 - 9) SPMC resumes the pre-empted vCPU of SP2. 1414 1415EL3 interrupt handling 1416~~~~~~~~~~~~~~~~~~~~~~ 1417 1418In GICv3 based systems, EL3 interrupts are configured as Group0 secure 1419interrupts. Execution traps to SPMC when a Group0 interrupt triggers while an 1420SP is running. Further, SPMC running at S-EL2 uses FFA_EL3_INTR_HANDLE ABI to 1421request EL3 platform firmware to handle a pending Group0 interrupt. 1422Similarly, SPMD registers a handler with interrupt management framework to 1423delegate handling of Group0 interrupt to the platform if the interrupt triggers 1424in normal world. 1425 1426 - Platform hook 1427 1428 - plat_spmd_handle_group0_interrupt 1429 1430 SPMD provides platform hook to handle Group0 secure interrupts. In the 1431 current design, SPMD expects the platform not to delegate handling to the 1432 NWd (such as through SDEI) while processing Group0 interrupts. 1433 1434Power management 1435---------------- 1436 1437In platforms with or without secure virtualization: 1438 1439- The NWd owns the platform PM policy. 1440- The Hypervisor or OS kernel is the component initiating PSCI service calls. 1441- The EL3 PSCI library is in charge of the PM coordination and control 1442 (eventually writing to platform registers). 1443- While coordinating PM events, the PSCI library calls backs into the Secure 1444 Payload Dispatcher for events the latter has statically registered to. 1445 1446When using the SPMD as a Secure Payload Dispatcher: 1447 1448- A power management event is relayed through the SPD hook to the SPMC. 1449- In the current implementation only cpu on (svc_on_finish) and cpu off 1450 (svc_off) hooks are registered. 1451- The behavior for the cpu on event is described in `Secondary cores boot-up`_. 1452 The SPMC is entered through its secondary physical core entry point. 1453- The cpu off event occurs when the NWd calls PSCI_CPU_OFF. The PM event is 1454 signaled to the SPMC through a power management framework message. 1455 It consists in a SPMD-to-SPMC direct request/response (`SPMC-SPMD direct 1456 requests/responses`_) conveying the event details and SPMC response. 1457 The SPMD performs a synchronous entry into the SPMC. The SPMC is entered and 1458 updates its internal state to reflect the physical core is being turned off. 1459 In the current implementation no SP is resumed as a consequence. This behavior 1460 ensures a minimal support for CPU hotplug e.g. when initiated by the NWd linux 1461 userspace. 1462 1463Arm architecture extensions for security hardening 1464================================================== 1465 1466Hafnium supports the following architecture extensions for security hardening: 1467 1468- Pointer authentication (FEAT_PAuth): the extension permits detection of forged 1469 pointers used by ROP type of attacks through the signing of the pointer 1470 value. Hafnium is built with the compiler branch protection option to permit 1471 generation of a pointer authentication code for return addresses (pointer 1472 authentication for instructions). The APIA key is used while Hafnium runs. 1473 A random key is generated at boot time and restored upon entry into Hafnium 1474 at run-time. APIA and other keys (APIB, APDA, APDB, APGA) are saved/restored 1475 in vCPU contexts permitting to enable pointer authentication in VMs/SPs. 1476- Branch Target Identification (FEAT_BTI): the extension permits detection of 1477 unexpected indirect branches used by JOP type of attacks. Hafnium is built 1478 with the compiler branch protection option, inserting land pads at function 1479 prologues that are reached by indirect branch instructions (BR/BLR). 1480 Hafnium code pages are marked as guarded in the EL2 Stage-1 MMU descriptors 1481 such that an indirect branch must always target a landpad. A fault is 1482 triggered otherwise. VMs/SPs can (independently) mark their code pages as 1483 guarded in the EL1&0 Stage-1 translation regime. 1484- Memory Tagging Extension (FEAT_MTE): the option permits detection of out of 1485 bound memory array accesses or re-use of an already freed memory region. 1486 Hafnium enables the compiler option permitting to leverage MTE stack tagging 1487 applied to core stacks. Core stacks are marked as normal tagged memory in the 1488 EL2 Stage-1 translation regime. A synchronous data abort is generated upon tag 1489 check failure on load/stores. A random seed is generated at boot time and 1490 restored upon entry into Hafnium. MTE system registers are saved/restored in 1491 vCPU contexts permitting MTE usage from VMs/SPs. 1492 1493SMMUv3 support in Hafnium 1494========================= 1495 1496An SMMU is analogous to an MMU in a CPU. It performs address translations for 1497Direct Memory Access (DMA) requests from system I/O devices. 1498The responsibilities of an SMMU include: 1499 1500- Translation: Incoming DMA requests are translated from bus address space to 1501 system physical address space using translation tables compliant to 1502 Armv8/Armv7 VMSA descriptor format. 1503- Protection: An I/O device can be prohibited from read, write access to a 1504 memory region or allowed. 1505- Isolation: Traffic from each individial device can be independently managed. 1506 The devices are differentiated from each other using unique translation 1507 tables. 1508 1509The following diagram illustrates a typical SMMU IP integrated in a SoC with 1510several I/O devices along with Interconnect and Memory system. 1511 1512.. image:: ../resources/diagrams/MMU-600.png 1513 1514SMMU has several versions including SMMUv1, SMMUv2 and SMMUv3. Hafnium provides 1515support for SMMUv3 driver in both normal and secure world. A brief introduction 1516of SMMUv3 functionality and the corresponding software support in Hafnium is 1517provided here. 1518 1519SMMUv3 features 1520--------------- 1521 1522- SMMUv3 provides Stage1, Stage2 translation as well as nested (Stage1 + Stage2) 1523 translation support. It can either bypass or abort incoming translations as 1524 well. 1525- Traffic (memory transactions) from each upstream I/O peripheral device, 1526 referred to as Stream, can be independently managed using a combination of 1527 several memory based configuration structures. This allows the SMMUv3 to 1528 support a large number of streams with each stream assigned to a unique 1529 translation context. 1530- Support for Armv8.1 VMSA where the SMMU shares the translation tables with 1531 a Processing Element. AArch32(LPAE) and AArch64 translation table format 1532 are supported by SMMUv3. 1533- SMMUv3 offers non-secure stream support with secure stream support being 1534 optional. Logically, SMMUv3 behaves as if there is an indepdendent SMMU 1535 instance for secure and non-secure stream support. 1536- It also supports sub-streams to differentiate traffic from a virtualized 1537 peripheral associated with a VM/SP. 1538- Additionally, SMMUv3.2 provides support for PEs implementing Armv8.4-A 1539 extensions. Consequently, SPM depends on Secure EL2 support in SMMUv3.2 1540 for providing Secure Stage2 translation support to upstream peripheral 1541 devices. 1542 1543SMMUv3 Programming Interfaces 1544----------------------------- 1545 1546SMMUv3 has three software interfaces that are used by the Hafnium driver to 1547configure the behaviour of SMMUv3 and manage the streams. 1548 1549- Memory based data strutures that provide unique translation context for 1550 each stream. 1551- Memory based circular buffers for command queue and event queue. 1552- A large number of SMMU configuration registers that are memory mapped during 1553 boot time by Hafnium driver. Except a few registers, all configuration 1554 registers have independent secure and non-secure versions to configure the 1555 behaviour of SMMUv3 for translation of secure and non-secure streams 1556 respectively. 1557 1558Peripheral device manifest 1559-------------------------- 1560 1561Currently, SMMUv3 driver in Hafnium only supports dependent peripheral devices. 1562These devices are dependent on PE endpoint to initiate and receive memory 1563management transactions on their behalf. The acccess to the MMIO regions of 1564any such device is assigned to the endpoint during boot. Moreover, SMMUv3 driver 1565uses the same stage 2 translations for the device as those used by partition 1566manager on behalf of the PE endpoint. This ensures that the peripheral device 1567has the same visibility of the physical address space as the endpoint. The 1568device node of the corresponding partition manifest (refer to `[1]`_ section 3.2 1569) must specify these additional properties for each peripheral device in the 1570system : 1571 1572- smmu-id: This field helps to identify the SMMU instance that this device is 1573 upstream of. 1574- stream-ids: List of stream IDs assigned to this device. 1575 1576.. code:: shell 1577 1578 smmuv3-testengine { 1579 base-address = <0x00000000 0x2bfe0000>; 1580 pages-count = <32>; 1581 attributes = <0x3>; 1582 smmu-id = <0>; 1583 stream-ids = <0x0 0x1>; 1584 interrupts = <0x2 0x3>, <0x4 0x5>; 1585 exclusive-access; 1586 }; 1587 1588SMMUv3 driver limitations 1589------------------------- 1590 1591The primary design goal for the Hafnium SMMU driver is to support secure 1592streams. 1593 1594- Currently, the driver only supports Stage2 translations. No support for 1595 Stage1 or nested translations. 1596- Supports only AArch64 translation format. 1597- No support for features such as PCI Express (PASIDs, ATS, PRI), MSI, RAS, 1598 Fault handling, Performance Monitor Extensions, Event Handling, MPAM. 1599- No support for independent peripheral devices. 1600 1601S-EL0 Partition support 1602======================= 1603The SPMC (Hafnium) has limited capability to run S-EL0 FF-A partitions using 1604FEAT_VHE (mandatory with ARMv8.1 in non-secure state, and in secure world 1605with ARMv8.4 and FEAT_SEL2). 1606 1607S-EL0 partitions are useful for simple partitions that don't require full 1608Trusted OS functionality. It is also useful to reduce jitter and cycle 1609stealing from normal world since they are more lightweight than VMs. 1610 1611S-EL0 partitions are presented, loaded and initialized the same as S-EL1 VMs by 1612the SPMC. They are differentiated primarily by the 'exception-level' property 1613and the 'execution-ctx-count' property in the SP manifest. They are host apps 1614under the single EL2&0 Stage-1 translation regime controlled by the SPMC and 1615call into the SPMC through SVCs as opposed to HVCs and SMCs. These partitions 1616can use FF-A defined services (FFA_MEM_PERM_*) to update or change permissions 1617for memory regions. 1618 1619S-EL0 partitions are required by the FF-A specification to be UP endpoints, 1620capable of migrating, and the SPMC enforces this requirement. The SPMC allows 1621a S-EL0 partition to accept a direct message from secure world and normal world, 1622and generate direct responses to them. 1623All S-EL0 partitions must use AArch64. AArch32 S-EL0 partitions are not supported. 1624 1625Memory sharing, indirect messaging, and notifications functionality with S-EL0 1626partitions is supported. 1627 1628Interrupt handling is not supported with S-EL0 partitions and is work in 1629progress. 1630 1631References 1632========== 1633 1634.. _[1]: 1635 1636[1] `Arm Firmware Framework for Arm A-profile <https://developer.arm.com/docs/den0077/latest>`__ 1637 1638.. _[2]: 1639 1640[2] :ref:`Secure Partition Manager using MM interface<Secure Partition Manager (MM)>` 1641 1642.. _[3]: 1643 1644[3] `Trusted Boot Board Requirements 1645Client <https://developer.arm.com/documentation/den0006/d/>`__ 1646 1647.. _[4]: 1648 1649[4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/lib/el3_runtime/aarch64/context.S#n45 1650 1651.. _[5]: 1652 1653[5] https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/plat/arm/fvp/fdts/cactus.dts 1654 1655.. _[6]: 1656 1657[6] https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html 1658 1659.. _[7]: 1660 1661[7] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/board/fvp/fdts/fvp_spmc_manifest.dts 1662 1663.. _[8]: 1664 1665[8] https://lists.trustedfirmware.org/archives/list/[email protected]/thread/CFQFGU6H2D5GZYMUYGTGUSXIU3OYZP6U/ 1666 1667.. _[9]: 1668 1669[9] https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html#dynamic-configuration-during-cold-boot 1670 1671-------------- 1672 1673*Copyright (c) 2020-2024, Arm Limited and Contributors. All rights reserved.* 1674
