1fvp_r-Platform Threat Model
2***************************
3
4************************
5Introduction
6************************
7This document provides a threat model for TF-A fvp_r platform.
8
9************************
10Target of Evaluation
11************************
12In this threat model, the target of evaluation is the fvp_r platform of Trusted
13Firmware for A-class Processors (TF-A).  The fvp_r platform provides limited
14support of AArch64 R-class Processors (v8-R64).
15
16This is a delta document, only pointing out differences from the general TF-A
17threat-model document, :ref:`Generic Threat Model`
18
19BL1 Only
20========
21The most fundamental difference between the threat model for the current fvp_r
22implementation compared to the general TF-A threat model, is that fvp_r is
23currently limited to BL1 only.  Any threats from the general TF-A threat model
24unrelated to BL1 are therefore not relevant to the fvp_r implementation.
25
26The fvp_r BL1 implementation directly loads a customer/partner-defined runtime
27system.  The threat model for that runtime system, being partner-defined, is
28out-of-scope for this threat-model.
29
30Relatedly, all exceptions, synchronous and asynchronous, are disabled during BL1
31execution.  So, any references to exceptions are not relevant.
32
33EL3 is Unsupported and All Secure
34=================================
35v8-R64 cores do not support EL3, and (essentially) all operation is defined as
36Secure-mode.  Therefore:
37
38    - Any threats regarding NS operation are not relevant.
39
40    - Any mentions of SMCs are also not relevant.
41
42    - Anything otherwise-relevant code running in EL3 is instead run in EL2.
43
44MPU instead of MMU
45==================
46v8-R64 cores, running in EL2, use an MPU for memory management, rather than an
47MMU.  The MPU in the fvp_r implementation is configured to function effectively
48identically with the MMU for the usual BL1 implementation.  There are
49memory-map differences, but the MPU configuration is functionally equivalent.
50
51No AArch32 Support
52==================
53Another substantial difference between v8-A and v8-R64 cores is that v8-R64 does
54not support AArch32.  However, this is not believed to have any threat-modeling
55ramifications.
56
57
58Threat Assessment
59=================
60For this section, please reference the Threat Assessment under the general TF-A
61threat-model document, :ref:`Generic Threat Model`
62
63The following threats from that document are still relevant to the fvp_r
64implementation:
65
66    - ID 01:  An attacker can mangle firmware images to execute arbitrary code.
67
68    - ID 03:  An attacker can use Time-of-Check-Time-of-Use (TOCTOU) attack to
69      bypass image authentication during the boot process.
70
71    - ID 04:  An attacker with physical access can execute arbitrary image by
72      bypassing the signature verification stage using clock- or power-glitching
73      techniques.
74
75    - ID 05:  Information leak via UART logs such as crashes
76
77    - ID 06:  An attacker can read sensitive data and execute arbitrary code
78      through the external debug and trace interface.
79
80    - ID 08:  Memory corruption due to memory overflows and lack of boundary
81      checking when accessing resources could allow an attacker to execute
82      arbitrary code, modify some state variable to change the normal flow of
83      the program, or leak sensitive.
84
85    - ID 11:  Misconfiguration of the Memory Protection Unit (MPU) may allow
86      normal world software to access sensitive data or execute arbitrary code.
87      Arguably, MPUs having fewer memory regions, there may be a temptation to
88      share memory regions, making this a greater threat.  However, since the
89      fvp_r implementation is limited to BL1, since BL1's regions are fixed,
90      and since the MPU configuration is equivalent with that for the fvp
91      platform and others, this is not expected to be a concern.
92
93
94
95--------------
96
97*Copyright (c) 2021, Arm Limited. All rights reserved.*
98