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, &param_ptr, &param_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