11.3. fvp_r-Platform Threat Model

11.3.1. Introduction

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

11.3.2. 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, Generic Threat Model

11.3.2.1. 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.

11.3.2.2. 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.

11.3.2.3. 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.

11.3.2.4. 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.

11.3.2.5. Threat Assessment

For this section, please reference the Threat Assessment under the general TF-A threat-model document, 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.