Merge changes from topic "sb/threat-model" into integration
* changes:
docs(threat-model): broaden the scope of threat #05
docs(threat-model): emphasize whether mitigations are implemented
diff --git a/Makefile b/Makefile
index 05d97b0..6e72f75 100644
--- a/Makefile
+++ b/Makefile
@@ -307,13 +307,8 @@
$(eval $(call add_define,DEBUG))
ifneq (${DEBUG}, 0)
BUILD_TYPE := debug
- TF_CFLAGS += -g
-
- ifneq ($(findstring clang,$(notdir $(CC))),)
- ASFLAGS += -g
- else
- ASFLAGS += -g -Wa,--gdwarf-2
- endif
+ TF_CFLAGS += -g -gdwarf-4
+ ASFLAGS += -g -Wa,-gdwarf-4
# Use LOG_LEVEL_INFO by default for debug builds
LOG_LEVEL := 40
diff --git a/docs/about/maintainers.rst b/docs/about/maintainers.rst
index 159a3db..871afe3 100644
--- a/docs/about/maintainers.rst
+++ b/docs/about/maintainers.rst
@@ -787,6 +787,8 @@
^^^^^^
:|M|: Manish Pandey <manish.pandey2@arm.com>
:|G|: `manish-pandey-arm`_
+:|M|: Joao Alves <Joao.Alves@arm.com>
+:|G|: `J-Alves`_
:|F|: tools/sptool/
Build system
diff --git a/docs/components/ffa-manifest-binding.rst b/docs/components/ffa-manifest-binding.rst
index 59996cc..6d2f905 100644
--- a/docs/components/ffa-manifest-binding.rst
+++ b/docs/components/ffa-manifest-binding.rst
@@ -4,11 +4,8 @@
This document defines the nodes and properties used to define a partition,
according to the FF-A specification.
-Version 1.0
------------
-
Partition Properties
-^^^^^^^^^^^^^^^^^^^^
+--------------------
- compatible [mandatory]
- value type: <string>
@@ -137,14 +134,14 @@
- gp-register-num
- value type: <u32>
- - Presence of this field indicates that the partition expects the
- ffa_init_info structure to be passed in via the specified general purpose
- register.
- The field specifies the general purpose register number but not its width.
+ - The field specifies the general purpose register number but not its width.
The width is derived from the partition's execution state, as specified in
the partition properties. For example, if the number value is 1 then the
general-purpose register used will be x1 in AArch64 state and w1 in AArch32
state.
+ Presence of this field indicates that the partition expects the address of
+ the FF-A boot information blob to be passed in the specified general purpose
+ register.
- stream-endpoint-ids
- value type: <prop-encoded-array>
@@ -184,13 +181,14 @@
- 0x1: Read
- 0x2: Write
- 0x4: Execute
+ - 0x8: Security state
- base-address
- value type: <u64>
- Base address of the region. The address must be aligned to the translation
granule size.
The address given may be a Physical Address (PA), Virtual Address (VA), or
- Intermediate Physical Address (IPA). Refer to the FFA specification for
+ Intermediate Physical Address (IPA). Refer to the FF-A specification for
more information on the restrictions around the address type.
If the base address is omitted then the partition manager must map a memory
region of the specified size into the partition's translation regime and
@@ -208,14 +206,10 @@
- value type: <string>
- Name of the device region e.g. for debugging purposes.
-- reg [mandatory]
- - value type: <prop-encoded-array>
- - A (address, num-pages) pair describing the device, where:
-
- - address: The physical base address <u64> value of the device MMIO
- region.
- - num-pages: The <u32> number of pages of the region. The total size of
- the region is this value multiplied by the translation granule size.
+- pages-count [mandatory]
+ - value type: <u32>
+ - Count of pages of memory region as a multiple of the translation granule
+ size
- attributes [mandatory]
- value type: <u32>
@@ -224,6 +218,15 @@
- 0x1: Read
- 0x2: Write
- 0x4: Execute
+ - 0x8: Security state
+
+- base-address [mandatory]
+ - value type: <u64>
+ - Base address of the region. The address must be aligned to the translation
+ granule size.
+ The address given may be a Physical Address (PA), Virtual Address (VA), or
+ Intermediate Physical Address (IPA). Refer to the FF-A specification for
+ more information on the restrictions around the address type.
- smmu-id
- value type: <u32>
@@ -243,14 +246,32 @@
- A list of (id, attributes) pair describing the device interrupts, where:
- id: The <u32> interrupt IDs.
- - attributes: A <u32> value,
- containing the attributes for each interrupt ID:
+ - attributes: A <u32> value, containing attributes for each interrupt ID:
+
+ +----------------------+----------+
+ |Field | Bit(s) |
+ +----------------------+----------+
+ | Priority | 7:0 |
+ +----------------------+----------+
+ | Security state | 8 |
+ +----------------------+----------+
+ | Config(Edge/Level) | 9 |
+ +----------------------+----------+
+ | Type(SPI/PPI/SGI) | 11:10 |
+ +----------------------+----------+
- - Interrupt type: SPI, PPI, SGI
- - Interrupt configuration: Edge triggered, Level triggered
- - Interrupt security state: Secure, Non-secure
- - Interrupt priority value
- - Target execution context/vCPU for each SPI
+ Security state:
+ - Secure: 1
+ - Non-secure: 0
+
+ Configuration:
+ - Edge triggered: 0
+ - Level triggered: 1
+
+ Type:
+ - SPI: 0b10
+ - PPI: 0b01
+ - SGI: 0b00
- exclusive-access
- value type: <empty>
@@ -259,4 +280,4 @@
--------------
-*Copyright (c) 2019-2021, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2019-2022, Arm Limited and Contributors. All rights reserved.*
diff --git a/docs/components/index.rst b/docs/components/index.rst
index 95fe42c..2f81f23 100644
--- a/docs/components/index.rst
+++ b/docs/components/index.rst
@@ -21,7 +21,6 @@
sdei
secure-partition-manager
secure-partition-manager-mm
- ffa-manifest-binding
xlat-tables-lib-v2-design
cot-binding
realm-management-extension
diff --git a/docs/components/secure-partition-manager.rst b/docs/components/secure-partition-manager.rst
index 2eaae75..18d870b 100644
--- a/docs/components/secure-partition-manager.rst
+++ b/docs/components/secure-partition-manager.rst
@@ -3,6 +3,9 @@
.. contents::
+.. toctree::
+ ffa-manifest-binding
+
Acronyms
========
@@ -23,6 +26,8 @@
+--------+--------------------------------------+
| IPA | Intermediate Physical Address |
+--------+--------------------------------------+
+| JOP | Jump-Oriented Programming |
++--------+--------------------------------------+
| NWd | Normal World |
+--------+--------------------------------------+
| ODM | Original Design Manufacturer |
@@ -37,6 +42,8 @@
+--------+--------------------------------------+
| PVM | Primary VM |
+--------+--------------------------------------+
+| ROP | Return-Oriented Programming |
++--------+--------------------------------------+
| SMMU | System Memory Management Unit |
+--------+--------------------------------------+
| SP | Secure Partition |
@@ -63,24 +70,25 @@
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 @@
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 @@
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 @@
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 @@
- 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 @@
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 @@
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 @@
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 @@
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 @@
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 @@
| - 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
============
@@ -358,6 +373,15 @@
A json-formatted description file is passed to the build flow specifying paths
to the SP binary image and associated DTS partition manifest file. The latter
is processed by the dtc compiler to generate a DTB fed into the SP package.
+Optionally, the partition's json description can contain offsets for both
+the image and partition manifest within the SP package. Both offsets need to be
+4KB aligned, because it is the translation granule supported by Hafnium SPMC.
+These fields can be leveraged to support SPs with S1 translation granules that
+differ from 4KB, and to configure the regions allocated within the SP package,
+as well as to comply with the requirements for the implementation of the boot
+information protocol (see `Passing boot data to the SP`_ for more details). In
+case the offsets are absent in their json node, they default to 0x1000 and
+0x4000 for the manifest offset and image offset respectively.
This file also specifies the SP owner (as an optional field) identifying the
signing domain in case of dual root CoT.
The SP owner can either be the silicon or the platform provider. The
@@ -381,7 +405,19 @@
"image": "tee2.bin",
"pm": "tee2.dts",
"owner": "Plat"
- }
+ },
+
+ "tee3" : {
+ "image": {
+ "file": "tee3.bin",
+ "offset":"0x2000"
+ },
+ "pm": {
+ "file": "tee3.dts",
+ "offset":"0x6000"
+ },
+ "owner": "Plat"
+ },
}
SPMC manifest
@@ -403,7 +439,7 @@
attribute {
spmc_id = <0x8000>;
maj_ver = <0x1>;
- min_ver = <0x0>;
+ min_ver = <0x1>;
exec_state = <0x0>;
load_address = <0x0 0x6000000>;
entrypoint = <0x0 0x6000000>;
@@ -422,13 +458,13 @@
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.
@@ -460,7 +496,7 @@
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
~~~~~~~~~~~
@@ -475,6 +511,8 @@
- 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.
@@ -491,20 +529,23 @@
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
@@ -544,13 +585,46 @@
Passing boot data to the SP
---------------------------
+In `[1]`_ , the section "Boot information protocol" defines a method for passing
+data to the SPs at boot time. It specifies the format for the boot information
+descriptor and boot information header structures, which describe the data to be
+exchanged between SPMC and SP.
+The specification also defines the types of data that can be passed.
+The aggregate of both the boot info structures and the data itself is designated
+the boot information blob, and is passed to a Partition as a contiguous memory
+region.
+
+Currently, the SPM implementation supports the FDT type which is used to pass the
+partition's DTB manifest.
+
-In `[1]`_ , the "Protocol for passing data" section defines a method for passing
-boot data to SPs (not currently implemented).
+The region for the boot information blob is allocated through the SP package.
-Provided that the whole secure partition package image (see
-`Secure Partition packages`_) is mapped to the SP secure EL1&0 Stage-2
-translation regime, an SP can access its own manifest DTB blob and extract its
-partition manifest properties.
+.. image:: ../resources/diagrams/partition-package.png
+
+To adjust the space allocated for the boot information blob, the json description
+of the SP (see section `Describing secure partitions`_) shall be updated to contain
+the manifest offset. If no offset is provided the manifest offset defaults to 0x1000,
+which is the page size in the Hafnium SPMC.
+
+The configuration of the boot protocol is done in the SPs manifest. As defined by
+the specification, the manifest field 'gp-register-num' configures the GP register
+which shall be used to pass the address to the partitions boot information blob when
+booting the partition.
+In addition, the Hafnium SPMC implementation requires the boot information arguments
+to be listed in a designated DT node:
+
+.. code:: shell
+
+ boot-info {
+ compatible = "arm,ffa-manifest-boot-info";
+ ffa_manifest;
+ };
+
+The whole secure partition package image (see `Secure Partition packages`_) is
+mapped to the SP secure EL1&0 Stage-2 translation regime. As such, the SP can
+retrieve the address for the boot information blob in the designated GP register,
+process the boot information header and descriptors, access its own manifest
+DTB blob and extract its partition manifest properties.
SP Boot order
-------------
@@ -657,28 +731,29 @@
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.
-The notifications receipt support is enabled in the partition FF-A manifest.
+- 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 subsequent section provides more details about the each one of the
-FF-A interfaces for notifications support.
+The notifications receipt support is enabled in the partition FF-A manifest.
Mandatory interfaces
--------------------
@@ -701,9 +776,12 @@
- ``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``
@@ -714,6 +792,8 @@
- ``FFA_NOTIFICATION_INFO_GET``
- ``FFA_SPM_ID_GET``
- ``FFA_SECONDARY_EP_REGISTER``
+ - ``FFA_MEM_PERM_GET``
+ - ``FFA_MEM_PERM_SET``
FFA_VERSION
~~~~~~~~~~~
@@ -841,24 +921,21 @@
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.
@@ -866,18 +943,18 @@
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
~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -885,7 +962,7 @@
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.
@@ -902,26 +979,35 @@
- 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 (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.
+
-Secure and non-secure IPA regions use the same set of Stage-2 page tables within
-a SP.
+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
--------------------
@@ -1118,16 +1204,46 @@
(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
=========================
@@ -1237,7 +1353,7 @@
- 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).
diff --git a/docs/getting_started/build-options.rst b/docs/getting_started/build-options.rst
index be50e5e..cfd7201 100644
--- a/docs/getting_started/build-options.rst
+++ b/docs/getting_started/build-options.rst
@@ -1051,11 +1051,11 @@
make PLAT=<platform> DEBUG=1 V=1 all
-AArch64 GCC uses DWARF version 4 debugging symbols by default. Some tools (for
-example DS-5) might not support this and may need an older version of DWARF
-symbols to be emitted by GCC. This can be achieved by using the
-``-gdwarf-<version>`` flag, with the version being set to 2 or 3. Setting the
-version to 2 is recommended for DS-5 versions older than 5.16.
+AArch64 GCC 11 uses DWARF version 5 debugging symbols by default. Some tools
+(for example Arm-DS) might not support this and may need an older version of
+DWARF symbols to be emitted by GCC. This can be achieved by using the
+``-gdwarf-<version>`` flag, with the version being set to 2, 3, 4 or 5. Setting
+the version to 4 is recommended for Arm-DS.
When debugging logic problems it might also be useful to disable all compiler
optimizations by using ``-O0``.
@@ -1080,7 +1080,7 @@
post-BL2 phase of TF-A. This can be done by rebuilding BL1 with the
``SPIN_ON_BL1_EXIT=1`` build flag. Refer to the :ref:`build_options_common`
section. In this case, the developer may take control of the target using a
-debugger when indicated by the console output. When using DS-5, the following
+debugger when indicated by the console output. When using Arm-DS, the following
commands can be used:
::
diff --git a/docs/getting_started/prerequisites.rst b/docs/getting_started/prerequisites.rst
index c625090..0b8a71c 100644
--- a/docs/getting_started/prerequisites.rst
+++ b/docs/getting_started/prerequisites.rst
@@ -7,7 +7,6 @@
It may possible to build |TF-A| with combinations of software packages that are
different from those listed below, however only the software described in this
document can be officially supported.
-
Build Host
----------
@@ -71,7 +70,7 @@
source files (``.dts`` files). DTC is available for Linux through the package
repositories of most distributions.
-- Arm `Development Studio 5 (DS-5)`_
+- Arm `Development Studio (Arm-DS)`_
The standard software package used for debugging software on Arm development
platforms and |FVP| models.
@@ -166,5 +165,5 @@
.. _Gerrit Code Review: https://www.gerritcodereview.com/
.. _Linaro Release Notes: https://community.arm.com/dev-platforms/w/docs/226/old-release-notes
.. _Linaro instructions: https://community.arm.com/dev-platforms/w/docs/304/arm-reference-platforms-deliverables
-.. _Development Studio 5 (DS-5): https://developer.arm.com/products/software-development-tools/ds-5-development-studio
+.. _Development Studio (Arm-DS): https://developer.arm.com/Tools%20and%20Software/Arm%20Development%20Studio
.. _Linaro Release 20.01: http://releases.linaro.org/members/arm/platforms/20.01
diff --git a/docs/resources/diagrams/partition-package.png b/docs/resources/diagrams/partition-package.png
new file mode 100644
index 0000000..3367422
--- /dev/null
+++ b/docs/resources/diagrams/partition-package.png
Binary files differ
diff --git a/include/arch/aarch64/arch.h b/include/arch/aarch64/arch.h
index dfb9fe4..e55d33f 100644
--- a/include/arch/aarch64/arch.h
+++ b/include/arch/aarch64/arch.h
@@ -1,6 +1,6 @@
/*
* Copyright (c) 2013-2022, Arm Limited and Contributors. All rights reserved.
- * Copyright (c) 2020, NVIDIA Corporation. All rights reserved.
+ * Copyright (c) 2020-2022, NVIDIA Corporation. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -108,14 +108,14 @@
#define HFGWTR_EL2 S3_4_C1_C1_5
#define ICH_HCR_EL2 S3_4_C12_C11_0
#define ICH_VMCR_EL2 S3_4_C12_C11_7
-#define MPAMVPM0_EL2 S3_4_C10_C5_0
-#define MPAMVPM1_EL2 S3_4_C10_C5_1
-#define MPAMVPM2_EL2 S3_4_C10_C5_2
-#define MPAMVPM3_EL2 S3_4_C10_C5_3
-#define MPAMVPM4_EL2 S3_4_C10_C5_4
-#define MPAMVPM5_EL2 S3_4_C10_C5_5
-#define MPAMVPM6_EL2 S3_4_C10_C5_6
-#define MPAMVPM7_EL2 S3_4_C10_C5_7
+#define MPAMVPM0_EL2 S3_4_C10_C6_0
+#define MPAMVPM1_EL2 S3_4_C10_C6_1
+#define MPAMVPM2_EL2 S3_4_C10_C6_2
+#define MPAMVPM3_EL2 S3_4_C10_C6_3
+#define MPAMVPM4_EL2 S3_4_C10_C6_4
+#define MPAMVPM5_EL2 S3_4_C10_C6_5
+#define MPAMVPM6_EL2 S3_4_C10_C6_6
+#define MPAMVPM7_EL2 S3_4_C10_C6_7
#define MPAMVPMV_EL2 S3_4_C10_C4_1
#define TRFCR_EL2 S3_4_C1_C2_1
#define PMSCR_EL2 S3_4_C9_C9_0
diff --git a/lib/cpus/aarch64/denver.S b/lib/cpus/aarch64/denver.S
index 224ee26..3c54a6f 100644
--- a/lib/cpus/aarch64/denver.S
+++ b/lib/cpus/aarch64/denver.S
@@ -1,6 +1,6 @@
/*
* Copyright (c) 2015-2018, ARM Limited and Contributors. All rights reserved.
- * Copyright (c) 2020, NVIDIA Corporation. All rights reserved.
+ * Copyright (c) 2020-2022, NVIDIA Corporation. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -369,6 +369,7 @@
denver_reset_func, \
check_errata_cve_2017_5715, \
CPU_NO_EXTRA2_FUNC, \
+ CPU_NO_EXTRA3_FUNC, \
denver_core_pwr_dwn, \
denver_cluster_pwr_dwn
.endm
diff --git a/services/std_svc/spm/el3_spmc/spmc_shared_mem.c b/services/std_svc/spm/el3_spmc/spmc_shared_mem.c
index 1602981..4a24108 100644
--- a/services/std_svc/spm/el3_spmc/spmc_shared_mem.c
+++ b/services/std_svc/spm/el3_spmc/spmc_shared_mem.c
@@ -304,7 +304,7 @@
if ((region1_start >= region2_start &&
region1_start < region2_end) ||
- (region1_end >= region2_start
+ (region1_end > region2_start
&& region1_end < region2_end)) {
WARN("Overlapping mem regions 0x%lx-0x%lx & 0x%lx-0x%lx\n",
region1_start, region1_end,
@@ -815,7 +815,7 @@
if ((obj->desc.handle != inflight_obj->desc.handle) &&
(obj->desc_size == obj->desc_filled)) {
other_mrd = spmc_shmem_obj_get_comp_mrd(inflight_obj,
- ffa_version);
+ FFA_VERSION_COMPILED);
if (other_mrd == NULL) {
return -EINVAL;
}
