Merge "feat(morello): add cpuidle support" into integration
diff --git a/docs/threat_model/threat_model.rst b/docs/threat_model/threat_model.rst
index 71ec9b1..c50ed8e 100644
--- a/docs/threat_model/threat_model.rst
+++ b/docs/threat_model/threat_model.rst
@@ -7,10 +7,7 @@
This document provides a generic threat model for TF-A firmware.
-.. note::
-
- This threat model doesn't consider Root and Realm worlds introduced by
- :ref:`Realm Management Extension (RME)`.
+.. _Target of Evaluation:
********************
Target of Evaluation
@@ -36,33 +33,12 @@
- There is no Secure-EL2. We don't consider threats that may come with
Secure-EL2 software.
+- There are no Root and Realm worlds. These are introduced by :ref:`Realm
+ Management Extension (RME)`.
+
- No experimental features are enabled. We do not consider threats that may come
from them.
-.. note::
-
- In the current Measured Boot design, BL1, BL2, and BL31, as well as the
- secure world components, form the |SRTM|. Measurement data is currently
- considered an asset to be protected against attack, and this is achieved
- by storing them in the Secure Memory.
- Beyond the measurements stored inside the TCG-compliant Event Log buffer,
- there are no other assets to protect or threats to defend against that
- could compromise |TF-A| execution environment's security.
-
- There are general security assets and threats associated with remote/delegated
- attestation. However, these are outside the |TF-A| security boundary and
- should be dealt with by the appropriate agent in the platform/system.
- Since current Measured Boot design does not use local attestation, there would
- be no further assets to protect(like unsealed keys).
-
- A limitation of the current Measured Boot design is that it is dependent upon
- Secure Boot as implementation of Measured Boot does not extend measurements
- into a discrete |TPM|, where they would be securely stored and protected
- against tampering. This implies that if Secure-Boot is compromised, Measured
- Boot may also be compromised.
-
- Platforms must carefully evaluate the security of the default implementation
- since the |SRTM| includes all secure world components.
Data Flow Diagram
=================
@@ -286,201 +262,16 @@
Also, some mitigations require enabling specific features, which must be
explicitly turned on via a build flag.
-These are highlighted in the ``Mitigations implemented?`` box.
+When such conditions must be met, these are highlighted in the ``Mitigations
+implemented?`` box.
-+------------------------+----------------------------------------------------+
-| ID | 01 |
-+========================+====================================================+
-| Threat | | **An attacker can mangle firmware images to |
-| | execute arbitrary code** |
-| | |
-| | | Some TF-A images are loaded from external |
-| | storage. It is possible for an attacker to access|
-| | the external flash memory and change its contents|
-| | physically, through the Rich OS, or using the |
-| | updating mechanism to modify the non-volatile |
-| | images to execute arbitrary code. |
-+------------------------+----------------------------------------------------+
-| Diagram Elements | DF1, DF4, DF5 |
-+------------------------+----------------------------------------------------+
-| Affected TF-A | BL2, BL31 |
-| Components | |
-+------------------------+----------------------------------------------------+
-| Assets | Code Execution |
-+------------------------+----------------------------------------------------+
-| Threat Agent | PhysicalAccess, NSCode, SecCode |
-+------------------------+----------------------------------------------------+
-| Threat Type | Tampering, 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 | | 1) Implement the `Trusted Board Boot (TBB)`_ |
-| | feature which prevents malicious firmware from |
-| | running on the platform by authenticating all |
-| | firmware images. |
-| | |
-| | | 2) Perform extra checks on unauthenticated data, |
-| | such as FIP metadata, prior to use. |
-+------------------------+----------------------------------------------------+
-| Mitigations | | 1) Yes, provided that the ``TRUSTED_BOARD_BOOT`` |
-| implemented? | build option is set to 1. |
-| | |
-| | | 2) Yes. |
-+------------------------+----------------------------------------------------+
+As our :ref:`Target of Evaluation` is made of several, distinct firmware images,
+some threats are confined in specific images, while others apply to each of
+them. To help developers implement mitigations in the right place, threats below
+are categorized based on the firmware image that should mitigate them.
-+------------------------+----------------------------------------------------+
-| ID | 02 |
-+========================+====================================================+
-| Threat | | **An attacker may attempt to boot outdated, |
-| | potentially vulnerable firmware image** |
-| | |
-| | | When updating firmware, an attacker may attempt |
-| | to rollback to an older version that has unfixed |
-| | vulnerabilities. |
-+------------------------+----------------------------------------------------+
-| Diagram Elements | DF1, DF4, DF5 |
-+------------------------+----------------------------------------------------+
-| Affected TF-A | BL2, BL31 |
-| Components | |
-+------------------------+----------------------------------------------------+
-| Assets | Code Execution |
-+------------------------+----------------------------------------------------+
-| Threat Agent | PhysicalAccess, NSCode, SecCode |
-+------------------------+----------------------------------------------------+
-| Threat Type | Tampering |
-+------------------------+------------------+-----------------+---------------+
-| 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 | Implement anti-rollback protection using |
-| | non-volatile counters (NV counters) as required |
-| | by `TBBR-Client specification`_. |
-+------------------------+----------------------------------------------------+
-| Mitigations | | Yes / Platform specific. |
-| implemented? | |
-| | | After a firmware image is validated, the image |
-| | revision number taken from a certificate |
-| | extension field is compared with the |
-| | corresponding NV counter stored in hardware to |
-| | make sure the new counter value is larger than |
-| | the current counter value. |
-| | |
-| | | **Platforms must implement this protection using |
-| | platform specific hardware NV counters.** |
-+------------------------+----------------------------------------------------+
-
-+------------------------+-------------------------------------------------------+
-| ID | 03 |
-+========================+=======================================================+
-| Threat | | **An attacker can use Time-of-Check-Time-of-Use |
-| | (TOCTOU) attack to bypass image authentication |
-| | during the boot process** |
-| | |
-| | | Time-of-Check-Time-of-Use (TOCTOU) threats occur |
-| | when the security check is produced before the time |
-| | the resource is accessed. If an attacker is sitting |
-| | in the middle of the off-chip images, they could |
-| | change the binary containing executable code right |
-| | after the integrity and authentication check has |
-| | been performed. |
-+------------------------+-------------------------------------------------------+
-| Diagram Elements | DF1 |
-+------------------------+-------------------------------------------------------+
-| Affected TF-A | BL1, BL2 |
-| Components | |
-+------------------------+-------------------------------------------------------+
-| Assets | Code Execution, Sensitive Data |
-+------------------------+-------------------------------------------------------+
-| Threat Agent | PhysicalAccess |
-+------------------------+-------------------------------------------------------+
-| Threat Type | Elevation of Privilege |
-+------------------------+---------------------+-----------------+---------------+
-| Application | Server | IoT | Mobile |
-+------------------------+---------------------+-----------------+---------------+
-| Impact | N/A | Critical (5) | Critical (5) |
-+------------------------+---------------------+-----------------+---------------+
-| Likelihood | N/A | Medium (3) | Medium (3) |
-+------------------------+---------------------+-----------------+---------------+
-| Total Risk Rating | N/A | High (15) | High (15) |
-+------------------------+---------------------+-----------------+---------------+
-| Mitigations | Copy image to on-chip memory before authenticating |
-| | it. |
-+------------------------+-------------------------------------------------------+
-| Mitigations | | Platform specific. |
-| implemented? | |
-| | | The list of images to load and their location is |
-| | platform specific. Platforms are responsible for |
-| | arranging images to be loaded in on-chip memory. |
-+------------------------+-------------------------------------------------------+
-
-+------------------------+-------------------------------------------------------+
-| ID | 04 |
-+========================+=======================================================+
-| Threat | | **An attacker with physical access can execute |
-| | arbitrary image by bypassing the signature |
-| | verification stage using glitching techniques** |
-| | |
-| | | Glitching (Fault injection) attacks attempt to put |
-| | a hardware into a undefined state by manipulating an|
-| | environmental variable such as power supply. |
-| | |
-| | | TF-A relies on a chain of trust that starts with the|
-| | ROTPK, which is the key stored inside the chip and |
-| | the root of all validation processes. If an attacker|
-| | can break this chain of trust, they could execute |
-| | arbitrary code on the device. This could be |
-| | achieved with physical access to the device by |
-| | attacking the normal execution flow of the |
-| | process using glitching techniques that target |
-| | points where the image is validated against the |
-| | signature. |
-+------------------------+-------------------------------------------------------+
-| Diagram Elements | DF1 |
-+------------------------+-------------------------------------------------------+
-| Affected TF-A | BL1, BL2 |
-| Components | |
-+------------------------+-------------------------------------------------------+
-| Assets | Code Execution |
-+------------------------+-------------------------------------------------------+
-| Threat Agent | PhysicalAccess |
-+------------------------+-------------------------------------------------------+
-| Threat Type | Tampering, Elevation of Privilege |
-+------------------------+---------------------+-----------------+---------------+
-| Application | Server | IoT | Mobile |
-+------------------------+---------------------+-----------------+---------------+
-| Impact | N/A | Critical (5) | Critical (5) |
-+------------------------+---------------------+-----------------+---------------+
-| Likelihood | N/A | Medium (3) | Medium (3) |
-+------------------------+---------------------+-----------------+---------------+
-| Total Risk Rating | N/A | High (15) | High (15) |
-+------------------------+---------------------+-----------------+---------------+
-| Mitigations | Mechanisms to detect clock glitch and power |
-| | variations. |
-+------------------------+-------------------------------------------------------+
-| Mitigations | | No. |
-| implemented? | |
-| | | The most effective mitigation is adding glitching |
-| | detection and mitigation circuit at the hardware |
-| | level. |
-| | |
-| | | However, software techniques, such as adding |
-| | redundant checks when performing conditional |
-| | branches that are security sensitive, can be used |
-| | to harden TF-A against such attacks. |
-| | **At the moment TF-A doesn't implement such |
-| | mitigations.** |
-+------------------------+-------------------------------------------------------+
+General Threats for All Firmware Images
+---------------------------------------
+------------------------+---------------------------------------------------+
| ID | 05 |
@@ -598,49 +389,6 @@
+------------------------+----------------------------------------------------+
+------------------------+------------------------------------------------------+
-| ID | 07 |
-+========================+======================================================+
-| Threat | | **An attacker can perform a denial-of-service |
-| | attack by using a broken SMC call that causes the |
-| | system to reboot or enter into unknown state.** |
-| | |
-| | | Secure and non-secure clients access TF-A services |
-| | through SMC calls. Malicious code can attempt to |
-| | place the TF-A runtime into an inconsistent state |
-| | by calling unimplemented SMC call or by passing |
-| | invalid arguments. |
-+------------------------+------------------------------------------------------+
-| Diagram Elements | DF4, DF5 |
-+------------------------+------------------------------------------------------+
-| Affected TF-A | BL31 |
-| Components | |
-+------------------------+------------------------------------------------------+
-| Assets | Availability |
-+------------------------+------------------------------------------------------+
-| Threat Agent | NSCode, SecCode |
-+------------------------+------------------------------------------------------+
-| Threat Type | Denial of Service |
-+------------------------+-------------------+----------------+-----------------+
-| Application | Server | IoT | Mobile |
-+------------------------+-------------------+----------------+-----------------+
-| Impact | Medium (3) | Medium (3) | Medium (3) |
-+------------------------+-------------------+----------------+-----------------+
-| Likelihood | High (4) | High (4) | High (4) |
-+------------------------+-------------------+----------------+-----------------+
-| Total Risk Rating | High (12) | High (12) | High (12) |
-+------------------------+-------------------+----------------+-----------------+
-| Mitigations | Validate SMC function ids and arguments before using |
-| | them. |
-+------------------------+------------------------------------------------------+
-| Mitigations | | Yes / Platform specific. |
-| implemented? | |
-| | | For standard services, all input is validated. |
-| | |
-| | | Platforms that implement SiP services must also |
-| | validate SMC call arguments. |
-+------------------------+------------------------------------------------------+
-
-+------------------------+------------------------------------------------------+
| ID | 08 |
+========================+======================================================+
| Threat | | **Memory corruption due to memory overflows and |
@@ -712,6 +460,380 @@
| | platforms. |
+------------------------+------------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 11 |
++========================+====================================================+
+| Threat | | **Misconfiguration of the Memory Management Unit |
+| | (MMU) may allow a normal world software to |
+| | access sensitive data, execute arbitrary |
+| | code or access otherwise restricted HW |
+| | interface** |
+| | |
+| | | A misconfiguration of the MMU could |
+| | lead to an open door for software running in the |
+| | normal world to access sensitive data or even |
+| | execute code if the proper security mechanisms |
+| | are not in place. |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF5, DF6 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | BL1, BL2, BL31 |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | Sensitive Data, Code execution |
++------------------------+----------------------------------------------------+
+| Threat Agent | NSCode |
++------------------------+----------------------------------------------------+
+| Threat Type | Information Disclosure, Elevation of Privilege |
++------------------------+-----------------+-----------------+----------------+
+| Application | Server | IoT | Mobile |
++------------------------+-----------------+-----------------+----------------+
+| Impact | Critical (5) | Critical (5) | Critical (5) |
++------------------------+-----------------+-----------------+----------------+
+| Likelihood | High (4) | High (4) | High (4) |
++------------------------+-----------------+-----------------+----------------+
+| Total Risk Rating | Critical (20) | Critical (20) | Critical (20) |
++------------------------+-----------------+-----------------+----------------+
+| Mitigations | When configuring access permissions, the |
+| | principle of least privilege ought to be |
+| | enforced. This means we should not grant more |
+| | privileges than strictly needed, e.g. code |
+| | should be read-only executable, read-only data |
+| | should be read-only execute-never, and so on. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | MMU configuration is platform specific, |
+| | therefore platforms need to make sure that the |
+| | correct attributes are assigned to memory |
+| | regions. |
+| | |
+| | | TF-A provides a library which abstracts the |
+| | low-level details of MMU configuration. It |
+| | provides well-defined and tested APIs. |
+| | Platforms are encouraged to use it to limit the |
+| | risk of misconfiguration. |
++------------------------+----------------------------------------------------+
+
+
++------------------------+-----------------------------------------------------+
+| ID | 13 |
++========================+=====================================================+
+| Threat | | **Leaving sensitive information in the memory, |
+| | can allow an attacker to retrieve them.** |
+| | |
+| | | Accidentally leaving not-needed sensitive data in |
+| | internal buffers can leak them if an attacker |
+| | gains access to memory due to a vulnerability. |
++------------------------+-----------------------------------------------------+
+| Diagram Elements | DF4, DF5 |
++------------------------+-----------------------------------------------------+
+| Affected TF-A | BL1, BL2, BL31 |
+| Components | |
++------------------------+-----------------------------------------------------+
+| Assets | Sensitive Data |
++------------------------+-----------------------------------------------------+
+| Threat Agent | NSCode, SecCode |
++------------------------+-----------------------------------------------------+
+| Threat Type | Information Disclosure |
++------------------------+-------------------+----------------+----------------+
+| Application | Server | IoT | Mobile |
++------------------------+-------------------+----------------+----------------+
+| Impact | Critical (5) | Critical (5) | Critical (5) |
++------------------------+-------------------+----------------+----------------+
+| Likelihood | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| Total Risk Rating | High (15) | High (15) | High (15) |
++------------------------+-------------------+----------------+----------------+
+| Mitigations | Clear the sensitive data from internal buffers as |
+| | soon as they are not needed anymore. |
++------------------------+-----------------------------------------------------+
+| Mitigations | | Yes / Platform specific |
++------------------------+-----------------------------------------------------+
+
+
+Threats to be Mitigated by the Boot Firmware
+--------------------------------------------
+
+The boot firmware here refers to the boot ROM (BL1) and the trusted boot
+firmware (BL2). Typically it does not stay resident in memory and it is
+dismissed once execution has reached the runtime EL3 firmware (BL31). Thus, past
+that point in time, the threats below can no longer be exploited.
+
+Note, however, that this is not necessarily true on all platforms. Platform
+vendors should review these threats to make sure they cannot be exploited
+nonetheless once execution has reached the runtime EL3 firmware.
+
++------------------------+----------------------------------------------------+
+| ID | 01 |
++========================+====================================================+
+| Threat | | **An attacker can mangle firmware images to |
+| | execute arbitrary code** |
+| | |
+| | | Some TF-A images are loaded from external |
+| | storage. It is possible for an attacker to access|
+| | the external flash memory and change its contents|
+| | physically, through the Rich OS, or using the |
+| | updating mechanism to modify the non-volatile |
+| | images to execute arbitrary code. |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF4, DF5 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | BL2, BL31 |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | Code Execution |
++------------------------+----------------------------------------------------+
+| Threat Agent | PhysicalAccess, NSCode, SecCode |
++------------------------+----------------------------------------------------+
+| Threat Type | Tampering, 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 | | 1) Implement the `Trusted Board Boot (TBB)`_ |
+| | feature which prevents malicious firmware from |
+| | running on the platform by authenticating all |
+| | firmware images. |
+| | |
+| | | 2) Perform extra checks on unauthenticated data, |
+| | such as FIP metadata, prior to use. |
++------------------------+----------------------------------------------------+
+| Mitigations | | 1) Yes, provided that the ``TRUSTED_BOARD_BOOT`` |
+| implemented? | build option is set to 1. |
+| | |
+| | | 2) Yes. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 02 |
++========================+====================================================+
+| Threat | | **An attacker may attempt to boot outdated, |
+| | potentially vulnerable firmware image** |
+| | |
+| | | When updating firmware, an attacker may attempt |
+| | to rollback to an older version that has unfixed |
+| | vulnerabilities. |
++------------------------+----------------------------------------------------+
+| Diagram Elements | DF1, DF4, DF5 |
++------------------------+----------------------------------------------------+
+| Affected TF-A | BL2, BL31 |
+| Components | |
++------------------------+----------------------------------------------------+
+| Assets | Code Execution |
++------------------------+----------------------------------------------------+
+| Threat Agent | PhysicalAccess, NSCode, SecCode |
++------------------------+----------------------------------------------------+
+| Threat Type | Tampering |
++------------------------+------------------+-----------------+---------------+
+| 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 | Implement anti-rollback protection using |
+| | non-volatile counters (NV counters) as required |
+| | by `TBBR-Client specification`_. |
++------------------------+----------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | After a firmware image is validated, the image |
+| | revision number taken from a certificate |
+| | extension field is compared with the |
+| | corresponding NV counter stored in hardware to |
+| | make sure the new counter value is larger than |
+| | the current counter value. |
+| | |
+| | | **Platforms must implement this protection using |
+| | platform specific hardware NV counters.** |
++------------------------+----------------------------------------------------+
+
+
++------------------------+-------------------------------------------------------+
+| ID | 03 |
++========================+=======================================================+
+| Threat | | **An attacker can use Time-of-Check-Time-of-Use |
+| | (TOCTOU) attack to bypass image authentication |
+| | during the boot process** |
+| | |
+| | | Time-of-Check-Time-of-Use (TOCTOU) threats occur |
+| | when the security check is produced before the time |
+| | the resource is accessed. If an attacker is sitting |
+| | in the middle of the off-chip images, they could |
+| | change the binary containing executable code right |
+| | after the integrity and authentication check has |
+| | been performed. |
++------------------------+-------------------------------------------------------+
+| Diagram Elements | DF1 |
++------------------------+-------------------------------------------------------+
+| Affected TF-A | BL1, BL2 |
+| Components | |
++------------------------+-------------------------------------------------------+
+| Assets | Code Execution, Sensitive Data |
++------------------------+-------------------------------------------------------+
+| Threat Agent | PhysicalAccess |
++------------------------+-------------------------------------------------------+
+| Threat Type | Elevation of Privilege |
++------------------------+---------------------+-----------------+---------------+
+| Application | Server | IoT | Mobile |
++------------------------+---------------------+-----------------+---------------+
+| Impact | N/A | Critical (5) | Critical (5) |
++------------------------+---------------------+-----------------+---------------+
+| Likelihood | N/A | Medium (3) | Medium (3) |
++------------------------+---------------------+-----------------+---------------+
+| Total Risk Rating | N/A | High (15) | High (15) |
++------------------------+---------------------+-----------------+---------------+
+| Mitigations | Copy image to on-chip memory before authenticating |
+| | it. |
++------------------------+-------------------------------------------------------+
+| Mitigations | | Platform specific. |
+| implemented? | |
+| | | The list of images to load and their location is |
+| | platform specific. Platforms are responsible for |
+| | arranging images to be loaded in on-chip memory. |
++------------------------+-------------------------------------------------------+
+
+
++------------------------+-------------------------------------------------------+
+| ID | 04 |
++========================+=======================================================+
+| Threat | | **An attacker with physical access can execute |
+| | arbitrary image by bypassing the signature |
+| | verification stage using glitching techniques** |
+| | |
+| | | Glitching (Fault injection) attacks attempt to put |
+| | a hardware into a undefined state by manipulating an|
+| | environmental variable such as power supply. |
+| | |
+| | | TF-A relies on a chain of trust that starts with the|
+| | ROTPK, which is the key stored inside the chip and |
+| | the root of all validation processes. If an attacker|
+| | can break this chain of trust, they could execute |
+| | arbitrary code on the device. This could be |
+| | achieved with physical access to the device by |
+| | attacking the normal execution flow of the |
+| | process using glitching techniques that target |
+| | points where the image is validated against the |
+| | signature. |
++------------------------+-------------------------------------------------------+
+| Diagram Elements | DF1 |
++------------------------+-------------------------------------------------------+
+| Affected TF-A | BL1, BL2 |
+| Components | |
++------------------------+-------------------------------------------------------+
+| Assets | Code Execution |
++------------------------+-------------------------------------------------------+
+| Threat Agent | PhysicalAccess |
++------------------------+-------------------------------------------------------+
+| Threat Type | Tampering, Elevation of Privilege |
++------------------------+---------------------+-----------------+---------------+
+| Application | Server | IoT | Mobile |
++------------------------+---------------------+-----------------+---------------+
+| Impact | N/A | Critical (5) | Critical (5) |
++------------------------+---------------------+-----------------+---------------+
+| Likelihood | N/A | Medium (3) | Medium (3) |
++------------------------+---------------------+-----------------+---------------+
+| Total Risk Rating | N/A | High (15) | High (15) |
++------------------------+---------------------+-----------------+---------------+
+| Mitigations | Mechanisms to detect clock glitch and power |
+| | variations. |
++------------------------+-------------------------------------------------------+
+| Mitigations | | No. |
+| implemented? | |
+| | | The most effective mitigation is adding glitching |
+| | detection and mitigation circuit at the hardware |
+| | level. |
+| | |
+| | | However, software techniques, such as adding |
+| | redundant checks when performing conditional |
+| | branches that are security sensitive, can be used |
+| | to harden TF-A against such attacks. |
+| | **At the moment TF-A doesn't implement such |
+| | mitigations.** |
++------------------------+-------------------------------------------------------+
+
+.. topic:: Measured Boot Threats (or lack of)
+
+ In the current Measured Boot design, BL1, BL2, and BL31, as well as the
+ secure world components, form the |SRTM|. Measurement data is currently
+ considered an asset to be protected against attack, and this is achieved
+ by storing them in the Secure Memory.
+ Beyond the measurements stored inside the TCG-compliant Event Log buffer,
+ there are no other assets to protect or threats to defend against that
+ could compromise |TF-A| execution environment's security.
+
+ There are general security assets and threats associated with remote/delegated
+ attestation. However, these are outside the |TF-A| security boundary and
+ should be dealt with by the appropriate agent in the platform/system.
+ Since current Measured Boot design does not use local attestation, there would
+ be no further assets to protect(like unsealed keys).
+
+ A limitation of the current Measured Boot design is that it is dependent upon
+ Secure Boot as implementation of Measured Boot does not extend measurements
+ into a discrete |TPM|, where they would be securely stored and protected
+ against tampering. This implies that if Secure-Boot is compromised, Measured
+ Boot may also be compromised.
+
+ Platforms must carefully evaluate the security of the default implementation
+ since the |SRTM| includes all secure world components.
+
+
+Threats to be Mitigated by the Runtime EL3 Firmware
+---------------------------------------------------
+
++------------------------+------------------------------------------------------+
+| ID | 07 |
++========================+======================================================+
+| Threat | | **An attacker can perform a denial-of-service |
+| | attack by using a broken SMC call that causes the |
+| | system to reboot or enter into unknown state.** |
+| | |
+| | | Secure and non-secure clients access TF-A services |
+| | through SMC calls. Malicious code can attempt to |
+| | place the TF-A runtime into an inconsistent state |
+| | by calling unimplemented SMC call or by passing |
+| | invalid arguments. |
++------------------------+------------------------------------------------------+
+| Diagram Elements | DF4, DF5 |
++------------------------+------------------------------------------------------+
+| Affected TF-A | BL31 |
+| Components | |
++------------------------+------------------------------------------------------+
+| Assets | Availability |
++------------------------+------------------------------------------------------+
+| Threat Agent | NSCode, SecCode |
++------------------------+------------------------------------------------------+
+| Threat Type | Denial of Service |
++------------------------+-------------------+----------------+-----------------+
+| Application | Server | IoT | Mobile |
++------------------------+-------------------+----------------+-----------------+
+| Impact | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+-----------------+
+| Likelihood | High (4) | High (4) | High (4) |
++------------------------+-------------------+----------------+-----------------+
+| Total Risk Rating | High (12) | High (12) | High (12) |
++------------------------+-------------------+----------------+-----------------+
+| Mitigations | Validate SMC function ids and arguments before using |
+| | them. |
++------------------------+------------------------------------------------------+
+| Mitigations | | Yes / Platform specific. |
+| implemented? | |
+| | | For standard services, all input is validated. |
+| | |
+| | | Platforms that implement SiP services must also |
+| | validate SMC call arguments. |
++------------------------+------------------------------------------------------+
+
+
+------------------------+------------------------------------------------------+
| ID | 09 |
+========================+======================================================+
@@ -795,60 +917,6 @@
| | attacks. |
+------------------------+-----------------------------------------------------+
-+------------------------+----------------------------------------------------+
-| ID | 11 |
-+========================+====================================================+
-| Threat | | **Misconfiguration of the Memory Management Unit |
-| | (MMU) may allow a normal world software to |
-| | access sensitive data, execute arbitrary |
-| | code or access otherwise restricted HW |
-| | interface** |
-| | |
-| | | A misconfiguration of the MMU could |
-| | lead to an open door for software running in the |
-| | normal world to access sensitive data or even |
-| | execute code if the proper security mechanisms |
-| | are not in place. |
-+------------------------+----------------------------------------------------+
-| Diagram Elements | DF5, DF6 |
-+------------------------+----------------------------------------------------+
-| Affected TF-A | BL1, BL2, BL31 |
-| Components | |
-+------------------------+----------------------------------------------------+
-| Assets | Sensitive Data, Code execution |
-+------------------------+----------------------------------------------------+
-| Threat Agent | NSCode |
-+------------------------+----------------------------------------------------+
-| Threat Type | Information Disclosure, Elevation of Privilege |
-+------------------------+-----------------+-----------------+----------------+
-| Application | Server | IoT | Mobile |
-+------------------------+-----------------+-----------------+----------------+
-| Impact | Critical (5) | Critical (5) | Critical (5) |
-+------------------------+-----------------+-----------------+----------------+
-| Likelihood | High (4) | High (4) | High (4) |
-+------------------------+-----------------+-----------------+----------------+
-| Total Risk Rating | Critical (20) | Critical (20) | Critical (20) |
-+------------------------+-----------------+-----------------+----------------+
-| Mitigations | When configuring access permissions, the |
-| | principle of least privilege ought to be |
-| | enforced. This means we should not grant more |
-| | privileges than strictly needed, e.g. code |
-| | should be read-only executable, read-only data |
-| | should be read-only execute-never, and so on. |
-+------------------------+----------------------------------------------------+
-| Mitigations | | Platform specific. |
-| implemented? | |
-| | | MMU configuration is platform specific, |
-| | therefore platforms need to make sure that the |
-| | correct attributes are assigned to memory |
-| | regions. |
-| | |
-| | | TF-A provides a library which abstracts the |
-| | low-level details of MMU configuration. It |
-| | provides well-defined and tested APIs. |
-| | Platforms are encouraged to use it to limit the |
-| | risk of misconfiguration. |
-+------------------------+----------------------------------------------------+
+------------------------+-----------------------------------------------------+
| ID | 12 |
@@ -905,40 +973,9 @@
| | mitigated. |
+------------------------+-----------------------------------------------------+
-+------------------------+-----------------------------------------------------+
-| ID | 13 |
-+========================+=====================================================+
-| Threat | | **Leaving sensitive information in the memory, |
-| | can allow an attacker to retrieve them.** |
-| | |
-| | | Accidentally leaving not-needed sensitive data in |
-| | internal buffers can leak them if an attacker |
-| | gains access to memory due to a vulnerability. |
-+------------------------+-----------------------------------------------------+
-| Diagram Elements | DF4, DF5 |
-+------------------------+-----------------------------------------------------+
-| Affected TF-A | BL1, BL2, BL31 |
-| Components | |
-+------------------------+-----------------------------------------------------+
-| Assets | Sensitive Data |
-+------------------------+-----------------------------------------------------+
-| Threat Agent | NSCode, SecCode |
-+------------------------+-----------------------------------------------------+
-| Threat Type | Information Disclosure |
-+------------------------+-------------------+----------------+----------------+
-| Application | Server | IoT | Mobile |
-+------------------------+-------------------+----------------+----------------+
-| Impact | Critical (5) | Critical (5) | Critical (5) |
-+------------------------+-------------------+----------------+----------------+
-| Likelihood | Medium (3) | Medium (3) | Medium (3) |
-+------------------------+-------------------+----------------+----------------+
-| Total Risk Rating | High (15) | High (15) | High (15) |
-+------------------------+-------------------+----------------+----------------+
-| Mitigations | Clear the sensitive data from internal buffers as |
-| | soon as they are not needed anymore. |
-+------------------------+-----------------------------------------------------+
-| Mitigations | | Yes / Platform specific |
-+------------------------+-----------------------------------------------------+
+
+Threats to be Mitigated by an External Agent Outside of TF-A
+------------------------------------------------------------
+------------------------+-----------------------------------------------------+
| ID | 14 |
diff --git a/drivers/scmi-msg/clock.c b/drivers/scmi-msg/clock.c
index 98fdc6a..5aaf68c 100644
--- a/drivers/scmi-msg/clock.c
+++ b/drivers/scmi-msg/clock.c
@@ -37,7 +37,8 @@
int32_t plat_scmi_clock_rates_array(unsigned int agent_id __unused,
unsigned int scmi_id __unused,
unsigned long *rates __unused,
- size_t *nb_elts __unused)
+ size_t *nb_elts __unused,
+ uint32_t start_idx __unused)
{
return SCMI_NOT_SUPPORTED;
}
@@ -298,7 +299,7 @@
/* Platform may support array rate description */
status = plat_scmi_clock_rates_array(msg->agent_id, clock_id, NULL,
- &nb_rates);
+ &nb_rates, 0);
if (status == SCMI_SUCCESS) {
/* Currently 12 cells mex, so it's affordable for the stack */
unsigned long plat_rates[RATES_ARRAY_SIZE_MAX / RATE_DESC_SIZE];
@@ -307,7 +308,8 @@
size_t rem_nb = nb_rates - in_args->rate_index - ret_nb;
status = plat_scmi_clock_rates_array(msg->agent_id, clock_id,
- plat_rates, &ret_nb);
+ plat_rates, &ret_nb,
+ in_args->rate_index);
if (status == SCMI_SUCCESS) {
write_rate_desc_array_in_buffer(msg->out + sizeof(p2a),
plat_rates, ret_nb);
diff --git a/include/drivers/scmi-msg.h b/include/drivers/scmi-msg.h
index eb90859..c93c455 100644
--- a/include/drivers/scmi-msg.h
+++ b/include/drivers/scmi-msg.h
@@ -113,10 +113,12 @@
* @scmi_id: SCMI clock ID
* @rates: If NULL, function returns, else output rates array
* @nb_elts: Array size of @rates.
+ * @start_idx: Start index of rates array
* Return an SCMI compliant error code
*/
int32_t plat_scmi_clock_rates_array(unsigned int agent_id, unsigned int scmi_id,
- unsigned long *rates, size_t *nb_elts);
+ unsigned long *rates, size_t *nb_elts,
+ uint32_t start_idx);
/*
* Get clock possible rate as range with regular steps in Hertz
diff --git a/plat/arm/board/arm_fpga/platform.mk b/plat/arm/board/arm_fpga/platform.mk
index c31697e..bd56f30 100644
--- a/plat/arm/board/arm_fpga/platform.mk
+++ b/plat/arm/board/arm_fpga/platform.mk
@@ -33,7 +33,17 @@
FPGA_PRELOADED_CMD_LINE := 0x1000
$(eval $(call add_define,FPGA_PRELOADED_CMD_LINE))
-ENABLE_FEAT_AMU := 2
+ENABLE_BRBE_FOR_NS := 2
+ENABLE_TRBE_FOR_NS := 2
+ENABLE_FEAT_AMU := 2
+ENABLE_FEAT_AMUv1p1 := 2
+ENABLE_FEAT_CSV2_2 := 2
+ENABLE_FEAT_ECV := 2
+ENABLE_FEAT_FGT := 2
+ENABLE_FEAT_HCX := 2
+ENABLE_MPAM_FOR_LOWER_ELS := 2
+ENABLE_SYS_REG_TRACE_FOR_NS := 2
+ENABLE_TRF_FOR_NS := 2
# Treating this as a memory-constrained port for now
USE_COHERENT_MEM := 0
diff --git a/plat/imx/imx8m/ddr/clock.c b/plat/imx/imx8m/ddr/clock.c
index 8b132d2..31f2f56 100644
--- a/plat/imx/imx8m/ddr/clock.c
+++ b/plat/imx/imx8m/ddr/clock.c
@@ -91,6 +91,10 @@
case 4000:
mmio_write_32(DRAM_PLL_CTRL + 0x4, (250 << 12) | (3 << 4) | 1);
break;
+ case 3733:
+ case 3732:
+ mmio_write_32(DRAM_PLL_CTRL + 0x4, (311 << 12) | (4 << 4) | 1);
+ break;
case 3200:
mmio_write_32(DRAM_PLL_CTRL + 0x4, (200 << 12) | (3 << 4) | 1);
break;
diff --git a/plat/imx/imx8m/ddr/dram_retention.c b/plat/imx/imx8m/ddr/dram_retention.c
index 983f6e2..d98a37e 100644
--- a/plat/imx/imx8m/ddr/dram_retention.c
+++ b/plat/imx/imx8m/ddr/dram_retention.c
@@ -8,14 +8,12 @@
#include <lib/mmio.h>
#include <dram.h>
+#include <gpc_reg.h>
#include <platform_def.h>
#define SRC_DDR1_RCR (IMX_SRC_BASE + 0x1000)
#define SRC_DDR2_RCR (IMX_SRC_BASE + 0x1004)
-#define PU_PGC_UP_TRG 0xf8
-#define PU_PGC_DN_TRG 0x104
-#define GPC_PU_PWRHSK (IMX_GPC_BASE + 0x01FC)
#define CCM_SRC_CTRL_OFFSET (IMX_CCM_BASE + 0x800)
#define CCM_CCGR_OFFSET (IMX_CCM_BASE + 0x4000)
#define CCM_TARGET_ROOT_OFFSET (IMX_CCM_BASE + 0x8000)
@@ -102,21 +100,12 @@
}
dwc_ddrphy_apb_wr(0xd0000, 0x1);
-#if defined(PLAT_imx8mq)
/* pwrdnreqn_async adbm/adbs of ddr */
- mmio_clrbits_32(GPC_PU_PWRHSK, BIT(1));
- while (mmio_read_32(GPC_PU_PWRHSK) & BIT(18)) {
+ mmio_clrbits_32(IMX_GPC_BASE + GPC_PU_PWRHSK, DDRMIX_ADB400_SYNC);
+ while (mmio_read_32(IMX_GPC_BASE + GPC_PU_PWRHSK) & DDRMIX_ADB400_ACK)
;
- }
- mmio_setbits_32(GPC_PU_PWRHSK, BIT(1));
-#else
- /* pwrdnreqn_async adbm/adbs of ddr */
- mmio_clrbits_32(GPC_PU_PWRHSK, BIT(2));
- while (mmio_read_32(GPC_PU_PWRHSK) & BIT(20)) {
- ;
- }
- mmio_setbits_32(GPC_PU_PWRHSK, BIT(2));
-#endif
+ mmio_setbits_32(IMX_GPC_BASE + GPC_PU_PWRHSK, DDRMIX_ADB400_SYNC);
+
/* remove PowerOk */
mmio_write_32(SRC_DDR1_RCR, 0x8F000008);
@@ -124,8 +113,8 @@
mmio_write_32(CCM_SRC_CTRL(15), 2);
/* enable the phy iso */
- mmio_setbits_32(IMX_GPC_BASE + 0xd40, 1);
- mmio_setbits_32(IMX_GPC_BASE + PU_PGC_DN_TRG, BIT(5));
+ mmio_setbits_32(IMX_GPC_BASE + DDRMIX_PGC, 1);
+ mmio_setbits_32(IMX_GPC_BASE + PU_PGC_DN_TRG, DDRMIX_PWR_REQ);
VERBOSE("dram enter retention\n");
}
@@ -150,7 +139,7 @@
mmio_write_32(CCM_TARGET_ROOT(65) + 0x4, (0x4 << 24) | (0x3 << 16));
/* disable iso */
- mmio_setbits_32(IMX_GPC_BASE + PU_PGC_UP_TRG, BIT(5));
+ mmio_setbits_32(IMX_GPC_BASE + PU_PGC_UP_TRG, DDRMIX_PWR_REQ);
mmio_write_32(SRC_DDR1_RCR, 0x8F000006);
/* wait dram pll locked */
diff --git a/plat/imx/imx8m/imx8mm/gpc.c b/plat/imx/imx8m/imx8mm/gpc.c
index e0e38a9..f173a16 100644
--- a/plat/imx/imx8m/imx8mm/gpc.c
+++ b/plat/imx/imx8m/imx8mm/gpc.c
@@ -19,46 +19,7 @@
#include <gpc.h>
#include <imx_sip_svc.h>
-#define MIPI_PWR_REQ BIT(0)
-#define PCIE_PWR_REQ BIT(1)
-#define OTG1_PWR_REQ BIT(2)
-#define OTG2_PWR_REQ BIT(3)
-#define HSIOMIX_PWR_REQ BIT(4)
-#define GPU2D_PWR_REQ BIT(6)
-#define GPUMIX_PWR_REQ BIT(7)
-#define VPUMIX_PWR_REQ BIT(8)
-#define GPU3D_PWR_REQ BIT(9)
-#define DISPMIX_PWR_REQ BIT(10)
-#define VPU_G1_PWR_REQ BIT(11)
-#define VPU_G2_PWR_REQ BIT(12)
-#define VPU_H1_PWR_REQ BIT(13)
-
-#define HSIOMIX_ADB400_SYNC (0x3 << 5)
-#define DISPMIX_ADB400_SYNC BIT(7)
-#define VPUMIX_ADB400_SYNC BIT(8)
-#define GPU3D_ADB400_SYNC BIT(9)
-#define GPU2D_ADB400_SYNC BIT(10)
-#define GPUMIX_ADB400_SYNC BIT(11)
-#define HSIOMIX_ADB400_ACK (0x3 << 23)
-#define DISPMIX_ADB400_ACK BIT(25)
-#define VPUMIX_ADB400_ACK BIT(26)
-#define GPU3D_ADB400_ACK BIT(27)
-#define GPU2D_ADB400_ACK BIT(28)
-#define GPUMIX_ADB400_ACK BIT(29)
-
-#define MIPI_PGC 0xc00
-#define PCIE_PGC 0xc40
-#define OTG1_PGC 0xc80
-#define OTG2_PGC 0xcc0
-#define HSIOMIX_PGC 0xd00
-#define GPU2D_PGC 0xd80
-#define GPUMIX_PGC 0xdc0
-#define VPUMIX_PGC 0xe00
-#define GPU3D_PGC 0xe40
-#define DISPMIX_PGC 0xe80
-#define VPU_G1_PGC 0xec0
-#define VPU_G2_PGC 0xf00
-#define VPU_H1_PGC 0xf40
+#define CCGR(x) (0x4000 + (x) * 16)
enum pu_domain_id {
HSIOMIX,
diff --git a/plat/st/stm32mp1/stm32mp1_scmi.c b/plat/st/stm32mp1/stm32mp1_scmi.c
index 98585dc..625d01a 100644
--- a/plat/st/stm32mp1/stm32mp1_scmi.c
+++ b/plat/st/stm32mp1/stm32mp1_scmi.c
@@ -260,7 +260,8 @@
}
int32_t plat_scmi_clock_rates_array(unsigned int agent_id, unsigned int scmi_id,
- unsigned long *array, size_t *nb_elts)
+ unsigned long *array, size_t *nb_elts,
+ uint32_t start_idx)
{
struct stm32_scmi_clk *clock = find_clock(agent_id, scmi_id);
@@ -272,6 +273,10 @@
return SCMI_DENIED;
}
+ if (start_idx > 0) {
+ return SCMI_OUT_OF_RANGE;
+ }
+
if (array == NULL) {
*nb_elts = 1U;
} else if (*nb_elts == 1U) {