fvp_r-Platform Threat Model
***************************

************************
Introduction
************************
This document provides a threat model for TF-A fvp_r platform.

************************
Target of Evaluation
************************
In this threat model, the target of evaluation is the fvp_r platform of Trusted
Firmware for A-class Processors (TF-A).  The fvp_r platform provides limited
support of AArch64 R-class Processors (v8-R64).

This is a delta document, only pointing out differences from the general TF-A
threat-model document, :ref:`Generic Threat Model`

BL1 Only
========
The most fundamental difference between the threat model for the current fvp_r
implementation compared to the general TF-A threat model, is that fvp_r is
currently limited to BL1 only.  Any threats from the general TF-A threat model
unrelated to BL1 are therefore not relevant to the fvp_r implementation.

The fvp_r BL1 implementation directly loads a customer/partner-defined runtime
system.  The threat model for that runtime system, being partner-defined, is
out-of-scope for this threat-model.

Relatedly, all exceptions, synchronous and asynchronous, are disabled during BL1
execution.  So, any references to exceptions are not relevant.

EL3 is Unsupported and All Secure
=================================
v8-R64 cores do not support EL3, and (essentially) all operation is defined as
Secure-mode.  Therefore:

    - Any threats regarding NS operation are not relevant.

    - Any mentions of SMCs are also not relevant.

    - Anything otherwise-relevant code running in EL3 is instead run in EL2.

MPU instead of MMU
==================
v8-R64 cores, running in EL2, use an MPU for memory management, rather than an
MMU.  The MPU in the fvp_r implementation is configured to function effectively
identically with the MMU for the usual BL1 implementation.  There are
memory-map differences, but the MPU configuration is functionally equivalent.

No AArch32 Support
==================
Another substantial difference between v8-A and v8-R64 cores is that v8-R64 does
not support AArch32.  However, this is not believed to have any threat-modeling
ramifications.


Threat Assessment
=================
For this section, please reference the Threat Assessment under the general TF-A
threat-model document, :ref:`Generic Threat Model`

The following threats from that document are still relevant to the fvp_r
implementation:

    - ID 01:  An attacker can mangle firmware images to execute arbitrary code.

    - ID 03:  An attacker can use Time-of-Check-Time-of-Use (TOCTOU) attack to
      bypass image authentication during the boot process.

    - ID 04:  An attacker with physical access can execute arbitrary image by
      bypassing the signature verification stage using clock- or power-glitching
      techniques.

    - ID 05:  Information leak via UART logs such as crashes

    - ID 06:  An attacker can read sensitive data and execute arbitrary code
      through the external debug and trace interface.

    - ID 08:  Memory corruption due to memory overflows and lack of boundary
      checking when accessing resources could allow an attacker to execute 
      arbitrary code, modify some state variable to change the normal flow of
      the program, or leak sensitive.

    - ID 11:  Misconfiguration of the Memory Protection Unit (MPU) may allow
      normal world software to access sensitive data or execute arbitrary code.
      Arguably, MPUs having fewer memory regions, there may be a temptation to
      share memory regions, making this a greater threat.  However, since the
      fvp_r implementation is limited to BL1, since BL1's regions are fixed,
      and since the MPU configuration is equivalent with that for the fvp
      platform and others, this is not expected to be a concern.

    - ID 15:  Improper handling of input data received over a UART interface may
      allow an attacker to tamper with TF-A execution environment.


--------------

*Copyright (c) 2021-2023, Arm Limited. All rights reserved.*