Djam/arm-trusted-firmware
1
0
Fork 0
mirror of https://github.com/ARM-software/arm-trusted-firmware.git synced 2025-04-25 14:25:44 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

Merge changes from topic "ffa_el3_spmc" into integration

Browse source 
* changes:
  docs(spm): add threat model for el3 spmc
  docs(spm): add design documentation
This commit is contained in:
Olivier Deprez 2022-10-28 10:22:39 +02:00 • committed by TrustedFirmware Code Review
commit 77a53b8fe4
8 changed files with 1330 additions and 0 deletions

597
docs/components/el3-spmc.rst Normal file
View file

@ -0,0 +1,597 @@
EL3 Secure Partition Manager
****************************
.. contents::
Foreword
========
This document describes the design of the EL3 SPMC based on the FF-A specification.
EL3 SPMC provides reference FF-A compliant implementation without S-EL2 virtualization support,
to help adopt and migrate to FF-A early.
EL3 SPMC implementation in TF-A:
- Manages a single S-EL1 Secure Partition
- Provides a standard protocol for communication and memory sharing between FF-A endpoints.
- Provides support for EL3 Logical Partitions to support easy migration from EL3 to S-EL1.
Sample reference stack
======================
The following diagram illustrates a possible configuration when the
FEAT_SEL2 architecture extension is not implemented, showing the SPMD
and SPMC at EL3, one S-EL1 secure partition, with an optional
Hypervisor:
.. image:: ../resources/diagrams/ff-a-spm-at-el3.png
TF-A build options
==================
This section explains the TF-A build options involved in building
an FF-A based SPM where the SPMD and SPMC are located at EL3:
- **SPD=spmd**: this option selects the SPMD component to relay the FF-A
protocol from NWd to SWd back and forth. It is not possible to
enable another Secure Payload Dispatcher when this option is chosen.
- **SPMC_AT_EL3**: this option adjusts the SPMC exception level to being
at EL3.
- **ARM_SPMC_MANIFEST_DTS**: this option specifies a manifest file
providing SP description. It is required when
``SPMC_AT_EL3`` is enabled, the secure partitions are loaded
by BL2 on behalf of the SPMC.
Notes:
- BL32 option is re-purposed to specify the S-EL1 TEE or SP image.
BL32 option can be omitted if using TF-A Test Secure Payload as SP.
- BL33 option can specify the TFTF binary or a normal world loader
such as U-Boot or the UEFI framework payload.
Sample TF-A build command line when the SPMC is located at EL3:
.. code:: shell
make \
CROSS_COMPILE=aarch64-none-elf- \
SPD=spmd \
SPMD_SPM_AT_SEL2=0 \
SPMC_AT_EL3=1 \
BL32=<path-to-tee-binary> (opt for TSP) \
BL33=<path-to-bl33-binary> \
PLAT=fvp \
all fip
FVP model invocation
====================
Sample FVP command line invocation:
.. code:: shell
<path-to-fvp-model>/FVP_Base_RevC-2xAEMvA -C pctl.startup=0.0.0.0 \
-C cluster0.NUM_CORES=4 -C cluster1.NUM_CORES=4 -C bp.secure_memory=1 \
-C bp.secureflashloader.fname=trusted-firmware-a/build/fvp/debug/bl1.bin \
-C bp.flashloader0.fname=trusted-firmware-a/build/fvp/debug/fip.bin \
-C bp.pl011_uart0.out_file=fvp-uart0.log -C bp.pl011_uart1.out_file=fvp-uart1.log \
-C bp.pl011_uart2.out_file=fvp-uart2.log -C bp.vis.disable_visualisation=1
Platform Guide
==============
- Platform Hooks See - `[4]`_
- plat_spmc_shmem_begin
- plat_spmc_shmem_reclaim
SPMC provides platform hooks related to memory management interfaces.
These hooks can be used for platform specific implementations like
for managing access control, programming TZ Controller or MPUs.
These hooks are called by SPMC before the initial share request completes,
and after the final reclaim has been completed.
- Datastore
- plat_spmc_shmem_datastore_get
EL3 SPMC uses datastore for tracking memory transaction descriptors.
On FVP platform datastore is allocated from TZC DRAM section.
Other platforms need to allocate a similar secure memory region
to be used as shared memory datastore.
The accessor function is used during SPMC initialization to obtain
address and size of the datastore.
SPMC will also zero out the provided memory region.
- Platform Defines See - `[5]`_
- SECURE_PARTITION_COUNT
Number of Secure Partitions supported: must be 1.
- NS_PARTITION_COUNT
Number of NWd Partitions supported.
- MAX_EL3_LP_DESCS_COUNT
Number of Logical Partitions supported.
Logical Secure Partition (LSP)
==============================
- The SPMC provides support for statically allocated EL3 Logical Secure Partitions
as per FF-A v1.1 specification.
- The DECLARE_LOGICAL_PARTITION macro can be used to add a LSP.
- For reference implementation See - `[2]`_
.. image:: ../resources/diagrams/ff-a-lsp-at-el3.png
SPMC boot
=========
The SPMD and SPMC are built into the BL31 image along with TF-A's runtime components.
BL2 loads the BL31 image as a part of (secure) boot process.
The SPMC manifest is loaded by BL2 as the ``TOS_FW_CONFIG`` image `[9]`_.
BL2 passes the SPMC manifest address to BL31 through a register.
At boot time, the SPMD in BL31 runs from the primary core, initializes the core
contexts and launches the SPMC passing the following information through
registers:
- X0 holds the SPMC manifest blob address.
- X4 holds the currently running core linear id.
Parsing SP partition manifests
------------------------------
SPMC consumes the SP manifest, as defined in `[7]`_.
SP manifest fields align with Hafnium SP manifest for easy porting.
.. code:: shell
compatible = "arm,ffa-manifest-1.0";
ffa-version = <0x00010001>; /* 31:16 - Major, 15:0 - Minor */
id = <0x8001>;
uuid = <0x6b43b460 0x74a24b78 0xade24502 0x40682886>;
messaging-method = <0x3>; /* Direct Messaging Only */
exception-level = <0x2>; /* S-EL1 */
execution-state = <0>;
execution-ctx-count = <8>;
gp-register-num = <0>;
power-management-messages = <0x7>;
Passing boot data to the SP
---------------------------
In `[1]`_ , the section "Boot information protocol" defines a method for passing
data to the SPs at boot time. It specifies the format for the boot information
descriptor and boot information header structures, which describe the data to be
exchanged between SPMC and SP.
The specification also defines the types of data that can be passed.
The aggregate of both the boot info structures and the data itself is designated
the boot information blob, and is passed to a Partition as a contiguous memory
region.
Currently, the SPM implementation supports the FDT type which is used to pass the
partition's DTB manifest.
The region for the boot information blob is statically allocated (4K) by SPMC.
BLOB contains Boot Info Header, followed by SP Manifest contents.
The configuration of the boot protocol is done in the SP manifest. As defined by
the specification, the manifest field 'gp-register-num' configures the GP register
which shall be used to pass the address to the partitions boot information blob when
booting the partition.
Supported interfaces
====================
The following interfaces are exposed to SPs only:
- ``FFA_MSG_WAIT``
- ``FFA_MEM_RETRIEVE_REQ``
- ``FFA_MEM_RETRIEVE_RESP``
- ``FFA_MEM_RELINQUISH``
- ``FFA_SECONDARY_EP_REGISTER``
The following interfaces are exposed to both NS Client and SPs:
- ``FFA_VERSION``
- ``FFA_FEATURES``
- ``FFA_RX_RELEASE``
- ``FFA_RXTX_MAP``
- ``FFA_RXTX_UNMAP``
- ``FFA_PARTITION_INFO_GET``
- ``FFA_ID_GET``
- ``FFA_MSG_SEND_DIRECT_REQ``
- ``FFA_MSG_SEND_DIRECT_RESP``
- ``FFA_MEM_FRAG_TX``
- ``FFA_SPM_ID_GET``
The following additional interfaces are forwarded from SPMD to support NS Client:
- ``FFA_RUN``
- ``FFA_MEM_LEND``
- ``FFA_MEM_SHARE``
- ``FFA_MEM_FRAG_RX``
- ``FFA_MEM_RECLAIM``
FFA_VERSION
-----------
``FFA_VERSION`` requires a *requested_version* parameter from the caller.
SPMD forwards call to SPMC, the SPMC returns its own implemented version.
SPMC asserts SP and SPMC are at same FF-A Version.
FFA_FEATURES
------------
FF-A features supported by the SPMC may be discovered by secure partitions at
boot (that is prior to NWd is booted) or run-time.
The SPMC calling FFA_FEATURES at secure physical FF-A instance always get
FFA_SUCCESS from the SPMD.
The request made by an Hypervisor or OS kernel is forwarded to the SPMC and
the response relayed back to the NWd.
FFA_RXTX_MAP
------------
FFA_RXTX_UNMAP
--------------
When invoked from a secure partition FFA_RXTX_MAP maps the provided send and
receive buffers described by their PAs to the EL3 translation regime
as secure buffers in the MMU descriptors.
When invoked from the Hypervisor or OS kernel, the buffers are mapped into the
SPMC EL3 translation regime and marked as NS buffers in the MMU
descriptors.
The FFA_RXTX_UNMAP unmaps the RX/TX pair from the translation regime of the
caller, either it being the Hypervisor or OS kernel, as well as a secure
partition.
FFA_PARTITION_INFO_GET
----------------------
Partition info get call can originate:
- from SP to SPMC
- from Hypervisor or OS kernel to SPMC. The request is relayed by the SPMD.
The format (v1.0 or v1.1) of the populated data structure returned is based upon the
FFA version of the calling entity.
EL3 SPMC also supports returning only the count of partitions deployed.
All LSPs and SP are discoverable from FFA_PARTITION_INFO_GET call made by
either SP or NWd entities.
FFA_ID_GET
----------
The FF-A ID space is split into a non-secure space and secure space:
- FF-A ID with bit 15 clear relates to VMs.
- FF-A ID with bit 15 set related to SPs or LSPs.
- FF-A IDs 0, 0xffff, 0x8000 are assigned respectively to the Hypervisor
(or OS Kernel if Hyp is absent), SPMD and SPMC.
This convention helps the SPM to determine the origin and destination worlds in
an FF-A ABI invocation. In particular the SPM shall filter unauthorized
transactions in its world switch routine. It must not be permitted for a VM to
use a secure FF-A ID as origin world by spoofing:
- A VM-to-SP direct request/response shall set the origin world to be non-secure
(FF-A ID bit 15 clear) and destination world to be secure (FF-A ID bit 15
set).
- Similarly, an SP-to-LSP direct request/response shall set the FF-A ID bit 15
for both origin and destination IDs.
An incoming direct message request arriving at SPMD from NWd is forwarded to
SPMC without a specific check. The SPMC is resumed through eret and "knows" the
message is coming from normal world in this specific code path. Thus the origin
endpoint ID must be checked by SPMC for being a normal world ID.
An SP sending a direct message request must have bit 15 set in its origin
endpoint ID and this can be checked by the SPMC when the SP invokes the ABI.
The SPMC shall reject the direct message if the claimed world in origin endpoint
ID is not consistent:
- It is either forwarded by SPMD and thus origin endpoint ID must be a "normal
world ID",
- or initiated by an SP and thus origin endpoint ID must be a "secure world ID".
FFA_MSG_SEND_DIRECT_REQ
-----------------------
FFA_MSG_SEND_DIRECT_RESP
------------------------
This is a mandatory interface for secure partitions participating in direct request
and responses with the following rules:
- An SP can send a direct request to LSP.
- An LSP can send a direct response to SP.
- An SP cannot send a direct request to an Hypervisor or OS kernel.
- An Hypervisor or OS kernel can send a direct request to an SP or LSP.
- An SP and LSP can send a direct response to an Hypervisor or OS kernel.
- SPMD can send direct request to SPMC.
FFA_SPM_ID_GET
--------------
Returns the FF-A ID allocated to an SPM component which can be one of SPMD
or SPMC.
At initialization, the SPMC queries the SPMD for the SPMC ID, using the
FFA_ID_GET interface, and records it. The SPMC can also query the SPMD ID using
the FFA_SPM_ID_GET interface at the secure physical FF-A instance.
Secure partitions call this interface at the virtual FF-A instance, to which
the SPMC returns the SPMC ID.
The Hypervisor or OS kernel can issue the FFA_SPM_ID_GET call handled by the
SPMD, which returns the SPMC ID.
FFA_ID_GET
----------
Returns the FF-A ID of the calling endpoint.
FFA_MEM_SHARE
-------------
FFA_MEM_LEND
------------
- If SP is borrower in the memory transaction, these calls are forwarded to SPMC.
SPMC performs Relayer responsibilities, caches the memory descriptors in the datastore,
and allocates FF-A memory handle.
- If format of descriptor was v1.0, SPMC converts the descriptor to v1.1 before caching.
In case of fragmented sharing, conversion of memory descriptors happens after last
fragment has been received.
- Multiple borrowers (including NWd endpoint) and fragmented memory sharing are supported.
FFA_MEM_RETRIEVE_REQ
--------------------
FFA_MEM_RETRIEVE_RESP
---------------------
- Memory retrieve is supported only from SP.
- SPMC fetches the cached memory descriptor from the datastore,
- Performs Relayer responsiilities and sends FFA_MEM_RETRIEVE_RESP back to SP.
- If descriptor size is more than RX buffer size, SPMC will send the descriptor in fragments.
- SPMC will set NS Bit to 1 in memory descriptor response.
FFA_MEM_FRAG_RX
---------------
FFA_MEM_FRAG_TX
---------------
FFA_MEM_FRAG_RX is to be used by:
- SP if FFA_MEM_RETRIEVE_RESP returned descriptor with fragment length less than total length.
- or by SPMC if FFA_MEM_SHARE/FFA_MEM_LEND is called with fragment length less than total length.
SPMC validates handle and Endpoint ID and returns response with FFA_MEM_FRAG_TX.
FFA_SECONDARY_EP_REGISTER
-------------------------
When the SPMC boots, secure partition is initialized on its primary
Execution Context.
The FFA_SECONDARY_EP_REGISTER interface is to be used by a secure partition
from its first execution context, to provide the entry point address for
secondary execution contexts.
A secondary EC is first resumed either upon invocation of PSCI_CPU_ON from
the NWd or by invocation of FFA_RUN.
Power management
================
In platforms with or without secure virtualization:
- The NWd owns the platform PM policy.
- The Hypervisor or OS kernel is the component initiating PSCI service calls.
- The EL3 PSCI library is in charge of the PM coordination and control
(eventually writing to platform registers).
- While coordinating PM events, the PSCI library calls backs into the Secure
Payload Dispatcher for events the latter has statically registered to.
When using the SPMD as a Secure Payload Dispatcher:
- A power management event is relayed through the SPD hook to the SPMC.
- In the current implementation CPU_ON (svc_on_finish), CPU_OFF
(svc_off), CPU_SUSPEND (svc_suspend) and CPU_SUSPEND_RESUME (svc_suspend_finish)
hooks are registered.
Secure partitions scheduling
============================
The FF-A specification `[1]`_ provides two ways to relinquinsh CPU time to
secure partitions. For this a VM (Hypervisor or OS kernel), or SP invokes one of:
- the FFA_MSG_SEND_DIRECT_REQ interface.
- the FFA_RUN interface.
Additionally a secure interrupt can pre-empt the normal world execution and give
CPU cycles by transitioning to EL3.
Partition Runtime State and Model
=================================
EL3 SPMC implements Partition runtime states are described in v1.1 FF-A specification `[1]`_
An SP can be in one of the following state:
- RT_STATE_WAITING
- RT_STATE_RUNNING
- RT_STATE_PREEMPTED
- RT_STATE_BLOCKED
An SP will transition to one of the following runtime model when not in waiting state:
- RT_MODEL_DIR_REQ
- RT_MODEL_RUN
- RT_MODEL_INIT
- RT_MODEL_INTR
Platform topology
=================
SPMC only supports a single Pinned MP S-EL1 SP. The *execution-ctx-count*
SP manifest field should match the number of physical PE.
Interrupt handling
==================
Secure Interrupt handling
-------------------------
- SPMC is capable of forwarding Secure interrupt to S-EL1 SP
which has preempted the normal world.
- Interrupt is forwarded to SP using FFA_INTERRUPT interface.
- Interrupt Number is not passed, S-EL1 SP can access the GIC registers directly.
- Upon completion of Interrupt handling SP is expected to return to
SPMC using FFA_MSG_WAIT interface.
- SPMC returns to normal world after interrupt handling is completed.
In the scenario when secure interrupt occurs while the secure partition is running,
the SPMC is not involved and the handling is implementation defined in the TOS.
Non-Secure Interrupt handling
-----------------------------
The 'managed exit' scenario is the responsibility of the TOS and the SPMC is not involved.
Test Secure Payload (TSP)
=========================
- TSP provides reference implementation of FF-A programming model.
- TSP has the following support:
- SP initialization on all CPUs.
- Consuming Power Messages including CPU_ON, CPU_OFF, CPU_SUSPEND, CPU_SUSPEND_RESUME.
- Event Loop to receive Direct Requests.
- Sending Direct Response.
- Memory Sharing helper library.
- Ability to handle secure interrupt (timer).
TSP Tests in CI
---------------
- TSP Tests are exercised in the TF-A CI using prebuilt FF-A Linux Test driver in NWd.
- Expected output:
.. code:: shell
#ioctl 255
Test: Echo Message to SP.
Status: Completed Test Case: 1
Test Executed Successfully
Test: Message Relay vis SP to EL3 LSP.
Status: Completed Test Case: 2
Test Executed Successfully
Test: Memory Send.
Verified 1 constituents successfully
Status: Completed Test Case: 3
Test Executed Successfully
Test: Memory Send in Fragments.
Verified 256 constituents successfully
Status: Completed Test Case: 4
Test Executed Successfully
Test: Memory Lend.
Verified 1 constituents successfully
Status: Completed Test Case: 5
Test Executed Successfully
Test: Memory Lend in Fragments.
Verified 256 constituents successfully
Status: Completed Test Case: 6
Test Executed Successfully
Test: Memory Send with Multiple Endpoints.
random: fast init done
Verified 256 constituents successfully
Status: Completed Test Case: 7
Test Executed Successfully
Test: Memory Lend with Multiple Endpoints.
Verified 256 constituents successfully
Status: Completed Test Case: 8
Test Executed Successfully
Test: Ensure Duplicate Memory Send Requests are Rejected.
Status: Completed Test Case: 9
Test Executed Successfully
Test: Ensure Duplicate Memory Lend Requests are Rejected.
Status: Completed Test Case: 10
Test Executed Successfully
0 Tests Failed
Exiting Test Application - Total Failures: 0
References
==========
.. _[1]:
[1] `Arm Firmware Framework for Arm A-profile <https://developer.arm.com/docs/den0077/latest>`__
.. _[2]:
[2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/board/fvp/fvp_el3_spmc_logical_sp.c
.. _[3]:
[3] `Trusted Boot Board Requirements
Client <https://developer.arm.com/documentation/den0006/d/>`__
.. _[4]:
[4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/board/fvp/fvp_el3_spmc.c
.. _[5]:
[5] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/board/fvp/include/platform_def.h
.. _[6]:
[6] https://trustedfirmware-a.readthedocs.io/en/latest/components/ffa-manifest-binding.html
.. _[7]:
[7] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/tree/plat/arm/board/fvp/fdts/fvp_tsp_sp_manifest.dts
.. _[8]:
[8] https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.org/thread/CFQFGU6H2D5GZYMUYGTGUSXIU3OYZP6U/
.. _[9]:
[9] https://trustedfirmware-a.readthedocs.io/en/latest/design/firmware-design.html#dynamic-configuration-during-cold-boot
--------------
*Copyright (c) 2020-2022, Arm Limited and Contributors. All rights reserved.*

1
docs/components/index.rst
View file

@ -20,6 +20,7 @@ Components
romlib-design
sdei
secure-partition-manager
el3-spmc
secure-partition-manager-mm
xlat-tables-lib-v2-design
cot-binding

3
docs/glossary.rst
View file

@ -98,6 +98,9 @@ You can find additional definitions in the `Arm Glossary`_.
A collaborative engineering organization consolidating
and optimizing open source software and tools for the Arm architecture.
LSP
A logical secure partition managed by SPM
MMU
Memory Management Unit

BIN
docs/resources/diagrams/ff-a-lsp-at-el3.png Normal file
View file

Binary file not shown.
Side by side

After

(image error) Size: 38 KiB

BIN
docs/resources/diagrams/ff-a-spm-at-el3.png Normal file
View file

Binary file not shown.
Side by side

After

(image error) Size: 29 KiB

78
docs/resources/diagrams/plantuml/el3_spm_dfd.puml Normal file
View file

@ -0,0 +1,78 @@
/'
' Copyright (c) 2022, Arm Limited. All rights reserved.
'
' SPDX-License-Identifier: BSD-3-Clause
'/
/'
TF-A EL3 SPMC Data Flow Diagram
'/
@startuml
digraph tfa_el3_dfd {
# Allow arrows to end on cluster boundaries
compound=true
concentrate=false
newrank=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)"]
{rank="same" smmu, spmd}
# Trust boundary cluster
subgraph cluster_trusted {
graph [style=dashed color="#f22430"]
concentrate=false
# 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"]
{rank="same" spmc, bl31}
{rank="same" spmd, lsp}
spmc [label="SPMC" fillcolor="#ddffb3"]
bl31 [label="BL31" fillcolor="#ddffb3"];
spmd [label="SPMD" fillcolor="#ddffb3"]
lsp[label="LSP1" fillcolor="#ddffb3"]
}
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"]
}
sp1 -> spmc [dir="both" label="DF1"]
lsp -> spmc [dir="both" label="DF4"]
spmc -> spmd [dir="both" label="DF2"]
spmd -> nsec [dir="both" label="DF3"]
spmc -> smmu [lhead=cluster_spmc label="DF5"]
bl2 -> spmc [lhead=cluster_spmc label="DF6"]
bl2 -> sp1 [lhead=cluster_spmc label="DF6"]
sp1 -> ddr [dir="both" label="DF7"]
spmc -> ddr [dir="both" label="DF7"]
}
@enduml

1
docs/threat_model/index.rst
View file

@ -15,6 +15,7 @@ based on the data flow diagram and potential threat mitigations.
threat_model
threat_model_spm
threat_model_el3_spm
threat_model_fvp_r
--------------

650
docs/threat_model/threat_model_el3_spm.rst Normal file
View file

@ -0,0 +1,650 @@
EL3 SPMC Threat Model
*********************
************
Introduction
************
This document provides a threat model for the TF-A `EL3 Secure Partition Manager`_
(EL3 SPM) implementation. The EL3 SPM implementation is based on the
`Arm Firmware Framework for Arm A-profile`_ specification.
********************
Target of Evaluation
********************
In this threat model, the target of evaluation is the ``Secure Partition Manager Core``
component (SPMC) within the EL3 firmware.
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 EL3 SPMC
- The implementation complies with the FF-A v1.1 specification.
- Secure partition is 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.
Data Flow Diagram
=================
Figure 1 shows a high-level data flow diagram for the SPM split into an SPMD
and SPMC component at EL3. 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/el3_spm_dfd.puml
:caption: Figure 1: EL3 SPMC Data Flow Diagram
.. table:: Table 1: EL3 SPMC Data Flow Diagram Description
+---------------------+--------------------------------------------------------+
| Diagram Element | Description |
+=====================+========================================================+
| DF1 | SP to SPMC communication. FF-A function invocation or |
| | implementation-defined Hypervisor call. |
| | |
| | Note:- To communicate with LSP, SP1 performs a direct |
| | message request to SPMC targeting LSP as destination. |
+---------------------+--------------------------------------------------------+
| DF2 | SPMC to SPMD communication. |
+---------------------+--------------------------------------------------------+
| DF3 | SPMD to NS forwarding. |
+---------------------+--------------------------------------------------------+
| DF4 | SPMC to LSP communication. |
| | NWd to LSP communication happens through SPMC. |
| | LSP can send direct response SP1 or NWd through SPMC. |
+---------------------+--------------------------------------------------------+
| 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 trusted boot.
- EL3 monitor, SPMD, SPMC do not trust SPs.
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:
- Non-secure endpoint (referred NS-Endpoint later): normal world client at
NS-EL2 (Hypervisor) or NS-EL1 (VM or OS kernel).
- Secure endpoint (referred as S-Endpoint later): 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``.
IOT is not evaluated as the EL3 SPMC is primarily meant for use in Client.
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 |
| | 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 | SPMC must be able to correctly identify an |
| | endpoint and enforce checks to disallow spoofing. |
+------------------------+----------------------------------------------------+
| Mitigations | Yes. |
| implemented? | The SPMC enforces 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). |
| | Also enforces check for direct response being sent |
| | only to originator of request. |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
| ID | 02 |
+========================+====================================================+
| Threat | **An endpoint impersonates the 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, Denial of Service |
+------------------------+--------------------------+-------------------------+
| Application | Server | Mobile |
+------------------------+--------------------------++------------------------+
| Impact | Critical(5) | Critical(5) |
+------------------------+--------------------------++------------------------+
| Likelihood | Critical(5) | Critical(5) |
+------------------------+--------------------------++------------------------+
| Total Risk Rating | Critical(25) | Critical(25) |
+------------------------+--------------------------+-------------------------+
| Mitigations | Validate if endpoind has permission to send |
| | request to other endpoint by implementation |
| | defined means. |
+------------------------+----------------------------------------------------+
| Mitigations | Platform specific. |
| implemented? | |
| | The guidance below is left for a system integrator |
| | to implement as necessary. |
| | |
| | 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 | 03 |
+========================+====================================================+
| 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, 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 | Validate all inputs, copy before use. |
+------------------------+----------------------------------------------------+
| Mitigations | Yes. In context of FF-A v1.1 this is the case of |
| implemented? | sharing the RX/TX buffer pair and usage in the |
| | PARTITION_INFO_GET or memory sharing primitives. |
| | |
| | The SPMC copies the contents of the TX buffer |
| | to an internal temporary buffer before processing |
| | its contents. The SPMC implements hardened input |
| | validation on data transmitted through the TX |
| | buffer by an untrusted endpoint. |
| | |
| | The TF-A SPMC enforces |
| | checks on data transmitted through RX/TX buffers. |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
| ID | 04 |
+========================+====================================================+
| 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. |
| | 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 |
+------------------------+----------------------------------------------------+
| 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 | Follow guidelines in FF-A v1.1 specification on |
| | state transitions (run-time model). |
+------------------------+----------------------------------------------------+
| Mitigations | Yes. The TF-A SPMC is hardened to follow this |
| implemented? | guidance. |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
| ID | 05 |
+========================+====================================================+
| Threat | **Replay fragments of past communication between |
| | endpoints.** |
| | |
| | A malicious endpoint may replay a message exchange |
| | that occurred between two legitimate endpoints 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 | Repudiation |
+------------------------+--------------------------+-------------------------+
| Application | Server | Mobile |
+------------------------+--------------------------+-------------------------+
| Impact | Medium (3) | Medium (3) |
+------------------------+--------------------------+-------------------------+
| Likelihood | High (4) | High (4) |
+------------------------+--------------------------+-------------------------+
| Total Risk Rating | High (12) | High (12) |
+------------------------+--------------------------+-------------------------+
| Mitigations | Strict input validation and state tracking. |
+------------------------+----------------------------------------------------+
| Mitigations | Platform specific. |
| implemented? | |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
| ID | 06 |
+========================+====================================================+
| 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 |
+------------------------+----------------------------------------------------+
| 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 | SPMC must be prepared to receive incorrect input |
| | data from secure partitions and reject them |
| | appropriately. |
| | The use of software (canaries) or hardware |
| | hardening techniques (XN, WXN, pointer |
| | authentication) helps detecting and stopping |
| | an exploitation early. |
+------------------------+----------------------------------------------------+
| Mitigations | Yes. The TF-A SPMC mitigates this threat by |
| implemented? | implementing stack protector, pointer |
| | authentication, XN, WXN, security hardening |
| | techniques. |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
| ID | 07 |
+========================+====================================================+
| 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 |
+------------------------+----------------------------------------------------+
| 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 | Follow FF-A specification about state transitions, |
| | run time model, do input validation. |
+------------------------+----------------------------------------------------+
| Mitigations | Yes. For the specific case of direct requests |
| implemented? | targeting the SPMC, the latter is hardened to |
| | prevent its internal state or the state of an SP |
| | to be revealed through a direct message response. |
| | Further FF-A v1.1 guidance about run time models |
| | and partition states is followed. |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
| ID | 08 |
+========================+====================================================+
| 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 | Implement DRAM protection techniques using |
| | hardware countermeasures at platform or chip level.|
+------------------------+--------------------------+-------------------------+
| Mitigations | Platform specific. |
| implemented? | |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
| ID | 09 |
+========================+====================================================+
| 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 | 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. |
+------------------------+----------------------------------------------------+
| Mitigations | No. |
| implemented? | |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
| ID | 10 |
+========================+====================================================+
| Threat | **A malicious endpoint may attempt flooding the |
| | SPMC with requests targeting a service within an |
| | endpoint such that it denies another endpoint to |
| | access this service.** |
| | |
| | Similarly, the malicious endpoint may target a |
| | a service within an endpoint such that the latter |
| | is unable to request services from another |
| | endpoint. |
+------------------------+----------------------------------------------------+
| Diagram Elements | DF1, DF2, DF3 |
+------------------------+----------------------------------------------------+
| Affected TF-A | SPMC |
| Components | |
+------------------------+----------------------------------------------------+
| Assets | SPMC state, Scheduling cycles |
+------------------------+----------------------------------------------------+
| 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 | 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. |
+------------------------+----------------------------------------------------+
| Mitigations | Platform specific. |
| implemented? | |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
| ID | 11 |
+========================+====================================================+
| Threat | **Denying a lender endpoint to make progress if |
| | borrower endpoint encountered a fatal exception. |
| | Denying a new sender endpoint to make progress |
| | if receiver encountered a fatal exception.** |
+------------------------+----------------------------------------------------+
| Diagram Elements | DF1, DF2, DF3 |
+------------------------+----------------------------------------------------+
| Affected TF-A | SPMC |
| Components | |
+------------------------+----------------------------------------------------+
| Assets | Shared resources, Scheduling cycles. |
+------------------------+----------------------------------------------------+
| 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 | SPMC must be able to detect fatal error in SP and |
| | take ownership of shared resources. It should |
| | be able to relinquish the access to shared memory |
| | regions to allow lender to proceed. |
| | SPMC must return ABORTED if new direct requests are|
| | targeted to SP which has had a fatal error. |
+------------------------+----------------------------------------------------+
| Mitigations | Platform specific. |
| implemented? | |
+------------------------+----------------------------------------------------+
+------------------------+----------------------------------------------------+
| ID | 12 |
+========================+====================================================+
| Threat | **A malicious endpoint may attempt to donate, |
| | share, lend, relinquish or reclaim unauthorized |
| | memory region.** |
+------------------------+----------------------------------------------------+
| Diagram Elements | DF1, DF2, DF3 |
+------------------------+----------------------------------------------------+
| Affected TF-A | SPMC |
| Components | |
+------------------------+----------------------------------------------------+
| Assets | SP secrets, SPMC secrets, SP state, SPMC state |
+------------------------+----------------------------------------------------+
| Threat Agent | NS-Endpoint, S-Endpoint |
+------------------------+----------------------------------------------------+
| Threat Type | Elevation of Privilege |
+------------------------+--------------------------+-------------------------+
| Application | Server | Mobile |
+------------------------+--------------------------+-------------------------+
| Impact | High (4) | High (4) |
+------------------------+--------------------------+-------------------------+
| Likelihood | High (4) | High (4) |
+------------------------+--------------------------+-------------------------+
| Total Risk Rating | High (16) | High (16) |
+------------------------+--------------------------+-------------------------+
| Mitigations | Follow FF-A specification guidelines |
| | on Memory management transactions. |
+------------------------+----------------------------------------------------+
| Mitigations | Yes. The SPMC tracks ownership and access state |
| implemented? | for memory transactions appropriately, and |
| | validating the same for all operations. |
| | SPMC follows FF-A v1.1 |
| | guidance for memory transaction lifecycle. |
+------------------------+----------------------------------------------------+
---------------
*Copyright (c) 2022, Arm Limited. All rights reserved.*
.. _Arm Firmware Framework for Arm A-profile: https://developer.arm.com/docs/den0077/latest
.. _EL3 Secure Partition Manager: ../components/el3-spmc.html
.. _Generic TF-A threat model: ./threat_model.html#threat-analysis
.. _FF-A ACS: https://github.com/ARM-software/ff-a-acs/releases