Merge changes from topic "hm/rt-instr" into integration
* changes:
docs(juno): update PSCI instrumentation data
docs(n1sdp): update N1SDP PSCI instrumentation data
diff --git a/docs/about/features.rst b/docs/about/features.rst
index 4a2c77e..c12509d 100644
--- a/docs/about/features.rst
+++ b/docs/about/features.rst
@@ -108,6 +108,28 @@
- Position-Independent Executable (PIE) support.
+Experimental features
+---------------------
+
+A feature is considered experimental when still in development or isn't known
+to the TF-A team as widely deployed or proven on end products. It is generally
+advised such options aren't pulled into real deployments, or done with the
+appropriate level of supplementary integration testing.
+
+A feature is no longer considered experimental when it is generally agreed
+the said feature has reached a level of maturity and quality comparable to
+other features that have been integrated into products.
+
+Experimental build options are found in following section
+:ref:`build_options_experimental`. Their use through the build emits a warning
+message.
+
+Additionally the following libraries are marked experimental when included
+in a platform:
+
+- MPU translation library ``lib/xlat_mpu``
+- RSS comms driver ``drivers/arm/rss``
+
Still to come
-------------
diff --git a/docs/about/maintainers.rst b/docs/about/maintainers.rst
index aca5ec0..4531a03 100644
--- a/docs/about/maintainers.rst
+++ b/docs/about/maintainers.rst
@@ -67,6 +67,8 @@
:|G|: `bytefire`_
:|M|: Varun Wadekar <vwadekar@nvidia.com>
:|G|: `vwadekar`_
+:|M|: Yann Gautier <yann.gautier@st.com>
+:|G|: `Yann-lms`_
.. _code owners:
diff --git a/docs/about/release-information.rst b/docs/about/release-information.rst
index d6e2ee9..654d65f 100644
--- a/docs/about/release-information.rst
+++ b/docs/about/release-information.rst
@@ -81,6 +81,8 @@
| | Date | after | |
| | | Release | |
+================================+=============+=========+=========================================================+
+| Mbedtls-2.x | 2.10 | 2.10 | Support for TF-A builds with Mbedtls-2.x will be removed|
++--------------------------------+-------------+---------+---------------------------------------------------------+
| STM32MP15_OPTEE_RSV_SHM | 2.10 | 3.0 | OP-TEE manages its own memory on STM32MP15 |
+--------------------------------+-------------+---------+---------------------------------------------------------+
diff --git a/docs/components/secure-partition-manager-mm.rst b/docs/components/secure-partition-manager-mm.rst
index 4cdb96c..d9b2b1b 100644
--- a/docs/components/secure-partition-manager-mm.rst
+++ b/docs/components/secure-partition-manager-mm.rst
@@ -4,17 +4,10 @@
Foreword
========
-Two implementations of a Secure Partition Manager co-exist in the TF-A codebase:
-
-- SPM based on the FF-A specification (:ref:`Secure Partition Manager`).
-- SPM based on the MM interface.
-
-Both implementations differ in their architectures and only one can be selected
-at build time.
-
-This document describes the latter implementation where the Secure Partition Manager
-resides at EL3 and management services run from isolated Secure Partitions at S-EL0.
-The communication protocol is established through the Management Mode (MM) interface.
+This document describes the implementation where the Secure Partition Manager
+resides at EL3 and management services run from isolated Secure Partitions at
+S-EL0. The communication protocol is established through the Management Mode
+(MM) interface.
Background
==========
diff --git a/docs/getting_started/build-options.rst b/docs/getting_started/build-options.rst
index 79a3b1d..80baf9c 100644
--- a/docs/getting_started/build-options.rst
+++ b/docs/getting_started/build-options.rst
@@ -436,40 +436,12 @@
be enabled. If ``ENABLE_PMF`` is set, the residency statistics are tracked in
software.
-- ``ENABLE_RME``: Numeric value to enable support for the ARMv9 Realm
- Management Extension. This flag can take the values 0 to 2, to align with
- the ``FEATURE_DETECTION`` mechanism. Default value is 0. This is currently
- an experimental feature.
-
- ``ENABLE_RUNTIME_INSTRUMENTATION``: Boolean option to enable runtime
instrumentation which injects timestamp collection points into TF-A to
allow runtime performance to be measured. Currently, only PSCI is
instrumented. Enabling this option enables the ``ENABLE_PMF`` build option
as well. Default is 0.
-- ``ENABLE_SME_FOR_NS``: Numeric value to enable Scalable Matrix Extension
- (SME), SVE, and FPU/SIMD for the non-secure world only. These features share
- registers so are enabled together. Using this option without
- ENABLE_SME_FOR_SWD=1 will cause SME, SVE, and FPU/SIMD instructions in secure
- world to trap to EL3. Requires ``ENABLE_SVE_FOR_NS`` to be set as SME is a
- superset of SVE. SME is an optional architectural feature for AArch64
- and TF-A support is experimental. At this time, this build option cannot be
- used on systems that have SPD=spmd/SPM_MM and atempting to build with this
- option will fail. This flag can take the values 0 to 2, to align with the
- ``FEATURE_DETECTION`` mechanism. Default is 0.
-
-- ``ENABLE_SME2_FOR_NS``: Numeric value to enable Scalable Matrix Extension
- version 2 (SME2) for the non-secure world only. SME2 is an optional
- architectural feature for AArch64 and TF-A support is experimental.
- This should be set along with ENABLE_SME_FOR_NS=1, if not, the default SME
- accesses will still be trapped. This flag can take the values 0 to 2, to
- align with the ``FEATURE_DETECTION`` mechanism. Default is 0.
-
-- ``ENABLE_SME_FOR_SWD``: Boolean option to enable the Scalable Matrix
- Extension for secure world. Used along with SVE and FPU/SIMD.
- ENABLE_SME_FOR_NS and ENABLE_SVE_FOR_SWD must also be set to use this.
- This is experimental. Default is 0.
-
- ``ENABLE_SPE_FOR_NS`` : Numeric value to enable Statistical Profiling
extensions. This is an optional architectural feature for AArch64.
This flag can take the values 0 to 2, to align with the ``FEATURE_DETECTION``
@@ -555,44 +527,6 @@
This feature is intended for testing purposes only, and is advisable to keep
disabled for production images.
-- ``FEATURE_DETECTION``: Boolean option to enable the architectural features
- detection mechanism. It detects whether the Architectural features enabled
- through feature specific build flags are supported by the PE or not by
- validating them either at boot phase or at runtime based on the value
- possessed by the feature flag (0 to 2) and report error messages at an early
- stage. This flag will also enable errata ordering checking for ``DEBUG``
- builds.
-
- This prevents and benefits us from EL3 runtime exceptions during context save
- and restore routines guarded by these build flags. Henceforth validating them
- before their usage provides more control on the actions taken under them.
-
- The mechanism permits the build flags to take values 0, 1 or 2 and
- evaluates them accordingly.
-
- Lets consider ``ENABLE_FEAT_HCX``, build flag for ``FEAT_HCX`` as an example:
-
- ::
-
- ENABLE_FEAT_HCX = 0: Feature disabled statically at compile time.
- ENABLE_FEAT_HCX = 1: Feature Enabled and the flag is validated at boottime.
- ENABLE_FEAT_HCX = 2: Feature Enabled and the flag is validated at runtime.
-
- In the above example, if the feature build flag, ``ENABLE_FEAT_HCX`` set to
- 0, feature is disabled statically during compilation. If it is defined as 1,
- feature is validated, wherein FEAT_HCX is detected at boot time. In case not
- implemented by the PE, a hard panic is generated. Finally, if the flag is set
- to 2, feature is validated at runtime.
-
- Note that the entire implementation is divided into two phases, wherein as
- as part of phase-1 we are supporting the values 0,1. Value 2 is currently not
- supported and is planned to be handled explicilty in phase-2 implementation.
-
- FEATURE_DETECTION macro is disabled by default, and is currently an
- experimental procedure. Platforms can explicitly make use of this by
- mechanism, by enabling it to validate whether they have set their build flags
- properly at an early phase.
-
- ``FIP_NAME``: This is an optional build option which specifies the FIP
filename for the ``fip`` target. Default is ``fip.bin``.
@@ -730,15 +664,6 @@
This option defaults to 0.
-- ``DRTM_SUPPORT``: Boolean flag to enable support for Dynamic Root of Trust
- for Measurement (DRTM). This feature has trust dependency on BL31 for taking
- the measurements and recording them as per `PSA DRTM specification`_. For
- platforms which use BL2 to load/authenticate BL31 ``TRUSTED_BOARD_BOOT`` can
- be used and for the platforms which use ``RESET_TO_BL31`` platform owners
- should have mechanism to authenticate BL31. This is an experimental feature.
-
- This option defaults to 0.
-
- ``MARCH_DIRECTIVE``: used to pass a -march option from the platform build
options to the compiler. An example usage:
@@ -894,7 +819,7 @@
Dispatcher option (``SPD=spmd``). When enabled (1) it indicates the SPMC
component runs at the EL3 exception level. The default value is ``0`` (
disabled). This configuration supports pre-Armv8.4 platforms (aka not
- implementing the ``FEAT_SEL2`` extension). This is an experimental feature.
+ implementing the ``FEAT_SEL2`` extension).
- ``SPMC_AT_EL3_SEL0_SP`` : Boolean option to enable SEL0 SP load support when
``SPMC_AT_EL3`` is enabled. The default value if ``0`` (disabled). This
@@ -914,12 +839,6 @@
support pre-Armv8.4 platforms (aka not implementing the ``FEAT_SEL2``
extension).
-- ``ENABLE_SPMD_LP`` : This boolean option is used jointly with the SPM
- Dispatcher option (``SPD=spmd``). When enabled (1) it indicates support
- for logical partitions in EL3, managed by the SPMD as defined in the FF-A
- 1.2 specification. This flag is disabled by default. This flag must not be
- used if ``SPMC_AT_EL3`` is enabled. This is an experimental feature.
-
- ``SPM_MM`` : Boolean option to enable the Management Mode (MM)-based Secure
Partition Manager (SPM) implementation. The default value is ``0``
(disabled). This option cannot be enabled (``1``) when SPM Dispatcher is
@@ -945,11 +864,6 @@
hardware will limit the effective VL to the maximum physically supported
VL.
-- ``TRANSFER_LIST``: Setting this to ``1`` enables support for Firmware
- Handoff using Transfer List defined in `Firmware Handoff specification`_.
- This defaults to ``0``. Please note that this is an experimental feature
- based on Firmware Handoff specification v0.9.
-
- ``TRNG_SUPPORT``: Setting this to ``1`` enables support for True
Random Number Generator Interface to BL31 image. This defaults to ``0``.
@@ -1008,10 +922,6 @@
(Coherent memory region is included) or 0 (Coherent memory region is
excluded). Default is 1.
-- ``USE_DEBUGFS``: When set to 1 this option activates an EXPERIMENTAL feature
- exposing a virtual filesystem interface through BL31 as a SiP SMC function.
- Default is 0.
-
- ``ARM_IO_IN_DTB``: This flag determines whether to use IO based on the
firmware configuration framework. This will move the io_policies into a
configuration device tree, instead of static structure in the code base.
@@ -1185,13 +1095,6 @@
errata mitigation for platforms with a non-arm interconnect using the errata
ABI. By default its disabled (``0``).
-- ``PSA_CRYPTO``: Boolean option for enabling MbedTLS PSA crypto APIs support.
- The platform will use PSA compliant Crypto APIs during authentication and
- image measurement process by enabling this option. It uses APIs defined as
- per the `PSA Crypto API specification`_. This feature is only supported if
- using MbedTLS 3.x version. By default it is disabled (``0``), and this is an
- experimental feature.
-
- ``ENABLE_CONSOLE_GETC``: Boolean option to enable `getc()` feature in console
driver(s). By default it is disabled (``0``) because it constitutes an attack
vector into TF-A by potentially allowing an attacker to inject arbitrary data.
@@ -1288,8 +1191,118 @@
# Resume execution
continue
+.. _build_options_experimental:
+
+Experimental build options
+---------------------------
+
+Common build options
+~~~~~~~~~~~~~~~~~~~~
+
+- ``DRTM_SUPPORT``: Boolean flag to enable support for Dynamic Root of Trust
+ for Measurement (DRTM). This feature has trust dependency on BL31 for taking
+ the measurements and recording them as per `PSA DRTM specification`_. For
+ platforms which use BL2 to load/authenticate BL31 ``TRUSTED_BOARD_BOOT`` can
+ be used and for the platforms which use ``RESET_TO_BL31`` platform owners
+ should have mechanism to authenticate BL31. This option defaults to 0.
+
+- ``ENABLE_RME``: Numeric value to enable support for the ARMv9 Realm
+ Management Extension. This flag can take the values 0 to 2, to align with
+ the ``FEATURE_DETECTION`` mechanism. Default value is 0.
+
+- ``ENABLE_SME_FOR_NS``: Numeric value to enable Scalable Matrix Extension
+ (SME), SVE, and FPU/SIMD for the non-secure world only. These features share
+ registers so are enabled together. Using this option without
+ ENABLE_SME_FOR_SWD=1 will cause SME, SVE, and FPU/SIMD instructions in secure
+ world to trap to EL3. Requires ``ENABLE_SVE_FOR_NS`` to be set as SME is a
+ superset of SVE. SME is an optional architectural feature for AArch64.
+ At this time, this build option cannot be used on systems that have
+ SPD=spmd/SPM_MM and atempting to build with this option will fail.
+ This flag can take the values 0 to 2, to align with the ``FEATURE_DETECTION``
+ mechanism. Default is 0.
+
+- ``ENABLE_SME2_FOR_NS``: Numeric value to enable Scalable Matrix Extension
+ version 2 (SME2) for the non-secure world only. SME2 is an optional
+ architectural feature for AArch64.
+ This should be set along with ENABLE_SME_FOR_NS=1, if not, the default SME
+ accesses will still be trapped. This flag can take the values 0 to 2, to
+ align with the ``FEATURE_DETECTION`` mechanism. Default is 0.
+
+- ``ENABLE_SME_FOR_SWD``: Boolean option to enable the Scalable Matrix
+ Extension for secure world. Used along with SVE and FPU/SIMD.
+ ENABLE_SME_FOR_NS and ENABLE_SVE_FOR_SWD must also be set to use this.
+ Default is 0.
+
+- ``ENABLE_SPMD_LP`` : This boolean option is used jointly with the SPM
+ Dispatcher option (``SPD=spmd``). When enabled (1) it indicates support
+ for logical partitions in EL3, managed by the SPMD as defined in the
+ FF-A v1.2 specification. This flag is disabled by default. This flag
+ must not be used if ``SPMC_AT_EL3`` is enabled.
+
+- ``FEATURE_DETECTION``: Boolean option to enable the architectural features
+ detection mechanism. It detects whether the Architectural features enabled
+ through feature specific build flags are supported by the PE or not by
+ validating them either at boot phase or at runtime based on the value
+ possessed by the feature flag (0 to 2) and report error messages at an early
+ stage. This flag will also enable errata ordering checking for ``DEBUG``
+ builds.
+
+ This prevents and benefits us from EL3 runtime exceptions during context save
+ and restore routines guarded by these build flags. Henceforth validating them
+ before their usage provides more control on the actions taken under them.
+
+ The mechanism permits the build flags to take values 0, 1 or 2 and
+ evaluates them accordingly.
+
+ Lets consider ``ENABLE_FEAT_HCX``, build flag for ``FEAT_HCX`` as an example:
+
+ ::
+
+ ENABLE_FEAT_HCX = 0: Feature disabled statically at compile time.
+ ENABLE_FEAT_HCX = 1: Feature Enabled and the flag is validated at boottime.
+ ENABLE_FEAT_HCX = 2: Feature Enabled and the flag is validated at runtime.
+
+ In the above example, if the feature build flag, ``ENABLE_FEAT_HCX`` set to
+ 0, feature is disabled statically during compilation. If it is defined as 1,
+ feature is validated, wherein FEAT_HCX is detected at boot time. In case not
+ implemented by the PE, a hard panic is generated. Finally, if the flag is set
+ to 2, feature is validated at runtime.
+
+ Note that the entire implementation is divided into two phases, wherein as
+ as part of phase-1 we are supporting the values 0,1. Value 2 is currently not
+ supported and is planned to be handled explicilty in phase-2 implementation.
+
+ ``FEATURE_DETECTION`` macro is disabled by default. Platforms can explicitly
+ make use of this by mechanism, by enabling it to validate whether they have
+ set their build flags properly at an early phase.
+
+- ``PSA_CRYPTO``: Boolean option for enabling MbedTLS PSA crypto APIs support.
+ The platform will use PSA compliant Crypto APIs during authentication and
+ image measurement process by enabling this option. It uses APIs defined as
+ per the `PSA Crypto API specification`_. This feature is only supported if
+ using MbedTLS 3.x version. It is disabled (``0``) by default.
+
+- ``TRANSFER_LIST``: Setting this to ``1`` enables support for Firmware
+ Handoff using Transfer List defined in `Firmware Handoff specification`_.
+ This defaults to ``0``. Current implementation follows the Firmware Handoff
+ specification v0.9.
+
+- ``USE_DEBUGFS``: When set to 1 this option exposes a virtual filesystem
+ interface through BL31 as a SiP SMC function.
+ Default is disabled (0).
+
Firmware update options
------------------------
+~~~~~~~~~~~~~~~~~~~~~~~
+
+- ``PSA_FWU_SUPPORT``: Enable the firmware update mechanism as per the
+ `PSA FW update specification`_. The default value is 0.
+ PSA firmware update implementation has few limitations, such as:
+
+ - BL2 is not part of the protocol-updatable images. If BL2 needs to
+ be updated, then it should be done through another platform-defined
+ mechanism.
+
+ - It assumes the platform's hardware supports CRC32 instructions.
- ``NR_OF_FW_BANKS``: Define the number of firmware banks. This flag is used
in defining the firmware update metadata structure. This flag is by default
@@ -1301,14 +1314,6 @@
This flag is used in defining the firmware update metadata structure. This
flag is by default set to '1'.
-- ``PSA_FWU_SUPPORT``: Enable the firmware update mechanism as per the
- `PSA FW update specification`_. The default value is 0, and this is an
- experimental feature.
- PSA firmware update implementation has some limitations, such as BL2 is
- not part of the protocol-updatable images, if BL2 needs to be updated, then
- it should be done through another platform-defined mechanism, and it assumes
- that the platform's hardware supports CRC32 instructions.
-
--------------
*Copyright (c) 2019-2023, Arm Limited. All rights reserved.*
diff --git a/docs/plat/arm/fvp/index.rst b/docs/plat/arm/fvp/index.rst
index fcfa04a..700020f 100644
--- a/docs/plat/arm/fvp/index.rst
+++ b/docs/plat/arm/fvp/index.rst
@@ -12,7 +12,7 @@
(64-bit host machine only).
.. note::
- The FVP models used are Version 11.19 Build 14, unless otherwise stated.
+ The FVP models used are Version 11.22 Build 14, unless otherwise stated.
- ``Foundation_Platform``
- ``FVP_Base_AEMv8A-AEMv8A-AEMv8A-AEMv8A-CCN502`` (Version 11.17/21)
@@ -41,18 +41,18 @@
- ``FVP_Base_Cortex-A76AE``
- ``FVP_Base_Cortex-A77``
- ``FVP_Base_Cortex-A78``
+- ``FVP_Base_Cortex-A78AE``
- ``FVP_Base_Cortex-A78C``
- ``FVP_Base_Cortex-X2x4`` (Version 11.17/21)
- ``FVP_Base_Neoverse-E1``
- ``FVP_Base_Neoverse-N1``
-- ``FVP_Base_Neoverse-N2x4`` (Version 11.16/16)
- ``FVP_Base_Neoverse-V1``
- ``FVP_Base_RevC-2xAEMvA``
-- ``FVP_Morello`` (Version 0.11/33)
-- ``FVP_RD_E1_edge`` (Version 11.17/29)
-- ``FVP_RD_V1`` (Version 11.17/29)
-- ``FVP_TC1`` (Version 11.17/33)
-- ``FVP_TC2`` (Version 11.18/28)
+- ``FVP_BaseR_AEMv8R``
+- ``FVP_Morello`` (Version 0.11/33)
+- ``FVP_RD_V1``
+- ``FVP_TC1``
+- ``FVP_TC2`` (Version 11.20/24)
The latest version of the AArch32 build of TF-A has been tested on the
following Arm FVPs without shifted affinities, and that do not support threaded
diff --git a/docs/resources/diagrams/ffa-ns-interrupt-handling-managed-exit.png b/docs/resources/diagrams/ffa-ns-interrupt-handling-managed-exit.png
deleted file mode 100644
index 0619cf2..0000000
--- a/docs/resources/diagrams/ffa-ns-interrupt-handling-managed-exit.png
+++ /dev/null
Binary files differ
diff --git a/docs/resources/diagrams/ffa-ns-interrupt-handling-sp-preemption.png b/docs/resources/diagrams/ffa-ns-interrupt-handling-sp-preemption.png
deleted file mode 100644
index f110028..0000000
--- a/docs/resources/diagrams/ffa-ns-interrupt-handling-sp-preemption.png
+++ /dev/null
Binary files differ
diff --git a/docs/resources/diagrams/plantuml/tfa_dfd.puml b/docs/resources/diagrams/plantuml/tfa_dfd.puml
index 0007911..9d3dcba 100644
--- a/docs/resources/diagrams/plantuml/tfa_dfd.puml
+++ b/docs/resources/diagrams/plantuml/tfa_dfd.puml
@@ -25,7 +25,7 @@
nsec [label="Non-secure\nClients"]
sec [label="Secure\nClients"]
dbg [label="Debug & Trace"]
- logs [label="Logs\n(UART)"]
+ uart [label="UART"]
nvm [label="Non-volatile\nMemory"]
# Trust boundary cluster
@@ -56,7 +56,7 @@
# Interactions between nodes
nvm -> bl31 [lhead=cluster_tfa label="DF1"]
- logs -> bl31 [dir="back" lhead=cluster_tfa label="DF2"]
+ uart -> bl31 [dir="both" lhead=cluster_tfa label="DF2"]
dbg -> bl2 [dir="both" lhead=cluster_tfa label="DF3"]
sec -> bl2 [dir="both" lhead=cluster_tfa label="DF4"]
nsec -> bl1 [dir="both" lhead=cluster_tfa, label="DF5"]
diff --git a/docs/resources/diagrams/plantuml/tfa_rss_dfd.puml b/docs/resources/diagrams/plantuml/tfa_rss_dfd.puml
index 23f5b17..a7e0ce5 100644
--- a/docs/resources/diagrams/plantuml/tfa_rss_dfd.puml
+++ b/docs/resources/diagrams/plantuml/tfa_rss_dfd.puml
@@ -25,7 +25,7 @@
nsec [label="Non-secure\nClients"]
sec [label="Secure\nClients"]
dbg [label="Debug & Trace"]
- logs [label="Logs\n(UART)"]
+ uart [label="UART"]
nvm [label="Non-volatile\nMemory"]
@@ -65,7 +65,7 @@
# Interactions between nodes
nvm -> bl31 [lhead=cluster_tfa label="DF1"]
- logs -> bl31 [dir="back" lhead=cluster_tfa label="DF2"]
+ uart -> bl31 [dir="both" lhead=cluster_tfa label="DF2"]
dbg -> bl2 [dir="both" lhead=cluster_tfa label="DF3"]
sec -> bl2 [dir="both" lhead=cluster_tfa label="DF4"]
nsec -> bl1 [dir="both" lhead=cluster_tfa, label="DF5"]
diff --git a/docs/threat_model/index.rst b/docs/threat_model/index.rst
index b22fb18..3e0393e 100644
--- a/docs/threat_model/index.rst
+++ b/docs/threat_model/index.rst
@@ -31,7 +31,6 @@
:caption: Contents
threat_model
- threat_model_spm
threat_model_el3_spm
threat_model_fvp_r
threat_model_rss_interface
diff --git a/docs/threat_model/threat_model.rst b/docs/threat_model/threat_model.rst
index 57a5e1b..d1a77f5 100644
--- a/docs/threat_model/threat_model.rst
+++ b/docs/threat_model/threat_model.rst
@@ -63,8 +63,10 @@
| | images include TF-A BL2 and BL31 images, as well as |
| | other secure and non-secure images. |
+-----------------+--------------------------------------------------------+
- | DF2 | | TF-A log system framework outputs debug messages |
- | | over a UART interface. |
+ | DF2 | | TF-A log system framework outputs debug or |
+ | | informative messages over a UART interface. |
+ | | |
+ | | | Also, characters can be read from a UART interface. |
+-----------------+--------------------------------------------------------+
| DF3 | | Debug and trace IP on a platform can allow access |
| | to registers and memory of TF-A. |
@@ -552,6 +554,57 @@
| | soon as they are not needed anymore. |
+------------------------+-----------------------------------------------------+
| Mitigations | | Yes / Platform specific |
+| implemented? | |
++------------------------+-----------------------------------------------------+
+
+
++------------------------+-----------------------------------------------------+
+| ID | 15 |
++========================+=====================================================+
+| Threat | | **Improper handling of input data received over |
+| | a UART interface may allow an attacker to tamper |
+| | with TF-A execution environment.** |
+| | |
+| | | The consequences of the attack depend on the |
+| | the exact usage of input data received over UART. |
+| | Examples are injection of arbitrary data, |
+| | sensitive data tampering, influencing the |
+| | execution path, denial of service (if using |
+| | blocking I/O). This list may not be exhaustive. |
++------------------------+-----------------------------------------------------+
+| Diagram Elements | DF2, DF4, DF5 |
++------------------------+-----------------------------------------------------+
+| Affected TF-A | BL1, BL2, BL31 |
+| Components | |
++------------------------+-----------------------------------------------------+
+| Assets | Sensitive Data, Code Execution, Availability |
++------------------------+-----------------------------------------------------+
+| Threat Agent | NSCode, SecCode |
++------------------------+-----------------------------------------------------+
+| Threat Type | Tampering, Information Disclosure, Denial of |
+| | service, Elevation of privilege. |
++------------------------+-------------------+----------------+----------------+
+| Application | Server | IoT | Mobile |
++------------------------+-------------------+----------------+----------------+
+| Impact | Critical (5) | Critical (5) | Critical (5) |
++------------------------+-------------------+----------------+----------------+
+| Likelihood | Critical (5) | Critical (5) | Critical (5) |
++------------------------+-------------------+----------------+----------------+
+| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) |
++------------------------+-------------------+----------------+----------------+
+| Mitigations | | By default, the code to read input data from UART |
+| | interfaces is disabled (see `ENABLE_CONSOLE_GETC` |
+| | build option). It should only be enabled on a |
+| | need basis. |
+| | |
+| | | Data received over UART interfaces should be |
+| | treated as untrusted data. As such, it should be |
+| | properly sanitized and handled with caution. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | Generic code does not read any input data from |
+| | UART interface(s). |
+------------------------+-----------------------------------------------------+
diff --git a/docs/threat_model/threat_model_fvp_r.rst b/docs/threat_model/threat_model_fvp_r.rst
index c1462bb..725eeed 100644
--- a/docs/threat_model/threat_model_fvp_r.rst
+++ b/docs/threat_model/threat_model_fvp_r.rst
@@ -90,8 +90,10 @@
and since the MPU configuration is equivalent with that for the fvp
platform and others, this is not expected to be a concern.
+ - ID 15: Improper handling of input data received over a UART interface may
+ allow an attacker to tamper with TF-A execution environment.
--------------
-*Copyright (c) 2021, Arm Limited. All rights reserved.*
+*Copyright (c) 2021-2023, Arm Limited. All rights reserved.*
diff --git a/docs/threat_model/threat_model_spm.rst b/docs/threat_model/threat_model_spm.rst
deleted file mode 100644
index 24a115b..0000000
--- a/docs/threat_model/threat_model_spm.rst
+++ /dev/null
@@ -1,1340 +0,0 @@
-SPMC Threat Model
-*****************
-
-************************
-Introduction
-************************
-This document provides a threat model for the TF-A :ref:`Secure Partition Manager`
-(SPM) implementation or more generally the S-EL2 reference firmware running on
-systems implementing the FEAT_SEL2 (formerly Armv8.4 Secure EL2) architecture
-extension. The SPM implementation is based on the `Arm Firmware Framework for
-Arm A-profile`_ specification.
-
-In brief, the broad FF-A specification and S-EL2 firmware implementation
-provide:
-
-- Isolation of mutually mistrusting SW components, or endpoints in the FF-A
- terminology.
-- Distinct sandboxes in the secure world called secure partitions. This permits
- isolation of services from multiple vendors.
-- A standard protocol for communication and memory sharing between FF-A
- endpoints.
-- Mutual isolation of the normal world and the secure world (e.g. a Trusted OS
- is prevented to map an arbitrary NS physical memory region such as the kernel
- or the Hypervisor).
-
-************************
-Target of Evaluation
-************************
-In this threat model, the target of evaluation is the S-EL2 firmware or the
-``Secure Partition Manager Core`` component (SPMC).
-The monitor and SPMD at EL3 are covered by the :ref:`Generic TF-A threat model
-<threat_analysis>`.
-
-The scope for this threat model is:
-
-- The TF-A implementation for the S-EL2 SPMC based on the Hafnium hypervisor
- running in the secure world of TrustZone (at S-EL2 exception level).
- The threat model is not related to the normal world Hypervisor or VMs.
- The S-EL1 and EL3 SPMC solutions are not covered.
-- The implementation complies with the FF-A v1.0 specification, and a few
- features of FF-A v1.1 specification.
-- Secure partitions are statically provisioned at boot time.
-- Focus on the run-time part of the life-cycle (no specific emphasis on boot
- time, factory firmware provisioning, firmware udpate etc.)
-- Not covering advanced or invasive physical attacks such as decapsulation,
- FIB etc.
-- Assumes secure boot or in particular TF-A trusted boot (TBBR or dual CoT) is
- enabled. An attacker cannot boot arbitrary images that are not approved by the
- SiP or platform providers.
-
-Data Flow Diagram
-======================
-Figure 1 shows a high-level data flow diagram for the SPM split into an SPMD
-component at EL3 and an SPMC component at S-EL2. The SPMD mostly acts as a
-relayer/pass-through between the normal world and the secure world. It is
-assumed to expose small attack surface.
-
-A description of each diagram element is given in Table 1. In the diagram, the
-red broken lines indicate trust boundaries.
-
-Components outside of the broken lines are considered untrusted.
-
-.. uml:: ../resources/diagrams/plantuml/spm_dfd.puml
- :caption: Figure 1: SPMC Data Flow Diagram
-
-.. table:: Table 1: SPMC Data Flow Diagram Description
-
- +---------------------+--------------------------------------------------------+
- | Diagram Element | Description |
- +=====================+========================================================+
- | ``DF1`` | SP to SPMC communication. FF-A function invocation or |
- | | implementation-defined Hypervisor call. |
- +---------------------+--------------------------------------------------------+
- | ``DF2`` | SPMC to SPMD FF-A call. |
- +---------------------+--------------------------------------------------------+
- | ``DF3`` | SPMD to NS forwarding. |
- +---------------------+--------------------------------------------------------+
- | ``DF4`` | SP to SP FF-A direct message request/response. |
- | | Note as a matter of simplifying the diagram |
- | | the SP to SP communication happens through the SPMC |
- | | (SP1 performs a direct message request to the |
- | | SPMC targeting SP2 as destination. And similarly for |
- | | the direct message response from SP2 to SP1). |
- +---------------------+--------------------------------------------------------+
- | ``DF5`` | HW control. |
- +---------------------+--------------------------------------------------------+
- | ``DF6`` | Bootloader image loading. |
- +---------------------+--------------------------------------------------------+
- | ``DF7`` | External memory access. |
- +---------------------+--------------------------------------------------------+
-
-*********************
-Threat Analysis
-*********************
-
-This threat model follows a similar methodology to the :ref:`Generic TF-A threat model
-<threat_analysis>`.
-The following sections define:
-
-- Trust boundaries
-- Assets
-- Theat agents
-- Threat types
-
-Trust boundaries
-============================
-
-- Normal world is untrusted.
-- Secure world and normal world are separate trust boundaries.
-- EL3 monitor, SPMD and SPMC are trusted.
-- Bootloaders (in particular BL1/BL2 if using TF-A) and run-time BL31 are
- implicitely trusted by the usage of secure boot.
-- EL3 monitor, SPMD, SPMC do not trust SPs.
-
-.. figure:: ../resources/diagrams/spm-threat-model-trust-boundaries.png
-
- Figure 2: Trust boundaries
-
-Assets
-============================
-
-The following assets are identified:
-
-- SPMC state.
-- SP state.
-- Information exchange between endpoints (partition messages).
-- SPMC secrets (e.g. pointer authentication key when enabled)
-- SP secrets (e.g. application keys).
-- Scheduling cycles.
-- Shared memory.
-
-Threat Agents
-============================
-
-The following threat agents are identified:
-
-- NS-Endpoint identifies a non-secure endpoint: normal world client at NS-EL2
- (Hypervisor) or NS-EL1 (VM or OS kernel).
-- S-Endpoint identifies a secure endpoint typically a secure partition.
-- Hardware attacks (non-invasive) requiring a physical access to the device,
- such as bus probing or DRAM stress.
-
-Threat types
-============================
-
-The following threat categories as exposed in the :ref:`Generic TF-A threat model
-<threat_analysis>`
-are re-used:
-
-- Spoofing
-- Tampering
-- Repudiation
-- Information disclosure
-- Denial of service
-- Elevation of privileges
-
-Similarly this threat model re-uses the same threat risk ratings. The risk
-analysis is evaluated based on the environment being ``Server`` or ``Mobile``.
-
-Threat Assessment
-============================
-
-The following threats are identified by applying STRIDE analysis on each diagram
-element of the data flow diagram.
-
-+------------------------+----------------------------------------------------+
-| ID | 01 |
-+========================+====================================================+
-| ``Threat`` | **An endpoint impersonates the sender or receiver |
-| | FF-A ID in a direct request/response invocation.** |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3, DF4 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMD, SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SP state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Spoofing |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------++----------------+---------------+
-| ``Impact`` | Critical(5) | Critical(5) | |
-+------------------------+------------------++----------------+---------------+
-| ``Likelihood`` | Critical(5) | Critical(5) | |
-+------------------------+------------------++----------------+---------------+
-| ``Total Risk Rating`` | Critical(25) | Critical(25) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC does not mitigate this threat. |
-| | The guidance below is left for a system integrator |
-| | to implemented as necessary. |
-| | The SPMC must enforce checks in the direct message |
-| | request/response interfaces such an endpoint cannot|
-| | spoof the origin and destination worlds (e.g. a NWd|
-| | originated message directed to the SWd cannot use a|
-| | SWd ID as the sender ID). |
-| | Additionally a software component residing in the |
-| | SPMC can be added for the purpose of direct |
-| | request/response filtering. |
-| | It can be configured with the list of known IDs |
-| | and about which interaction can occur between one |
-| | and another endpoint (e.g. which NWd endpoint ID |
-| | sends a direct request to which SWd endpoint ID). |
-| | This component checks the sender/receiver fields |
-| | for a legitimate communication between endpoints. |
-| | A similar component can exist in the OS kernel |
-| | driver, or Hypervisor although it remains untrusted|
-| | by the SPMD/SPMC. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 02 |
-+========================+====================================================+
-| ``Threat`` | **Tampering with memory shared between an endpoint |
-| | and the SPMC.** |
-| | A malicious endpoint may attempt tampering with its|
-| | RX/TX buffer contents while the SPMC is processing |
-| | it (TOCTOU). |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF3, DF4, DF7 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | Shared memory, Information exchange |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Tampering |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | High (4) | High (4) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | High (4) | High (4) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | High (16) | High (16) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | In context of FF-A v1.0 and v1.1 this is the case |
-| | of sharing the RX/TX buffer pair and usage in the |
-| | PARTITION_INFO_GET or mem sharing primitives. |
-| | The SPMC must copy the contents of the TX buffer |
-| | to an internal temporary buffer before processing |
-| | its contents. The SPMC must implement hardened |
-| | input validation on data transmitted through the TX|
-| | buffer by an untrusted endpoint. |
-| | The TF-A SPMC mitigates this threat by enforcing |
-| | checks on data transmitted through RX/TX buffers. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 03 |
-+========================+====================================================+
-| ``Threat`` | **An endpoint may tamper with its own state or the |
-| | state of another endpoint.** |
-| | A malicious endpoint may attempt violating: |
-| | - its own or another SP state by using an unusual |
-| | combination (or out-of-order) FF-A function |
-| | invocations. |
-| | This can also be an endpoint emitting |
-| | FF-A function invocations to another endpoint while|
-| | the latter is not in a state to receive it (e.g. a |
-| | SP sends a direct request to the normal world early|
-| | while the normal world is not booted yet). |
-| | - the SPMC state itself by employing unexpected |
-| | transitions in FF-A memory sharing, direct requests|
-| | and responses, or handling of interrupts. |
-| | This can be led by random stimuli injection or |
-| | fuzzing. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3, DF4 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMD, SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SP state, SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Tampering |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | High (4) | High (4) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | High (12) | High (12) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC provides mitigation against such |
-| | threat by following the guidance for partition |
-| | runtime models as described in FF-A v1.1 EAC0 spec.|
-| | The SPMC performs numerous checks in runtime to |
-| | prevent illegal state transitions by adhering to |
-| | the partition runtime model. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 04 |
-+========================+====================================================+
-| ``Threat`` | *An attacker may attempt injecting errors by the |
-| | use of external DRAM stress techniques.** |
-| | A malicious agent may attempt toggling an SP |
-| | Stage-2 MMU descriptor bit within the page tables |
-| | that the SPMC manages. This can happen in Rowhammer|
-| | types of attack. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF7 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SP or SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | Hardware attack |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Tampering |
-+------------------------+------------------+---------------+-----------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+---------------+-----------------+
-| ``Impact`` | High (4) | High (4) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Likelihood`` | Low (2) | Medium (3) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Total Risk Rating`` | Medium (8) | High (12) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Mitigations`` | The TF-A SPMC does not provide mitigations to this |
-| | type of attack. It can be addressed by the use of |
-| | dedicated HW circuity or hardening at the chipset |
-| | or platform level left to the integrator. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 05 |
-+========================+====================================================+
-| ``Threat`` | **Protection of the SPMC from a DMA capable device |
-| | upstream to an SMMU.** |
-| | A device may attempt to tamper with the internal |
-| | SPMC code/data sections. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF5 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC or SP state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Tampering, Elevation of privileges |
-+------------------------+------------------+---------------+-----------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+---------------+-----------------+
-| ``Impact`` | High (4) | High (4) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Total Risk Rating`` | High (12) | High (12) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Mitigations`` | A platform may prefer assigning boot time, |
-| | statically alocated memory regions through the SMMU|
-| | configuration and page tables. The FF-A v1.1 |
-| | specification provisions this capability through |
-| | static DMA isolation. |
-| | The TF-A SPMC does not mitigate this threat. |
-| | It will adopt the static DMA isolation approach in |
-| | a future release. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 06 |
-+========================+====================================================+
-| ``Threat`` | **Replay fragments of past communication between |
-| | endpoints.** |
-| | A malicious endpoint may replay a message exchange |
-| | that occured between two legitimate endpoint as |
-| | a matter of triggering a malfunction or extracting |
-| | secrets from the receiving endpoint. In particular |
-| | the memory sharing operation with fragmented |
-| | messages between an endpoint and the SPMC may be |
-| | replayed by a malicious agent as a matter of |
-| | getting access or gaining permissions to a memory |
-| | region which does not belong to this agent. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF2, DF3 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | Information exchange |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Repdudiation |
-+------------------------+------------------+---------------+-----------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+---------------+-----------------+
-| ``Impact`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Likelihood`` | High (4) | High (4) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Total Risk Rating`` | High (12) | High (12) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Mitigations`` | The TF-A SPMC does not mitigate this threat. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 07 |
-+========================+====================================================+
-| ``Threat`` | **A malicious endpoint may attempt to extract data |
-| | or state information by the use of invalid or |
-| | incorrect input arguments.** |
-| | Lack of input parameter validation or side effects |
-| | of maliciously forged input parameters might affect|
-| | the SPMC. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3, DF4 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMD, SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SP secrets, SPMC secrets, SP state, SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Information discolure |
-+------------------------+------------------+---------------+-----------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+---------------+-----------------+
-| ``Impact`` | High (4) | High (4) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Total Risk Rating`` | High (12) | High (12) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Mitigations`` | Secure Partitions must follow security standards |
-| | and best practises as a way to mitigate the risk |
-| | of common vulnerabilities to be exploited. |
-| | The use of software (canaries) or hardware |
-| | hardening techniques (XN, WXN, BTI, pointer |
-| | authentication, MTE) helps detecting and stopping |
-| | an exploitation early. |
-| | The TF-A SPMC mitigates this threat by implementing|
-| | stack protector, pointer authentication, BTI, XN, |
-| | WXN, security hardening techniques. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 08 |
-+========================+====================================================+
-| ``Threat`` | **A malicious endpoint may forge a direct message |
-| | request such that it reveals the internal state of |
-| | another endpoint through the direct message |
-| | response.** |
-| | The secure partition or SPMC replies to a partition|
-| | message by a direct message response with |
-| | information which may reveal its internal state |
-| | (.e.g. partition message response outside of |
-| | allowed bounds). |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3, DF4 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC or SP state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Information discolure |
-+------------------------+------------------+---------------+-----------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+---------------+-----------------+
-| ``Impact`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Likelihood`` | Low (2) | Low (2) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Total Risk Rating`` | Medium (6) | Medium (6) | |
-+------------------------+------------------+---------------+-----------------+
-| ``Mitigations`` | For the specific case of direct requests targeting |
-| | the SPMC, the latter is hardened to prevent |
-| | its internal state or the state of an SP to be |
-| | revealed through a direct message response. |
-| | Further, SPMC performs numerous checks in runtime |
-| | on the basis of the rules established by partition |
-| | runtime models to stop any malicious attempts by |
-| | an endpoint to extract internal state of another |
-| | endpoint. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 09 |
-+========================+====================================================+
-| ``Threat`` | **Probing the FF-A communication between |
-| | endpoints.** |
-| | SPMC and SPs are typically loaded to external |
-| | memory (protected by a TrustZone memory |
-| | controller). A malicious agent may use non invasive|
-| | methods to probe the external memory bus and |
-| | extract the traffic between an SP and the SPMC or |
-| | among SPs when shared buffers are held in external |
-| | memory. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF7 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SP/SPMC state, SP/SPMC secrets |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | Hardware attack |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Information disclosure |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Low (2) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium (6) | Medium (9) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | It is expected the platform or chipset provides |
-| | guarantees in protecting the DRAM contents. |
-| | The TF-A SPMC does not mitigate this class of |
-| | attack and this is left to the integrator. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 10 |
-+========================+====================================================+
-| ``Threat`` | **A malicious agent may attempt revealing the SPMC |
-| | state or secrets by the use of software-based cache|
-| | side-channel attack techniques.** |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF7 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SP or SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Information disclosure |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Low (2) | Low (2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium (6) | Medium (6) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | From an integration perspective it is assumed |
-| | platforms consuming the SPMC component at S-EL2 |
-| | (hence implementing the Armv8.4 FEAT_SEL2 |
-| | architecture extension) implement mitigations to |
-| | Spectre, Meltdown or other cache timing |
-| | side-channel type of attacks. |
-| | The TF-A SPMC implements one mitigation (barrier |
-| | preventing speculation past exeception returns). |
-| | The SPMC may be hardened further with SW |
-| | mitigations (e.g. speculation barriers) for the |
-| | cases not covered in HW. Usage of hardened |
-| | compilers and appropriate options, code inspection |
-| | are recommended ways to mitigate Spectre types of |
-| | attacks. For non-hardened cores, the usage of |
-| | techniques such a kernel page table isolation can |
-| | help mitigating Meltdown type of attacks. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 11 |
-+========================+====================================================+
-| ``Threat`` | **A malicious endpoint may attempt flooding the |
-| | SPMC with requests targeting a service within an |
-| | endpoint such that it denies another endpoint to |
-| | access this service.** |
-| | Similarly, the malicious endpoint may target a |
-| | a service within an endpoint such that the latter |
-| | is unable to request services from another |
-| | endpoint. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3, DF4 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Denial of service |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium (9) | Medium (9) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC does not mitigate this threat. |
-| | Bounding the time for operations to complete can |
-| | be achieved by the usage of a trusted watchdog. |
-| | Other quality of service monitoring can be achieved|
-| | in the SPMC such as counting a number of operations|
-| | in a limited timeframe. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 12 |
-+========================+====================================================+
-| ``Threat`` | **A malicious endpoint may attempt to allocate |
-| | notifications bitmaps in the SPMC, through the |
-| | FFA_NOTIFICATION_BITMAP_CREATE.** |
-| | This might be an attempt to exhaust SPMC's memory, |
-| | or to allocate a bitmap for a VM that was not |
-| | intended to receive notifications from SPs. Thus |
-| | creating the possibility for a channel that was not|
-| | meant to exist. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Denial of service, Spoofing |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Medium(3) | Medium(3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium(3) | Medium(3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium(9) | Medium(9) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC mitigates this threat by defining a |
-| | a fixed size pool for bitmap allocation. |
-| | It also limits the designated FF-A calls to be used|
-| | from NWd endpoints. |
-| | In the NWd the hypervisor is supposed to limit the |
-| | access to the designated FF-A call. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 13 |
-+========================+====================================================+
-| ``Threat`` | **A malicious endpoint may attempt to destroy the |
-| | notifications bitmaps in the SPMC, through the |
-| | FFA_NOTIFICATION_BITMAP_DESTROY.** |
-| | This might be an attempt to tamper with the SPMC |
-| | state such that a partition isn't able to receive |
-| | notifications. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Tampering |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Low(2) | Low(2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Low(2) | Low(2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Low(4) | Low(4) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC mitigates this issue by limiting the |
-| | designated FF-A call to be issued by the NWd. |
-| | Also, the notifications bitmap can't be destroyed |
-| | if there are pending notifications. |
-| | In the NWd, the hypervisor must restrict the |
-| | NS-endpoints that can issue the designated call. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 14 |
-+========================+====================================================+
-| ``Threat`` | **A malicious endpoint might attempt to give |
-| | permissions to an unintended sender to set |
-| | notifications targeting another receiver using the |
-| | FF-A call FFA_NOTIFICATION_BIND.** |
-| | This might be an attempt to tamper with the SPMC |
-| | state such that an unintended, and possibly |
-| | malicious, communication channel is established. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Tampering, Spoofing |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Low(2) | Low(2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium(3) | Medium(3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium(6) | Medium(6) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC mitigates this by restricting |
-| | designated FFA_NOTIFICATION_BIND call to be issued |
-| | by the receiver only. The receiver is responsible |
-| | for allocating the notifications IDs to one |
-| | specific partition. |
-| | Also, receivers that are not meant to receive |
-| | notifications, must have notifications receipt |
-| | disabled in the respective partition's manifest. |
-| | As for calls coming from NWd, if the NWd VM has had|
-| | its bitmap allocated at initialization, the TF-A |
-| | SPMC can't guarantee this threat won't happen. |
-| | The Hypervisor must mitigate in the NWd, similarly |
-| | to SPMC for calls in SWd. Though, if the Hypervisor|
-| | has been compromised, the SPMC won't be able to |
-| | mitigate it for calls forwarded from NWd. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 15 |
-+========================+====================================================+
-| ``Threat`` | **A malicious partition endpoint might attempt to |
-| | set notifications that are not bound to it.** |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Spoofing |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Low(2) | Low(2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Low(2) | Low(2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Low(4) | Low(4) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC mitigates this by checking the |
-| | sender's ID provided in the input to the call |
-| | FFA_NOTIFICATION_SET. The SPMC keeps track of which|
-| | notifications are bound to which sender, for a |
-| | given receiver. If the sender is an SP, the |
-| | provided sender ID must match the ID of the |
-| | currently running partition. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 16 |
-+========================+====================================================+
-| ``Threat`` | **A malicious partition endpoint might attempt to |
-| | get notifications that are not targeted to it.** |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Spoofing |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Informational(1) | Informational(1)| |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Low(2) | Low(2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Low(2) | Low(2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC mitigates this by checking the |
-| | receiver's ID provided in the input to the call |
-| | FFA_NOTIFICATION_GET. The SPMC keeps track of which|
-| | notifications are pending for each receiver. |
-| | The provided receiver ID must match the ID of the |
-| | currently running partition, if it is an SP. |
-| | For calls forwarded from NWd, the SPMC will return |
-| | the pending notifications if the receiver had its |
-| | bitmap created, and has pending notifications. |
-| | If Hypervisor or OS kernel are compromised, the |
-| | SPMC won't be able to mitigate calls from rogue NWd|
-| | endpoints. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 17 |
-+========================+====================================================+
-| ``Threat`` | **A malicious partition endpoint might attempt to |
-| | get the information about pending notifications, |
-| | through the FFA_NOTIFICATION_INFO_GET call.** |
-| | This call is meant to be used by the NWd FF-A |
-| | driver. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Information disclosure |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Low(2) | Low(2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium(3) | Medium(3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium(6) | Medium(6) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC mitigates this by returning error to |
-| | calls made by SPs to FFA_NOTIFICATION_INFO_GET. |
-| | If Hypervisor or OS kernel are compromised, the |
-| | SPMC won't be able mitigate calls from rogue NWd |
-| | endpoints. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 18 |
-+========================+====================================================+
-| ``Threat`` | **A malicious partition endpoint might attempt to |
-| | flood another partition endpoint with notifications|
-| | hindering its operation.** |
-| | The intent of the malicious endpoint could be to |
-| | interfere with both the receiver's and/or primary |
-| | endpoint execution, as they can both be preempted |
-| | by the NPI and SRI, respectively. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3, DF4 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state, SP state, CPU cycles |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | DoS |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Low(2) | Low(2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium(3) | Medium(3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium(6) | Medium(6) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC does not mitigate this threat. |
-| | However, the impact is limited due to the |
-| | architecture: |
-| | - Notifications are not queued, one that has been |
-| | signaled needs to be retrieved by the receiver, |
-| | until it can be sent again. |
-| | - Both SRI and NPI can't be pended until handled |
-| | which limits the amount of spurious interrupts. |
-| | - A given receiver could only bind a maximum number|
-| | of notifications to a given sender, within a given |
-| | execution context. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 19 |
-+========================+====================================================+
-| ``Threat`` | **A malicious endpoint may abuse FFA_RUN call to |
-| | resume or turn on other endpoint execution |
-| | contexts, attempting to alter the internal state of|
-| | SPMC and SPs, potentially leading to illegal state |
-| | transitions and deadlocks.** |
-| | An endpoint can call into another endpoint |
-| | execution context using FFA_MSG_SEND_DIRECT_REQ |
-| | ABI to create a call chain. A malicious endpoint |
-| | could abuse this to form loops in a call chain that|
-| | could lead to potential deadlocks. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF4 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC, SPMD |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state, SP state, Scheduling cycles |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Tampering, Denial of Service |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium (9) | Medium (9) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC provides mitigation against such |
-| | threats by following the guidance for partition |
-| | runtime models as described in FF-A v1.1 EAC0 spec.|
-| | The SPMC performs numerous checks in runtime to |
-| | prevent illegal state transitions by adhering to |
-| | the partition runtime model. Further, if the |
-| | receiver endpoint is a predecessor of current |
-| | endpoint in the present call chain, the SPMC denies|
-| | any attempts to form loops by returning FFA_DENIED |
-| | error code. Only the primary scheduler is allowed |
-| | to turn on execution contexts of other partitions |
-| | though SPMC does not have the ability to |
-| | scrutinize its identity. Secure partitions have |
-| | limited ability to resume execution contexts of |
-| | other partitions based on the runtime model. Such |
-| | attempts cannot compromise the integrity of the |
-| | SPMC. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 20 |
-+========================+====================================================+
-| ``Threat`` | **A malicious endpoint can perform a |
-| | denial-of-service attack by using FFA_INTERRUPT |
-| | call that could attempt to cause the system to |
-| | crash or enter into an unknown state as no physical|
-| | interrupt could be pending for it to be handled in |
-| | the SPMC.** |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF5 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC, SPMD |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state, SP state, Scheduling cycles |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Tampering, Denial of Service |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium (9) | Medium (9) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC provides mitigation against such |
-| | attack by detecting invocations from partitions |
-| | and simply returning FFA_ERROR status interface. |
-| | SPMC only allows SPMD to use FFA_INTERRUPT ABI to |
-| | communicate a pending secure interrupt triggered |
-| | while execution was in normal world. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 21 |
-+========================+====================================================+
-| ``Threat`` | **A malicious secure endpoint might deactivate a |
-| | (virtual) secure interrupt that was not originally |
-| | signaled by SPMC, thereby attempting to alter the |
-| | state of the SPMC and potentially lead to system |
-| | crash.** |
-| | SPMC maps the virtual interrupt ids to the physical|
-| | interrupt ids to keep the implementation of virtual|
-| | interrupt driver simple. |
-| | Similarly, a malicious secure endpoint might invoke|
-| | the deactivation ABI more than once for a secure |
-| | interrupt. Moreover, a malicious secure endpoint |
-| | might attempt to deactivate a (virtual) secure |
-| | interrupt that was signaled to another endpoint |
-| | execution context by the SPMC even before secure |
-| | interrupt was handled. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF5 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state, SP state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Tampering |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium (9) | Medium (9) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | At initialization, the TF-A SPMC parses the |
-| | partition manifests to find the target execution |
-| | context responsible for handling the various |
-| | secure physical interrupts. The TF-A SPMC provides |
-| | mitigation against above mentioned threats by: |
-| | |
-| | - Keeping track of each pending virtual interrupt |
-| | signaled to an execution context of a secure |
-| | secure partition. |
-| | - Denying any deactivation call from SP if there is|
-| | no pending physical interrupt mapped to the |
-| | given virtual interrupt. |
-| | - Denying any deactivation call from SP if the |
-| | virtual interrupt has not been signaled to the |
-| | current execution context. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 22 |
-+========================+====================================================+
-| ``Threat`` | **A malicious secure endpoint might not deactivate |
-| | a virtual interrupt signaled to it by the SPMC but |
-| | perform secure interrupt signal completion. This |
-| | attempt to corrupt the internal state of the SPMC |
-| | could lead to an unknown state and further lead to |
-| | system crash.** |
-| | Similarly, a malicious secure endpoint could |
-| | deliberately not perform either interrupt |
-| | deactivation or interrupt completion signal. Since,|
-| | the SPMC can only process one secure interrupt at a|
-| | time, this could choke the system where all |
-| | interrupts are indefinitely masked which could |
-| | potentially lead to system crash or reboot. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF5 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state, SP state, Scheduling cycles |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Tampering, Denial of Service |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium (9) | Medium (9) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC does not provide mitigation against |
-| | such threat. This is a limitation of the current |
-| | SPMC implementation and needs to be handled in the |
-| | future releases. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 23 |
-+========================+====================================================+
-| ``Threat`` | **A malicious endpoint could leverage non-secure |
-| | interrupts to preempt a secure endpoint, thereby |
-| | attempting to render it unable to handle a secure |
-| | virtual interrupt targetted for it. This could lead|
-| | to priority inversion as secure virtual interrupts |
-| | are kept pending while non-secure interrupts are |
-| | handled by normal world VMs.** |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3, DF5 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC, SPMD |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state, SP state, Scheduling cycles |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Denial of Service |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium (9) | Medium (9) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC alone does not provide mitigation |
-| | against such threats. System integrators must take |
-| | necessary high level design decisions that takes |
-| | care of interrupt prioritization. The SPMC performs|
-| | its role of enabling SPs to specify appropriate |
-| | action towards non-secure interrupt with the help |
-| | of partition manifest based on the guidance in the |
-| | FF-A v1.1 EAC0 specification. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 24 |
-+========================+====================================================+
-| ``Threat`` | **A secure endpoint depends on primary scheduler |
-| | for CPU cycles. A malicious endpoint could delay |
-| | the secure endpoint from being scheduled. Secure |
-| | interrupts, if not handled timely, could compromise|
-| | the state of SP and SPMC, thereby rendering the |
-| | system unresponsive.** |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2, DF3, DF5 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC, SPMD |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state, SP state, Scheduling cycles |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Denial of Service |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium (9) | Medium (9) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC does not provide full mitigation |
-| | against such threats. However, based on the |
-| | guidance provided in the FF-A v1.1 EAC0 spec, SPMC |
-| | provisions CPU cycles to run a secure endpoint |
-| | execution context in SPMC schedule mode which |
-| | cannot be preempted by a non-secure interrupt. |
-| | This reduces the dependency on primary scheduler |
-| | for cycle allocation. Moreover, all further |
-| | interrupts are masked until pending secure virtual |
-| | interrupt on current CPU is handled. This allows SP|
-| | execution context to make progress even upon being |
-| | interrupted. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 25 |
-+========================+====================================================+
-| ``Threat`` | **A rogue FF-A endpoint can use memory sharing |
-| | calls to exhaust SPMC resources.** |
-| | For each on-going operation that involves an SP, |
-| | the SPMC allocates resources to track its state. |
-| | If the operation is never concluded, the resources |
-| | are never freed. |
-| | In the worst scenario, multiple operations that |
-| | never conclude may exhaust the SPMC resources to a |
-| | point in which renders memory sharing operations |
-| | impossible. This could affect other, non-harmful |
-| | FF-A endpoints, from legitimately using memory |
-| | share functionality. The intent might even be |
-| | to cause the SPMC to consume excessive CPU cycles, |
-| | attempting to make it deny its service to the NWd. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC, SPMD |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SPMC state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Denial of Service |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | High (4) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | High (4) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | High (16) | Medium (9) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC uses a statically allocated pool of |
-| | memory to keep track of on-going memory sharing |
-| | operations. After a possible attack, this could |
-| | fail due to insufficient memory, and return an |
-| | error to the caller. At this point, any other |
-| | endpoint that requires use of memory sharing for |
-| | its operation could get itself in an unusable |
-| | state. |
-| | Regarding CPU cycles starving threat, the SPMC |
-| | doesn't provide any mitigation for this, as any |
-| | FF-A endpoint, at the virtual FF-A instance is |
-| | allowed to invoke memory share/lend/donate. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 26 |
-+========================+====================================================+
-| ``Threat`` | **A borrower may interfere with lender's |
-| | operation, if it terminates due to a fatal error |
-| | condition without releasing the memory |
-| | shared/lent.** |
-| | Such scenario may render the lender inoperable. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SP state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Denial of Service |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | High (4) | Low (2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | High (12) | Medium(6) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC does not provide mitigation for such |
-| | scenario. The FF-A endpoints must attempt to |
-| | relinquish memory shared/lent themselves in |
-| | case of failure. The memory used to track the |
-| | operation in the SPMC will also remain usuable. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 27 |
-+========================+====================================================+
-| ``Threat`` | **A rogue FF-A endpoint may attempt to tamper with |
-| | the content of the memory shared/lent, whilst |
-| | being accessed by other FF-A endpoints.** |
-| | It might attempt to do so: using one of the clear |
-| | flags, when either retrieving or relinquishing |
-| | access to the memory via the respective FF-A |
-| | calls; or directly accessing memory without |
-| | respecting the synchronization protocol between |
-| | all involved endpoints. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC, FF-A endpoint |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SP state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Denial of Service, Tampering |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | Low (2) | Low (2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium (3) | Medium (3) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | Medium (6) | Medium(6) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The first case defined in the threat, the TF-A |
-| | SPMC mitigates it, by ensuring a memory is cleared |
-| | only when all borrowers have relinquished access |
-| | to the memory, in a scenario involving multiple |
-| | borrowers. Also, if the receiver is granted RO, |
-| | permissions, the SPMC will reject any request |
-| | to clear memory on behalf of the borrower, by |
-| | returning an error to the respective FF-A call. |
-| | The second case defined in the threat can't be |
-| | mitigated by the SPMC. It is up to the NS/S FF-A |
-| | endpoints to establish a robust protocol for using |
-| | the shared memory. |
-+------------------------+----------------------------------------------------+
-
-+------------------------+----------------------------------------------------+
-| ID | 28 |
-+========================+====================================================+
-| ``Threat`` | **A rogue FF-A endpoint may attempt to share |
-| | memory that is not in its translation regime, or |
-| | attempt to specify attributes more permissive than |
-| | those it possesses at a given time.** |
-| | Both ways could be an attempt for escalating its |
-| | privileges. |
-+------------------------+----------------------------------------------------+
-| ``Diagram Elements`` | DF1, DF2 |
-+------------------------+----------------------------------------------------+
-| ``Affected TF-A | SPMC, FF-A endpoint |
-| Components`` | |
-+------------------------+----------------------------------------------------+
-| ``Assets`` | SP state |
-+------------------------+----------------------------------------------------+
-| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
-+------------------------+----------------------------------------------------+
-| ``Threat Type`` | Denial of Service, Tampering |
-+------------------------+------------------+-----------------+---------------+
-| ``Application`` | ``Server`` | ``Mobile`` | |
-+------------------------+------------------+-----------------+---------------+
-| ``Impact`` | High (4) | Low (2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Likelihood`` | Medium (3) | Low (2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Total Risk Rating`` | High (12) | Low (2) | |
-+------------------------+------------------+-----------------+---------------+
-| ``Mitigations`` | The TF-A SPMC mitigates this threat by performing |
-| | sanity checks to the provided memory region |
-| | descriptor. |
-| | For operations at the virtual FF-A instance, and |
-| | once the full memory descriptor is provided, |
-| | the SPMC validates that the memory is part of the |
-| | caller's translation regime. The SPMC also checks |
-| | that the memory attributes provided are within |
-| | those the owner possesses, in terms of |
-| | permissiveness. If more permissive attributes are |
-| | specified, the SPMC returns an error |
-| | FFA_INVALID_PARAMETERS. The permissiveness rules |
-| | are enforced in any call to share/lend or donate |
-| | the memory, and in retrieve requests. |
-+------------------------+----------------------------------------------------+
-
---------------
-
-*Copyright (c) 2021-2023, Arm Limited. All rights reserved.*
-
-.. _Arm Firmware Framework for Arm A-profile: https://developer.arm.com/docs/den0077/latest
-.. _FF-A ACS: https://github.com/ARM-software/ff-a-acs/releases
-
diff --git a/drivers/auth/auth_mod.c b/drivers/auth/auth_mod.c
index 14c3172..608866c 100644
--- a/drivers/auth/auth_mod.c
+++ b/drivers/auth/auth_mod.c
@@ -25,13 +25,6 @@
/* ASN.1 tags */
#define ASN1_INTEGER 0x02
-#define return_if_error(rc) \
- do { \
- if (rc != 0) { \
- return rc; \
- } \
- } while (0)
-
#pragma weak plat_set_nv_ctr2
static int cmp_auth_param_type_desc(const auth_param_type_desc_t *a,
@@ -99,24 +92,37 @@
{
void *data_ptr, *hash_der_ptr;
unsigned int data_len, hash_der_len;
- int rc = 0;
+ int rc;
/* Get the hash from the parent image. This hash will be DER encoded
* and contain the hash algorithm */
rc = auth_get_param(param->hash, img_desc->parent,
&hash_der_ptr, &hash_der_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
/* Get the data to be hashed from the current image */
rc = img_parser_get_auth_param(img_desc->img_type, param->data,
img, img_len, &data_ptr, &data_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
/* Ask the crypto module to verify this hash */
rc = crypto_mod_verify_hash(data_ptr, data_len,
hash_der_ptr, hash_der_len);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
- return rc;
+ return 0;
}
/*
@@ -153,22 +159,34 @@
void *data_ptr, *pk_ptr, *cnv_pk_ptr, *pk_plat_ptr, *sig_ptr, *sig_alg_ptr, *pk_oid;
unsigned int data_len, pk_len, cnv_pk_len, pk_plat_len, sig_len, sig_alg_len;
unsigned int flags = 0;
- int rc = 0;
+ int rc;
/* Get the data to be signed from current image */
rc = img_parser_get_auth_param(img_desc->img_type, param->data,
img, img_len, &data_ptr, &data_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
/* Get the signature from current image */
rc = img_parser_get_auth_param(img_desc->img_type, param->sig,
img, img_len, &sig_ptr, &sig_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
/* Get the signature algorithm from current image */
rc = img_parser_get_auth_param(img_desc->img_type, param->alg,
img, img_len, &sig_alg_ptr, &sig_alg_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
/* Get the public key from the parent. If there is no parent (NULL),
* the certificate has been signed with the ROTPK, so we have to get
@@ -176,7 +194,11 @@
if (img_desc->parent != NULL) {
rc = auth_get_param(param->pk, img_desc->parent,
&pk_ptr, &pk_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
} else {
/*
* Root certificates are signed with the ROTPK, so we have to
@@ -184,7 +206,11 @@
*/
rc = plat_get_rotpk_info(param->pk->cookie, &pk_plat_ptr,
&pk_plat_len, &flags);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
assert(is_rotpk_flags_valid(flags));
@@ -192,7 +218,11 @@
rc = img_parser_get_auth_param(img_desc->img_type,
param->pk, img, img_len,
&pk_ptr, &pk_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
/*
* Validate the certificate's key against the platform ROTPK.
@@ -211,7 +241,11 @@
* suffixed or modified pk
*/
rc = crypto_mod_convert_pk(pk_ptr, pk_len, &cnv_pk_ptr, &cnv_pk_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
/*
* The hash of the certificate's public key must match
@@ -219,7 +253,11 @@
*/
rc = crypto_mod_verify_hash(cnv_pk_ptr, cnv_pk_len,
pk_plat_ptr, pk_plat_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
} else {
/* Platform supports full ROTPK */
if ((pk_len != pk_plat_len) ||
@@ -245,7 +283,8 @@
*/
rc = plat_mboot_measure_key(pk_oid, pk_ptr, pk_len);
if (rc != 0) {
- WARN("Public Key measurement failure = %d\n", rc);
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
}
}
@@ -254,8 +293,13 @@
sig_ptr, sig_len,
sig_alg_ptr, sig_alg_len,
pk_ptr, pk_len);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
- return rc;
+ return 0;
}
/*
@@ -283,14 +327,18 @@
void *data_ptr = NULL;
unsigned int data_len, len, i;
unsigned int plat_nv_ctr;
- int rc = 0;
+ int rc;
bool is_trial_run = false;
/* Get the counter value from current image. The AM expects the IPM
* to return the counter value as a DER encoded integer */
rc = img_parser_get_auth_param(img_desc->img_type, param->cert_nv_ctr,
img, img_len, &data_ptr, &data_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
/* Parse the DER encoded integer */
assert(data_ptr);
@@ -329,7 +377,11 @@
/* Get the counter from the platform */
rc = plat_get_nv_ctr(param->plat_nv_ctr->cookie, &plat_nv_ctr);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
if (*cert_nv_ctr < plat_nv_ctr) {
/* Invalid NV-counter */
@@ -417,7 +469,11 @@
/* Ask the parser to check the image integrity */
rc = img_parser_check_integrity(img_desc->img_type, img_ptr, img_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
/* Authenticate the image using the methods indicated in the image
* descriptor. */
@@ -449,7 +505,11 @@
rc = 1;
break;
}
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
- return_if_error(rc);
}
/*
@@ -459,7 +519,11 @@
if (need_nv_ctr_upgrade && sig_auth_done) {
rc = plat_set_nv_ctr2(nv_ctr_param->plat_nv_ctr->cookie,
img_desc, cert_nv_ctr);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
}
/* Extract the parameters indicated in the image descriptor to
@@ -474,7 +538,11 @@
rc = img_parser_get_auth_param(img_desc->img_type,
img_desc->authenticated_data[i].type_desc,
img_ptr, img_len, ¶m_ptr, ¶m_len);
- return_if_error(rc);
+ if (rc != 0) {
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
+ return rc;
+ }
/* Check parameter size */
if (param_len > img_desc->authenticated_data[i].data.len) {
@@ -495,8 +563,8 @@
param_ptr,
param_len);
if (rc != 0) {
- WARN("Public Key measurement "
- "failure = %d\n", rc);
+ VERBOSE("[TBB] %s():%d failed with error code %d.\n",
+ __func__, __LINE__, rc);
}
}
}
diff --git a/drivers/auth/mbedtls/mbedtls_common.mk b/drivers/auth/mbedtls/mbedtls_common.mk
index e380c86..a2c6430 100644
--- a/drivers/auth/mbedtls/mbedtls_common.mk
+++ b/drivers/auth/mbedtls/mbedtls_common.mk
@@ -21,7 +21,8 @@
# Specify mbed TLS configuration file
ifeq (${MBEDTLS_MAJOR}, 2)
- MBEDTLS_CONFIG_FILE ?= "<drivers/auth/mbedtls/mbedtls_config-2.h>"
+ $(info Deprecation Notice: Please migrate to Mbedtls version 3.x (refer to TF-A documentation for the exact version number))
+ MBEDTLS_CONFIG_FILE ?= "<drivers/auth/mbedtls/mbedtls_config-2.h>"
else ifeq (${MBEDTLS_MAJOR}, 3)
ifeq (${PSA_CRYPTO},1)
MBEDTLS_CONFIG_FILE ?= "<drivers/auth/mbedtls/psa_mbedtls_config.h>"
diff --git a/plat/qemu/common/common.mk b/plat/qemu/common/common.mk
index 020dc1f..2dcac69 100644
--- a/plat/qemu/common/common.mk
+++ b/plat/qemu/common/common.mk
@@ -29,18 +29,6 @@
lib/cpus/aarch64/qemu_max.S
PLAT_INCLUDES += -Iinclude/plat/arm/common/${ARCH}
-
-# Cpu core architecture level:
-# v8.0: a53, a57, a72
-# v8.2: a55, a76, n1
-# v8.4: v1
-# v9.0: a710, n2
-#
-# let treat v9.0 as v8.5 as they share cpu features
-# https://developer.arm.com/documentation/102378/0201/Armv8-x-and-Armv9-x-extensions-and-features
-
-ARM_ARCH_MAJOR := 8
-ARM_ARCH_MINOR := 5
endif
PLAT_BL_COMMON_SOURCES := ${PLAT_QEMU_COMMON_PATH}/qemu_common.c \
@@ -91,7 +79,44 @@
# CPU flag enablement
ifeq (${ARCH},aarch64)
+# Cpu core architecture level:
+# v8.0: a53, a57, a72
+# v8.2: a55, a76, n1
+# v8.4: v1
+# v9.0: a710, n2
+#
+#
+# We go v8.0 by default and will enable all features we want
+
+ARM_ARCH_MAJOR := 8
+ARM_ARCH_MINOR := 0
+
+# 8.0
+ENABLE_FEAT_CSV2_2 := 2
+
+# 8.1
+ENABLE_FEAT_PAN := 2
+ENABLE_FEAT_VHE := 2
+
-# Later QEMU versions support SME and SVE.
+# 8.2
+# TF-A currently does not permit dynamic detection of FEAT_RAS
+# so this is the only safe setting
+ENABLE_FEAT_RAS := 0
+
+# 8.4
+ENABLE_FEAT_SEL2 := 2
+ENABLE_FEAT_DIT := 2
+
+# 8.5
+ENABLE_FEAT_RNG := 2
+ENABLE_FEAT_SB := 2
+
+# 8.6
+ENABLE_FEAT_FGT := 2
+
+# 8.7
+ENABLE_FEAT_HCX := 2
+
# SPM_MM is not compatible with ENABLE_SVE_FOR_NS (build breaks)
ifeq (${SPM_MM},1)
ENABLE_SVE_FOR_NS := 0
@@ -101,12 +126,6 @@
ENABLE_SME_FOR_NS := 2
endif
-# QEMU will use the RNDR instruction for the stack protector canary.
-ENABLE_FEAT_RNG := 2
-
-# QEMU 7.2+ has support for FGT and Linux needs it enabled to boot on max
-ENABLE_FEAT_FGT := 2
-
# Treating this as a memory-constrained port for now
USE_COHERENT_MEM := 0
