Merge "docs(changelog): changelog for v2.7 release" into integration
diff --git a/Makefile b/Makefile
index 8d55ab9..3941f86 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/docs/threat_model/threat_model.rst b/docs/threat_model/threat_model.rst
index 2e11a94..38e5c87 100644
--- a/docs/threat_model/threat_model.rst
+++ b/docs/threat_model/threat_model.rst
@@ -254,6 +254,18 @@
The following threats were identified by applying STRIDE analysis on
each diagram element of the data flow diagram.
+For each threat, we strive to indicate whether the mitigations are currently
+implemented or not. However, the answer to this question is not always straight
+forward. Some mitigations are partially implemented in the generic code but also
+rely on the platform code to implement some bits of it. This threat model aims
+to be platform-independent and it is important to keep in mind that such threats
+only get mitigated if the platform code properly fulfills its responsibilities.
+
+Also, some mitigations require enabling specific features, which must be
+explicitly turned on via a build flag.
+
+These are highlighted in the ``Mitigations implemented?`` box.
+
+------------------------+----------------------------------------------------+
| ID | 01 |
+========================+====================================================+
@@ -286,13 +298,18 @@
+------------------------+------------------+-----------------+---------------+
| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) |
+------------------------+------------------+-----------------+---------------+
-| Mitigations | | TF-A implements the `Trusted Board Boot (TBB)`_ |
+| Mitigations | | 1) Implement the `Trusted Board Boot (TBB)`_ |
| | feature which prevents malicious firmware from |
| | running on the platform by authenticating all |
-| | firmware images. In addition to this, the TF-A |
-| | boot firmware performs extra checks on |
-| | unauthenticated data, such as FIP metadata, prior|
-| | to use. |
+| | firmware images. |
+| | |
+| | | 2) Perform extra checks on unauthenticated data, |
+| | such as FIP metadata, prior to use. |
++------------------------+----------------------------------------------------+
+| Mitigations | | 1) Yes, provided that the ``TRUSTED_BOARD_BOOT`` |
+| implemented? | build option is set to 1. |
+| | |
+| | | 2) Yes. |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
@@ -324,22 +341,27 @@
+------------------------+------------------+-----------------+---------------+
| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) |
+------------------------+------------------+-----------------+---------------+
-| Mitigations | | TF-A supports anti-rollback protection using |
-| | non-volatile counters (NV counters) as required |
-| | by `TBBR-Client specification`_. After a firmware|
-| | image is validated, the image revision number |
-| | taken from a certificate extension field is |
-| | compared with the corresponding NV counter stored|
-| | in hardware to make sure the new counter value is|
-| | larger or equal to the current counter value. |
-| | Platforms must implement this protection using |
-| | platform specific hardware NV counters. |
+| Mitigations | Implement anti-rollback protection using |
+| | non-volatile counters (NV counters) as required |
+| | by `TBBR-Client specification`_. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | After a firmware image is validated, the image |
+| | revision number taken from a certificate |
+| | extension field is compared with the |
+| | corresponding NV counter stored in hardware to |
+| | make sure the new counter value is larger than |
+| | the current counter value. |
+| | |
+| | | **Platforms must implement this protection using |
+| | platform specific hardware NV counters.** |
+------------------------+----------------------------------------------------+
+------------------------+-------------------------------------------------------+
| ID | 03 |
+========================+=======================================================+
-| Threat | | **An attacker can use Time-of-Check-Time-of-Use |
+| Threat | | **An attacker can use Time-of-Check-Time-of-Use |
| | (TOCTOU) attack to bypass image authentication |
| | during the boot process** |
| | |
@@ -370,8 +392,14 @@
+------------------------+---------------------+-----------------+---------------+
| Total Risk Rating | N/A | High (15) | High (15) |
+------------------------+---------------------+-----------------+---------------+
-| Mitigations | | TF-A boot firmware copies image to on-chip |
-| | memory before authenticating an image. |
+| Mitigations | Copy image to on-chip memory before authenticating |
+| | it. |
++------------------------+-------------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | The list of images to load and their location is |
+| | platform specific. Platforms are responsible for |
+| | arranging images to be loaded in on-chip memory. |
+------------------------+-------------------------------------------------------+
+------------------------+-------------------------------------------------------+
@@ -415,12 +443,19 @@
+------------------------+---------------------+-----------------+---------------+
| Total Risk Rating | N/A | High (15) | High (15) |
+------------------------+---------------------+-----------------+---------------+
-| Mitigations | | The most effective mitigation is adding glitching |
+| Mitigations | Mechanisms to detect clock glitch and power |
+| | variations. |
++------------------------+-------------------------------------------------------+
+| Mitigations | | No. |
+| implemented? | |
+| | | The most effective mitigation is adding glitching |
| | detection and mitigation circuit at the hardware |
-| | level. However, software techniques, |
-| | such as adding redundant checks when performing |
-| | conditional branches that are security sensitive, |
-| | can be used to harden TF-A against such attacks. |
+| | level. |
+| | |
+| | | However, software techniques, such as adding |
+| | redundant checks when performing conditional |
+| | branches that are security sensitive, can be used |
+| | to harden TF-A against such attacks. |
| | **At the moment TF-A doesn't implement such |
| | mitigations.** |
+------------------------+-------------------------------------------------------+
@@ -428,18 +463,25 @@
+------------------------+---------------------------------------------------+
| ID | 05 |
+========================+===================================================+
-| Threat | | **Information leak via UART logs such as |
-| | crashes** |
+| Threat | | **Information leak via UART logs** |
| | |
| | | During the development stages of software it is |
-| | common to include crash reports with detailed |
-| | information of the CPU state including current |
-| | values of the registers, privilege level and |
-| | stack dumps. This information is useful when |
-| | debugging problems before releasing the |
-| | production version, but it could be used by an |
-| | attacker to develop a working exploit if left |
-| | in the production version. |
+| | common to print all sorts of information on the |
+| | console, including sensitive or confidential |
+| | information such as crash reports with detailed |
+| | information of the CPU state, current registers |
+| | values, privilege level or stack dumps. |
+| | |
+| | | This information is useful when debugging |
+| | problems before releasing the production |
+| | version but it could be used by an attacker |
+| | to develop a working exploit if left enabled in |
+| | the production version. |
+| | |
+| | | This happens when directly logging sensitive |
+| | information and more subtly when logging |
+| | side-channel information that can be used by an |
+| | attacker to learn about sensitive information. |
+------------------------+---------------------------------------------------+
| Diagram Elements | DF2 |
+------------------------+---------------------------------------------------+
@@ -460,11 +502,31 @@
+------------------------+------------------+----------------+---------------+
| Total Risk Rating | N/A | Medium (8) | Medium (8) |
+------------------------+------------------+----------------+---------------+
-| Mitigations | | In TF-A, crash reporting is only enabled for |
-| | debug builds by default. Alternatively, the log |
-| | level can be tuned at build time (from verbose |
-| | to no output at all), independently of the |
-| | build type. |
+| Mitigations | | Remove sensitive information logging in |
+| | production releases. |
+| | |
+| | | Do not conditionally log information depending |
+| | on potentially sensitive data. |
+| | |
+| | | Do not log high precision timing information. |
++------------------------+---------------------------------------------------+
+| Mitigations | | Yes / Platform Specific. |
+| implemented? | Requires the right build options to be used. |
+| | |
+| | | Crash reporting is only enabled for debug |
+| | builds by default, see ``CRASH_REPORTING`` |
+| | build option. |
+| | |
+| | | The log level can be tuned at build time, from |
+| | very verbose to no output at all. See |
+| | ``LOG_LEVEL`` build option. By default, release |
+| | builds are a lot less verbose than debug ones |
+| | but still produce some output. |
+| | |
+| | | Messages produced by the platform code should |
+| | use the appropriate level of verbosity so as |
+| | not to leak sensitive information in production |
+| | builds. |
+------------------------+---------------------------------------------------+
+------------------------+----------------------------------------------------+
@@ -503,11 +565,14 @@
+------------------------+------------------+---------------+-----------------+
| Total Risk Rating | N/A | Critical (20) | Critical (20) |
+------------------------+------------------+---------------+-----------------+
-| Mitigations | | Configuration of debug and trace capabilities is |
-| | platform specific. Therefore, platforms must |
-| | disable the debug and trace capability for |
-| | production releases or enable proper debug |
-| | authentication as recommended by [`DEN0034`_]. |
+| Mitigations | Disable the debug and trace capability for |
+| | production releases or enable proper debug |
+| | authentication as recommended by [`DEN0034`_]. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | Configuration of debug and trace capabilities is |
+| | entirely platform specific. |
+------------------------+----------------------------------------------------+
+------------------------+------------------------------------------------------+
@@ -542,9 +607,14 @@
+------------------------+-------------------+----------------+-----------------+
| Total Risk Rating | High (12) | High (12) | High (12) |
+------------------------+-------------------+----------------+-----------------+
-| Mitigations | | The generic TF-A code validates SMC function ids |
-| | and arguments before using them. |
-| | Platforms that implement SiP services must also |
+| Mitigations | Validate SMC function ids and arguments before using |
+| | them. |
++------------------------+------------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | For standard services, all input is validated. |
+| | |
+| | | Platforms that implement SiP services must also |
| | validate SMC call arguments. |
+------------------------+------------------------------------------------------+
@@ -588,17 +658,12 @@
+------------------------+-------------------+-----------------+----------------+
| Total Risk Rating | High (15) | High (15) | High (15) |
+------------------------+-------------------+-----------------+----------------+
-| Mitigations | | TF-A uses a combination of manual code reviews and |
-| | automated program analysis and testing to detect |
-| | and fix memory corruption bugs. All TF-A code |
-| | including platform code go through manual code |
-| | reviews. Additionally, static code analysis is |
-| | performed using Coverity Scan on all TF-A code. |
-| | The code is also tested with |
-| | `Trusted Firmware-A Tests`_ on Juno and FVP |
-| | platforms. |
+| Mitigations | | 1) Use proper input validation. |
| | |
-| | | Data received from normal world, such as addresses |
+| | | 2) Code reviews, testing. |
++------------------------+------------------------------------------------------+
+| Mitigations | | 1) Yes. |
+| implemented? | Data received from normal world, such as addresses |
| | and sizes identifying memory regions, are |
| | sanitized before being used. These security checks |
| | make sure that the normal world software does not |
@@ -612,6 +677,17 @@
| | option to use *asserts* in release builds, however |
| | we recommend using proper runtime checks instead |
| | of relying on asserts in release builds. |
+| | |
+| | | 2) Yes. |
+| | TF-A uses a combination of manual code reviews |
+| | and automated program analysis and testing to |
+| | detect and fix memory corruption bugs. All TF-A |
+| | code including platform code go through manual |
+| | code reviews. Additionally, static code analysis |
+| | is performed using Coverity Scan on all TF-A code. |
+| | The code is also tested with |
+| | `Trusted Firmware-A Tests`_ on Juno and FVP |
+| | platforms. |
+------------------------+------------------------------------------------------+
+------------------------+------------------------------------------------------+
@@ -643,10 +719,14 @@
+------------------------+-------------------+----------------+-----------------+
| Total Risk Rating | High (12) | High (12) | High (12) |
+------------------------+-------------------+----------------+-----------------+
-| Mitigations | | TF-A saves and restores registers |
-| | by default when switching contexts. Build options |
-| | are also provided to save/restore additional |
-| | registers such as floating-point registers. |
+| Mitigations | Save and restore registers when switching contexts. |
++------------------------+------------------------------------------------------+
+| Mitigations | | Yes. |
+| implemented? | |
+| | | This is the default behaviour in TF-A. |
+| | Build options are also provided to save/restore |
+| | additional registers such as floating-point |
+| | registers. These should be enabled if required. |
+------------------------+------------------------------------------------------+
+------------------------+-----------------------------------------------------+
@@ -680,11 +760,17 @@
+------------------------+-------------------+----------------+----------------+
| Total Risk Rating | Medium (9) | Medium (9) | Medium (9) |
+------------------------+-------------------+----------------+----------------+
-| Mitigations | | TF-A implements software mitigations for Spectre |
+| Mitigations | Enable appropriate side-channel protections. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | TF-A implements software mitigations for Spectre |
| | type attacks as recommended by `Cache Speculation |
-| | Side-channels`_ for the generic code. SiPs should |
-| | implement similar mitigations for code that is |
-| | deemed to be vulnerable to such attacks. |
+| | Side-channels`_ for the generic code. |
+| | |
+| | | SiPs should implement similar mitigations for |
+| | code that is deemed to be vulnerable to such |
+| | attacks. |
+------------------------+-----------------------------------------------------+
+------------------------+----------------------------------------------------+
@@ -720,19 +806,25 @@
+------------------------+-----------------+-----------------+----------------+
| Total Risk Rating | Critical (20) | Critical (20) | Critical (20) |
+------------------------+-----------------+-----------------+----------------+
-| Mitigations | | In TF-A, configuration of the MMU is done |
-| | through a translation tables library. The |
-| | library provides APIs to define memory regions |
-| | and assign attributes including memory types and |
-| | access permissions. Memory configurations are |
-| | platform specific, therefore platforms need make |
-| | sure the correct attributes are assigned to |
-| | memory regions. When assigning access |
-| | permissions, principle of least privilege ought |
-| | to be enforced, i.e. we should not grant more |
-| | privileges than strictly needed, e.g. code |
-| | should be read-only executable, RO data should |
-| | be read-only XN, and so on. |
+| Mitigations | When configuring access permissions, the |
+| | principle of least privilege ought to be |
+| | enforced. This means we should not grant more |
+| | privileges than strictly needed, e.g. code |
+| | should be read-only executable, read-only data |
+| | should be read-only execute-never, and so on. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | MMU configuration is platform specific, |
+| | therefore platforms need to make sure that the |
+| | correct attributes are assigned to memory |
+| | regions. |
+| | |
+| | | TF-A provides a library which abstracts the |
+| | low-level details of MMU configuration. It |
+| | provides well-defined and tested APIs. |
+| | Platforms are encouraged to use it to limit the |
+| | risk of misconfiguration. |
+------------------------+----------------------------------------------------+
+------------------------+-----------------------------------------------------+
@@ -747,7 +839,7 @@
| | to count events at any exception level and in |
| | both Secure and Non-secure states. This allows |
| | a Non-secure software (or a lower-level Secure |
-| | software) to potentially carry out |
+| | software) to potentially carry out |
| | side-channel timing attacks against TF-A. |
+------------------------+-----------------------------------------------------+
| Diagram Elements | DF5, DF6 |
@@ -767,18 +859,25 @@
+------------------------+-------------------+----------------+----------------+
| Total Risk Rating | Medium (6) | Medium (6) | Medium (6) |
+------------------------+-------------------+----------------+----------------+
-| Mitigations | | TF-A follows mitigation strategies as described |
-| | in `Secure Development Guidelines`_. General |
-| | events and cycle counting in the Secure world is |
-| | prohibited by default when applicable. However, |
-| | on some implementations (e.g. PMUv3) Secure world |
-| | event counting depends on external debug interface|
-| | signals, i.e. Secure world event counting is |
-| | enabled if external debug is enabled. |
-| | Configuration of debug signals is platform |
+| Mitigations | Follow mitigation strategies as described in |
+| | `Secure Development Guidelines`_. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | Yes / platform specific. |
+| implemented? | |
+| | | General events and cycle counting in the Secure |
+| | world is prohibited by default when applicable. |
+| | |
+| | | However, on some implementations (e.g. PMUv3) |
+| | Secure world event counting depends on external |
+| | debug interface signals, i.e. Secure world event |
+| | counting is enabled if external debug is enabled. |
+| | |
+| | | Configuration of debug signals is platform |
| | specific, therefore platforms need to make sure |
| | that external debug is disabled in production or |
-| | proper debug authentication is in place. |
+| | proper debug authentication is in place. This |
+| | should be the case if threat #06 is properly |
+| | mitigated. |
+------------------------+-----------------------------------------------------+
--------------
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;
}
