Djam/arm-trusted-firmware
1
0
Fork 0
mirror of https://github.com/ARM-software/arm-trusted-firmware.git synced 2025-04-16 09:34:18 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs(spm): refresh FF-A SPM design doc

Browse source 
- Move manifest binding doc as a dedicated SPM doc section.
- Highlight introduction of an EL3 FF-A SPM solution.
- Refresh TF-A build options.
- Refresh PE MMU configuration section.
- Add arch extensions for security hardening section.
- Minor corrections, typos fixes and rephrasing.

Signed-off-by: Olivier Deprez <olivier.deprez@arm.com>
Change-Id: I2db06c140ef5871a812ce00a4398c663d5433bb4
This commit is contained in:
Olivier Deprez 2022-04-28 18:18:36 +02:00
parent 79a913812f
commit 9eea92a1f2
2 changed files with 171 additions and 110 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

1
docs/components/index.rst
View file

@ -21,7 +21,6 @@ Components
sdei
secure-partition-manager
secure-partition-manager-mm
ffa-manifest-binding
xlat-tables-lib-v2-design
cot-binding
realm-management-extension

280
docs/components/secure-partition-manager.rst
View file

@ -3,6 +3,9 @@ Secure Partition Manager
.. contents::
.. toctree::
ffa-manifest-binding
Acronyms
========
@ -23,6 +26,8 @@ Acronyms
+--------+--------------------------------------+
| IPA | Intermediate Physical Address |
+--------+--------------------------------------+
| JOP | Jump-Oriented Programming |
+--------+--------------------------------------+
| NWd | Normal World |
+--------+--------------------------------------+
| ODM | Original Design Manufacturer |
@ -37,6 +42,8 @@ Acronyms
+--------+--------------------------------------+
| PVM | Primary VM |
+--------+--------------------------------------+
| ROP | Return-Oriented Programming |
+--------+--------------------------------------+
| SMMU | System Memory Management Unit |
+--------+--------------------------------------+
| SP | Secure Partition |
@ -63,24 +70,25 @@ Acronyms
Foreword
========
Two implementations of a Secure Partition Manager co-exist in the TF-A codebase:
Three implementations of a Secure Partition Manager co-exist in the TF-A
codebase:
- SPM based on the FF-A specification `[1]`_.
- SPM based on the MM interface to communicate with an S-EL0 partition `[2]`_.
#. S-EL2 SPMC based on the FF-A specification `[1]`_, enabling virtualization in
the secure world, managing multiple S-EL1 or S-EL0 partitions.
#. EL3 SPMC based on the FF-A specification, managing a single S-EL1 partition
without virtualization in the secure world.
#. EL3 SPM based on the MM specification, legacy implementation managing a
single S-EL0 partition `[2]`_.
Both implementations differ in their architectures and only one can be selected
at build time.
These implementations differ in their respective SW architecture and only one
can be selected at build time. This document:
This document:
- describes the FF-A implementation where the Secure Partition Manager
resides at EL3 and S-EL2 (or EL3 and S-EL1).
- describes the implementation from bullet 1. when the SPMC resides at S-EL2.
- is not an architecture specification and it might provide assumptions
on sections mandated as implementation-defined in the specification.
- covers the implications to TF-A used as a bootloader, and Hafnium
used as a reference code base for an S-EL2 secure firmware on
platforms implementing the FEAT_SEL2 (formerly Armv8.4 Secure EL2)
architecture extension.
- covers the implications to TF-A used as a bootloader, and Hafnium used as a
reference code base for an S-EL2/SPMC secure firmware on platforms
implementing the FEAT_SEL2 architecture extension.
Terminology
-----------
@ -98,20 +106,23 @@ Terminology
Support for legacy platforms
----------------------------
In the implementation, the SPM is split into SPMD and SPMC components.
The SPMD is located at EL3 and mainly relays FF-A messages from
NWd (Hypervisor or OS kernel) to SPMC located either at S-EL1 or S-EL2.
The SPM is split into a dispatcher and a core component (respectively SPMD and
SPMC) residing at different exception levels. To permit the FF-A specification
adoption and a smooth migration, the SPMD supports an SPMC residing either at
S-EL1 or S-EL2:
Hence TF-A supports both cases where the SPMC is located either at:
- The SPMD is located at EL3 and mainly relays the FF-A protocol from NWd
(Hypervisor or OS kernel) to the SPMC.
- The same SPMD component is used for both S-EL1 and S-EL2 SPMC configurations.
- The SPMC exception level is a build time choice.
- S-EL1 supporting platforms not implementing the FEAT_SEL2 architecture
TF-A supports both cases:
- S-EL1 SPMC for platforms not supporting the FEAT_SEL2 architecture
extension. The SPMD relays the FF-A protocol from EL3 to S-EL1.
- or S-EL2 supporting platforms implementing the FEAT_SEL2 architecture
- S-EL2 SPMC for platforms implementing the FEAT_SEL2 architecture
extension. The SPMD relays the FF-A protocol from EL3 to S-EL2.
The same TF-A SPMD component is used to support both configurations.
The SPMC exception level is a build time choice.
Sample reference stack
======================
@ -137,7 +148,7 @@ SPMC located at S-EL1, S-EL2 or EL3:
SPD=spmd is chosen.
- **SPMC_AT_EL3**: this option adjusts the SPMC exception level to being
at EL3.
- If neither **SPMD_SPM_AT_SEL2** or **SPMC_AT_EL3** are enabled the SPMC
- If neither ``SPMD_SPM_AT_SEL2`` or ``SPMC_AT_EL3`` are enabled the SPMC
exception level is set to S-EL1.
- **CTX_INCLUDE_EL2_REGS**: this option permits saving (resp.
restoring) the EL2 system register context before entering (resp.
@ -148,7 +159,7 @@ SPMC located at S-EL1, S-EL2 or EL3:
providing paths to SP binary images and manifests in DTS format
(see `Describing secure partitions`_). It
is required when ``SPMD_SPM_AT_SEL2`` is enabled hence when multiple
secure partitions are to be loaded on behalf of the SPMC.
secure partitions are to be loaded by BL2 on behalf of the SPMC.
+---------------+----------------------+------------------+-------------+
| | CTX_INCLUDE_EL2_REGS | SPMD_SPM_AT_SEL2 | SPMC_AT_EL3 |
@ -168,9 +179,8 @@ Notes:
- Only Arm's FVP platform is supported to use with the TF-A reference software
stack.
- The reference software stack uses FEAT_PAuth (formerly Armv8.3-PAuth) and
FEAT_BTI (formerly Armv8.5-BTI) architecture extensions by default at EL3
and S-EL2.
- When ``SPMD_SPM_AT_SEL2=1``, the reference software stack assumes enablement
of FEAT_PAuth, FEAT_BTI and FEAT_MTE architecture extensions.
- The ``CTX_INCLUDE_EL2_REGS`` option provides the generic support for
barely saving/restoring EL2 registers from an Arm arch perspective. As such
it is decoupled from the ``SPD=spmd`` option.
@ -178,10 +188,10 @@ Notes:
the Hafnium binary path (built for the secure world) or the path to a TEE
binary implementing FF-A interfaces.
- BL33 option can specify the TFTF binary or a normal world loader
such as U-Boot or the UEFI framework.
such as U-Boot or the UEFI framework payload.
Sample TF-A build command line when SPMC is located at S-EL1
(e.g. when the FEAT_EL2 architecture extension is not implemented):
Sample TF-A build command line when the SPMC is located at S-EL1
(e.g. when the FEAT_SEL2 architecture extension is not implemented):
.. code:: shell
@ -194,9 +204,8 @@ Sample TF-A build command line when SPMC is located at S-EL1
PLAT=fvp \
all fip
Sample TF-A build command line for a FEAT_SEL2 enabled system where the SPMC is
located at S-EL2:
Sample TF-A build command line when FEAT_SEL2 architecture extension is
implemented and the SPMC is located at S-EL2:
.. code:: shell
make \
@ -207,13 +216,14 @@ located at S-EL2:
ARM_ARCH_MINOR=5 \
BRANCH_PROTECTION=1 \
CTX_INCLUDE_PAUTH_REGS=1 \
CTX_INCLUDE_MTE_REGS=1 \
BL32=<path-to-hafnium-binary> \
BL33=<path-to-bl33-binary> \
SP_LAYOUT_FILE=sp_layout.json \
all fip
Same as above with enabling secure boot in addition:
Sample TF-A build command line when FEAT_SEL2 architecture extension is
implemented, the SPMC is located at S-EL2, and enabling secure boot:
.. code:: shell
make \
@ -224,6 +234,7 @@ Same as above with enabling secure boot in addition:
ARM_ARCH_MINOR=5 \
BRANCH_PROTECTION=1 \
CTX_INCLUDE_PAUTH_REGS=1 \
CTX_INCLUDE_MTE_REGS=1 \
BL32=<path-to-hafnium-binary> \
BL33=<path-to-bl33-binary> \
SP_LAYOUT_FILE=sp_layout.json \
@ -235,7 +246,7 @@ Same as above with enabling secure boot in addition:
GENERATE_COT=1 \
all fip
Sample TF-A build command line when SPMC is located at EL3:
Sample TF-A build command line when the SPMC is located at EL3:
.. code:: shell
@ -270,29 +281,33 @@ The FVP command line needs the following options to exercise the S-EL2 SPMC:
| - cluster0.has_branch_target_exception=1 | Implements FEAT_BTI. |
| - cluster1.has_branch_target_exception=1 | |
+---------------------------------------------------+------------------------------------+
| - cluster0.restriction_on_speculative_execution=2 | Required by the EL2 context |
| - cluster1.restriction_on_speculative_execution=2 | save/restore routine. |
| - cluster0.has_pointer_authentication=2 | Implements FEAT_PAuth |
| - cluster1.has_pointer_authentication=2 | |
+---------------------------------------------------+------------------------------------+
| - cluster0.memory_tagging_support_level=2 | Implements FEAT_MTE2 |
| - cluster1.memory_tagging_support_level=2 | |
| - bp.dram_metadata.is_enabled=1 | |
+---------------------------------------------------+------------------------------------+
Sample FVP command line invocation:
.. code:: shell
<path-to-fvp-model>/FVP_Base_RevC-2xAEMv8A -C pctl.startup=0.0.0.0
<path-to-fvp-model>/FVP_Base_RevC-2xAEMvA -C pctl.startup=0.0.0.0 \
-C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 \
-C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin \
-C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin \
-C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log \
-C bp.pl011_uart2.out_file=fvp-uart2.log \
-C cluster0.has_arm_v8-5=1 -C cluster1.has_arm_v8-5=1 -C pci.pci_smmuv3.mmu.SMMU_AIDR=2 \
-C pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B -C pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 \
-C pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 -C pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0472 \
-C pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 -C pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 \
-C pci.pci_smmuv3.mmu.SMMU_S_IDR3=0 \
-C cluster0.has_branch_target_exception=1 \
-C cluster1.has_branch_target_exception=1 \
-C cluster0.restriction_on_speculative_execution=2 \
-C cluster1.restriction_on_speculative_execution=2
-C cluster0.has_arm_v8-5=1 -C cluster1.has_arm_v8-5=1 \
-C cluster0.has_pointer_authentication=2 -C cluster1.has_pointer_authentication=2 \
-C cluster0.has_branch_target_exception=1 -C cluster1.has_branch_target_exception=1 \
-C cluster0.memory_tagging_support_level=2 -C cluster1.memory_tagging_support_level=2 \
-C bp.dram_metadata.is_enabled=1 \
-C pci.pci_smmuv3.mmu.SMMU_AIDR=2 -C pci.pci_smmuv3.mmu.SMMU_IDR0=0x0046123B \
-C pci.pci_smmuv3.mmu.SMMU_IDR1=0x00600002 -C pci.pci_smmuv3.mmu.SMMU_IDR3=0x1714 \
-C pci.pci_smmuv3.mmu.SMMU_IDR5=0xFFFF0472 -C pci.pci_smmuv3.mmu.SMMU_S_IDR1=0xA0000002 \
-C pci.pci_smmuv3.mmu.SMMU_S_IDR2=0 -C pci.pci_smmuv3.mmu.SMMU_S_IDR3=0
Boot process
============
@ -424,7 +439,7 @@ two different cases:
attribute {
spmc_id = <0x8000>;
maj_ver = <0x1>;
min_ver = <0x0>;
min_ver = <0x1>;
exec_state = <0x0>;
load_address = <0x0 0x6000000>;
entrypoint = <0x0 0x6000000>;
@ -443,13 +458,13 @@ two different cases:
SPMD (currently matches ``BL32_BASE``) to enter the SPMC.
Other nodes in the manifest are consumed by Hafnium in the secure world.
A sample can be found at [7]:
A sample can be found at `[7]`_:
- The *hypervisor* node describes SPs. *is_ffa_partition* boolean attribute
indicates a FF-A compliant SP. The *load_address* field specifies the load
address at which TF-A loaded the SP package.
address at which BL2 loaded the SP package.
- *cpus* node provide the platform topology and allows MPIDR to VMPIDR mapping.
Note the primary core is declared first, then secondary core are declared
Note the primary core is declared first, then secondary cores are declared
in reverse order.
- The *memory* node provides platform information on the ranges of memory
available to the SPMC.
@ -481,7 +496,7 @@ below:
Note this boot flow is an implementation sample on Arm's FVP platform.
Platforms not using TF-A's *Firmware CONFiguration* framework would adjust to a
different implementation.
different boot flow. The flow restricts to a maximum of 8 secure partitions.
Secure boot
~~~~~~~~~~~
@ -496,6 +511,8 @@ the use of two root keys namely S-ROTPK and NS-ROTPK:
- SPMC (BL32) and SPMC manifest are signed by the SiP using the S-ROTPK.
- BL33 may be signed by the OEM using NS-ROTPK.
- An SP may be signed either by SiP (using S-ROTPK) or by OEM (using NS-ROTPK).
- A maximum of 4 partitions can be signed with the S-ROTPK key and 4 partitions
signed with the NS-ROTPK key.
Also refer to `Describing secure partitions`_ and `TF-A build options`_ sections.
@ -512,20 +529,23 @@ In the Hafnium reference implementation specific code parts are only relevant to
the secure world. Such portions are isolated in architecture specific files
and/or enclosed by a ``SECURE_WORLD`` macro.
Secure partitions CPU scheduling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Secure partitions scheduling
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The FF-A v1.0 specification `[1]`_ provides two ways to relinquinsh CPU time to
The FF-A specification `[1]`_ provides two ways to relinquinsh CPU time to
secure partitions. For this a VM (Hypervisor or OS kernel), or SP invokes one of:
- the FFA_MSG_SEND_DIRECT_REQ interface.
- the FFA_RUN interface.
Additionally a secure interrupt can pre-empt the normal world execution and give
CPU cycles by transitioning to EL3 and S-EL2.
Platform topology
~~~~~~~~~~~~~~~~~
The *execution-ctx-count* SP manifest field can take the value of one or the
total number of PEs. The FF-A v1.0 specification `[1]`_ recommends the
total number of PEs. The FF-A specification `[1]`_ recommends the
following SP types:
- Pinned MP SPs: an execution context matches a physical PE. MP SPs must
@ -711,29 +731,30 @@ called and informed by the FF-A driver, and it should allocate CPU cycles to the
receiver.
There are two types of notifications supported:
- Global, which are targeted to a FF-A endpoint and can be handled within any of
its execution contexts, as determined by the scheduler of the system.
its execution contexts, as determined by the scheduler of the system.
- Per-vCPU, which are targeted to a FF-A endpoint and to be handled within a
a specific execution context, as determined by the sender.
a specific execution context, as determined by the sender.
The type of a notification is set when invoking FFA_NOTIFICATION_BIND to give
permissions to the sender.
Notification signaling resorts to two interrupts:
- Schedule Receiver Interrupt: Non-secure physical interrupt to be handled by
the FF-A 'transport' driver within the receiver scheduler. At initialization
the SPMC (as suggested by the spec) configures a secure SGI, as non-secure, and
triggers it when there are pending notifications, and the respective receivers
need CPU cycles to handle them.
- Notifications Pending Interrupt: Virtual Interrupt to be handled by the
receiver of the notification. Set when there are pending notifications. For
per-vCPU the NPI is pended at the handling of FFA_NOTIFICATION_SET interface.
- Schedule Receiver Interrupt: non-secure physical interrupt to be handled by
the FF-A driver within the receiver scheduler. At initialization the SPMC
donates a SGI ID chosen from the secure SGI IDs range and configures it as
non-secure. The SPMC triggers this SGI on the currently running core when
there are pending notifications, and the respective receivers need CPU cycles
to handle them.
- Notifications Pending Interrupt: virtual interrupt to be handled by the
receiver of the notification. Set when there are pending notifications for the
given secure partition. The NPI is pended when the NWd relinquishes CPU cycles
to an SP.
The notifications receipt support is enabled in the partition FF-A manifest.
The subsequent section provides more details about the each one of the
FF-A interfaces for notifications support.
Mandatory interfaces
--------------------
@ -755,9 +776,12 @@ The following interfaces are exposed to SPs:
- ``FFA_MEM_RETRIEVE_REQ``
- ``FFA_MEM_RETRIEVE_RESP``
- ``FFA_MEM_RELINQUISH``
- ``FFA_MEM_FRAG_RX``
- ``FFA_MEM_FRAG_TX``
- ``FFA_MEM_RECLAIM``
- ``FFA_RUN``
As part of the support of FF-A v1.1, the following interfaces were added:
As part of the FF-A v1.1 support, the following interfaces were added:
- ``FFA_NOTIFICATION_BITMAP_CREATE``
- ``FFA_NOTIFICATION_BITMAP_DESTROY``
@ -768,6 +792,8 @@ As part of the support of FF-A v1.1, the following interfaces were added:
- ``FFA_NOTIFICATION_INFO_GET``
- ``FFA_SPM_ID_GET``
- ``FFA_SECONDARY_EP_REGISTER``
- ``FFA_MEM_PERM_GET``
- ``FFA_MEM_PERM_SET``
FFA_VERSION
~~~~~~~~~~~
@ -895,24 +921,21 @@ notifications.
FFA_NOTIFICATION_SET/FFA_NOTIFICATION_GET
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
If the notifications set are per-vCPU, the NPI interrupt is set as pending
for a given receiver partition.
FFA_NOTIFICATION_GET retrieves all pending global notifications and
per-vCPU notifications targeted to the current vCPU.
The FFA_NOTIFICATION_GET will retrieve all pending global notifications and all
pending per-vCPU notifications targeted to the current vCPU.
Hafnium keeps the global counting of the pending notifications, which is
incremented and decremented at the handling of FFA_NOTIFICATION_SET and
FFA_NOTIFICATION_GET, respectively. If the counter reaches zero, prior to SPMC
triggering the SRI, it won't be triggered.
Hafnium maintains a global count of pending notifications which gets incremented
and decremented when handling FFA_NOTIFICATION_SET and FFA_NOTIFICATION_GET
respectively. A delayed SRI is triggered if the counter is non-zero when the
SPMC returns to normal world.
FFA_NOTIFICATION_INFO_GET
~~~~~~~~~~~~~~~~~~~~~~~~~
Hafnium keeps the global counting of pending notifications whose info has been
retrieved by this interface. The counting is incremented and decremented at the
handling of FFA_NOTIFICATION_INFO_GET and FFA_NOTIFICATION_GET, respectively.
It also tracks the notifications whose info has been retrieved individually,
Hafnium maintains a global count of pending notifications whose information
has been retrieved by this interface. The count is incremented and decremented
when handling FFA_NOTIFICATION_INFO_GET and FFA_NOTIFICATION_GET respectively.
It also tracks notifications whose information has been retrieved individually,
such that it avoids duplicating returned information for subsequent calls to
FFA_NOTIFICATION_INFO_GET. For each notification, this state information is
reset when receiver called FFA_NOTIFICATION_GET to retrieve them.
@ -920,18 +943,18 @@ reset when receiver called FFA_NOTIFICATION_GET to retrieve them.
FFA_SPM_ID_GET
~~~~~~~~~~~~~~
Returns the FF-A ID allocated to the SPM component (which includes SPMC + SPMD).
At initialization, the SPMC queries the SPMD for the SPM ID, using this
same interface, and saves it.
Returns the FF-A ID allocated to an SPM component which can be one of SPMD
or SPMC.
The call emitted at NS and secure physical FF-A instances returns the SPM ID
specified in the SPMC manifest.
At initialization, the SPMC queries the SPMD for the SPMC ID, using the
FFA_ID_GET interface, and records it. The SPMC can also query the SPMD ID using
the FFA_SPM_ID_GET interface at the secure physical FF-A instance.
Secure partitions call this interface at the virtual instance, to which the SPMC
shall return the priorly retrieved SPM ID.
Secure partitions call this interface at the virtual FF-A instance, to which
the SPMC returns the priorly retrieved SPMC ID.
The Hypervisor or OS kernel can issue an FFA_SPM_ID_GET call handled by the
SPMD, which returns the SPM ID.
The Hypervisor or OS kernel can issue the FFA_SPM_ID_GET call handled by the
SPMD, which returns the SPMC ID.
FFA_SECONDARY_EP_REGISTER
~~~~~~~~~~~~~~~~~~~~~~~~~
@ -939,7 +962,7 @@ FFA_SECONDARY_EP_REGISTER
When the SPMC boots, all secure partitions are initialized on their primary
Execution Context.
The interface FFA_SECONDARY_EP_REGISTER is to be used by a secure partitions
The FFA_SECONDARY_EP_REGISTER interface is to be used by a secure partition
from its first execution context, to provide the entry point address for
secondary execution contexts.
@ -956,26 +979,35 @@ permits SPMD to SPMC communication and either way.
- SPMC to SPMD direct request/response uses SMC conduit.
- SPMD to SPMC direct request/response uses ERET conduit.
This is used in particular to convey power management messages.
PE MMU configuration
--------------------
With secure virtualization enabled, two IPA spaces are output from the secure
EL1&0 Stage-1 translation (secure and non-secure). The EL1&0 Stage-2 translation
hardware is fed by:
With secure virtualization enabled (``HCR_EL2.VM = 1``) and for S-EL1
partitions, two IPA spaces (secure and non-secure) are output from the
secure EL1&0 Stage-1 translation.
The EL1&0 Stage-2 translation hardware is fed by:
- A single secure IPA space when the SP EL1&0 Stage-1 MMU is disabled.
- Two IPA spaces (secure and non-secure) when the SP EL1&0 Stage-1 MMU is
enabled.
- A secure IPA when the SP EL1&0 Stage-1 MMU is disabled.
- One of secure or non-secure IPA when the secure EL1&0 Stage-1 MMU is enabled.
``VTCR_EL2`` and ``VSTCR_EL2`` provide configuration bits for controlling the
NS/S IPA translations.
``VSTCR_EL2.SW`` = 0, ``VSTCR_EL2.SA`` = 0,``VTCR_EL2.NSW`` = 0, ``VTCR_EL2.NSA`` = 1:
NS/S IPA translations. The following controls are set up:
``VSTCR_EL2.SW = 0`` , ``VSTCR_EL2.SA = 0``, ``VTCR_EL2.NSW = 0``,
``VTCR_EL2.NSA = 1``:
- Stage-2 translations for the NS IPA space access the NS PA space.
- Stage-2 translation table walks for the NS IPA space are to the secure PA space.
Secure and non-secure IPA regions use the same set of Stage-2 page tables within
a SP.
Secure and non-secure IPA regions (rooted to by ``VTTBR_EL2`` and ``VSTTBR_EL2``)
use the same set of Stage-2 page tables within a SP.
The ``VTCR_EL2/VSTCR_EL2/VTTBR_EL2/VSTTBR_EL2`` virtual address space
configuration is made part of a vCPU context.
For S-EL0 partitions with VHE enabled, a single secure EL2&0 Stage-1 translation
regime is used for both Hafnium and the partition.
Interrupt management
--------------------
@ -1172,16 +1204,46 @@ When using the SPMD as a Secure Payload Dispatcher:
(svc_off) hooks are registered.
- The behavior for the cpu on event is described in `Secondary cores boot-up`_.
The SPMC is entered through its secondary physical core entry point.
- The cpu off event occurs when the NWd calls PSCI_CPU_OFF. The method by which
the PM event is conveyed to the SPMC is implementation-defined in context of
FF-A v1.0 (`SPMC-SPMD direct requests/responses`_). It consists in a SPMD-to-SPMC
direct request/response conveying the PM event details and SPMC response.
- The cpu off event occurs when the NWd calls PSCI_CPU_OFF. The PM event is
signaled to the SPMC through a power management framework message.
It consists in a SPMD-to-SPMC direct request/response (`SPMC-SPMD direct
requests/responses`_) conveying the event details and SPMC response.
The SPMD performs a synchronous entry into the SPMC. The SPMC is entered and
updates its internal state to reflect the physical core is being turned off.
In the current implementation no SP is resumed as a consequence. This behavior
ensures a minimal support for CPU hotplug e.g. when initiated by the NWd linux
userspace.
Arm architecture extensions for security hardening
==================================================
Hafnium supports the following architecture extensions for security hardening:
- Pointer authentication (FEAT_PAuth): the extension permits detection of forged
pointers used by ROP type of attacks through the signing of the pointer
value. Hafnium is built with the compiler branch protection option to permit
generation of a pointer authentication code for return addresses (pointer
authentication for instructions). The APIA key is used while Hafnium runs.
A random key is generated at boot time and restored upon entry into Hafnium
at run-time. APIA and other keys (APIB, APDA, APDB, APGA) are saved/restored
in vCPU contexts permitting to enable pointer authentication in VMs/SPs.
- Branch Target Identification (FEAT_BTI): the extension permits detection of
unexpected indirect branches used by JOP type of attacks. Hafnium is built
with the compiler branch protection option, inserting land pads at function
prologues that are reached by indirect branch instructions (BR/BLR).
Hafnium code pages are marked as guarded in the EL2 Stage-1 MMU descriptors
such that an indirect branch must always target a landpad. A fault is
triggered otherwise. VMs/SPs can (independently) mark their code pages as
guarded in the EL1&0 Stage-1 translation regime.
- Memory Tagging Extension (FEAT_MTE): the option permits detection of out of
bound memory array accesses or re-use of an already freed memory region.
Hafnium enables the compiler option permitting to leverage MTE stack tagging
applied to core stacks. Core stacks are marked as normal tagged memory in the
EL2 Stage-1 translation regime. A synchronous data abort is generated upon tag
check failure on load/stores. A random seed is generated at boot time and
restored upon entry into Hafnium. MTE system registers are saved/restored in
vCPU contexts permitting MTE usage from VMs/SPs.
SMMUv3 support in Hafnium
=========================
@ -1291,7 +1353,7 @@ streams.
- No support for independent peripheral devices.
S-EL0 Partition support
=========================
=======================
The SPMC (Hafnium) has limited capability to run S-EL0 FF-A partitions using
FEAT_VHE (mandatory with ARMv8.1 in non-secure state, and in secure world
with ARMv8.4 and FEAT_SEL2).