1Generic Threat Model 2******************** 3 4************ 5Introduction 6************ 7 8This document provides a generic threat model for TF-A firmware. 9 10.. _Target of Evaluation: 11 12******************** 13Target of Evaluation 14******************** 15 16In this threat model, the target of evaluation is the Trusted 17Firmware for A-class Processors (TF-A). This includes the boot ROM (BL1), 18the trusted boot firmware (BL2) and the runtime EL3 firmware (BL31) as 19shown on Figure 1. Everything else on Figure 1 is outside of the scope of 20the evaluation. 21 22TF-A can be configured in various ways. In this threat model we consider 23only the most basic configuration. To that end we make the following 24assumptions: 25 26- All TF-A images are run from either ROM or on-chip trusted SRAM. This means 27 TF-A is not vulnerable to an attacker that can probe or tamper with off-chip 28 memory. 29 30- Trusted boot is enabled. This means an attacker can't boot arbitrary images 31 that are not approved by platform providers. 32 33- There is no Secure-EL2. We don't consider threats that may come with 34 Secure-EL2 software. 35 36- There are no Root and Realm worlds. These are introduced by :ref:`Realm 37 Management Extension (RME)`. 38 39 The :ref:`Threat Model for TF-A with Arm CCA support` covers these types of 40 configurations. 41 42- No experimental features are enabled. We do not consider threats that may come 43 from them. 44 45- The platform's hardware complies with the `PSR specification`_, defining the 46 bare-minimum security prerequisites for System-on-Chips (SoC). 47 48Data Flow Diagram 49================= 50 51Figure 1 shows a high-level data flow diagram for TF-A. The diagram 52shows a model of the different components of a TF-A-based system and 53their interactions with TF-A. A description of each diagram element 54is given on Table 1. On the diagram, the red broken lines indicate 55trust boundaries. Components outside of the broken lines 56are considered untrusted by TF-A. 57 58.. _tfa_dfd: 59.. uml:: ../../resources/diagrams/plantuml/tfa_dfd.puml 60 :caption: Figure 1: TF-A Data Flow Diagram 61 62.. table:: Table 1: TF-A Data Flow Diagram Description 63 64 +-----------------+--------------------------------------------------------+ 65 | Diagram Element | Description | 66 +=================+========================================================+ 67 | DF1 | | At boot time, images are loaded from non-volatile | 68 | | memory and verified by TF-A boot firmware. These | 69 | | images include TF-A BL2 and BL31 images, as well as | 70 | | other secure and non-secure images. | 71 +-----------------+--------------------------------------------------------+ 72 | DF2 | | TF-A log system framework outputs debug or | 73 | | informative messages over a UART interface. | 74 | | | 75 | | | Also, characters can be read from a UART interface. | 76 +-----------------+--------------------------------------------------------+ 77 | DF3 | | Debug and trace IP on a platform can allow access | 78 | | to registers and memory of TF-A. | 79 +-----------------+--------------------------------------------------------+ 80 | DF4 | | Secure world software (e.g. trusted OS) interact | 81 | | with TF-A through SMC call interface and/or shared | 82 | | memory. | 83 +-----------------+--------------------------------------------------------+ 84 | DF5 | | Non-secure world software (e.g. rich OS) interact | 85 | | with TF-A through SMC call interface and/or shared | 86 | | memory. | 87 +-----------------+--------------------------------------------------------+ 88 | DF6 | | This path represents the interaction between TF-A and| 89 | | various hardware IPs such as TrustZone controller | 90 | | and GIC. At boot time TF-A configures/initializes the| 91 | | IPs and interacts with them at runtime through | 92 | | interrupts and registers. | 93 +-----------------+--------------------------------------------------------+ 94 95 96.. _threat_analysis: 97 98*************** 99Threat Analysis 100*************** 101 102In this section we identify and provide assessment of potential threats to TF-A 103firmware. The threats are identified for each diagram element on the 104data flow diagram above. 105 106For each threat, we identify the *asset* that is under threat, the 107*threat agent* and the *threat type*. Each threat is given a *risk rating* 108that represents the impact and likelihood of that threat. We also discuss 109potential mitigations. 110 111Assets 112====== 113 114We have identified the following assets for TF-A: 115 116.. table:: Table 2: TF-A Assets 117 118 +--------------------+---------------------------------------------------+ 119 | Asset | Description | 120 +====================+===================================================+ 121 | Sensitive Data | | These include sensitive data that an attacker | 122 | | must not be able to tamper with (e.g. the Root | 123 | | of Trust Public Key) or see (e.g. secure logs, | 124 | | debugging information such as crash reports). | 125 +--------------------+---------------------------------------------------+ 126 | Code Execution | | This represents the requirement that the | 127 | | platform should run only TF-A code approved by | 128 | | the platform provider. | 129 +--------------------+---------------------------------------------------+ 130 | Availability | | This represents the requirement that TF-A | 131 | | services should always be available for use. | 132 +--------------------+---------------------------------------------------+ 133 134Threat Agents 135============= 136 137To understand the attack surface, it is important to identify potential 138attackers, i.e. attack entry points. The following threat agents are 139in scope of this threat model. 140 141.. table:: Table 3: Threat Agents 142 143 +-------------------+-------------------------------------------------------+ 144 | Threat Agent | Description | 145 +===================+=======================================================+ 146 | NSCode | | Malicious or faulty code running in the Non-secure | 147 | | world, including NS-EL0 NS-EL1 and NS-EL2 levels | 148 +-------------------+-------------------------------------------------------+ 149 | SecCode | | Malicious or faulty code running in the secure | 150 | | world, including S-EL0 and S-EL1 levels | 151 +-------------------+-------------------------------------------------------+ 152 | AppDebug | | Physical attacker using debug signals to access | 153 | | TF-A resources | 154 +-------------------+-------------------------------------------------------+ 155 | PhysicalAccess | | Physical attacker having access to external device | 156 | | communication bus and to external flash | 157 | | communication bus using common hardware | 158 +-------------------+-------------------------------------------------------+ 159 160.. note:: 161 162 In this threat model an advanced physical attacker that has the capability 163 to tamper with a hardware (e.g. "rewiring" a chip using a focused 164 ion beam (FIB) workstation or decapsulate the chip using chemicals) is 165 considered out-of-scope. 166 167 Certain non-invasive physical attacks that do not need modifications to the 168 chip, notably those like Power Analysis Attacks, are out-of-scope. Power 169 analysis side-channel attacks represent a category of security threats that 170 capitalize on information leakage through a device's power consumption during 171 its normal operation. These attacks leverage the correlation between a 172 device's power usage and its internal data processing activities. This 173 correlation provides attackers with the means to extract sensitive 174 information, including cryptographic keys. 175 176Threat Types 177============ 178 179In this threat model we categorize threats using the `STRIDE threat 180analysis technique`_. In this technique a threat is categorized as one 181or more of these types: ``Spoofing``, ``Tampering``, ``Repudiation``, 182``Information disclosure``, ``Denial of service`` or 183``Elevation of privilege``. 184 185Threat Risk Ratings 186=================== 187 188For each threat identified, a risk rating that ranges 189from *informational* to *critical* is given based on the likelihood of the 190threat occurring if a mitigation is not in place, and the impact of the 191threat (i.e. how severe the consequences could be). Table 4 explains each 192rating in terms of score, impact and likelihood. 193 194.. table:: Table 4: Rating and score as applied to impact and likelihood 195 196 +-----------------------+-------------------------+---------------------------+ 197 | **Rating (Score)** | **Impact** | **Likelihood** | 198 +=======================+=========================+===========================+ 199 | Critical (5) | | Extreme impact to | | Threat is almost | 200 | | entire organization | certain to be exploited.| 201 | | if exploited. | | 202 | | | | Knowledge of the threat | 203 | | | and how to exploit it | 204 | | | are in the public | 205 | | | domain. | 206 +-----------------------+-------------------------+---------------------------+ 207 | High (4) | | Major impact to entire| | Threat is relatively | 208 | | organization or single| easy to detect and | 209 | | line of business if | exploit by an attacker | 210 | | exploited | with little skill. | 211 +-----------------------+-------------------------+---------------------------+ 212 | Medium (3) | | Noticeable impact to | | A knowledgeable insider | 213 | | line of business if | or expert attacker could| 214 | | exploited. | exploit the threat | 215 | | | without much difficulty.| 216 +-----------------------+-------------------------+---------------------------+ 217 | Low (2) | | Minor damage if | | Exploiting the threat | 218 | | exploited or could | would require | 219 | | be used in conjunction| considerable expertise | 220 | | with other | and resources | 221 | | vulnerabilities to | | 222 | | perform a more serious| | 223 | | attack | | 224 +-----------------------+-------------------------+---------------------------+ 225 | Informational (1) | | Poor programming | | Threat is not likely | 226 | | practice or poor | to be exploited on its | 227 | | design decision that | own, but may be used to | 228 | | may not represent an | gain information for | 229 | | immediate risk on its | launching another | 230 | | own, but may have | attack | 231 | | security implications | | 232 | | if multiplied and/or | | 233 | | combined with other | | 234 | | threats. | | 235 +-----------------------+-------------------------+---------------------------+ 236 237Aggregate risk scores are assigned to identified threats; 238specifically, the impact score multiplied by the likelihood score. 239For example, a threat with high likelihood and low impact would have an 240aggregate risk score of eight (8); that is, four (4) for high likelihood 241multiplied by two (2) for low impact. The aggregate risk score determines 242the finding's overall risk level, as shown in the following table. 243 244.. table:: Table 5: Overall risk levels and corresponding aggregate scores 245 246 +---------------------+-----------------------------------+ 247 | Overall Risk Level | Aggregate Risk Score | 248 | | (Impact multiplied by Likelihood) | 249 +=====================+===================================+ 250 | Critical | 20–25 | 251 +---------------------+-----------------------------------+ 252 | High | 12–19 | 253 +---------------------+-----------------------------------+ 254 | Medium | 6–11 | 255 +---------------------+-----------------------------------+ 256 | Low | 2–5 | 257 +---------------------+-----------------------------------+ 258 | Informational | 1 | 259 +---------------------+-----------------------------------+ 260 261The likelihood and impact of a threat depends on the 262target environment in which TF-A is running. For example, attacks 263that require physical access are unlikely in server environments while 264they are more common in Internet of Things(IoT) environments. 265In this threat model we consider three target environments: 266``Internet of Things(IoT)``, ``Mobile`` and ``Server``. 267 268Threat Assessment 269================= 270 271The following threats were identified by applying STRIDE analysis on 272each diagram element of the data flow diagram. 273 274For each threat, we strive to indicate whether the mitigations are currently 275implemented or not. However, the answer to this question is not always straight 276forward. Some mitigations are partially implemented in the generic code but also 277rely on the platform code to implement some bits of it. This threat model aims 278to be platform-independent and it is important to keep in mind that such threats 279only get mitigated if the platform code properly fulfills its responsibilities. 280 281Also, some mitigations require enabling specific features, which must be 282explicitly turned on via a build flag. 283 284When such conditions must be met, these are highlighted in the ``Mitigations 285implemented?`` box. 286 287As our :ref:`Target of Evaluation` is made of several, distinct firmware images, 288some threats are confined in specific images, while others apply to each of 289them. To help developers implement mitigations in the right place, threats below 290are categorized based on the firmware image that should mitigate them. 291 292.. _General Threats: 293 294General Threats for All Firmware Images 295--------------------------------------- 296 297+------------------------+---------------------------------------------------+ 298| ID | 05 | 299+========================+===================================================+ 300| Threat | | **Information leak via UART logs** | 301| | | 302| | | During the development stages of software it is | 303| | common to print all sorts of information on the | 304| | console, including sensitive or confidential | 305| | information such as crash reports with detailed | 306| | information of the CPU state, current registers | 307| | values, privilege level or stack dumps. | 308| | | 309| | | This information is useful when debugging | 310| | problems before releasing the production | 311| | version but it could be used by an attacker | 312| | to develop a working exploit if left enabled in | 313| | the production version. | 314| | | 315| | | This happens when directly logging sensitive | 316| | information and more subtly when logging | 317| | side-channel information that can be used by an | 318| | attacker to learn about sensitive information. | 319+------------------------+---------------------------------------------------+ 320| Diagram Elements | DF2 | 321+------------------------+---------------------------------------------------+ 322| Affected TF-A | BL1, BL2, BL31 | 323| Components | | 324+------------------------+---------------------------------------------------+ 325| Assets | Sensitive Data | 326+------------------------+---------------------------------------------------+ 327| Threat Agent | AppDebug | 328+------------------------+---------------------------------------------------+ 329| Threat Type | Information Disclosure | 330+------------------------+------------------+----------------+---------------+ 331| Application | Server | IoT | Mobile | 332+------------------------+------------------+----------------+---------------+ 333| Impact | N/A | Low (2) | Low (2) | 334+------------------------+------------------+----------------+---------------+ 335| Likelihood | N/A | High (4) | High (4) | 336+------------------------+------------------+----------------+---------------+ 337| Total Risk Rating | N/A | Medium (8) | Medium (8) | 338+------------------------+------------------+----------------+---------------+ 339| Mitigations | | Remove sensitive information logging in | 340| | production releases. | 341| | | 342| | | Do not conditionally log information depending | 343| | on potentially sensitive data. | 344| | | 345| | | Do not log high precision timing information. | 346+------------------------+---------------------------------------------------+ 347| Mitigations | | Yes / Platform Specific. | 348| implemented? | Requires the right build options to be used. | 349| | | 350| | | Crash reporting is only enabled for debug | 351| | builds by default, see ``CRASH_REPORTING`` | 352| | build option. | 353| | | 354| | | The log level can be tuned at build time, from | 355| | very verbose to no output at all. See | 356| | ``LOG_LEVEL`` build option. By default, release | 357| | builds are a lot less verbose than debug ones | 358| | but still produce some output. | 359| | | 360| | | Messages produced by the platform code should | 361| | use the appropriate level of verbosity so as | 362| | not to leak sensitive information in production | 363| | builds. | 364+------------------------+---------------------------------------------------+ 365 366+------------------------+----------------------------------------------------+ 367| ID | 06 | 368+========================+====================================================+ 369| Threat | | **An attacker can read sensitive data and | 370| | execute arbitrary code through the external | 371| | debug and trace interface** | 372| | | 373| | | Arm processors include hardware-assisted debug | 374| | and trace features that can be controlled without| 375| | the need for software operating on the platform. | 376| | If left enabled without authentication, this | 377| | feature can be used by an attacker to inspect and| 378| | modify TF-A registers and memory allowing the | 379| | attacker to read sensitive data and execute | 380| | arbitrary code. | 381+------------------------+----------------------------------------------------+ 382| Diagram Elements | DF3 | 383+------------------------+----------------------------------------------------+ 384| Affected TF-A | BL1, BL2, BL31 | 385| Components | | 386+------------------------+----------------------------------------------------+ 387| Assets | Code Execution, Sensitive Data | 388+------------------------+----------------------------------------------------+ 389| Threat Agent | AppDebug | 390+------------------------+----------------------------------------------------+ 391| Threat Type | Tampering, Information Disclosure, | 392| | Elevation of privilege | 393+------------------------+------------------+---------------+-----------------+ 394| Application | Server | IoT | Mobile | 395+------------------------+------------------+---------------+-----------------+ 396| Impact | N/A | High (4) | High (4) | 397+------------------------+------------------+---------------+-----------------+ 398| Likelihood | N/A | Critical (5) | Critical (5) | 399+------------------------+------------------+---------------+-----------------+ 400| Total Risk Rating | N/A | Critical (20) | Critical (20) | 401+------------------------+------------------+---------------+-----------------+ 402| Mitigations | Disable the debug and trace capability for | 403| | production releases or enable proper debug | 404| | authentication as recommended by [`DEN0034`_]. | 405+------------------------+----------------------------------------------------+ 406| Mitigations | | Platform specific. | 407| implemented? | | 408| | | Configuration of debug and trace capabilities is | 409| | entirely platform specific. | 410+------------------------+----------------------------------------------------+ 411 412+------------------------+------------------------------------------------------+ 413| ID | 08 | 414+========================+======================================================+ 415| Threat | | **Memory corruption due to memory overflows and | 416| | lack of boundary checking when accessing resources | 417| | could allow an attacker to execute arbitrary code, | 418| | modify some state variable to change the normal | 419| | flow of the program, or leak sensitive | 420| | information** | 421| | | 422| | | Like in other software, TF-A has multiple points | 423| | where memory corruption security errors can arise. | 424| | | 425| | | Some of the errors include integer overflow, | 426| | buffer overflow, incorrect array boundary checks, | 427| | and incorrect error management. | 428| | Improper use of asserts instead of proper input | 429| | validations might also result in these kinds of | 430| | errors in release builds. | 431+------------------------+------------------------------------------------------+ 432| Diagram Elements | DF4, DF5 | 433+------------------------+------------------------------------------------------+ 434| Affected TF-A | BL1, BL2, BL31 | 435| Components | | 436+------------------------+------------------------------------------------------+ 437| Assets | Code Execution, Sensitive Data | 438+------------------------+------------------------------------------------------+ 439| Threat Agent | NSCode, SecCode | 440+------------------------+------------------------------------------------------+ 441| Threat Type | Tampering, Information Disclosure, | 442| | Elevation of Privilege | 443+------------------------+-------------------+-----------------+----------------+ 444| Application | Server | IoT | Mobile | 445+------------------------+-------------------+-----------------+----------------+ 446| Impact | Critical (5) | Critical (5) | Critical (5) | 447+------------------------+-------------------+-----------------+----------------+ 448| Likelihood | Medium (3 | Medium (3) | Medium (3) | 449+------------------------+-------------------+-----------------+----------------+ 450| Total Risk Rating | High (15) | High (15) | High (15) | 451+------------------------+-------------------+-----------------+----------------+ 452| Mitigations | | 1) Use proper input validation. | 453| | | 454| | | 2) Code reviews, testing. | 455+------------------------+------------------------------------------------------+ 456| Mitigations | | 1) Yes. | 457| implemented? | Data received from normal world, such as addresses | 458| | and sizes identifying memory regions, are | 459| | sanitized before being used. These security checks | 460| | make sure that the normal world software does not | 461| | access memory beyond its limit. | 462| | | 463| | | By default *asserts* are only used to check for | 464| | programming errors in debug builds. Other types of | 465| | errors are handled through condition checks that | 466| | remain enabled in release builds. See | 467| | `TF-A error handling policy`_. TF-A provides an | 468| | option to use *asserts* in release builds, however | 469| | we recommend using proper runtime checks instead | 470| | of relying on asserts in release builds. | 471| | | 472| | | 2) Yes. | 473| | TF-A uses a combination of manual code reviews | 474| | and automated program analysis and testing to | 475| | detect and fix memory corruption bugs. All TF-A | 476| | code including platform code go through manual | 477| | code reviews. Additionally, static code analysis | 478| | is performed using Coverity Scan on all TF-A code. | 479| | The code is also tested with | 480| | `Trusted Firmware-A Tests`_ on Juno and FVP | 481| | platforms. | 482+------------------------+------------------------------------------------------+ 483 484 485+------------------------+----------------------------------------------------+ 486| ID | 11 | 487+========================+====================================================+ 488| Threat | | **Misconfiguration of the Memory Management Unit | 489| | (MMU) may allow a normal world software to | 490| | access sensitive data, execute arbitrary | 491| | code or access otherwise restricted HW | 492| | interface** | 493| | | 494| | | A misconfiguration of the MMU could | 495| | lead to an open door for software running in the | 496| | normal world to access sensitive data or even | 497| | execute code if the proper security mechanisms | 498| | are not in place. | 499+------------------------+----------------------------------------------------+ 500| Diagram Elements | DF5, DF6 | 501+------------------------+----------------------------------------------------+ 502| Affected TF-A | BL1, BL2, BL31 | 503| Components | | 504+------------------------+----------------------------------------------------+ 505| Assets | Sensitive Data, Code execution | 506+------------------------+----------------------------------------------------+ 507| Threat Agent | NSCode | 508+------------------------+----------------------------------------------------+ 509| Threat Type | Information Disclosure, Elevation of Privilege | 510+------------------------+-----------------+-----------------+----------------+ 511| Application | Server | IoT | Mobile | 512+------------------------+-----------------+-----------------+----------------+ 513| Impact | Critical (5) | Critical (5) | Critical (5) | 514+------------------------+-----------------+-----------------+----------------+ 515| Likelihood | High (4) | High (4) | High (4) | 516+------------------------+-----------------+-----------------+----------------+ 517| Total Risk Rating | Critical (20) | Critical (20) | Critical (20) | 518+------------------------+-----------------+-----------------+----------------+ 519| Mitigations | When configuring access permissions, the | 520| | principle of least privilege ought to be | 521| | enforced. This means we should not grant more | 522| | privileges than strictly needed, e.g. code | 523| | should be read-only executable, read-only data | 524| | should be read-only execute-never, and so on. | 525+------------------------+----------------------------------------------------+ 526| Mitigations | | Platform specific. | 527| implemented? | | 528| | | MMU configuration is platform specific, | 529| | therefore platforms need to make sure that the | 530| | correct attributes are assigned to memory | 531| | regions. | 532| | | 533| | | TF-A provides a library which abstracts the | 534| | low-level details of MMU configuration. It | 535| | provides well-defined and tested APIs. | 536| | Platforms are encouraged to use it to limit the | 537| | risk of misconfiguration. | 538+------------------------+----------------------------------------------------+ 539 540 541+------------------------+-----------------------------------------------------+ 542| ID | 13 | 543+========================+=====================================================+ 544| Threat | | **Leaving sensitive information in the memory, | 545| | can allow an attacker to retrieve them.** | 546| | | 547| | | Accidentally leaving not-needed sensitive data in | 548| | internal buffers can leak them if an attacker | 549| | gains access to memory due to a vulnerability. | 550+------------------------+-----------------------------------------------------+ 551| Diagram Elements | DF4, DF5 | 552+------------------------+-----------------------------------------------------+ 553| Affected TF-A | BL1, BL2, BL31 | 554| Components | | 555+------------------------+-----------------------------------------------------+ 556| Assets | Sensitive Data | 557+------------------------+-----------------------------------------------------+ 558| Threat Agent | NSCode, SecCode | 559+------------------------+-----------------------------------------------------+ 560| Threat Type | Information Disclosure | 561+------------------------+-------------------+----------------+----------------+ 562| Application | Server | IoT | Mobile | 563+------------------------+-------------------+----------------+----------------+ 564| Impact | Critical (5) | Critical (5) | Critical (5) | 565+------------------------+-------------------+----------------+----------------+ 566| Likelihood | Medium (3) | Medium (3) | Medium (3) | 567+------------------------+-------------------+----------------+----------------+ 568| Total Risk Rating | High (15) | High (15) | High (15) | 569+------------------------+-------------------+----------------+----------------+ 570| Mitigations | Clear the sensitive data from internal buffers as | 571| | soon as they are not needed anymore. | 572+------------------------+-----------------------------------------------------+ 573| Mitigations | | Yes / Platform specific | 574| implemented? | | 575+------------------------+-----------------------------------------------------+ 576 577 578+------------------------+-----------------------------------------------------+ 579| ID | 15 | 580+========================+=====================================================+ 581| Threat | | **Improper handling of input data received over | 582| | a UART interface may allow an attacker to tamper | 583| | with TF-A execution environment.** | 584| | | 585| | | The consequences of the attack depend on the | 586| | the exact usage of input data received over UART. | 587| | Examples are injection of arbitrary data, | 588| | sensitive data tampering, influencing the | 589| | execution path, denial of service (if using | 590| | blocking I/O). This list may not be exhaustive. | 591+------------------------+-----------------------------------------------------+ 592| Diagram Elements | DF2, DF4, DF5 | 593+------------------------+-----------------------------------------------------+ 594| Affected TF-A | BL1, BL2, BL31 | 595| Components | | 596+------------------------+-----------------------------------------------------+ 597| Assets | Sensitive Data, Code Execution, Availability | 598+------------------------+-----------------------------------------------------+ 599| Threat Agent | NSCode, SecCode | 600+------------------------+-----------------------------------------------------+ 601| Threat Type | Tampering, Information Disclosure, Denial of | 602| | service, Elevation of privilege. | 603+------------------------+-------------------+----------------+----------------+ 604| Application | Server | IoT | Mobile | 605+------------------------+-------------------+----------------+----------------+ 606| Impact | Critical (5) | Critical (5) | Critical (5) | 607+------------------------+-------------------+----------------+----------------+ 608| Likelihood | Critical (5) | Critical (5) | Critical (5) | 609+------------------------+-------------------+----------------+----------------+ 610| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) | 611+------------------------+-------------------+----------------+----------------+ 612| Mitigations | | By default, the code to read input data from UART | 613| | interfaces is disabled (see `ENABLE_CONSOLE_GETC` | 614| | build option). It should only be enabled on a | 615| | need basis. | 616| | | 617| | | Data received over UART interfaces should be | 618| | treated as untrusted data. As such, it should be | 619| | properly sanitized and handled with caution. | 620+------------------------+-----------------------------------------------------+ 621| Mitigations | | Platform specific. | 622| implemented? | | 623| | | Generic code does not read any input data from | 624| | UART interface(s). | 625+------------------------+-----------------------------------------------------+ 626 627+------------------------+-----------------------------------------------------+ 628| ID | 16 | 629+========================+=====================================================+ 630| Threat | | **An attacker could analyse the timing behaviour | 631| | of implemented methods in the system to infer | 632| | sensitive information.** | 633| | | 634| | | A timing side-channel attack is a type of attack | 635| | that exploits variations in the time it takes a | 636| | system to perform different operations. This | 637| | form of attack focuses on analyzing the time- | 638| | related information leakage that occurs during | 639| | the execution of cryptographic algorithms or | 640| | other security-sensitive processes. By observing | 641| | these timing differences, an attacker can gain | 642| | insights into the internal workings of a system | 643| | and potentially extract sensitive information. | 644| | Sensitive information that, when revealed even | 645| | partially, could heighten the susceptibility to | 646| | traditional attacks like brute-force attacks. | 647+------------------------+-----------------------------------------------------+ 648| Diagram Elements | DF2 | 649+------------------------+-----------------------------------------------------+ 650| Affected TF-A | BL1, BL2, BL31 | 651| Components | | 652+------------------------+-----------------------------------------------------+ 653| Assets | Sensitive Data | 654+------------------------+-----------------------------------------------------+ 655| Threat Agent | AppDebug | 656+------------------------+-----------------------------------------------------+ 657| Threat Type | Information Disclosure | 658+------------------------+------------------+----------------+-----------------+ 659| Application | Server | IoT | Mobile | 660+------------------------+------------------+----------------+-----------------+ 661| Impact | Critical (5) | Critical (5) | Critical (5) | 662+------------------------+------------------+----------------+-----------------+ 663| Likelihood | Critical (5) | Critical (5) | Critical (5) | 664+------------------------+------------------+----------------+-----------------+ 665| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) | 666+------------------------+------------------+----------------+-----------------+ 667| Mitigations | | Ensure that the execution time of critical | 668| | operations is constant and independent of | 669| | secret data. This prevents attackers from | 670| | exploiting timing differences to infer | 671| | information about sensitive data. | 672| | | 673| | | Introduce random delays/timing jitter or dummy | 674| | operations to make the timing behavior of program| 675| | execution less predictable. This can disrupt the | 676| | correlation between the execution time and | 677| | sensitive data. | 678| | | 679+------------------------+-----------------------------------------------------+ 680| Mitigations | | Not implemented | 681| implemented? | | 682+------------------------+-----------------------------------------------------+ 683 684.. _Boot Firmware Threats: 685 686Threats to be Mitigated by the Boot Firmware 687-------------------------------------------- 688 689The boot firmware here refers to the boot ROM (BL1) and the trusted boot 690firmware (BL2). Typically it does not stay resident in memory and it is 691dismissed once execution has reached the runtime EL3 firmware (BL31). Thus, past 692that point in time, the threats below can no longer be exploited. 693 694Note, however, that this is not necessarily true on all platforms. Platform 695vendors should review these threats to make sure they cannot be exploited 696nonetheless once execution has reached the runtime EL3 firmware. 697 698+------------------------+----------------------------------------------------+ 699| ID | 01 | 700+========================+====================================================+ 701| Threat | | **An attacker can mangle firmware images to | 702| | execute arbitrary code** | 703| | | 704| | | Some TF-A images are loaded from external | 705| | storage. It is possible for an attacker to access| 706| | the external flash memory and change its contents| 707| | physically, through the Rich OS, or using the | 708| | updating mechanism to modify the non-volatile | 709| | images to execute arbitrary code. | 710+------------------------+----------------------------------------------------+ 711| Diagram Elements | DF1, DF4, DF5 | 712+------------------------+----------------------------------------------------+ 713| Affected TF-A | BL2, BL31 | 714| Components | | 715+------------------------+----------------------------------------------------+ 716| Assets | Code Execution | 717+------------------------+----------------------------------------------------+ 718| Threat Agent | PhysicalAccess, NSCode, SecCode | 719+------------------------+----------------------------------------------------+ 720| Threat Type | Tampering, Elevation of Privilege | 721+------------------------+------------------+-----------------+---------------+ 722| Application | Server | IoT | Mobile | 723+------------------------+------------------+-----------------+---------------+ 724| Impact | Critical (5) | Critical (5) | Critical (5) | 725+------------------------+------------------+-----------------+---------------+ 726| Likelihood | Critical (5) | Critical (5) | Critical (5) | 727+------------------------+------------------+-----------------+---------------+ 728| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) | 729+------------------------+------------------+-----------------+---------------+ 730| Mitigations | | 1) Implement the `Trusted Board Boot (TBB)`_ | 731| | feature which prevents malicious firmware from | 732| | running on the platform by authenticating all | 733| | firmware images. | 734| | | 735| | | 2) Perform extra checks on unauthenticated data, | 736| | such as FIP metadata, prior to use. | 737+------------------------+----------------------------------------------------+ 738| Mitigations | | 1) Yes, provided that the ``TRUSTED_BOARD_BOOT`` | 739| implemented? | build option is set to 1. | 740| | | 741| | | 2) Yes. | 742+------------------------+----------------------------------------------------+ 743 744+------------------------+----------------------------------------------------+ 745| ID | 02 | 746+========================+====================================================+ 747| Threat | | **An attacker may attempt to boot outdated, | 748| | potentially vulnerable firmware image** | 749| | | 750| | | When updating firmware, an attacker may attempt | 751| | to rollback to an older version that has unfixed | 752| | vulnerabilities. | 753+------------------------+----------------------------------------------------+ 754| Diagram Elements | DF1, DF4, DF5 | 755+------------------------+----------------------------------------------------+ 756| Affected TF-A | BL2, BL31 | 757| Components | | 758+------------------------+----------------------------------------------------+ 759| Assets | Code Execution | 760+------------------------+----------------------------------------------------+ 761| Threat Agent | PhysicalAccess, NSCode, SecCode | 762+------------------------+----------------------------------------------------+ 763| Threat Type | Tampering | 764+------------------------+------------------+-----------------+---------------+ 765| Application | Server | IoT | Mobile | 766+------------------------+------------------+-----------------+---------------+ 767| Impact | Critical (5) | Critical (5) | Critical (5) | 768+------------------------+------------------+-----------------+---------------+ 769| Likelihood | Critical (5) | Critical (5) | Critical (5) | 770+------------------------+------------------+-----------------+---------------+ 771| Total Risk Rating | Critical (25) | Critical (25) | Critical (25) | 772+------------------------+------------------+-----------------+---------------+ 773| Mitigations | Implement anti-rollback protection using | 774| | non-volatile counters (NV counters) as required | 775| | by `TBBR-Client specification`_. | 776+------------------------+----------------------------------------------------+ 777| Mitigations | | Yes / Platform specific. | 778| implemented? | | 779| | | After a firmware image is validated, the image | 780| | revision number taken from a certificate | 781| | extension field is compared with the | 782| | corresponding NV counter stored in hardware to | 783| | make sure the new counter value is larger than | 784| | the current counter value. | 785| | | 786| | | **Platforms must implement this protection using | 787| | platform specific hardware NV counters.** | 788+------------------------+----------------------------------------------------+ 789 790 791+------------------------+-------------------------------------------------------+ 792| ID | 03 | 793+========================+=======================================================+ 794| Threat | | **An attacker can use Time-of-Check-Time-of-Use | 795| | (TOCTOU) attack to bypass image authentication | 796| | during the boot process** | 797| | | 798| | | Time-of-Check-Time-of-Use (TOCTOU) threats occur | 799| | when the security check is produced before the time | 800| | the resource is accessed. If an attacker is sitting | 801| | in the middle of the off-chip images, they could | 802| | change the binary containing executable code right | 803| | after the integrity and authentication check has | 804| | been performed. | 805+------------------------+-------------------------------------------------------+ 806| Diagram Elements | DF1 | 807+------------------------+-------------------------------------------------------+ 808| Affected TF-A | BL1, BL2 | 809| Components | | 810+------------------------+-------------------------------------------------------+ 811| Assets | Code Execution, Sensitive Data | 812+------------------------+-------------------------------------------------------+ 813| Threat Agent | PhysicalAccess | 814+------------------------+-------------------------------------------------------+ 815| Threat Type | Elevation of Privilege | 816+------------------------+---------------------+-----------------+---------------+ 817| Application | Server | IoT | Mobile | 818+------------------------+---------------------+-----------------+---------------+ 819| Impact | N/A | Critical (5) | Critical (5) | 820+------------------------+---------------------+-----------------+---------------+ 821| Likelihood | N/A | Medium (3) | Medium (3) | 822+------------------------+---------------------+-----------------+---------------+ 823| Total Risk Rating | N/A | High (15) | High (15) | 824+------------------------+---------------------+-----------------+---------------+ 825| Mitigations | Copy image to on-chip memory before authenticating | 826| | it. | 827+------------------------+-------------------------------------------------------+ 828| Mitigations | | Platform specific. | 829| implemented? | | 830| | | The list of images to load and their location is | 831| | platform specific. Platforms are responsible for | 832| | arranging images to be loaded in on-chip memory. | 833+------------------------+-------------------------------------------------------+ 834 835 836+------------------------+-------------------------------------------------------+ 837| ID | 04 | 838+========================+=======================================================+ 839| Threat | | **An attacker with physical access can execute | 840| | arbitrary image by bypassing the signature | 841| | verification stage using glitching techniques** | 842| | | 843| | | Glitching (Fault injection) attacks attempt to put | 844| | a hardware into a undefined state by manipulating an| 845| | environmental variable such as power supply. | 846| | | 847| | | TF-A relies on a chain of trust that starts with the| 848| | ROTPK, which is the key stored inside the chip and | 849| | the root of all validation processes. If an attacker| 850| | can break this chain of trust, they could execute | 851| | arbitrary code on the device. This could be | 852| | achieved with physical access to the device by | 853| | attacking the normal execution flow of the | 854| | process using glitching techniques that target | 855| | points where the image is validated against the | 856| | signature. | 857+------------------------+-------------------------------------------------------+ 858| Diagram Elements | DF1 | 859+------------------------+-------------------------------------------------------+ 860| Affected TF-A | BL1, BL2 | 861| Components | | 862+------------------------+-------------------------------------------------------+ 863| Assets | Code Execution | 864+------------------------+-------------------------------------------------------+ 865| Threat Agent | PhysicalAccess | 866+------------------------+-------------------------------------------------------+ 867| Threat Type | Tampering, Elevation of Privilege | 868+------------------------+---------------------+-----------------+---------------+ 869| Application | Server | IoT | Mobile | 870+------------------------+---------------------+-----------------+---------------+ 871| Impact | N/A | Critical (5) | Critical (5) | 872+------------------------+---------------------+-----------------+---------------+ 873| Likelihood | N/A | Medium (3) | Medium (3) | 874+------------------------+---------------------+-----------------+---------------+ 875| Total Risk Rating | N/A | High (15) | High (15) | 876+------------------------+---------------------+-----------------+---------------+ 877| Mitigations | Mechanisms to detect clock glitch and power | 878| | variations. | 879+------------------------+-------------------------------------------------------+ 880| Mitigations | | No. | 881| implemented? | | 882| | | The most effective mitigation is adding glitching | 883| | detection and mitigation circuit at the hardware | 884| | level. | 885| | | 886| | | However, software techniques, such as adding | 887| | redundant checks when performing conditional | 888| | branches that are security sensitive, can be used | 889| | to harden TF-A against such attacks. | 890| | **At the moment TF-A doesn't implement such | 891| | mitigations.** | 892+------------------------+-------------------------------------------------------+ 893 894.. topic:: Measured Boot Threats (or lack of) 895 896 In the current Measured Boot design the following components form the |TCB|: 897 898 - BL1, BL2, BL31 899 - Secure world components 900 - RMM (if RME extension is implemented) 901 - The configuration data of the above components 902 903 Across various Measured Boot backends, the data recorded during the flow as 904 well as the criticality of this data can vary. In most cases, these attributes 905 are considered valuable assets and are protected against potential attacks: 906 907 - Image measurement: the digest value of a component produced by a hash 908 function. 909 - Signer-id: the digest value of the image verification publiy key. The 910 verification public key is part of the image metadata. 911 912 In addition to these, other metadata attributes (image version, hash algorithm 913 identifier, etc) could be recorded during the Measured Boot process. But these 914 are not critical data. 915 916 In this context, an attack means modifying the measurement data (image or 917 public key hash) or recording arbitrary data as valid measurements. 918 919 The current Measured Boot design consists of two main parts. A frontend, which 920 is responsible for taking the measurements, and a backend which is responsible 921 for storing them. |TF-A| makes it possible to integrate various backends. Some 922 of these are implemented by the |TF-A| projects, while others are part of 923 different projects, and |TF-A| provides an integration layer. 924 925 - TCG-compliant Event Log: Implemented by |TF-A|. Measurements are stored in 926 the Event Log which is located on the secure on-chip memory of the AP. The 927 address of the Event Log buffer is handed off between boot stages and new 928 measurements are appended to the Event Log. A limitation of the current 929 Measured Boot implementation in |TF-A| is that it does not extend the 930 measurements into a |PCR| of a Discrete |TPM|, where measurements would 931 be securely stored and protected against tampering. 932 - Discrete |TPM|: Implemented in |TF-A| as a proof of concept, the Discrete 933 |TPM| is used alongside the existing TCG-compliant Event Log. This 934 Measured Boot implementation extends measurement hashes to a |PCR| in the 935 |TPM|, which provides a hardware-backed root of trust. The measurements in 936 the Event Log can now be hashed and compared to the value of the |PCR| to 937 determine if tampering of the Event Log has taken place. 938 - `CCA Measured Boot`_: Implemented by |TF-M|. Measurements are stored in 939 |HES| secure on-chip memory. |HES| implements protection against tampering 940 its on-chip memory. |HES| interface is available for BL1 and BL2. 941 - `DICE Protection Environment`_ (DPE): Implemented by |TF-M|. Measurements 942 are stored in |RSE| secure on-chip memory. |RSE| implements protection 943 against tampering its on-chip memory. DPE provides additional protection 944 against unauthorized access by malicious actors through the use of one-time 945 context handles and the identification of the client's target locality 946 (location of the client). 947 948 Beyond the measurements (image digest and signer-id) there are no other assets 949 to protect or threats to defend against that could compromise |TF-A| execution 950 environment's security. 951 952 When considering the implementation of Measured Boot using a TCG-compliant 953 Event Log backed by a discrete TPM, physical vulnerabilities come to mind. 954 Platforms have many different ways of integrating a discrete TPM, and these 955 implementations can be susceptible to man-in-the-middle attacks, where the 956 attacker intercepts the bus traffic between the discrete TPM and the host 957 machine. This can lead to PCR extend operations being modified, compromising 958 Measured Boot. This vulnerability requires physical access to the host machine. 959 960 TF-A does not provide any mitigations against these physical vulnerabilities, 961 it is the responsibility of the platform owners to address this based on their 962 specific threat model. Mitigation of this can be achieved through dedicated 963 hardware solutions, such as an encrypted AP/dTPM bus, or software-based 964 approaches designed to protect sensitive data such as parameter encryption. 965 966 There are general security assets and threats associated with remote/delegated 967 attestation. However, these are outside the |TF-A| security boundary and 968 should be dealt with by the appropriate agent in the platform/system. 969 Since current Measured Boot design does not use local attestation, there would 970 be no further assets to protect (like unsealed keys). 971 972 System integrators must carefully evaluate the security requirement and 973 capabilities of their platform and choose an appropriate Measured Boot 974 solution. 975 976 977.. _Runtime Firmware Threats: 978 979Threats to be Mitigated by the Runtime EL3 Firmware 980--------------------------------------------------- 981 982+------------------------+------------------------------------------------------+ 983| ID | 07 | 984+========================+======================================================+ 985| Threat | | **An attacker can perform a denial-of-service | 986| | attack by using a broken SMC call that causes the | 987| | system to reboot or enter into unknown state.** | 988| | | 989| | | Secure and non-secure clients access TF-A services | 990| | through SMC calls. Malicious code can attempt to | 991| | place the TF-A runtime into an inconsistent state | 992| | by calling unimplemented SMC call or by passing | 993| | invalid arguments. | 994+------------------------+------------------------------------------------------+ 995| Diagram Elements | DF4, DF5 | 996+------------------------+------------------------------------------------------+ 997| Affected TF-A | BL31 | 998| Components | | 999+------------------------+------------------------------------------------------+ 1000| Assets | Availability | 1001+------------------------+------------------------------------------------------+ 1002| Threat Agent | NSCode, SecCode | 1003+------------------------+------------------------------------------------------+ 1004| Threat Type | Denial of Service | 1005+------------------------+-------------------+----------------+-----------------+ 1006| Application | Server | IoT | Mobile | 1007+------------------------+-------------------+----------------+-----------------+ 1008| Impact | Medium (3) | Medium (3) | Medium (3) | 1009+------------------------+-------------------+----------------+-----------------+ 1010| Likelihood | High (4) | High (4) | High (4) | 1011+------------------------+-------------------+----------------+-----------------+ 1012| Total Risk Rating | High (12) | High (12) | High (12) | 1013+------------------------+-------------------+----------------+-----------------+ 1014| Mitigations | Validate SMC function ids and arguments before using | 1015| | them. | 1016+------------------------+------------------------------------------------------+ 1017| Mitigations | | Yes / Platform specific. | 1018| implemented? | | 1019| | | For standard services, all input is validated. | 1020| | | 1021| | | Platforms that implement SiP services must also | 1022| | validate SMC call arguments. | 1023+------------------------+------------------------------------------------------+ 1024 1025 1026+------------------------+------------------------------------------------------+ 1027| ID | 09 | 1028+========================+======================================================+ 1029| Threat | | **Improperly handled SMC calls can leak register | 1030| | contents** | 1031| | | 1032| | | When switching between worlds, TF-A register state | 1033| | can leak to software in different security | 1034| | contexts. | 1035+------------------------+------------------------------------------------------+ 1036| Diagram Elements | DF4, DF5 | 1037+------------------------+------------------------------------------------------+ 1038| Affected TF-A | BL31 | 1039| Components | | 1040+------------------------+------------------------------------------------------+ 1041| Assets | Availability, Sensitive data | 1042+------------------------+------------------------------------------------------+ 1043| Threat Agent | NSCode, SecCode | 1044+------------------------+------------------------------------------------------+ 1045| Threat Type | Information disclosure, Denial of Service | 1046+------------------------+-------------------+----------------+-----------------+ 1047| Application | Server | IoT | Mobile | 1048+------------------------+-------------------+----------------+-----------------+ 1049| Impact | Medium (3) | Medium (3) | Medium (3) | 1050+------------------------+-------------------+----------------+-----------------+ 1051| Likelihood | High (4) | High (4) | High (4) | 1052+------------------------+-------------------+----------------+-----------------+ 1053| Total Risk Rating | High (12) | High (12) | High (12) | 1054+------------------------+-------------------+----------------+-----------------+ 1055| Mitigations | Save and restore registers when switching contexts. | 1056+------------------------+------------------------------------------------------+ 1057| Mitigations | | Yes / Platform specific. FEATURE_DETECTION is | 1058| implemented? | provided to match firmware to hardware. | 1059| | | 1060| | | This is the default behaviour in TF-A. | 1061| | Build options are also provided to save/restore | 1062| | additional registers such as floating-point | 1063| | registers. These should be enabled if required. | 1064+------------------------+------------------------------------------------------+ 1065 1066+------------------------+-----------------------------------------------------+ 1067| ID | 10 | 1068+========================+=====================================================+ 1069| Threat | | **SMC calls can leak sensitive information from | 1070| | TF-A memory via microarchitectural side channels**| 1071| | | 1072| | | Microarchitectural side-channel attacks such as | 1073| | `Spectre`_ can be used to leak data across | 1074| | security boundaries. An attacker might attempt to | 1075| | use this kind of attack to leak sensitive | 1076| | data from TF-A memory. | 1077+------------------------+-----------------------------------------------------+ 1078| Diagram Elements | DF4, DF5 | 1079+------------------------+-----------------------------------------------------+ 1080| Affected TF-A | BL31 | 1081| Components | | 1082+------------------------+-----------------------------------------------------+ 1083| Assets | Sensitive Data | 1084+------------------------+-----------------------------------------------------+ 1085| Threat Agent | SecCode, NSCode | 1086+------------------------+-----------------------------------------------------+ 1087| Threat Type | Information Disclosure | 1088+------------------------+-------------------+----------------+----------------+ 1089| Application | Server | IoT | Mobile | 1090+------------------------+-------------------+----------------+----------------+ 1091| Impact | Medium (3) | Medium (3) | Medium (3) | 1092+------------------------+-------------------+----------------+----------------+ 1093| Likelihood | Medium (3) | Medium (3) | Medium (3) | 1094+------------------------+-------------------+----------------+----------------+ 1095| Total Risk Rating | Medium (9) | Medium (9) | Medium (9) | 1096+------------------------+-------------------+----------------+----------------+ 1097| Mitigations | Enable appropriate side-channel protections. | 1098+------------------------+-----------------------------------------------------+ 1099| Mitigations | | Yes / Platform specific. | 1100| implemented? | | 1101| | | TF-A implements software mitigations for Spectre | 1102| | type attacks as recommended by `Cache Speculation | 1103| | Side-channels`_ for the generic code. | 1104| | | 1105| | | SiPs should implement similar mitigations for | 1106| | code that is deemed to be vulnerable to such | 1107| | attacks. | 1108+------------------------+-----------------------------------------------------+ 1109 1110 1111+------------------------+-----------------------------------------------------+ 1112| ID | 12 | 1113+========================+=====================================================+ 1114| Threat | | **Incorrect configuration of Performance Monitor | 1115| | Unit (PMU) counters can allow an attacker to | 1116| | mount side-channel attacks using information | 1117| | exposed by the counters** | 1118| | | 1119| | | Non-secure software can configure PMU registers | 1120| | to count events at any exception level and in | 1121| | both Secure and Non-secure states. This allows | 1122| | a Non-secure software (or a lower-level Secure | 1123| | software) to potentially carry out | 1124| | side-channel timing attacks against TF-A. | 1125+------------------------+-----------------------------------------------------+ 1126| Diagram Elements | DF5, DF6 | 1127+------------------------+-----------------------------------------------------+ 1128| Affected TF-A | BL31 | 1129| Components | | 1130+------------------------+-----------------------------------------------------+ 1131| Assets | Sensitive Data | 1132+------------------------+-----------------------------------------------------+ 1133| Threat Agent | NSCode | 1134+------------------------+-----------------------------------------------------+ 1135| Threat Type | Information Disclosure | 1136+------------------------+-------------------+----------------+----------------+ 1137| Application | Server | IoT | Mobile | 1138+------------------------+-------------------+----------------+----------------+ 1139| Impact | Medium (3) | Medium (3) | Medium (3) | 1140+------------------------+-------------------+----------------+----------------+ 1141| Likelihood | Low (2) | Low (2) | Low (2) | 1142+------------------------+-------------------+----------------+----------------+ 1143| Total Risk Rating | Medium (6) | Medium (6) | Medium (6) | 1144+------------------------+-------------------+----------------+----------------+ 1145| Mitigations | Follow mitigation strategies as described in | 1146| | `Secure Development Guidelines`_. | 1147+------------------------+-----------------------------------------------------+ 1148| Mitigations | | Yes / platform specific. | 1149| implemented? | | 1150| | | General events and cycle counting in the Secure | 1151| | world is prohibited by default when applicable. | 1152| | | 1153| | | However, on some implementations (e.g. PMUv3) | 1154| | Secure world event counting depends on external | 1155| | debug interface signals, i.e. Secure world event | 1156| | counting is enabled if external debug is enabled. | 1157| | | 1158| | | Configuration of debug signals is platform | 1159| | specific, therefore platforms need to make sure | 1160| | that external debug is disabled in production or | 1161| | proper debug authentication is in place. This | 1162| | should be the case if threat #06 is properly | 1163| | mitigated. | 1164+------------------------+-----------------------------------------------------+ 1165 1166 1167Threats to be Mitigated by an External Agent Outside of TF-A 1168------------------------------------------------------------ 1169 1170+------------------------+-----------------------------------------------------+ 1171| ID | 14 | 1172+========================+=====================================================+ 1173| Threat | | **Attacker wants to execute an arbitrary or | 1174| | untrusted binary as the secure OS.** | 1175| | | 1176| | | When the option OPTEE_ALLOW_SMC_LOAD is enabled, | 1177| | this trusts the non-secure world up until the | 1178| | point it issues the SMC call to load the Secure | 1179| | BL32 payload. If a compromise occurs before the | 1180| | SMC call is invoked, then arbitrary code execution| 1181| | in S-EL1 can occur or arbitrary memory in EL3 can | 1182| | be overwritten. | 1183+------------------------+-----------------------------------------------------+ 1184| Diagram Elements | DF5 | 1185+------------------------+-----------------------------------------------------+ 1186| Affected TF-A | BL31, BL32 | 1187| Components | | 1188+------------------------+-----------------------------------------------------+ 1189| Assets | Code Execution, Sensitive Data | 1190+------------------------+-----------------------------------------------------+ 1191| Threat Agent | NSCode | 1192+------------------------+-----------------------------------------------------+ 1193| Threat Type | Tampering, Information Disclosure, | 1194| | Elevation of privilege | 1195+------------------------+-----------------+-----------------+-----------------+ 1196| Application | Server | IoT | Mobile | 1197+------------------------+-----------------+-----------------+-----------------+ 1198| Impact | Critical (5) | Critical (5) | Critical (5) | 1199+------------------------+-----------------+-----------------+-----------------+ 1200| Likelihood | High (4) | High (4) | High (4) | 1201+------------------------+-----------------+-----------------+-----------------+ 1202| Total Risk Rating | Critical (20) | Critical (20) | Critical (20) | 1203+------------------------+-----------------+-----------------+-----------------+ 1204| Mitigations | When enabling the option OPTEE_ALLOW_SMC_LOAD, | 1205| | the non-secure OS must be considered a closed | 1206| | platform up until the point the SMC can be invoked | 1207| | to load OP-TEE. | 1208+------------------------+-----------------------------------------------------+ 1209| Mitigations | | None in TF-A itself. This option is only used by | 1210| implemented? | ChromeOS currently which has other mechanisms to | 1211| | to mitigate this threat which are described in | 1212| | `OP-TEE Dispatcher`_. | 1213+------------------------+-----------------------------------------------------+ 1214 1215-------------- 1216 1217*Copyright (c) 2021-2025, Arm Limited. All rights reserved.* 1218 1219 1220.. _STRIDE threat analysis technique: https://docs.microsoft.com/en-us/azure/security/develop/threat-modeling-tool-threats#stride-model 1221.. _DEN0034: https://developer.arm.com/documentation/den0034/latest 1222.. _Cache Speculation Side-channels: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability 1223.. _Spectre: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability 1224.. _TBBR-Client specification: https://developer.arm.com/documentation/den0006/d/ 1225.. _Trusted Board Boot (TBB): https://trustedfirmware-a.readthedocs.io/en/latest/design/trusted-board-boot.html 1226.. _TF-A error handling policy: https://trustedfirmware-a.readthedocs.io/en/latest/process/coding-guidelines.html#error-handling-and-robustness 1227.. _Secure Development Guidelines: https://trustedfirmware-a.readthedocs.io/en/latest/process/security-hardening.html#secure-development-guidelines 1228.. _Trusted Firmware-A Tests: https://git.trustedfirmware.org/TF-A/tf-a-tests.git/about/ 1229.. _OP-TEE Dispatcher: https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/components/spd/optee-dispatcher.rst 1230.. _PSR Specification: https://developer.arm.com/documentation/den0106/0100 1231.. _CCA Measured Boot: https://trustedfirmware-m.readthedocs.io/projects/tf-m-extras/en/latest/partitions/measured_boot_integration_guide.html 1232.. _DICE Protection Environment: https://trustedfirmware-m.readthedocs.io/projects/tf-m-extras/en/latest/partitions/dice_protection_environment/dice_protection_environment.html 1233