Merge "docs: update list of supported FVP platforms" into integration
diff --git a/commitlint.config.js b/commitlint.config.js
index b7c1e5a..94cad8f 100644
--- a/commitlint.config.js
+++ b/commitlint.config.js
@@ -9,6 +9,6 @@
rules: {
"header-max-length": [1, "always", config.maxHeaderWidth], /* Warning */
"body-max-line-length": [1, "always", config.maxLineWidth], /* Warning */
- "signed-off-by": [2, "always", "Signed-off-by:"] /* Error */
+ "signed-off-by": [0, "always", "Signed-off-by:"] /* Disabled - buggy */
}
};
diff --git a/docs/_static/css/custom.css b/docs/_static/css/custom.css
new file mode 100644
index 0000000..f6f5fa0
--- /dev/null
+++ b/docs/_static/css/custom.css
@@ -0,0 +1,15 @@
+/*
+ * Copyright (c) 2021, Arm Limited. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+/*
+ * Set the white-space property of tables to normal.
+ * With this setting sequences of whitespace inside
+ * a table will collapse into a single whitespace,
+ * and text will wrap when necessary.
+ */
+.wy-table-responsive table td {
+white-space: normal;
+}
diff --git a/docs/about/features.rst b/docs/about/features.rst
index 964cb25..f5fc1e0 100644
--- a/docs/about/features.rst
+++ b/docs/about/features.rst
@@ -108,7 +108,7 @@
- Refinements to Position Independent Executable (PIE) support.
-- Continued support for the PSA FF-A v1.0 (formally known as SPCI) specification, to enable the
+- Continued support for the FF-A v1.0 (formally known as SPCI) specification, to enable the
use of secure partition management in the secure world.
- Documentation enhancements.
@@ -126,4 +126,4 @@
--------------
-*Copyright (c) 2019-2020, Arm Limited. All rights reserved.*
+*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
diff --git a/docs/components/psa-ffa-manifest-binding.rst b/docs/components/ffa-manifest-binding.rst
similarity index 97%
rename from docs/components/psa-ffa-manifest-binding.rst
rename to docs/components/ffa-manifest-binding.rst
index 4ec3faa..9e3919d 100644
--- a/docs/components/psa-ffa-manifest-binding.rst
+++ b/docs/components/ffa-manifest-binding.rst
@@ -1,8 +1,8 @@
-PSA FF-A manifest binding to device tree
+FF-A manifest binding to device tree
========================================
This document defines the nodes and properties used to define a partition,
-according to the PSA FF-A specification.
+according to the FF-A specification.
Version 1.0
-----------
@@ -25,9 +25,9 @@
- Must be two 16 bits values (X, Y), concatenated as 31:16 -> X,
15:0 -> Y, where:
- - X is the major version of PSA-FF-A expected by the partition at the FFA
+ - X is the major version of FF-A expected by the partition at the FFA
instance it will execute.
- - Y is the minor version of PSA-FF-A expected by the partition at the FFA
+ - Y is the minor version of FF-A expected by the partition at the FFA
instance it will execute.
- uuid [mandatory]
diff --git a/docs/components/index.rst b/docs/components/index.rst
index ffeef80..2409f96 100644
--- a/docs/components/index.rst
+++ b/docs/components/index.rst
@@ -19,6 +19,6 @@
sdei
secure-partition-manager
secure-partition-manager-mm
- psa-ffa-manifest-binding
+ ffa-manifest-binding
xlat-tables-lib-v2-design
cot-binding
diff --git a/docs/components/secure-partition-manager-mm.rst b/docs/components/secure-partition-manager-mm.rst
index d532901..30312ee 100644
--- a/docs/components/secure-partition-manager-mm.rst
+++ b/docs/components/secure-partition-manager-mm.rst
@@ -6,7 +6,7 @@
Two implementations of a Secure Partition Manager co-exist in the TF-A codebase:
-- SPM based on the PSA FF-A specification (:ref:`Secure Partition Manager`).
+- 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
@@ -822,7 +822,7 @@
--------------
-*Copyright (c) 2017-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2017-2021, Arm Limited and Contributors. All rights reserved.*
.. _Armv8-A ARM: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile
.. _instructions in the EDK2 repository: https://github.com/tianocore/edk2-staging/blob/AArch64StandaloneMm/HowtoBuild.MD
diff --git a/docs/components/secure-partition-manager.rst b/docs/components/secure-partition-manager.rst
index 842345a..8b02e7d 100644
--- a/docs/components/secure-partition-manager.rst
+++ b/docs/components/secure-partition-manager.rst
@@ -33,8 +33,6 @@
+--------+-----------------------------------+
| PVM | Primary VM |
+--------+-----------------------------------+
-| PSA | Platform Security Architecture |
-+--------+-----------------------------------+
| SMMU | System Memory Management Unit |
+--------+-----------------------------------+
| SP | Secure Partition |
@@ -61,7 +59,7 @@
Two implementations of a Secure Partition Manager co-exist in the TF-A codebase:
-- SPM based on the PSA FF-A specification `[1]`_.
+- SPM based on the FF-A specification `[1]`_.
- SPM based on the MM interface to communicate with an S-EL0 partition `[2]`_.
Both implementations differ in their architectures and only one can be selected
@@ -69,7 +67,7 @@
This document:
-- describes the PSA FF-A implementation where the Secure Partition Manager
+- describes the FF-A implementation where the Secure Partition Manager
resides at EL3 and S-EL2 (or EL3 and S-EL1).
- is not an architecture specification and it might provide assumptions
on sections mandated as implementation-defined in the specification.
@@ -565,7 +563,7 @@
- Re-purposing the ``PSCI_CPU_ON`` function id. It is
assumed that even if the input arguments are the same as the ones defined in
the PSCI standard, the usage deviates by the fact the secondary EC is not
- woken up immediately. At least for the PSA-FF-A EAC where only
+ woken up immediately. At least for the FF-A EAC where only
direct messaging is allowed, it is only after the first direct
message invocation that the secondary EC is entered. This option
might be preferred when the same code base is re-used for a VM or
@@ -949,7 +947,7 @@
.. _[1]:
-[1] `Platform Security Architecture Firmware Framework for Arm® v8-A 1.0 Platform Design Document <https://developer.arm.com/docs/den0077/latest>`__
+[1] `Arm Firmware Framework for Armv8-A <https://developer.arm.com/docs/den0077/latest>`__
.. _[2]:
@@ -970,7 +968,7 @@
.. _[6]:
-[6] https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manifest-binding.html
+[6] https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
.. _[7]:
@@ -982,4 +980,4 @@
--------------
-*Copyright (c) 2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2020-2021, Arm Limited and Contributors. All rights reserved.*
diff --git a/docs/conf.py b/docs/conf.py
index a100241..356be99 100644
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -1,6 +1,6 @@
# -*- coding: utf-8 -*-
#
-# Copyright (c) 2019, Arm Limited. All rights reserved.
+# Copyright (c) 2019-2021, Arm Limited. All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
@@ -76,6 +76,14 @@
'style_external_links': True # Display an icon next to external links
}
+# Path to _static directory
+html_static_path = ['_static']
+
+# Path to css file relative to html_static_path
+html_css_files = [
+ 'css/custom.css',
+]
+
# -- Options for autosectionlabel --------------------------------------------
# Only generate automatic section labels for document titles
diff --git a/docs/index.rst b/docs/index.rst
index cb53127..3760855 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -15,6 +15,7 @@
perf/index
security_advisories/index
design_documents/index
+ threat_model/index
change-log
change-log-upcoming
glossary
@@ -83,7 +84,7 @@
--------------
-*Copyright (c) 2013-2020, Arm Limited and Contributors. All rights reserved.*
+*Copyright (c) 2013-2021, Arm Limited and Contributors. All rights reserved.*
.. _Armv7-A and Armv8-A: https://developer.arm.com/products/architecture/a-profile
.. _Secure Monitor: http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php
diff --git a/docs/plat/arm/arm-build-options.rst b/docs/plat/arm/arm-build-options.rst
index 79b40d1..db8d945 100644
--- a/docs/plat/arm/arm-build-options.rst
+++ b/docs/plat/arm/arm-build-options.rst
@@ -104,6 +104,14 @@
device tree. This flag is defined only when ``ARM_SPMC_MANIFEST_DTS`` manifest
file name contains pattern optee_sp.
+- ``ARM_GPT_SUPPORT``: Enable GPT parser to get the entry address and length of
+ the various partitions present in the GPT image. This support is available
+ only for the BL2 component, and it is disabled by default.
+ The following diagram shows the view of the FIP partition inside the GPT
+ image:
+
+ |FIP in a GPT image|
+
For a better understanding of these options, the Arm development platform memory
map is explained in the :ref:`Firmware Design`.
@@ -140,4 +148,6 @@
--------------
+.. |FIP in a GPT image| image:: ../../resources/diagrams/FIP_in_a_GPT_image.png
+
*Copyright (c) 2019-2021, Arm Limited. All rights reserved.*
diff --git a/docs/resources/diagrams/FIP_in_a_GPT_image.png b/docs/resources/diagrams/FIP_in_a_GPT_image.png
new file mode 100644
index 0000000..4bafed9
--- /dev/null
+++ b/docs/resources/diagrams/FIP_in_a_GPT_image.png
Binary files differ
diff --git a/docs/resources/diagrams/plantuml/tfa_dfd.puml b/docs/resources/diagrams/plantuml/tfa_dfd.puml
new file mode 100644
index 0000000..0007911
--- /dev/null
+++ b/docs/resources/diagrams/plantuml/tfa_dfd.puml
@@ -0,0 +1,66 @@
+/'
+ ' Copyright (c) 2021, Arm Limited. All rights reserved.
+ '
+ ' SPDX-License-Identifier: BSD-3-Clause
+ '/
+
+/'
+TF-A Data Flow Diagram
+'/
+
+@startuml
+digraph tfa_dfd {
+
+ # Arrange nodes from left to right
+ rankdir="LR"
+
+ # Allow arrows to end on cluster boundaries
+ compound=true
+
+ # Default settings for edges and nodes
+ edge [minlen=2 color="#8c1b07"]
+ node [fillcolor="#ffb866" style=filled shape=box fixedsize=true width=1.6 height=0.7]
+
+ # Nodes outside of the trust boundary
+ nsec [label="Non-secure\nClients"]
+ sec [label="Secure\nClients"]
+ dbg [label="Debug & Trace"]
+ logs [label="Logs\n(UART)"]
+ nvm [label="Non-volatile\nMemory"]
+
+ # Trust boundary cluster
+ subgraph cluster_trusted{
+ graph [style=dashed color="#f22430"]
+
+ # HW IPs cluster
+ subgraph cluster_ip{
+ label ="Hardware IPs";
+ graph [style=filled color="#000000" fillcolor="#ffd29e"]
+
+ rank="same"
+ gic [label="GIC" width=1.2 height=0.5]
+ tzc [label="TZ\nController" width=1.2 height=0.5]
+ etc [label="..." shape=none style=none height=0.5]
+ }
+
+ # TF-A cluster
+ subgraph cluster_tfa{
+ label ="TF-A";
+ graph [style=filled color="#000000" fillcolor="#faf9cd"]
+
+ bl1 [label="Boot ROM\n(BL1)" fillcolor="#ddffb3"];
+ bl2 [label="Trusted Boot\nFirmware\n(BL2)" fillcolor="#ddffb3" height=1]
+ bl31 [label="TF-A Runtime\n(BL31)" fillcolor="#ddffb3"]
+ }
+ }
+
+ # Interactions between nodes
+ nvm -> bl31 [lhead=cluster_tfa label="DF1"]
+ logs -> bl31 [dir="back" 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"]
+ bl2 -> tzc [dir="both" ltail=cluster_tfa lhead=cluster_ip label="DF6" minlen=1]
+}
+
+@enduml
diff --git a/docs/threat_model/index.rst b/docs/threat_model/index.rst
new file mode 100644
index 0000000..e8f09b9
--- /dev/null
+++ b/docs/threat_model/index.rst
@@ -0,0 +1,13 @@
+Threat Model
+=============
+
+.. toctree::
+ :maxdepth: 1
+ :caption: Contents
+ :numbered:
+
+ threat_model
+
+--------------
+
+*Copyright (c) 2021, Arm Limited and Contributors. All rights reserved.*
diff --git a/docs/threat_model/threat_model.rst b/docs/threat_model/threat_model.rst
new file mode 100644
index 0000000..9cee104
--- /dev/null
+++ b/docs/threat_model/threat_model.rst
@@ -0,0 +1,784 @@
+*****************
+Introduction
+*****************
+Threat modeling is an important part of Secure Development Lifecycle (SDL)
+that helps us identify potential threats and mitigations affecting a system.
+
+This document provides a generic threat model for TF-A firmware. In the
+next sections, we first give a description of the target of evaluation
+using a data flow diagram. Then we provide a list of threats we have
+identified based on the data flow diagram and potential threat mitigations.
+
+************************
+Target of Evaluation
+************************
+In this threat model, the target of evaluation is the Trusted
+Firmware for A-class Processors (TF-A). This includes the boot ROM (BL1),
+the trusted boot firmware (BL2) and the runtime EL3 firmware (BL31) as
+shown on Figure 1. Everything else on Figure 1 is outside of the scope of
+the evaluation.
+
+TF-A can be configured in various ways. In this threat model we consider
+only the most basic configuration. To that end we make the following
+assumptions:
+
+- All TF-A images are run from either ROM or on-chip trusted SRAM. This means
+ TF-A is not vulnerable to an attacker that can probe or tamper with off-chip
+ memory.
+- Trusted boot is enabled. This means an attacker can't boot arbitrary images
+ that are not approved by platform providers.
+- There is no Secure-EL2. We don't consider threats that may come with
+ Secure-EL2 software.
+
+Data Flow Diagram
+======================
+Figure 1 shows a high-level data flow diagram for TF-A. The diagram
+shows a model of the different components of a TF-A-based system and
+their interactions with TF-A. A description of each diagram element
+is given on Table 1. On the diagram, the red broken lines indicate
+trust boundaries. Components outside of the broken lines
+are considered untrusted by TF-A.
+
+.. uml:: ../resources/diagrams/plantuml/tfa_dfd.puml
+ :caption: Figure 1: TF-A Data Flow Diagram
+
+.. table:: Table 1: TF-A Data Flow Diagram Description
+
+ +-----------------+--------------------------------------------------------+
+ | Diagram Element | Description |
+ +=================+========================================================+
+ | ``DF1`` | | At boot time, images are loaded from non-volatile |
+ | | memory and verified by TF-A boot firmware. These |
+ | | 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. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF3`` | | Debug and trace IP on a platform can allow access |
+ | | to registers and memory of TF-A. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF4`` | | Secure world software (e.g. trusted OS) interact |
+ | | with TF-A through SMC call interface and/or shared |
+ | | memory. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF5`` | | Non-secure world software (e.g. rich OS) interact |
+ | | with TF-A through SMC call interface and/or shared |
+ | | memory. |
+ +-----------------+--------------------------------------------------------+
+ | ``DF6`` | | This path represents the interaction between TF-A and|
+ | | various hardware IPs such as TrustZone controller |
+ | | and GIC. At boot time TF-A configures/initializes the|
+ | | IPs and interacts with them at runtime through |
+ | | interrupts and registers. |
+ +-----------------+--------------------------------------------------------+
+
+
+*********************
+Threat Analysis
+*********************
+In this section we identify and provide assessment of potential threats to TF-A
+firmware. The threats are identified for each diagram element on the
+data flow diagram above.
+
+For each threat, we identify the *asset* that is under threat, the
+*threat agent* and the *threat type*. Each threat is given a *risk rating*
+that represents the impact and likelihood of that threat. We also discuss
+potential mitigations.
+
+Assets
+==================
+We have identified the following assets for TF-A:
+
+.. table:: Table 2: TF-A Assets
+
+ +--------------------+---------------------------------------------------+
+ | Asset | Description |
+ +====================+===================================================+
+ | ``Sensitive Data`` | | These include sensitive data that an attacker |
+ | | must not be able to tamper with (e.g. the Root |
+ | | of Trust Public Key) or see (e.g. secure logs, |
+ | | debugging information such as crash reports). |
+ +--------------------+---------------------------------------------------+
+ | ``Code Execution`` | | This represents the requirement that the |
+ | | platform should run only TF-A code approved by |
+ | | the platform provider. |
+ +--------------------+---------------------------------------------------+
+ | ``Availability`` | | This represents the requirement that TF-A |
+ | | services should always be available for use. |
+ +--------------------+---------------------------------------------------+
+
+Threat Agents
+=====================
+To understand the attack surface, it is important to identify potential
+attackers, i.e. attack entry points. The following threat agents are
+in scope of this threat model.
+
+.. table:: Table 3: Threat Agents
+
+ +-------------------+-------------------------------------------------------+
+ | Threat Agent | Description |
+ +===================+=======================================================+
+ | ``NSCode`` | | Malicious or faulty code running in the Non-secure |
+ | | world, including NS-EL0 NS-EL1 and NS-EL2 levels |
+ +-------------------+-------------------------------------------------------+
+ | ``SecCode`` | | Malicious or faulty code running in the secure |
+ | | world, including S-EL0 and S-EL1 levels |
+ +-------------------+-------------------------------------------------------+
+ | ``AppDebug`` | | Physical attacker using debug signals to access |
+ | | TF-A resources |
+ +-------------------+-------------------------------------------------------+
+ | ``PhysicalAccess``| | Physical attacker having access to external device |
+ | | communication bus and to external flash |
+ | | communication bus using common hardware |
+ +-------------------+-------------------------------------------------------+
+
+.. note::
+
+ In this threat model an advanced physical attacker that has the capability
+ to tamper with a hardware (e.g. "rewiring" a chip using a focused
+ ion beam (FIB) workstation or decapsulate the chip using chemicals) is
+ considered out-of-scope.
+
+Threat Types
+========================
+In this threat model we categorize threats using the `STRIDE threat
+analysis technique`_. In this technique a threat is categorized as one
+or more of these types: ``Spoofing``, ``Tampering``, ``Repudiation``,
+``Information disclosure``, ``Denial of service`` or
+``Elevation of privilege``.
+
+Threat Risk Ratings
+========================
+For each threat identified, a risk rating that ranges
+from *informational* to *critical* is given based on the likelihood of the
+threat occuring if a mitigation is not in place, and the impact of the
+threat (i.e. how severe the consequences could be). Table 4 explains each
+rating in terms of score, impact and likelihood.
+
+.. table:: Table 4: Rating and score as applied to impact and likelihood
+
+ +-----------------------+-------------------------+---------------------------+
+ | **Rating (Score)** | **Impact** | **Likelihood** |
+ +=======================+=========================+===========================+
+ | ``Critical (5)`` | | Extreme impact to | | Threat is almost |
+ | | entire organization | certain to be exploited.|
+ | | if exploited. | |
+ | | | | Knowledge of the threat |
+ | | | and how to exploit it |
+ | | | are in the public |
+ | | | domain. |
+ +-----------------------+-------------------------+---------------------------+
+ | ``High (4)`` | | Major impact to entire| | Threat is relatively |
+ | | organization or single| easy to detect and |
+ | | line of business if | exploit by an attacker |
+ | | exploited | with little skill. |
+ +-----------------------+-------------------------+---------------------------+
+ | ``Medium (3)`` | | Noticeable impact to | | A knowledgeable insider |
+ | | line of business if | or expert attacker could|
+ | | exploited. | exploit the threat |
+ | | | without much difficulty.|
+ +-----------------------+-------------------------+---------------------------+
+ | ``Low (2)`` | | Minor damage if | | Exploiting the threat |
+ | | exploited or could | would require |
+ | | be used in conjunction| considerable expertise |
+ | | with other | and resources |
+ | | vulnerabilities to | |
+ | | perform a more serious| |
+ | | attack | |
+ +-----------------------+-------------------------+---------------------------+
+ | ``Informational (1)`` | | Poor programming | | Threat is not likely |
+ | | practice or poor | to be exploited on its |
+ | | design decision that | own, but may be used to |
+ | | may not represent an | gain information for |
+ | | immediate risk on its | launching another |
+ | | own, but may have | attack |
+ | | security implications | |
+ | | if multiplied and/or | |
+ | | combined with other | |
+ | | threats. | |
+ +-----------------------+-------------------------+---------------------------+
+
+Aggregate risk scores are assigned to identified threats;
+specifically, the impact score multiplied by the likelihood score.
+For example, a threat with high likelihood and low impact would have an
+aggregate risk score of eight (8); that is, four (4) for high likelihood
+multiplied by two (2) for low impact. The aggregate risk score determines
+the finding's overall risk level, as shown in the following table.
+
+.. table:: Table 5: Overall risk levels and corresponding aggregate scores
+
+ +---------------------+-----------------------------------+
+ | Overall Risk Level | Aggregate Risk Score |
+ | | (Impact multiplied by Likelihood) |
+ +=====================+===================================+
+ | Critical | 20–25 |
+ +---------------------+-----------------------------------+
+ | High | 12–19 |
+ +---------------------+-----------------------------------+
+ | Medium | 6–11 |
+ +---------------------+-----------------------------------+
+ | Low | 2–5 |
+ +---------------------+-----------------------------------+
+ | Informational | 1 |
+ +---------------------+-----------------------------------+
+
+The likelihood and impact of a threat depends on the
+target environment in which TF-A is running. For example, attacks
+that require physical access are unlikely in server environments while
+they are more common in Internet of Things(IoT) environments.
+In this threat model we consider three target environments:
+``Internet of Things(IoT)``, ``Mobile`` and ``Server``.
+
+Threat Assessment
+============================
+The following threats were identified by applying STRIDE analysis on
+each diagram element of the data flow diagram.
+
++------------------------+----------------------------------------------------+
+| 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`` | | TF-A implements the `Trusted Board Boot (TBB)`_ |
+| | feature which prevents malicious firmware from |
+| | running on the platform by authenticating all |
+| | firmware images. In addition to this, the TF-A |
+| | boot firmware performs extra checks on |
+| | unauthenticated data, such as FIP metadata, prior|
+| | to use. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| 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`` | | TF-A supports anti-rollback protection using |
+| | non-volatile counters (NV counters) as required |
+| | by `TBBR-Client specification`_. After a firmware|
+| | image is validated, the image revision number |
+| | taken from a certificate extension field is |
+| | compared with the corresponding NV counter stored|
+| | in hardware to make sure the new counter value is|
+| | larger or equal to the current counter value. |
+| | Platforms must implement this protection using |
+| | platform specific hardware NV counters. |
++------------------------+----------------------------------------------------+
+
++------------------------+-------------------------------------------------------+
+| 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`` | | TF-A boot firmware copies image to on-chip |
+| | memory before authenticating an image. |
++------------------------+-------------------------------------------------------+
+
++------------------------+-------------------------------------------------------+
+| 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`` | | 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.** |
++------------------------+-------------------------------------------------------+
+
++------------------------+---------------------------------------------------+
+| ID | 05 |
++========================+===================================================+
+| ``Threat`` | | **Information leak via UART logs such as |
+| | crashes** |
+| | |
+| | | During the development stages of software it is |
+| | common to include crash reports with detailed |
+| | information of the CPU state including current |
+| | values of the registers, privilege level and |
+| | stack dumps. This information is useful when |
+| | debugging problems before releasing the |
+| | production version, but it could be used by an |
+| | attacker to develop a working exploit if left |
+| | in the production version. |
++------------------------+---------------------------------------------------+
+| ``Diagram Elements`` | DF2 |
++------------------------+---------------------------------------------------+
+| ``Affected TF-A | BL1, BL2, BL31 |
+| Components`` | |
++------------------------+---------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+---------------------------------------------------+
+| ``Threat Agent`` | AppDebug |
++------------------------+---------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+------------------+----------------+---------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+------------------+----------------+---------------+
+| ``Impact`` | N/A | Low (2) | Low (2) |
++------------------------+------------------+----------------+---------------+
+| ``Likelihood`` | N/A | High (4) | High (4) |
++------------------------+------------------+----------------+---------------+
+| ``Total Risk Rating`` | N/A | Medium (8) | Medium (8) |
++------------------------+------------------+----------------+---------------+
+| ``Mitigations`` | | In TF-A, crash reporting is only enabled for |
+| | debug builds by default. Alternatively, the log |
+| | level can be tuned at build time (from verbose |
+| | to no output at all), independently of the |
+| | build type. |
++------------------------+---------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 06 |
++========================+====================================================+
+| ``Threat`` | | **An attacker can read sensitive data and |
+| | execute arbitrary code through the external |
+| | debug and trace interface** |
+| | |
+| | | Arm processors include hardware-assisted debug |
+| | and trace features that can be controlled without|
+| | the need for software operating on the platform. |
+| | If left enabled without authentication, this |
+| | feature can be used by an attacker to inspect and|
+| | modify TF-A registers and memory allowing the |
+| | attacker to read sensitive data and execute |
+| | arbitrary code. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF3 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | BL1, BL2, BL31 |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | Code Execution, Sensitive Data |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | AppDebug |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Tampering, Information Disclosure, |
+| | Elevation of privilege |
++------------------------+------------------+---------------+-----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+------------------+---------------+-----------------+
+| ``Impact`` | N/A | High (4) | High (4) |
++------------------------+------------------+---------------+-----------------+
+| ``Likelihood`` | N/A | Critical (5) | Critical (5) |
++------------------------+------------------+---------------+-----------------+
+| ``Total Risk Rating`` | N/A | Critical (20) | Critical (20) |
++------------------------+------------------+---------------+-----------------+
+| ``Mitigations`` | | Configuration of debug and trace capabilities is |
+| | platform specific. Therefore, platforms must |
+| | disable the debug and trace capability for |
+| | production releases or enable proper debug |
+| | authentication as recommended by [`DEN0034`_]. |
++------------------------+----------------------------------------------------+
+
++------------------------+------------------------------------------------------+
+| 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`` | | The generic TF-A code validates SMC function ids |
+| | and arguments before using them. |
+| | Platforms that implement SiP services must also |
+| | validate SMC call arguments. |
++------------------------+------------------------------------------------------+
+
++------------------------+------------------------------------------------------+
+| ID | 08 |
++========================+======================================================+
+| ``Threat`` | | **Memory corruption due to memory overflows and |
+| | lack of boundary checking when accessing resources |
+| | could allow an attacker to execute arbitrary code, |
+| | modify some state variable to change the normal |
+| | flow of the program, or leak sensitive |
+| | information** |
+| | |
+| | | Like in other software, the Trusted Firmware has |
+| | multiple points where memory corruption security |
+| | errors can arise. Memory corruption is a dangerous |
+| | security issue since it could allow an attacker |
+| | to execute arbitrary code, modify some state |
+| | variable to change the normal flow of the program, |
+| | or leak sensitive information. |
+| | |
+| | | Some of the errors include integer overflow, |
+| | buffer overflow, incorrect array boundary checks, |
+| | and incorrect error management. |
+| | Improper use of asserts instead of proper input |
+| | validations might also result in these kinds of |
+| | errors in release builds. |
++------------------------+------------------------------------------------------+
+| ``Diagram Elements`` | DF4, DF5 |
++------------------------+------------------------------------------------------+
+| ``Affected TF-A | BL1, BL2, BL31 |
+| Components`` | |
++------------------------+------------------------------------------------------+
+| ``Assets`` | Code Execution, Sensitive Data |
++------------------------+------------------------------------------------------+
+| ``Threat Agent`` | NSCode, SecCode |
++------------------------+------------------------------------------------------+
+| ``Threat Type`` | Tampering, Information Disclosure, |
+| | Elevation of Privilege |
++------------------------+-------------------+-----------------+----------------+
+| ``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`` | | TF-A uses a combination of manual code reviews and |
+| | automated program analysis and testing to detect |
+| | and fix memory corruption bugs. All TF-A code |
+| | including platform code go through manual code |
+| | reviews. Additionally, static code analysis is |
+| | performed using Coverity Scan on all TF-A code. |
+| | The code is also tested with |
+| | `Trusted Firmware-A Tests`_ on Juno and FVP |
+| | platforms. |
+| | |
+| | | Data received from normal world, such as addresses |
+| | and sizes identifying memory regions, are |
+| | sanitized before being used. These security checks |
+| | make sure that the normal world software does not |
+| | access memory beyond its limit. |
+| | |
+| | | By default *asserts* are only used to check for |
+| | programming errors in debug builds. Other types of |
+| | errors are handled through condition checks that |
+| | remain enabled in release builds. See |
+| | `TF-A error handling policy`_. TF-A provides an |
+| | option to use *asserts* in release builds, however |
+| | we recommend using proper runtime checks instead |
+| | of relying on asserts in release builds. |
++------------------------+------------------------------------------------------+
+
++------------------------+------------------------------------------------------+
+| ID | 09 |
++========================+======================================================+
+| ``Threat`` | | **Improperly handled SMC calls can leak register |
+| | contents** |
+| | |
+| | | When switching between secure and non-secure |
+| | states, register contents of Secure world or |
+| | register contents of other normal world clients |
+| | can be leaked. |
++------------------------+------------------------------------------------------+
+| ``Diagram Elements`` | DF5 |
++------------------------+------------------------------------------------------+
+| ``Affected TF-A | BL31 |
+| Components`` | |
++------------------------+------------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+------------------------------------------------------+
+| ``Threat Agent`` | NSCode |
++------------------------+------------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+-------------------+----------------+-----------------+
+| ``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`` | | TF-A saves and restores registers |
+| | by default when switching contexts. Build options |
+| | are also provided to save/restore additional |
+| | registers such as floating-point registers. |
++------------------------+------------------------------------------------------+
+
++------------------------+-----------------------------------------------------+
+| ID | 10 |
++========================+=====================================================+
+| ``Threat`` | | **SMC calls can leak sensitive information from |
+| | TF-A memory via microarchitectural side channels**|
+| | |
+| | | Microarchitectural side-channel attacks such as |
+| | `Spectre`_ can be used to leak data across |
+| | security boundaries. An attacker might attempt to |
+| | use this kind of attack to leak sensitive |
+| | data from TF-A memory. |
++------------------------+-----------------------------------------------------+
+| ``Diagram Elements`` | DF4, DF5 |
++------------------------+-----------------------------------------------------+
+| ``Affected TF-A | BL31 |
+| Components`` | |
++------------------------+-----------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+-----------------------------------------------------+
+| ``Threat Agent`` | SecCode, NSCode |
++------------------------+-----------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+-------------------+----------------+----------------+
+| ``Application`` | ``Server`` | ``IoT`` | ``Mobile`` |
++------------------------+-------------------+----------------+----------------+
+| ``Impact`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| ``Likelihood`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| ``Total Risk Rating`` | Medium (9) | Medium (9) | Medium (9) |
++------------------------+-------------------+----------------+----------------+
+| ``Mitigations`` | | TF-A implements software mitigations for Spectre |
+| | type attacks as recommended by `Cache Speculation |
+| | Side-channels`_ for the generic code. SiPs should |
+| | implement similar mitigations for code that is |
+| | deemed to be vulnerable to such attacks. |
++------------------------+-----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 11 |
++========================+====================================================+
+| ``Threat`` | | **Misconfiguration of the Memory Management Unit |
+| | (MMU) may allow a normal world software to |
+| | access sensitive data or execute arbitrary |
+| | code** |
+| | |
+| | | 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`` | | In TF-A, configuration of the MMU is done |
+| | through a translation tables library. The |
+| | library provides APIs to define memory regions |
+| | and assign attributes including memory types and |
+| | access permissions. Memory configurations are |
+| | platform specific, therefore platforms need make |
+| | sure the correct attributes are assigned to |
+| | memory regions. When assigning access |
+| | permissions, principle of least privilege ought |
+| | to be enforced, i.e. we should not grant more |
+| | privileges than strictly needed, e.g. code |
+| | should be read-only executable, RO data should |
+| | be read-only XN, and so on. |
++------------------------+----------------------------------------------------+
+
++------------------------+-----------------------------------------------------+
+| ID | 12 |
++========================+=====================================================+
+| ``Threat`` | | **Incorrect configuration of Performance Monitor |
+| | Unit (PMU) counters can allow an attacker to |
+| | mount side-channel attacks using information |
+| | exposed by the counters** |
+| | |
+| | | Non-secure software can configure PMU registers |
+| | to count events at any exception level and in |
+| | both Secure and Non-secure states. This allows |
+| | a Non-secure software (or a lower-level Secure |
+| | software) to potentially carry out |
+| | side-channel timing attacks against TF-A. |
++------------------------+-----------------------------------------------------+
+| ``Diagram Elements`` | DF5, DF6 |
++------------------------+-----------------------------------------------------+
+| ``Affected TF-A | BL31 |
+| Components`` | |
++------------------------+-----------------------------------------------------+
+| ``Assets`` | Sensitive Data |
++------------------------+-----------------------------------------------------+
+| ``Threat Agent`` | NSCode |
++------------------------+-----------------------------------------------------+
+| ``Threat Type`` | Information Disclosure |
++------------------------+-------------------+----------------+----------------+
+| ``Impact`` | Medium (3) | Medium (3) | Medium (3) |
++------------------------+-------------------+----------------+----------------+
+| ``Likelihood`` | Low (2) | Low (2) | Low (2) |
++------------------------+-------------------+----------------+----------------+
+| ``Total Risk Rating`` | Medium (6) | Medium (6) | Medium (6) |
++------------------------+-------------------+----------------+----------------+
+| ``Mitigations`` | | TF-A follows mitigation strategies as described |
+| | in `Secure Development Guidelines`_. General |
+| | events and cycle counting in the Secure world is |
+| | prohibited by default when applicable. However, |
+| | on some implementations (e.g. PMUv3) Secure world |
+| | event counting depends on external debug interface|
+| | signals, i.e. Secure world event counting is |
+| | enabled if external debug is enabled. |
+| | Configuration of debug signals is platform |
+| | specific, therefore platforms need to make sure |
+| | that external debug is disabled in production or |
+| | proper debug authentication is in place. |
++------------------------+-----------------------------------------------------+
+
+--------------
+
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
+
+
+.. _STRIDE threat analysis technique: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model
+.. _DEN0034: https://developer.arm.com/documentation/den0034/latest
+.. _Cache Speculation Side-channels: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
+.. _Spectre: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability
+.. _TBBR-Client specification: https://developer.arm.com/documentation/den0006/d/
+.. _Trusted Board Boot (TBB): https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot.html
+.. _TF-A error handling policy: https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guidelines.html#error-handling-and-robustness
+.. _Secure Development Guidelines: https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardening.html#secure-development-guidelines
+.. _Trusted Firmware-A Tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/
\ No newline at end of file
diff --git a/fdts/tc0.dts b/fdts/tc0.dts
index 382860d..a4f7a4d 100644
--- a/fdts/tc0.dts
+++ b/fdts/tc0.dts
@@ -146,7 +146,7 @@
compatible = "arm,armv8";
reg = <0x700>;
enable-method = "psci";
- clocks = <&scmi_dvfs 1>;
+ clocks = <&scmi_dvfs 2>;
cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
};
diff --git a/include/plat/arm/board/common/board_css_def.h b/include/plat/arm/board/common/board_css_def.h
index 775d034..1963bf0 100644
--- a/include/plat/arm/board/common/board_css_def.h
+++ b/include/plat/arm/board/common/board_css_def.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2015-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -47,6 +47,16 @@
#define PLAT_ARM_FLASH_IMAGE_BASE V2M_FLASH0_BASE
#define PLAT_ARM_FLASH_IMAGE_MAX_SIZE (V2M_FLASH0_SIZE - V2M_FLASH_BLOCK_SIZE)
+#if ARM_GPT_SUPPORT
+/*
+ * Offset of the FIP in the GPT image. BL1 component uses this option
+ * as it does not load the partition table to get the FIP base
+ * address. At sector 34 by default (i.e. after reserved sectors 0-33)
+ * Offset = 34 * 512(sector size) = 17408 i.e. 0x4400
+ */
+#define PLAT_ARM_FIP_OFFSET_IN_GPT 0x4400
+#endif /* ARM_GPT_SUPPORT */
+
#define PLAT_ARM_NVM_BASE V2M_FLASH0_BASE
#define PLAT_ARM_NVM_SIZE (V2M_FLASH0_SIZE - V2M_FLASH_BLOCK_SIZE)
diff --git a/include/plat/arm/common/plat_arm.h b/include/plat/arm/common/plat_arm.h
index 95fc18e..846c9a4 100644
--- a/include/plat/arm/common/plat_arm.h
+++ b/include/plat/arm/common/plat_arm.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2015-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -152,6 +152,9 @@
/* IO storage utility functions */
int arm_io_setup(void);
+/* Set image specification in IO block policy */
+int arm_set_image_source(unsigned int image_id, const char *part_name);
+
/* Security utility functions */
void arm_tzc400_setup(uintptr_t tzc_base,
const arm_tzc_regions_info_t *tzc_regions);
diff --git a/plat/arm/board/fvp/include/platform_def.h b/plat/arm/board/fvp/include/platform_def.h
index c95f27d..c46ddbe 100644
--- a/plat/arm/board/fvp/include/platform_def.h
+++ b/plat/arm/board/fvp/include/platform_def.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2014-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -115,7 +115,7 @@
#if USE_ROMLIB
#define PLAT_ARM_MAX_ROMLIB_RW_SIZE UL(0x1000)
#define PLAT_ARM_MAX_ROMLIB_RO_SIZE UL(0xe000)
-#define FVP_BL2_ROMLIB_OPTIMIZATION UL(0x6000)
+#define FVP_BL2_ROMLIB_OPTIMIZATION UL(0x5000)
#else
#define PLAT_ARM_MAX_ROMLIB_RW_SIZE UL(0)
#define PLAT_ARM_MAX_ROMLIB_RO_SIZE UL(0)
@@ -188,6 +188,16 @@
#define PLAT_ARM_FLASH_IMAGE_BASE V2M_FLASH0_BASE
#define PLAT_ARM_FLASH_IMAGE_MAX_SIZE (V2M_FLASH0_SIZE - V2M_FLASH_BLOCK_SIZE)
+#if ARM_GPT_SUPPORT
+/*
+ * Offset of the FIP in the GPT image. BL1 component uses this option
+ * as it does not load the partition table to get the FIP base
+ * address. At sector 34 by default (i.e. after reserved sectors 0-33)
+ * Offset = 34 * 512(sector size) = 17408 i.e. 0x4400
+ */
+#define PLAT_ARM_FIP_OFFSET_IN_GPT 0x4400
+#endif /* ARM_GPT_SUPPORT */
+
#define PLAT_ARM_NVM_BASE V2M_FLASH0_BASE
#define PLAT_ARM_NVM_SIZE (V2M_FLASH0_SIZE - V2M_FLASH_BLOCK_SIZE)
diff --git a/plat/arm/common/arm_bl2_setup.c b/plat/arm/common/arm_bl2_setup.c
index c90e93c..63ed9fe 100644
--- a/plat/arm/common/arm_bl2_setup.c
+++ b/plat/arm/common/arm_bl2_setup.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2015-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -14,6 +14,7 @@
#include <common/debug.h>
#include <common/desc_image_load.h>
#include <drivers/generic_delay_timer.h>
+#include <drivers/partition/partition.h>
#include <lib/fconf/fconf.h>
#include <lib/fconf/fconf_dyn_cfg_getter.h>
#ifdef SPD_opteed
@@ -70,6 +71,12 @@
/* Initialise the IO layer and register platform IO devices */
plat_arm_io_setup();
+
+ /* Load partition table */
+#if ARM_GPT_SUPPORT
+ partition_init(GPT_IMAGE_ID);
+#endif /* ARM_GPT_SUPPORT */
+
}
void bl2_early_platform_setup2(u_register_t arg0, u_register_t arg1, u_register_t arg2, u_register_t arg3)
@@ -86,6 +93,14 @@
void bl2_plat_preload_setup(void)
{
arm_bl2_dyn_cfg_init();
+
+#if ARM_GPT_SUPPORT
+ int result = arm_set_image_source(FIP_IMAGE_ID, "FIP_A");
+
+ if (result != 0) {
+ panic();
+ }
+#endif /* ARM_GPT_SUPPORT */
}
/*
diff --git a/plat/arm/common/arm_common.mk b/plat/arm/common/arm_common.mk
index 2ae26da..fff1294 100644
--- a/plat/arm/common/arm_common.mk
+++ b/plat/arm/common/arm_common.mk
@@ -167,6 +167,17 @@
endif
endif
+# Disable GPT parser support, use FIP image by default
+ARM_GPT_SUPPORT := 0
+$(eval $(call assert_boolean,ARM_GPT_SUPPORT))
+$(eval $(call add_define,ARM_GPT_SUPPORT))
+
+# Include necessary sources to parse GPT image
+ifeq (${ARM_GPT_SUPPORT}, 1)
+ BL2_SOURCES += drivers/partition/gpt.c \
+ drivers/partition/partition.c
+endif
+
ifeq (${ARCH}, aarch64)
PLAT_INCLUDES += -Iinclude/plat/arm/common/aarch64
endif
diff --git a/plat/arm/common/arm_io_storage.c b/plat/arm/common/arm_io_storage.c
index 34b4101..c5d913e 100644
--- a/plat/arm/common/arm_io_storage.c
+++ b/plat/arm/common/arm_io_storage.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2015-2020, ARM Limited. All rights reserved.
+ * Copyright (c) 2015-2021, ARM Limited. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -9,6 +9,7 @@
#include <drivers/io/io_fip.h>
#include <drivers/io/io_memmap.h>
#include <drivers/io/io_storage.h>
+#include <drivers/partition/partition.h>
#include <lib/utils.h>
#include <plat/arm/common/arm_fconf_getter.h>
@@ -136,3 +137,40 @@
{
return (io_dev_init(fip_dev_handle, (uintptr_t)FIP_IMAGE_ID) == 0);
}
+
+#if ARM_GPT_SUPPORT
+/**********************************************************************
+ * arm_set_image_source: Set image specification in IO policy
+ *
+ * @image_id: id of the image whose specification to be set
+ *
+ * @part_name: name of the partition that to be read for entry details
+ *
+ * set the entry and offset details of partition in global IO policy
+ * of the image
+ *********************************************************************/
+int arm_set_image_source(unsigned int image_id, const char *part_name)
+{
+ const partition_entry_t *entry = get_partition_entry(part_name);
+
+ if (entry == NULL) {
+ ERROR("Unable to find the %s partition\n", part_name);
+ return -ENOENT;
+ }
+
+ const struct plat_io_policy *policy = FCONF_GET_PROPERTY(arm,
+ io_policies,
+ image_id);
+
+ assert(policy != NULL);
+ assert(policy->image_spec != 0UL);
+
+ /* set offset and length of the image */
+ io_block_spec_t *image_spec = (io_block_spec_t *)policy->image_spec;
+
+ image_spec->offset = PLAT_ARM_FLASH_IMAGE_BASE + entry->start;
+ image_spec->length = entry->length;
+
+ return 0;
+}
+#endif
diff --git a/plat/arm/common/fconf/arm_fconf_io.c b/plat/arm/common/fconf/arm_fconf_io.c
index 4a64cb8..8e4469f 100644
--- a/plat/arm/common/fconf/arm_fconf_io.c
+++ b/plat/arm/common/fconf/arm_fconf_io.c
@@ -9,6 +9,7 @@
#include <common/debug.h>
#include <common/fdt_wrappers.h>
#include <drivers/io/io_storage.h>
+#include <drivers/partition/partition.h>
#include <lib/object_pool.h>
#include <libfdt.h>
#include <tools_share/firmware_image_package.h>
@@ -17,11 +18,35 @@
#include <plat/arm/common/arm_fconf_io_storage.h>
#include <platform_def.h>
-const io_block_spec_t fip_block_spec = {
+io_block_spec_t fip_block_spec = {
+/*
+ * This is fixed FIP address used by BL1, BL2 loads partition table
+ * to get FIP address.
+ */
+#if ARM_GPT_SUPPORT
+ .offset = PLAT_ARM_FLASH_IMAGE_BASE + PLAT_ARM_FIP_OFFSET_IN_GPT,
+#else
.offset = PLAT_ARM_FLASH_IMAGE_BASE,
+#endif /* ARM_GPT_SUPPORT */
.length = PLAT_ARM_FLASH_IMAGE_MAX_SIZE
};
+#if ARM_GPT_SUPPORT
+static const io_block_spec_t gpt_spec = {
+ .offset = PLAT_ARM_FLASH_IMAGE_BASE,
+ /*
+ * PLAT_PARTITION_BLOCK_SIZE = 512
+ * PLAT_PARTITION_MAX_ENTRIES = 128
+ * each sector has 4 partition entries, and there are
+ * 2 reserved sectors i.e. protective MBR and primary
+ * GPT header hence length gets calculated as,
+ * length = 512 * (128/4 + 2)
+ */
+ .length = PLAT_PARTITION_BLOCK_SIZE *
+ (PLAT_PARTITION_MAX_ENTRIES / 4 + 2),
+};
+#endif /* ARM_GPT_SUPPORT */
+
const io_uuid_spec_t arm_uuid_spec[MAX_NUMBER_IDS] = {
[BL2_IMAGE_ID] = {UUID_TRUSTED_BOOT_FIRMWARE_BL2},
[TB_FW_CONFIG_ID] = {UUID_TB_FW_CONFIG},
@@ -60,6 +85,13 @@
/* By default, ARM platforms load images from the FIP */
struct plat_io_policy policies[MAX_NUMBER_IDS] = {
+#if ARM_GPT_SUPPORT
+ [GPT_IMAGE_ID] = {
+ &memmap_dev_handle,
+ (uintptr_t)&gpt_spec,
+ open_memmap
+ },
+#endif /* ARM_GPT_SUPPORT */
[FIP_IMAGE_ID] = {
&memmap_dev_handle,
(uintptr_t)&fip_block_spec,
diff --git a/plat/arm/css/sgi/include/sgi_soc_css_def_v2.h b/plat/arm/css/sgi/include/sgi_soc_css_def_v2.h
index 28916f8..bebc597 100644
--- a/plat/arm/css/sgi/include/sgi_soc_css_def_v2.h
+++ b/plat/arm/css/sgi/include/sgi_soc_css_def_v2.h
@@ -187,6 +187,16 @@
#define PLAT_ARM_FLASH_IMAGE_BASE V2M_FLASH0_BASE
#define PLAT_ARM_FLASH_IMAGE_MAX_SIZE (V2M_FLASH0_SIZE - V2M_FLASH_BLOCK_SIZE)
+#if ARM_GPT_SUPPORT
+/*
+ * Offset of the FIP in the GPT image. BL1 component uses this option
+ * as it does not load the partition table to get the FIP base
+ * address. At sector 34 by default (i.e. after reserved sectors 0-33)
+ * Offset = 34 * 512(sector size) = 17408 i.e. 0x4400
+ */
+#define PLAT_ARM_FIP_OFFSET_IN_GPT 0x4400
+#endif /* ARM_GPT_SUPPORT */
+
#define PLAT_ARM_NVM_BASE V2M_FLASH0_BASE
#define PLAT_ARM_NVM_SIZE (V2M_FLASH0_SIZE - V2M_FLASH_BLOCK_SIZE)
diff --git a/plat/imx/imx8m/imx8mp/include/platform_def.h b/plat/imx/imx8m/imx8mp/include/platform_def.h
index 644adc7..a5f265d 100644
--- a/plat/imx/imx8m/imx8mp/include/platform_def.h
+++ b/plat/imx/imx8m/imx8mp/include/platform_def.h
@@ -34,8 +34,8 @@
#define PLAT_WAIT_RET_STATE U(1)
#define PLAT_STOP_OFF_STATE U(3)
-#define BL31_BASE U(0x960000)
-#define BL31_LIMIT U(0x980000)
+#define BL31_BASE U(0x970000)
+#define BL31_LIMIT U(0x990000)
/* non-secure uboot base */
#define PLAT_NS_IMAGE_OFFSET U(0x40200000)
diff --git a/plat/imx/imx8m/include/gpc.h b/plat/imx/imx8m/include/gpc.h
index 075da91..29b8ecf 100644
--- a/plat/imx/imx8m/include/gpc.h
+++ b/plat/imx/imx8m/include/gpc.h
@@ -32,7 +32,7 @@
.pwr_req = name##_PWR_REQ, \
.pgc_offset = name##_PGC, \
.need_sync = false, \
- .always_on = true, \
+ .always_on = (on), \
}
#define IMX_MIX_DOMAIN(name, on) \
@@ -42,7 +42,7 @@
.adb400_sync = name##_ADB400_SYNC, \
.adb400_ack = name##_ADB400_ACK, \
.need_sync = true, \
- .always_on = true, \
+ .always_on = (on), \
}
struct imx_pwr_domain {
diff --git a/plat/st/common/stm32mp_dt.c b/plat/st/common/stm32mp_dt.c
index 391e5f0..4f130ce 100644
--- a/plat/st/common/stm32mp_dt.c
+++ b/plat/st/common/stm32mp_dt.c
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2017-2020, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2017-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -72,21 +72,20 @@
uint8_t fdt_get_status(int node)
{
uint8_t status = DT_DISABLED;
- int len;
const char *cchar;
- cchar = fdt_getprop(fdt, node, "status", &len);
+ cchar = fdt_getprop(fdt, node, "status", NULL);
if ((cchar == NULL) ||
- (strncmp(cchar, "okay", (size_t)len) == 0)) {
+ (strncmp(cchar, "okay", strlen("okay")) == 0)) {
status |= DT_NON_SECURE;
}
- cchar = fdt_getprop(fdt, node, "secure-status", &len);
+ cchar = fdt_getprop(fdt, node, "secure-status", NULL);
if (cchar == NULL) {
if (status == DT_NON_SECURE) {
status |= DT_SECURE;
}
- } else if (strncmp(cchar, "okay", (size_t)len) == 0) {
+ } else if (strncmp(cchar, "okay", strlen("okay")) == 0) {
status |= DT_SECURE;
}
diff --git a/plat/ti/k3/board/generic/include/board_def.h b/plat/ti/k3/board/generic/include/board_def.h
index 0d45116..4ff687c 100644
--- a/plat/ti/k3/board/generic/include/board_def.h
+++ b/plat/ti/k3/board/generic/include/board_def.h
@@ -18,15 +18,26 @@
/*
* This RAM will be used for the bootloader including code, bss, and stacks.
* It may need to be increased if BL31 grows in size.
+ *
+ * The link addresses are determined by SEC_SRAM_BASE + offset.
+ * When ENABLE_PIE is set, the TF images can be loaded anywhere, so
+ * SEC_SRAM_BASE is really arbitrary.
+ *
+ * When ENABLE_PIE is unset, SEC_SRAM_BASE should be chosen so that
+ * it matches to the physical address where BL31 is loaded, that is,
+ * SEC_SRAM_BASE should be the base address of the RAM region.
+ *
+ * Lets make things explicit by mapping SRAM_BASE to 0x0 since ENABLE_PIE is
+ * defined as default for our platform.
*/
-#define SEC_SRAM_BASE 0x70000000 /* Base of MSMC SRAM */
-#define SEC_SRAM_SIZE 0x00020000 /* 128k */
+#define SEC_SRAM_BASE UL(0x00000000) /* PIE remapped on fly */
+#define SEC_SRAM_SIZE UL(0x00020000) /* 128k */
#define PLAT_MAX_OFF_STATE U(2)
#define PLAT_MAX_RET_STATE U(1)
-#define PLAT_PROC_START_ID 32
-#define PLAT_PROC_DEVICE_START_ID 202
-#define PLAT_CLUSTER_DEVICE_START_ID 198
+#define PLAT_PROC_START_ID U(32)
+#define PLAT_PROC_DEVICE_START_ID U(202)
+#define PLAT_CLUSTER_DEVICE_START_ID U(198)
#endif /* BOARD_DEF_H */
diff --git a/plat/ti/k3/board/lite/include/board_def.h b/plat/ti/k3/board/lite/include/board_def.h
index 7c7ea62..18b7f42 100644
--- a/plat/ti/k3/board/lite/include/board_def.h
+++ b/plat/ti/k3/board/lite/include/board_def.h
@@ -20,15 +20,26 @@
* It may need to be increased if BL31 grows in size.
* Current computation assumes data structures necessary for GIC and ARM for
* a single cluster of 4 processor.
+ *
+ * The link addresses are determined by SEC_SRAM_BASE + offset.
+ * When ENABLE_PIE is set, the TF images can be loaded anywhere, so
+ * SEC_SRAM_BASE is really arbitrary.
+ *
+ * When ENABLE_PIE is unset, SEC_SRAM_BASE should be chosen so that
+ * it matches to the physical address where BL31 is loaded, that is,
+ * SEC_SRAM_BASE should be the base address of the RAM region.
+ *
+ * Lets make things explicit by mapping SRAM_BASE to 0x0 since ENABLE_PIE is
+ * defined as default for our platform.
*/
-#define SEC_SRAM_BASE 0x70000000 /* Base of SRAM */
-#define SEC_SRAM_SIZE 0x0001a000 /* 104k */
+#define SEC_SRAM_BASE UL(0x00000000) /* PIE remapped on fly */
+#define SEC_SRAM_SIZE UL(0x0001c000) /* 112k */
#define PLAT_MAX_OFF_STATE U(2)
#define PLAT_MAX_RET_STATE U(1)
-#define PLAT_PROC_START_ID 32
-#define PLAT_PROC_DEVICE_START_ID 135
-#define PLAT_CLUSTER_DEVICE_START_ID 134
+#define PLAT_PROC_START_ID U(32)
+#define PLAT_PROC_DEVICE_START_ID U(135)
+#define PLAT_CLUSTER_DEVICE_START_ID U(134)
#endif /* BOARD_DEF_H */
diff --git a/plat/ti/k3/common/k3_bl31_setup.c b/plat/ti/k3/common/k3_bl31_setup.c
index ac4e60e..457c95d 100644
--- a/plat/ti/k3/common/k3_bl31_setup.c
+++ b/plat/ti/k3/common/k3_bl31_setup.c
@@ -101,7 +101,7 @@
void bl31_plat_arch_setup(void)
{
const mmap_region_t bl_regions[] = {
- MAP_REGION_FLAT(BL31_START, BL31_END - BL31_START, MT_MEMORY | MT_RW | MT_SECURE),
+ MAP_REGION_FLAT(BL31_START, BL31_SIZE, MT_MEMORY | MT_RW | MT_SECURE),
MAP_REGION_FLAT(BL_CODE_BASE, BL_CODE_END - BL_CODE_BASE, MT_CODE | MT_RO | MT_SECURE),
MAP_REGION_FLAT(BL_RO_DATA_BASE, BL_RO_DATA_END - BL_RO_DATA_BASE, MT_RO_DATA | MT_RO | MT_SECURE),
#if USE_COHERENT_MEM
diff --git a/plat/ti/k3/include/platform_def.h b/plat/ti/k3/include/platform_def.h
index f12fb0b..81a383a 100644
--- a/plat/ti/k3/include/platform_def.h
+++ b/plat/ti/k3/include/platform_def.h
@@ -60,7 +60,11 @@
* used, choose the smallest value needed to map the required virtual addresses
* for each BL stage.
*/
-#define MAX_XLAT_TABLES 8
+#if USE_COHERENT_MEM
+#define MAX_XLAT_TABLES 10
+#else
+#define MAX_XLAT_TABLES 9
+#endif
/*
* Defines the maximum number of regions that are allocated by the translation
