Merge changes from topic "allwinner-r329" into integration
* changes:
feat(plat/allwinner): add R329 support
refactor(plat/allwinner): allow custom BL31 offset
refactor(plat/allwinner): allow new AA64nAA32 position
fix(plat/allwinner): delay after enabling CPU power
diff --git a/docs/resources/diagrams/plantuml/spm_dfd.puml b/docs/resources/diagrams/plantuml/spm_dfd.puml
new file mode 100644
index 0000000..ad4996e
--- /dev/null
+++ b/docs/resources/diagrams/plantuml/spm_dfd.puml
@@ -0,0 +1,82 @@
+/'
+ ' Copyright (c) 2021, Arm Limited. All rights reserved.
+ '
+ ' SPDX-License-Identifier: BSD-3-Clause
+ '/
+
+/'
+TF-A SPMC Data Flow Diagram
+'/
+
+@startuml
+digraph tfa_dfd {
+
+ # 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="NS Client"]
+ ddr [label="External memory (DDR)"]
+
+ # 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]
+ smmu [label="SMMU" width=1.2 height=0.5]
+ uart [label="UART" width=1.2 height=0.5]
+ pe [label="PE" width=1.2 height=0.5]
+ }
+
+ # TF-A cluster
+ subgraph cluster_tfa {
+ label ="EL3 monitor";
+ graph [style=filled color="#000000" fillcolor="#faf9cd"]
+
+ bl31 [label="BL31" fillcolor="#ddffb3"];
+ spmd [label="SPMD" fillcolor="#ddffb3" height=1]
+ }
+
+ # SPMC cluster
+ subgraph cluster_spmc {
+ label ="SPMC";
+ graph [style=filled color="#000000" fillcolor="#faf9cd"]
+
+ spmc [label="SPMC" fillcolor="#ddffb3" height=1]
+ }
+ bl2 [label="BL2" width=1.2 height=0.5]
+ }
+
+ # Secure Partitions cluster
+ subgraph cluster_sp {
+ label ="Secure Partitions";
+ graph [style=filled color="#000000" fillcolor="#faf9cd"]
+
+ sp1 [label="SP1" fillcolor="#ddffb3" height=1]
+ sp2 [label="SP2" fillcolor="#ddffb3" height=1]
+ spn [label="SP..." fillcolor="#ddffb3" height=1]
+ }
+
+ # Interactions between nodes
+ sp1 -> spmc [dir="both" label="DF1"]
+ spmc -> spmd [dir="both" label="DF2"]
+ spmd -> nsec [dir="both" label="DF3"]
+ sp1 -> sp2 [dir="both" label="DF4"]
+ spmc -> smmu [lhead=cluster_spmc label="DF5"]
+ bl2 -> spmc [lhead=cluster_spmc label="DF6"]
+ bl2 -> spn [lhead=cluster_spmc label="DF6"]
+ sp1 -> ddr [dir="both" label="DF7"]
+ spmc -> ddr [dir="both" label="DF7"]
+}
+
+@enduml
diff --git a/docs/resources/diagrams/spm-threat-model-trust-boundaries.png b/docs/resources/diagrams/spm-threat-model-trust-boundaries.png
new file mode 100644
index 0000000..58898c5
--- /dev/null
+++ b/docs/resources/diagrams/spm-threat-model-trust-boundaries.png
Binary files differ
diff --git a/docs/threat_model/index.rst b/docs/threat_model/index.rst
index e8f09b9..b5ede69 100644
--- a/docs/threat_model/index.rst
+++ b/docs/threat_model/index.rst
@@ -1,5 +1,12 @@
Threat Model
-=============
+============
+
+Threat modeling is an important part of Secure Development Lifecycle (SDL)
+that helps us identify potential threats and mitigations affecting a system.
+
+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.
.. toctree::
:maxdepth: 1
@@ -7,6 +14,7 @@
:numbered:
threat_model
+ threat_model_spm
--------------
diff --git a/docs/threat_model/threat_model.rst b/docs/threat_model/threat_model.rst
index 9cee104..9f26487 100644
--- a/docs/threat_model/threat_model.rst
+++ b/docs/threat_model/threat_model.rst
@@ -1,13 +1,10 @@
-*****************
-Introduction
-*****************
-Threat modeling is an important part of Secure Development Lifecycle (SDL)
-that helps us identify potential threats and mitigations affecting a system.
+Generic threat model
+********************
-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.
+************************
+Introduction
+************************
+This document provides a generic threat model for TF-A firmware.
************************
Target of Evaluation
@@ -781,4 +778,4 @@
.. _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
+.. _Trusted Firmware-A Tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/
diff --git a/docs/threat_model/threat_model_spm.rst b/docs/threat_model/threat_model_spm.rst
new file mode 100644
index 0000000..96d33a2
--- /dev/null
+++ b/docs/threat_model/threat_model_spm.rst
@@ -0,0 +1,617 @@
+SPMC threat model
+*****************
+
+************************
+Introduction
+************************
+This document provides a threat model for the TF-A `Secure Partition Manager`_
+(SPM) implementation or more generally the S-EL2 reference firmware running on
+systems implementing the FEAT_SEL2 (formerly Armv8.4 Secure EL2) architecture
+extension. The SPM implementation is based on the `Arm Firmware Framework for
+Armv8-A`_ specification.
+
+In brief, the broad FF-A specification and S-EL2 firmware implementation
+provide:
+
+- Isolation of mutually mistrusting SW components, or endpoints in the FF-A
+ terminology.
+- Distinct sandboxes in the secure world called secure partitions. This permits
+ isolation of services from multiple vendors.
+- A standard protocol for communication and memory sharing between FF-A
+ endpoints.
+- Mutual isolation of the normal world and the secure world (e.g. a Trusted OS
+ is prevented to map an arbitrary NS physical memory region such as the kernel
+ or the Hypervisor).
+
+************************
+Target of Evaluation
+************************
+In this threat model, the target of evaluation is the S-EL2 firmware or the
+``Secure Partition Manager Core`` component (SPMC).
+The monitor and SPMD at EL3 are covered by the `Generic TF-A threat model`_.
+
+The scope for this threat model is:
+
+- The TF-A implementation for the S-EL2 SPMC based on the Hafnium hypervisor
+ running in the secure world of TrustZone (at S-EL2 exception level).
+ The threat model is not related to the normal world Hypervisor or VMs.
+ The S-EL1 SPMC solution is not covered.
+- The implementation complies with the FF-A v1.0 specification.
+- Secure partitions are statically provisioned at boot time.
+- Focus on the run-time part of the life-cycle (no specific emphasis on boot
+ time, factory firmware provisioning, firmware udpate etc.)
+- Not covering advanced or invasive physical attacks such as decapsulation,
+ FIB etc.
+- Assumes secure boot or in particular TF-A trusted boot (TBBR or dual CoT) is
+ enabled. An attacker cannot boot arbitrary images that are not approved by the
+ SiP or platform providers.
+
+Data Flow Diagram
+======================
+Figure 1 shows a high-level data flow diagram for the SPM split into an SPMD
+component at EL3 and an SPMC component at S-EL2. The SPMD mostly acts as a
+relayer/pass-through between the normal world and the secure world. It is
+assumed to expose small attack surface.
+
+A description of each diagram element is given in Table 1. In the diagram, the
+red broken lines indicate trust boundaries.
+
+Components outside of the broken lines are considered untrusted.
+
+.. uml:: ../resources/diagrams/plantuml/spm_dfd.puml
+ :caption: Figure 1: SPMC Data Flow Diagram
+
+.. table:: Table 1: SPMC Data Flow Diagram Description
+
+ +---------------------+--------------------------------------------------------+
+ | Diagram Element | Description |
+ +=====================+========================================================+
+ | ``DF1`` | SP to SPMC communication. FF-A function invocation or |
+ | | implementation-defined Hypervisor call. |
+ +---------------------+--------------------------------------------------------+
+ | ``DF2`` | SPMC to SPMD FF-A call. |
+ +---------------------+--------------------------------------------------------+
+ | ``DF3`` | SPMD to NS forwarding. |
+ +---------------------+--------------------------------------------------------+
+ | ``DF4`` | SP to SP FF-A direct message request/response. |
+ | | Note as a matter of simplifying the diagram |
+ | | the SP to SP communication happens through the SPMC |
+ | | (SP1 performs a direct message request to the |
+ | | SPMC targeting SP2 as destination. And similarly for |
+ | | the direct message response from SP2 to SP1). |
+ +---------------------+--------------------------------------------------------+
+ | ``DF5`` | HW control. |
+ +---------------------+--------------------------------------------------------+
+ | ``DF6`` | Bootloader image loading. |
+ +---------------------+--------------------------------------------------------+
+ | ``DF7`` | External memory access. |
+ +---------------------+--------------------------------------------------------+
+
+*********************
+Threat Analysis
+*********************
+
+This threat model follows a similar methodology to the `Generic TF-A threat model`_.
+The following sections define:
+
+- Trust boundaries
+- Assets
+- Theat agents
+- Threat types
+
+Trust boundaries
+============================
+
+- Normal world is untrusted.
+- Secure world and normal world are separate trust boundaries.
+- EL3 monitor, SPMD and SPMC are trusted.
+- Bootloaders (in particular BL1/BL2 if using TF-A) and run-time BL31 are
+ implicitely trusted by the usage of secure boot.
+- EL3 monitor, SPMD, SPMC do not trust SPs.
+
+.. figure:: ../resources/diagrams/spm-threat-model-trust-boundaries.png
+
+ Figure 2: Trust boundaries
+
+Assets
+============================
+
+The following assets are identified:
+
+- SPMC state.
+- SP state.
+- Information exchange between endpoints (partition messages).
+- SPMC secrets (e.g. pointer authentication key when enabled)
+- SP secrets (e.g. application keys).
+- Scheduling cycles.
+- Shared memory.
+
+Threat Agents
+============================
+
+The following threat agents are identified:
+
+- NS-Endpoint identifies a non-secure endpoint: normal world client at NS-EL2
+ (Hypervisor) or NS-EL1 (VM or OS kernel).
+- S-Endpoint identifies a secure endpoint typically a secure partition.
+- Hardware attacks (non-invasive) requiring a physical access to the device,
+ such as bus probing or DRAM stress.
+
+Threat types
+============================
+
+The following threat categories as exposed in the `Generic TF-A threat model`_
+are re-used:
+
+- Spoofing
+- Tampering
+- Repudiation
+- Information disclosure
+- Denial of service
+- Elevation of privileges
+
+Similarly this threat model re-uses the same threat risk ratings. The risk
+analysis is evaluated based on the environment being ``Server`` or ``Mobile``.
+
+Threat Assessment
+============================
+
+The following threats are identified by applying STRIDE analysis on each diagram
+element of the data flow diagram.
+
++------------------------+----------------------------------------------------+
+| ID | 01 |
++========================+====================================================+
+| ``Threat`` | **An endpoint impersonates the sender or receiver |
+| | FF-A ID in a direct request/response invocation.** |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF2, DF3, DF4 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMD, SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SP state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Spoofing |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------++----------------+---------------+
+| ``Impact`` | Critical(5) | Critical(5) | |
++------------------------+------------------++----------------+---------------+
+| ``Likelihood`` | Critical(5) | Critical(5) | |
++------------------------+------------------++----------------+---------------+
+| ``Total Risk Rating`` | Critical(25) | Critical(25) | |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | The TF-A SPMC does not mitigate this threat. |
+| | The guidance below is left for a system integrator |
+| | to implemented as necessary. |
+| | The SPMC must enforce checks in the direct message |
+| | request/response interfaces such an endpoint cannot|
+| | spoof the origin and destination worlds (e.g. a NWd|
+| | originated message directed to the SWd cannot use a|
+| | SWd ID as the sender ID). |
+| | Additionally a software component residing in the |
+| | SPMC can be added for the purpose of direct |
+| | request/response filtering. |
+| | It can be configured with the list of known IDs |
+| | and about which interaction can occur between one |
+| | and another endpoint (e.g. which NWd endpoint ID |
+| | sends a direct request to which SWd endpoint ID). |
+| | This component checks the sender/receiver fields |
+| | for a legitimate communication between endpoints. |
+| | A similar component can exist in the OS kernel |
+| | driver, or Hypervisor although it remains untrusted|
+| | by the SPMD/SPMC. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 02 |
++========================+====================================================+
+| ``Threat`` | **Tampering with memory shared between an endpoint |
+| | and the SPMC.** |
+| | A malicious endpoint may attempt tampering with its|
+| | RX/TX buffer contents while the SPMC is processing |
+| | it (TOCTOU). |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF3, DF4, DF7 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | Shared memory, Information exchange |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Tampering |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | High (4) | High (4) | |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | High (4) | High (4) | |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | High (16) | High (16) | |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | In context of FF-A v1.0 this is the case of sharing|
+| | the RX/TX buffer pair and usage in the |
+| | PARTITION_INFO_GET or mem sharing primitives. |
+| | The SPMC must copy the contents of the TX buffer |
+| | to an internal temporary buffer before processing |
+| | its contents. The SPMC must implement hardened |
+| | input validation on data transmitted through the TX|
+| | buffer by an untrusted endpoint. |
+| | The TF-A SPMC mitigates this threat by enforcing |
+| | checks on data transmitted through RX/TX buffers. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 03 |
++========================+====================================================+
+| ``Threat`` | **An endpoint may tamper with its own state or the |
+| | state of another endpoint.** |
+| | A malicious endpoint may attempt violating: |
+| | - its own or another SP state by using an unusual |
+| | combination (or out-of-order) FF-A function |
+| | invocations. |
+| | This can also be an endpoint emitting |
+| | FF-A function invocations to another endpoint while|
+| | the latter in not in a state to receive it (e.g. a |
+| | SP sends a direct request to the normal world early|
+| | while the normal world is not booted yet). |
+| | - the SPMC state itself by employing unexpected |
+| | transitions in FF-A memory sharing, direct requests|
+| | and responses, or handling of interrupts. |
+| | This can be led by random stimuli injection or |
+| | fuzzing. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF2, DF3, DF4 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMD, SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SP state, SPMC state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Tampering |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | High (4) | High (4) | |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | Medium (3) | Medium (3) | |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | High (12) | High (12) | |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | The SPMC may be vulnerable to invalid state |
+| | transitions for itself or while handling an SP |
+| | state. The FF-A v1.1 specification provides a |
+| | guidance on those state transitions (run-time |
+| | model). The TF-A SPMC will be hardened in future |
+| | releases to follow this guidance. |
+| | Additionally The TF-A SPMC mitigates the threat by |
+| | runs of the Arm `FF-A ACS`_ compliance test suite. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 04 |
++========================+====================================================+
+| ``Threat`` | *An attacker may attempt injecting errors by the |
+| | use of external DRAM stress techniques.** |
+| | A malicious agent may attempt toggling an SP |
+| | Stage-2 MMU descriptor bit within the page tables |
+| | that the SPMC manages. This can happen in Rowhammer|
+| | types of attack. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF7 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SP or SPMC state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | Hardware attack |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Tampering |
++------------------------+------------------+---------------+-----------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+---------------+-----------------+
+| ``Impact`` | High (4) | High (4) | |
++------------------------+------------------+---------------+-----------------+
+| ``Likelihood`` | Low (2) | Medium (3) | |
++------------------------+------------------+---------------+-----------------+
+| ``Total Risk Rating`` | Medium (8) | High (12) | |
++------------------------+------------------+---------------+-----------------+
+| ``Mitigations`` | The TF-A SPMC does not provide mitigations to this |
+| | type of attack. It can be addressed by the use of |
+| | dedicated HW circuity or hardening at the chipset |
+| | or platform level left to the integrator. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 05 |
++========================+====================================================+
+| ``Threat`` | **Protection of the SPMC from a DMA capable device |
+| | upstream to an SMMU.** |
+| | A device may attempt to tamper with the internal |
+| | SPMC code/data sections. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF5 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SPMC or SP state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Tampering, Elevation of privileges |
++------------------------+------------------+---------------+-----------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+---------------+-----------------+
+| ``Impact`` | High (4) | High (4) | |
++------------------------+------------------+---------------+-----------------+
+| ``Likelihood`` | Medium (3) | Medium (3) | |
++------------------------+------------------+---------------+-----------------+
+| ``Total Risk Rating`` | High (12) | High (12) | |
++------------------------+------------------+---------------+-----------------+
+| ``Mitigations`` | A platform may prefer assigning boot time, |
+| | statically alocated memory regions through the SMMU|
+| | configuration and page tables. The FF-A v1.1 |
+| | specification provisions this capability through |
+| | static DMA isolation. |
+| | The TF-A SPMC does not mitigate this threat. |
+| | It will adopt the static DMA isolation approach in |
+| | a future release. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 06 |
++========================+====================================================+
+| ``Threat`` | **Replay fragments of past communication between |
+| | endpoints.** |
+| | A malicious endpoint may replay a message exchange |
+| | that occured between two legitimate endpoint as |
+| | a matter of triggering a malfunction or extracting |
+| | secrets from the receiving endpoint. In particular |
+| | the memory sharing operation with fragmented |
+| | messages between an endpoint and the SPMC may be |
+| | replayed by a malicious agent as a matter of |
+| | getting access or gaining permissions to a memory |
+| | region which does not belong to this agent. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF2, DF3 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | Information exchange |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Repdudiation |
++------------------------+------------------+---------------+-----------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+---------------+-----------------+
+| ``Impact`` | Medium (3) | Medium (3) | |
++------------------------+------------------+---------------+-----------------+
+| ``Likelihood`` | High (4) | High (4) | |
++------------------------+------------------+---------------+-----------------+
+| ``Total Risk Rating`` | High (12) | High (12) | |
++------------------------+------------------+---------------+-----------------+
+| ``Mitigations`` | The TF-A SPMC does not mitigate this threat. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 07 |
++========================+====================================================+
+| ``Threat`` | **A malicious endpoint may attempt to extract data |
+| | or state information by the use of invalid or |
+| | incorrect input arguments.** |
+| | Lack of input parameter validation or side effects |
+| | of maliciously forged input parameters might affect|
+| | the SPMC. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF2, DF3, DF4 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMD, SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SP secrets, SPMC secrets, SP state, SPMC state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Information discolure |
++------------------------+------------------+---------------+-----------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+---------------+-----------------+
+| ``Impact`` | High (4) | High (4) | |
++------------------------+------------------+---------------+-----------------+
+| ``Likelihood`` | Medium (3) | Medium (3) | |
++------------------------+------------------+---------------+-----------------+
+| ``Total Risk Rating`` | High (12) | High (12) | |
++------------------------+------------------+---------------+-----------------+
+| ``Mitigations`` | Secure Partitions must follow security standards |
+| | and best practises as a way to mitigate the risk |
+| | of common vulnerabilities to be exploited. |
+| | The use of software (canaries) or hardware |
+| | hardening techniques (XN, WXN, BTI, pointer |
+| | authentication, MTE) helps detecting and stopping |
+| | an exploitation early. |
+| | The TF-A SPMC mitigates this threat by implementing|
+| | stack protector, pointer authentication, BTI, XN, |
+| | WXN, security hardening techniques. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 08 |
++========================+====================================================+
+| ``Threat`` | **A malicious endpoint may forge a direct message |
+| | request such that it reveals the internal state of |
+| | another endpoint through the direct message |
+| | response.** |
+| | The secure partition or SPMC replies to a partition|
+| | message by a direct message response with |
+| | information which may reveal its internal state |
+| | (.e.g. partition message response outside of |
+| | allowed bounds). |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF2, DF3, DF4 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SPMC or SP state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Information discolure |
++------------------------+------------------+---------------+-----------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+---------------+-----------------+
+| ``Impact`` | Medium (3) | Medium (3) | |
++------------------------+------------------+---------------+-----------------+
+| ``Likelihood`` | Low (2) | Low (2) | |
++------------------------+------------------+---------------+-----------------+
+| ``Total Risk Rating`` | Medium (6) | Medium (6) | |
++------------------------+------------------+---------------+-----------------+
+| ``Mitigations`` | For the specific case of direct requests targetting|
+| | the SPMC, the latter is hardened to prevent |
+| | its internal state or the state of an SP to be |
+| | revealed through a direct message response. |
+| | Further FF-A v1.1 guidance about run time models |
+| | and partition states will be implemented in future |
+| | TF-A SPMC releases. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 09 |
++========================+====================================================+
+| ``Threat`` | **Probing the FF-A communication between |
+| | endpoints.** |
+| | SPMC and SPs are typically loaded to external |
+| | memory (protected by a TrustZone memory |
+| | controller). A malicious agent may use non invasive|
+| | methods to probe the external memory bus and |
+| | extract the traffic between an SP and the SPMC or |
+| | among SPs when shared buffers are held in external |
+| | memory. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF7 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SP/SPMC state, SP/SPMC secrets |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | Hardware attack |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Information disclosure |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | Medium (3) | Medium (3) | |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | Low (2) | Medium (3) | |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | Medium (6) | Medium (9) | |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | It is expected the platform or chipset provides |
+| | guarantees in protecting the DRAM contents. |
+| | The TF-A SPMC does not mitigate this class of |
+| | attack and this is left to the integrator. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 10 |
++========================+====================================================+
+| ``Threat`` | **A malicious agent may attempt revealing the SPMC |
+| | state or secrets by the use of software-based cache|
+| | side-channel attack techniques.** |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF7 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SP or SPMC state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Information disclosure |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | Medium (3) | Medium (3) | |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | Low (2) | Low (2) | |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | Medium (6) | Medium (6) | |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | From an integration perspective it is assumed |
+| | platforms consuming the SPMC component at S-EL2 |
+| | (hence implementing the Armv8.4 FEAT_SEL2 |
+| | architecture extension) implement mitigations to |
+| | Spectre, Meltdown or other cache timing |
+| | side-channel type of attacks. |
+| | The TF-A SPMC implements one mitigation (barrier |
+| | preventing speculation past exeception returns). |
+| | The SPMC may be hardened further with SW |
+| | mitigations (e.g. speculation barriers) for the |
+| | cases not covered in HW. Usage of hardened |
+| | compilers and appropriate options, code inspection |
+| | are recommended ways to mitigate Spectre types of |
+| | attacks. For non-hardened cores, the usage of |
+| | techniques such a kernel page table isolation can |
+| | help mitigating Meltdown type of attacks. |
++------------------------+----------------------------------------------------+
+
++------------------------+----------------------------------------------------+
+| ID | 11 |
++========================+====================================================+
+| ``Threat`` | **A malicious endpoint may attempt flooding the |
+| | SPMC with requests targetting a service within an |
+| | endpoint such that it denies another endpoint to |
+| | access this service.** |
+| | Similarly, the malicious endpoint may target a |
+| | a service within an endpoint such that the latter |
+| | is unable to request services from another |
+| | endpoint. |
++------------------------+----------------------------------------------------+
+| ``Diagram Elements`` | DF1, DF2, DF3, DF4 |
++------------------------+----------------------------------------------------+
+| ``Affected TF-A | SPMC |
+| Components`` | |
++------------------------+----------------------------------------------------+
+| ``Assets`` | SPMC state |
++------------------------+----------------------------------------------------+
+| ``Threat Agent`` | NS-Endpoint, S-Endpoint |
++------------------------+----------------------------------------------------+
+| ``Threat Type`` | Denial of service |
++------------------------+------------------+-----------------+---------------+
+| ``Application`` | ``Server`` | ``Mobile`` | |
++------------------------+------------------+-----------------+---------------+
+| ``Impact`` | Medium (3) | Medium (3) | |
++------------------------+------------------+-----------------+---------------+
+| ``Likelihood`` | Medium (3) | Medium (3) | |
++------------------------+------------------+-----------------+---------------+
+| ``Total Risk Rating`` | Medium (9) | Medium (9) | |
++------------------------+------------------+-----------------+---------------+
+| ``Mitigations`` | The TF-A SPMC does not mitigate this threat. |
+| | Bounding the time for operations to complete can |
+| | be achieved by the usage of a trusted watchdog. |
+| | Other quality of service monitoring can be achieved|
+| | in the SPMC such as counting a number of operations|
+| | in a limited timeframe. |
++------------------------+----------------------------------------------------+
+
+--------------
+
+*Copyright (c) 2021, Arm Limited. All rights reserved.*
+
+.. _Arm Firmware Framework for Armv8-A: https://developer.arm.com/docs/den0077/latest
+.. _Secure Partition Manager: ../components/secure-partition-manager.html
+.. _Generic TF-A threat model: ./threat_model.html#threat-analysis
+.. _FF-A ACS: https://github.com/ARM-software/ff-a-acs/releases
diff --git a/include/lib/cpus/aarch64/cortex_demeter.h b/include/lib/cpus/aarch64/cortex_demeter.h
new file mode 100644
index 0000000..9dd0987
--- /dev/null
+++ b/include/lib/cpus/aarch64/cortex_demeter.h
@@ -0,0 +1,23 @@
+/*
+ * Copyright (c) 2021, Arm Limited. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#ifndef CORTEX_DEMETER_H
+#define CORTEX_DEMETER_H
+
+#define CORTEX_DEMETER_MIDR U(0x410FD4F0)
+
+/*******************************************************************************
+ * CPU Extended Control register specific definitions
+ ******************************************************************************/
+#define CORTEX_DEMETER_CPUECTLR_EL1 S3_0_C15_C1_4
+
+/*******************************************************************************
+ * CPU Power Control register specific definitions
+ ******************************************************************************/
+#define CORTEX_DEMETER_CPUPWRCTLR_EL1 S3_0_C15_C2_7
+#define CORTEX_DEMETER_CPUPWRCTLR_EL1_CORE_PWRDN_BIT U(1)
+
+#endif /* CORTEX_DEMETER_H */
diff --git a/include/lib/el3_runtime/cpu_data.h b/include/lib/el3_runtime/cpu_data.h
index 5426135..3d57a5c 100644
--- a/include/lib/el3_runtime/cpu_data.h
+++ b/include/lib/el3_runtime/cpu_data.h
@@ -1,5 +1,5 @@
/*
- * Copyright (c) 2014-2019, ARM Limited and Contributors. All rights reserved.
+ * Copyright (c) 2014-2021, ARM Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
@@ -125,7 +125,7 @@
#if ENABLE_PAUTH
CASSERT(CPU_DATA_APIAKEY_OFFSET == __builtin_offsetof
(cpu_data_t, apiakey),
- assert_cpu_data_crash_stack_offset_mismatch);
+ assert_cpu_data_pauth_stack_offset_mismatch);
#endif
#if CRASH_REPORTING
diff --git a/lib/cpus/aarch64/cortex_demeter.S b/lib/cpus/aarch64/cortex_demeter.S
new file mode 100644
index 0000000..9ad8b86
--- /dev/null
+++ b/lib/cpus/aarch64/cortex_demeter.S
@@ -0,0 +1,77 @@
+/*
+ * Copyright (c) 2021, Arm Limited. All rights reserved.
+ *
+ * SPDX-License-Identifier: BSD-3-Clause
+ */
+
+#include <arch.h>
+#include <asm_macros.S>
+#include <common/bl_common.h>
+#include <cortex_demeter.h>
+#include <cpu_macros.S>
+#include <plat_macros.S>
+
+/* Hardware handled coherency */
+#if HW_ASSISTED_COHERENCY == 0
+#error "Cortex Demeter must be compiled with HW_ASSISTED_COHERENCY enabled"
+#endif
+
+/* 64-bit only core */
+#if CTX_INCLUDE_AARCH32_REGS == 1
+#error "Cortex Demeter supports only AArch64. Compile with CTX_INCLUDE_AARCH32_REGS=0"
+#endif
+
+ /* ----------------------------------------------------
+ * HW will do the cache maintenance while powering down
+ * ----------------------------------------------------
+ */
+func cortex_demeter_core_pwr_dwn
+ /* ---------------------------------------------------
+ * Enable CPU power down bit in power control register
+ * ---------------------------------------------------
+ */
+ mrs x0, CORTEX_DEMETER_CPUPWRCTLR_EL1
+ orr x0, x0, #CORTEX_DEMETER_CPUPWRCTLR_EL1_CORE_PWRDN_BIT
+ msr CORTEX_DEMETER_CPUPWRCTLR_EL1, x0
+ isb
+ ret
+endfunc cortex_demeter_core_pwr_dwn
+
+#if REPORT_ERRATA
+/*
+ * Errata printing function for Cortex Demeter. Must follow AAPCS.
+ */
+func cortex_demeter_errata_report
+ ret
+endfunc cortex_demeter_errata_report
+#endif
+
+func cortex_demeter_reset_func
+ /* Disable speculative loads */
+ msr SSBS, xzr
+ isb
+ ret
+endfunc cortex_demeter_reset_func
+
+ /* ---------------------------------------------
+ * This function provides Cortex Demeter-
+ * specific register information for crash
+ * reporting. It needs to return with x6
+ * pointing to a list of register names in ascii
+ * and x8 - x15 having values of registers to be
+ * reported.
+ * ---------------------------------------------
+ */
+.section .rodata.cortex_demeter_regs, "aS"
+cortex_demeter_regs: /* The ascii list of register names to be reported */
+ .asciz "cpuectlr_el1", ""
+
+func cortex_demeter_cpu_reg_dump
+ adr x6, cortex_demeter_regs
+ mrs x8, CORTEX_DEMETER_CPUECTLR_EL1
+ ret
+endfunc cortex_demeter_cpu_reg_dump
+
+declare_cpu_ops cortex_demeter, CORTEX_DEMETER_MIDR, \
+ cortex_demeter_reset_func, \
+ cortex_demeter_core_pwr_dwn
diff --git a/plat/arm/board/fvp/platform.mk b/plat/arm/board/fvp/platform.mk
index 10258ad..3c70eed 100644
--- a/plat/arm/board/fvp/platform.mk
+++ b/plat/arm/board/fvp/platform.mk
@@ -135,6 +135,7 @@
lib/cpus/aarch64/cortex_a710.S \
lib/cpus/aarch64/cortex_makalu.S \
lib/cpus/aarch64/cortex_makalu_elp_arm.S \
+ lib/cpus/aarch64/cortex_demeter.S \
lib/cpus/aarch64/cortex_a65.S \
lib/cpus/aarch64/cortex_a65ae.S \
lib/cpus/aarch64/cortex_a78c.S
diff --git a/plat/qemu/qemu/include/platform_def.h b/plat/qemu/qemu/include/platform_def.h
index 0891d80..c02eff9 100644
--- a/plat/qemu/qemu/include/platform_def.h
+++ b/plat/qemu/qemu/include/platform_def.h
@@ -80,8 +80,8 @@
#define SEC_ROM_BASE 0x00000000
#define SEC_ROM_SIZE 0x00020000
-#define NS_DRAM0_BASE 0x40000000
-#define NS_DRAM0_SIZE 0xc0000000
+#define NS_DRAM0_BASE ULL(0x40000000)
+#define NS_DRAM0_SIZE ULL(0xc0000000)
#define SEC_SRAM_BASE 0x0e000000
#define SEC_SRAM_SIZE 0x00060000
diff --git a/plat/rpi/rpi4/rpi4_bl31_setup.c b/plat/rpi/rpi4/rpi4_bl31_setup.c
index cfacd1f..5259859 100644
--- a/plat/rpi/rpi4/rpi4_bl31_setup.c
+++ b/plat/rpi/rpi4/rpi4_bl31_setup.c
@@ -201,6 +201,44 @@
enable_mmu_el3(0);
}
+/*
+ * Remove the FDT /memreserve/ entry that covers the region at the very
+ * beginning of memory (if that exists). This is where the secondaries
+ * originally spin, but we pull them out there.
+ * Having overlapping /reserved-memory and /memreserve/ regions confuses
+ * the Linux kernel, so we need to get rid of this one.
+ */
+static void remove_spintable_memreserve(void *dtb)
+{
+ uint64_t addr, size;
+ int regions = fdt_num_mem_rsv(dtb);
+ int i;
+
+ for (i = 0; i < regions; i++) {
+ if (fdt_get_mem_rsv(dtb, i, &addr, &size) != 0) {
+ return;
+ }
+ if (size == 0U) {
+ return;
+ }
+ /* We only look for the region at the beginning of DRAM. */
+ if (addr != 0U) {
+ continue;
+ }
+ /*
+ * Currently the region in the existing DTs is exactly 4K
+ * in size. Should this value ever change, there is probably
+ * a reason for that, so inform the user about this.
+ */
+ if (size == 4096U) {
+ fdt_del_mem_rsv(dtb, i);
+ return;
+ }
+ WARN("Keeping unknown /memreserve/ region at 0, size: %lld\n",
+ size);
+ }
+}
+
static void rpi4_prepare_dtb(void)
{
void *dtb = (void *)rpi4_get_dtb_address();
@@ -227,7 +265,11 @@
return;
}
- /* Reserve memory used by Trusted Firmware. */
+ /*
+ * Remove the original reserved region (used for the spintable), and
+ * replace it with a region describing the whole of Trusted Firmware.
+ */
+ remove_spintable_memreserve(dtb);
if (fdt_add_reserved_memory(dtb, "atf@0", 0, 0x80000))
WARN("Failed to add reserved memory nodes to DT.\n");
diff --git a/plat/st/stm32mp1/bl2_plat_setup.c b/plat/st/stm32mp1/bl2_plat_setup.c
index 3e179fb..b4c42fc 100644
--- a/plat/st/stm32mp1/bl2_plat_setup.c
+++ b/plat/st/stm32mp1/bl2_plat_setup.c
@@ -153,8 +153,6 @@
#ifdef AARCH32_SP_OPTEE
INFO("BL2 runs OP-TEE setup\n");
- /* Initialize tzc400 after DDR initialization */
- stm32mp1_security_setup();
#else
INFO("BL2 runs SP_MIN setup\n");
#endif
@@ -384,4 +382,9 @@
return err;
}
+
+void bl2_el3_plat_prepare_exit(void)
+{
+ stm32mp1_security_setup();
+}
#endif
diff --git a/plat/xilinx/zynqmp/pm_service/pm_api_ioctl.c b/plat/xilinx/zynqmp/pm_service/pm_api_ioctl.c
index f165fb0..9c5af88 100644
--- a/plat/xilinx/zynqmp/pm_service/pm_api_ioctl.c
+++ b/plat/xilinx/zynqmp/pm_service/pm_api_ioctl.c
@@ -677,6 +677,10 @@
case IOCTL_AFI:
ret = pm_ioctl_afi(arg1, arg2);
break;
+ case IOCTL_SET_FEATURE_CONFIG:
+ case IOCTL_GET_FEATURE_CONFIG:
+ ret = pm_feature_config(ioctl_id, arg1, arg2, value);
+ break;
default:
ret = PM_RET_ERROR_NOTSUPPORTED;
break;
diff --git a/plat/xilinx/zynqmp/pm_service/pm_api_ioctl.h b/plat/xilinx/zynqmp/pm_service/pm_api_ioctl.h
index 337f732..f18dc00 100644
--- a/plat/xilinx/zynqmp/pm_service/pm_api_ioctl.h
+++ b/plat/xilinx/zynqmp/pm_service/pm_api_ioctl.h
@@ -15,28 +15,43 @@
//ioctl id
enum {
- IOCTL_GET_RPU_OPER_MODE,
- IOCTL_SET_RPU_OPER_MODE,
- IOCTL_RPU_BOOT_ADDR_CONFIG,
- IOCTL_TCM_COMB_CONFIG,
- IOCTL_SET_TAPDELAY_BYPASS,
- IOCTL_SET_SGMII_MODE,
- IOCTL_SD_DLL_RESET,
- IOCTL_SET_SD_TAPDELAY,
+ IOCTL_GET_RPU_OPER_MODE = 0,
+ IOCTL_SET_RPU_OPER_MODE = 1,
+ IOCTL_RPU_BOOT_ADDR_CONFIG = 2,
+ IOCTL_TCM_COMB_CONFIG = 3,
+ IOCTL_SET_TAPDELAY_BYPASS = 4,
+ IOCTL_SET_SGMII_MODE = 5,
+ IOCTL_SD_DLL_RESET = 6,
+ IOCTL_SET_SD_TAPDELAY = 7,
/* Ioctl for clock driver */
- IOCTL_SET_PLL_FRAC_MODE,
- IOCTL_GET_PLL_FRAC_MODE,
- IOCTL_SET_PLL_FRAC_DATA,
- IOCTL_GET_PLL_FRAC_DATA,
- IOCTL_WRITE_GGS,
- IOCTL_READ_GGS,
- IOCTL_WRITE_PGGS,
- IOCTL_READ_PGGS,
+ IOCTL_SET_PLL_FRAC_MODE = 8,
+ IOCTL_GET_PLL_FRAC_MODE = 9,
+ IOCTL_SET_PLL_FRAC_DATA = 10,
+ IOCTL_GET_PLL_FRAC_DATA = 11,
+ IOCTL_WRITE_GGS = 12,
+ IOCTL_READ_GGS = 13,
+ IOCTL_WRITE_PGGS = 14,
+ IOCTL_READ_PGGS = 15,
/* IOCTL for ULPI reset */
- IOCTL_ULPI_RESET,
+ IOCTL_ULPI_RESET = 16,
/* Set healthy bit value */
- IOCTL_SET_BOOT_HEALTH_STATUS,
- IOCTL_AFI,
+ IOCTL_SET_BOOT_HEALTH_STATUS = 17,
+ IOCTL_AFI = 18,
+ /* Probe counter read/write */
+ IOCTL_PROBE_COUNTER_READ = 19,
+ IOCTL_PROBE_COUNTER_WRITE = 20,
+ IOCTL_OSPI_MUX_SELECT = 21,
+ /* IOCTL for USB power request */
+ IOCTL_USB_SET_STATE = 22,
+ /* IOCTL to get last reset reason */
+ IOCTL_GET_LAST_RESET_REASON = 23,
+ /* AI engine NPI ISR clear */
+ IOCTL_AIE_ISR_CLEAR = 24,
+ /* Register SGI to ATF */
+ IOCTL_REGISTER_SGI = 25,
+ /* Runtime feature configuration */
+ IOCTL_SET_FEATURE_CONFIG = 26,
+ IOCTL_GET_FEATURE_CONFIG = 27,
};
//RPU operation mode
diff --git a/plat/xilinx/zynqmp/pm_service/pm_api_sys.c b/plat/xilinx/zynqmp/pm_service/pm_api_sys.c
index 62260bc..5d9408c 100644
--- a/plat/xilinx/zynqmp/pm_service/pm_api_sys.c
+++ b/plat/xilinx/zynqmp/pm_service/pm_api_sys.c
@@ -1648,3 +1648,36 @@
EM_PACK_PAYLOAD1(payload, EM_SEND_ERRORS);
return pm_ipi_send_sync(primary_proc, payload, value, 1);
}
+
+/**
+ * pm_feature_config() - feature configuration at runtime
+ *
+ * This function is used to send IPI request to PMUFW to configure feature
+ * at runtime. The feature can be enable or disable as well as the feature
+ * can be configure at runtime using an IOCTL call.
+ *
+ * @ioctl_id The ioctl id for the feature configuration
+ * @config_id The config id of the feature to be configured
+ * @value The value to be configured
+ * @response Return to reference pointer
+ *
+ * @return Returns 0 on success or error value on failure
+ */
+enum pm_ret_status pm_feature_config(unsigned int ioctl_id,
+ unsigned int config_id,
+ unsigned int value,
+ unsigned int *response)
+{
+ uint32_t payload[PAYLOAD_ARG_CNT];
+
+ /* Send request to the PMU */
+ PM_PACK_PAYLOAD5(payload, PM_IOCTL, 0, ioctl_id, config_id, value);
+
+ if (ioctl_id == IOCTL_GET_FEATURE_CONFIG) {
+ return pm_ipi_send_sync(primary_proc, payload, response, 1);
+ } else if (ioctl_id == IOCTL_SET_FEATURE_CONFIG) {
+ return pm_ipi_send_sync(primary_proc, payload, NULL, 0);
+ } else {
+ return PM_RET_ERROR_ARGS;
+ }
+}
diff --git a/plat/xilinx/zynqmp/pm_service/pm_api_sys.h b/plat/xilinx/zynqmp/pm_service/pm_api_sys.h
index b0c2652..ca07cef 100644
--- a/plat/xilinx/zynqmp/pm_service/pm_api_sys.h
+++ b/plat/xilinx/zynqmp/pm_service/pm_api_sys.h
@@ -202,4 +202,9 @@
enum pm_ret_status em_remove_action(unsigned int *value);
enum pm_ret_status em_send_errors(unsigned int *value);
+enum pm_ret_status pm_feature_config(unsigned int ioctl_id,
+ unsigned int config_id,
+ unsigned int value,
+ unsigned int *response);
+
#endif /* PM_API_SYS_H */
