1.. SPDX-License-Identifier: BSD-3-Clause 2.. SPDX-FileCopyrightText: Copyright TF-RMM Contributors. 3 4Threat Assessment 5================= 6 7The following threats were identified by applying STRIDE analysis on 8each diagram element of the data flow diagram. The threats are related to 9software and implementation specific to TF-RMM. 10 11For each threat, we strive to indicate whether the mitigations are currently 12implemented or not. However, the answer to this question is not always 13straightforward. Some mitigations are partially implemented in the generic code 14but also rely on the platform code to implement some bits of it. This threat 15model aims to be platform-independent and it is important to keep in mind that 16such threats only get mitigated if the platform properly fulfills its 17responsibilities. 18 19Also, some mitigations might require enabling specific features, which must be 20explicitly turned on via a build flag. 21 22The ``Pending actions?`` box highlights any action that needs to be done in 23order to implement the mitigations. 24 25+------------------------+---------------------------------------------------+ 26| ID | 01 | 27+========================+===================================================+ 28| Threat | | Information leak via UART logs. | 29| | | 30| | | During the development stages of software it is | 31| | common to print all sorts of information on the | 32| | | console, including sensitive or confidential | 33| | information such as crash reports with detailed | 34| | | information of the CPU state, current registers | 35| | values, privilege level or stack dumps. | 36| | | 37| | | This information is useful when debugging | 38| | problems before releasing the production | 39| | | version but it could be used by an adversary | 40| | to develop a working exploit if left enabled in | 41| | | the production version. | 42| | | 43| | | This happens when directly logging sensitive | 44| | information and more subtly when logging based | 45| | | on sensitive data that can be used as a | 46| | side-channel information by an adversary. | 47+------------------------+---------------------------------------------------+ 48| Diagram Elements | DF2 | 49+------------------------+---------------------------------------------------+ 50| Assets | Sensitive Data | 51+------------------------+---------------------------------------------------+ 52| Threat Agent | AppDebug | 53+------------------------+---------------------------------------------------+ 54| Threat Type | Information Disclosure | 55+------------------------+---------------------------------------------------+ 56| Impact | Informational (1) | 57+------------------------+---------------------------------------------------+ 58| Likelihood | Informational (1) | 59+------------------------+---------------------------------------------------+ 60| Total Risk Rating | Informational (1) | 61+------------------------+---------------------------------------------------+ 62| Mitigations | | 1) For production releases: | 63| | | i) Remove sensitive information logging. | 64| | | ii) Do not conditionally log based on | 65| | sensitive data. | 66| | | iii) Do not log high precision timing | 67| | information. | 68| | | iv) Do not log register contents which may | 69| | reveal secrets during crashes (Error | 70| | | Syndrome registers are allowed to be | 71| | logged). | 72| | | 73| | | 2) Provide option to fully disable RMM logging | 74| | for production releases. | 75+------------------------+---------------------------------------------------+ 76| Mitigations | | 1) Yes/Platform-specific. | 77| implemented? | | The default log level does not output verbose| 78| | log. RMM does not implement crash reporting. | 79| | | Messages produced by the platform code | 80| | should use the appropriate level of verbosity| 81| | | so as not to leak sensitive information in | 82| | production builds. | 83| | | 2) Yes. | 84| | | RMM provides the ``LOG_LEVEL`` build option | 85| | which can be used to disable all logging. | 86+------------------------+---------------------------------------------------+ 87| Pending actions? | | 1) Ensure the right verbosity level is used for | 88| | the type of information that it is logged. | 89+------------------------+---------------------------------------------------+ 90 91+------------------------+---------------------------------------------------+ 92| ID | 02 | 93+========================+===================================================+ 94| Threat | | An adversary can try stealing information by | 95| | using RMM ABI. | 96| | | 97| | | NS Host accesses RMM through RMM ABI. Malicious | 98| | code can attempt to invoke services that would | 99| | | result in disclosing private information or | 100| | secrets. | 101+------------------------+---------------------------------------------------+ 102| Diagram Elements | DF7 | 103+------------------------+---------------------------------------------------+ 104| Assets | Sensitive Data | 105+------------------------+---------------------------------------------------+ 106| Threat Agent | HostSoftware | 107+------------------------+---------------------------------------------------+ 108| Threat Type | Information Disclosure | 109+------------------------+---------------------------------------------------+ 110| Impact | High (4) | 111+------------------------+---------------------------------------------------+ 112| Likelihood | High (4) | 113+------------------------+---------------------------------------------------+ 114| Total Risk Rating | High (16) | 115+------------------------+---------------------------------------------------+ 116| Mitigations | | 1) Ensure that RMM protects the Realm memory by | 117| | using GPT service provided by EL3 Firmware | 118| | | and appropriate Stage 2 protections. NS Host | 119| | must not be able to change or access Realm | 120| | | memory. | 121| | | 2) NS host must not be able to change or access | 122| | Realm CPU register contents other than what | 123| | | is allowed by RMM ABI. Root code should | 124| | perform proper context switching of certain | 125| | | subset of CPU registers as mandated in | 126| | `RMM-EL3 Communication Interface`_ when | 127| | | entering and exiting the Realm world. | 128| | Similarly, RMM should context switch any | 129| | | registers not managed by EL3 when | 130| | entering/exiting Realms. | 131| | | 3) The RME Architecture provides means to | 132| | configure memory isolation to the Realm | 133| | | world. RMM relies on Root code for correct | 134| | RME setup. But when undelegating memory to | 135| | | the Normal world, RMM needs to ensure that | 136| | suitable memory scrubbing is implemented. | 137| | | Also, RMM should ensure any architectural | 138| | caches are invalidated before returning back | 139| | | to NS Host. | 140+------------------------+---------------------------------------------------+ 141| Mitigations | | 1) Yes. | 142| implemented? | | 2) Yes. | 143| | | 3) Yes. | 144+------------------------+---------------------------------------------------+ 145| Pending actions? | | None. | 146+------------------------+---------------------------------------------------+ 147 148+------------------------+---------------------------------------------------+ 149| ID | 03 | 150+========================+===================================================+ 151| Threat | | An adversary can perform a denial-of-service | 152| | attack on the system by causing the Realm | 153| | | world/RMM to deadlock, crash or enter into an | 154| | unknown state. | 155+------------------------+---------------------------------------------------+ 156| Diagram Elements | DF5, DF7 | 157+------------------------+---------------------------------------------------+ 158| Assets | Availability | 159+------------------------+---------------------------------------------------+ 160| Threat Agent | RealmCode, HostSoftware | 161+------------------------+---------------------------------------------------+ 162| Threat Type | Denial of Service | 163+------------------------+---------------------------------------------------+ 164| Impact | Medium (3) | 165+------------------------+---------------------------------------------------+ 166| Likelihood | Low (2) | 167+------------------------+---------------------------------------------------+ 168| Total Risk Rating | Medium (6) | 169+------------------------+---------------------------------------------------+ 170| Mitigations | | 1) Upon an unrecoverable/catastrophic condition,| 171| | RMM should issue a ``panic()``. This would | 172| | | return to EL3 Firmware, keeping the | 173| | availability of the overall system. It would | 174| | | be EL3 responsibility to decide how to | 175| | proceed (e.g. by disabling the whole Realm | 176| | | world). | 177| | | 2) EL3 Firmware needs to implement a watchdog | 178| | mechanism to recover CPUs from Realm World. | 179+------------------------+---------------------------------------------------+ 180| Mitigations | | 1) No. | 181| implemented? | | 2) Mitigation would need support from EL3 | 182| | Firmware. | 183+------------------------+---------------------------------------------------+ 184| Pending actions? | | ``panic()`` needs appropriate implementation to | 185| | return to EL3 Firmware. | 186+------------------------+---------------------------------------------------+ 187 188+------------------------+---------------------------------------------------+ 189| ID | 04 | 190+========================+===================================================+ 191| Threat | | Malicious Host or Realm code can attempt to | 192| | place the RMM into an inconsistent state due to | 193| | | incorrect implementation of RMM state machines. | 194| | This inconsistency can be exploited to lead | 195| | | incorrect operation of RMM. | 196+------------------------+---------------------------------------------------+ 197| Diagram Elements | DF5, DF7 | 198+------------------------+---------------------------------------------------+ 199| Assets | Availability, Sensitive Data, Code Execution | 200+------------------------+---------------------------------------------------+ 201| Threat Agent | RealmCode, HostSoftware | 202+------------------------+---------------------------------------------------+ 203| Threat Type | Denial of Service, Tampering, Elevation of | 204| | privilege, Information Disclosure | 205+------------------------+---------------------------------------------------+ 206| Impact | Medium (3) | 207+------------------------+---------------------------------------------------+ 208| Likelihood | Low (2) | 209+------------------------+---------------------------------------------------+ 210| Total Risk Rating | Medium (6) | 211+------------------------+---------------------------------------------------+ 212| Mitigations | | 1) State machines should be tested for all the | 213| | transitions and validated that all invalid | 214| | | transitions and inputs are rejected. | 215| | | 2) The RMM ABI mandates pre and post conditions | 216| | for each ABI. The tests should verify that | 217| | | these conditions are adhered to and | 218| | implemented. | 219| | | 3) Static analyzers and model checkers can be | 220| | used to uncover bugs in implementation. | 221| | | 4) Fuzz testing can be employed to uncover | 222| | further issues in implementation. | 223| | | 5) Upon an unrecoverable/catastrophic condition | 224| | occurs, RMM should issue a ``panic()`` to | 225| | | prevent further corruption of data or | 226| | propagation of errors. | 227+------------------------+---------------------------------------------------+ 228| Mitigations | | 1) Partial. | 229| implemented? | | There are various tests in TFTF, ACS and | 230| | kvm-unit-tests for exercising the ABI which | 231| | | triggers the state machines. Unit tests are | 232| | also present for some components to exercise | 233| | | internal APIs which can further test | 234| | conditions and invalid cases which cannot be | 235| | | triggered via RMM ABI. | 236| | | 2) Partial. | 237| | | Code reviews to ensure the implementation | 238| | complies the required conditions. Automated | 239| | | checking via CBMC to validate the same is | 240| | also being implemented. | 241| | | 3) Yes. | 242| | | CPPCheck and Coverity scan are used to detect| 243| | issues. CBMC is also utilized as a model | 244| | | checker. | 245| | | 4) No. | 246| | | 5) Yes. | 247+------------------------+---------------------------------------------------+ 248| Pending actions? | | Expand coverage of unittests in RMM. Evolve | 249| | tests in other test frameworks in an ongoing | 250| | | manner. Integrate CBMC into RMM testing. | 251| | Implement Fuzz testing for RMM. | 252+------------------------+---------------------------------------------------+ 253 254+------------------------+---------------------------------------------------+ 255| ID | 05 | 256+========================+===================================================+ 257| Threat | | Malicious Host or Realm code can attack RMM by | 258| | calling unimplemented SMC calls or by passing | 259| | | invalid arguments to the ABI. | 260+------------------------+---------------------------------------------------+ 261| Diagram Elements | DF5, DF7 | 262+------------------------+---------------------------------------------------+ 263| Assets | Sensitive Data, Code Execution | 264+------------------------+---------------------------------------------------+ 265| Threat Agent | RealmCode, HostSoftware | 266+------------------------+---------------------------------------------------+ 267| Threat Type | Denial of Service, Tampering, Elevation of | 268| | privilege, Information Disclosure | 269+------------------------+---------------------------------------------------+ 270| Impact | High (4) | 271+------------------------+---------------------------------------------------+ 272| Likelihood | High (4) | 273+------------------------+---------------------------------------------------+ 274| Total Risk Rating | High (16) | 275+------------------------+---------------------------------------------------+ 276| Mitigations | | 1) Validate SMC function IDs and arguments | 277| | before using them. | 278| | | 2) Invalid/Unimplemented SMCs should return back| 279| | to caller with error code. | 280| | | 3) Tests to exercise invalid arguments and | 281| | unimplemented SMCs. | 282+------------------------+---------------------------------------------------+ 283| Mitigations | | 1) Yes. | 284| implemented? | | 2) Yes. | 285| | | 3) Partial. | 286| | | The ACS test utility exercises many invalid | 287| | inputs. Unit tests also test various invalid | 288| | | cases. | 289+------------------------+---------------------------------------------------+ 290| Pending actions? | | Expand unit tests to cover the RMM ABI interface| 291| | and test for invalid inputs. | 292+------------------------+---------------------------------------------------+ 293 294+------------------------+---------------------------------------------------+ 295| ID | 06 | 296+========================+===================================================+ 297| Threat | | An adversary can make use of incorrect | 298| | implementation of concurrent sections in RMM to | 299| | | cause data corruption or dead/live locks. | 300+------------------------+---------------------------------------------------+ 301| Diagram Elements | DF5, DF7 | 302+------------------------+---------------------------------------------------+ 303| Assets | Availability, Sensitive Data, Code Execution | 304+------------------------+---------------------------------------------------+ 305| Threat Agent | RealmCode, HostSoftware | 306+------------------------+---------------------------------------------------+ 307| Threat Type | Denial of Service, Tampering, Elevation of | 308| | privilege, Information Disclosure | 309+------------------------+---------------------------------------------------+ 310| Impact | Medium (3) | 311+------------------------+---------------------------------------------------+ 312| Likelihood | Low (2) | 313+------------------------+---------------------------------------------------+ 314| Total Risk Rating | Medium (6) | 315+------------------------+---------------------------------------------------+ 316| Mitigations | | 1) Follow locking discipline described in | 317| | `RMM Locking Guidelines`_ when implementing | 318| | | concurrent sections in RMM. | 319| | | 2) Validate locking discipline using tests which| 320| | can run multiple threads in RMM. | 321| | | 3) Fuzz tests on RMM with multiple threads. | 322+------------------------+---------------------------------------------------+ 323| Mitigations | | 1) Yes. | 324| implemented? | | 2) Yes. | 325| | | The TFX test has tests which can test | 326| | concurrent sections in RMM. Also, stress | 327| | | tests in CI will also test this scenario. | 328| | | 3) No. | 329| | | Need further investigation. | 330+------------------------+---------------------------------------------------+ 331| Pending actions? | | Enhance TFX tests to test more concurrent | 332| | sections in RMM. Investigate the possibility of | 333| | | multithread Fuzz Testing. | 334+------------------------+---------------------------------------------------+ 335 336+------------------------+---------------------------------------------------+ 337| ID | 07 | 338+========================+===================================================+ 339| Threat | | A Realm can claim to be another Realm. NS Host | 340| | can associate the PA of one Realm to another | 341| | | Realm. | 342+------------------------+---------------------------------------------------+ 343| Diagram Elements | DF5, DF7 | 344+------------------------+---------------------------------------------------+ 345| Assets | Sensitive Data | 346+------------------------+---------------------------------------------------+ 347| Threat Agent | RealmCode, HostSoftware | 348+------------------------+---------------------------------------------------+ 349| Threat Type | Spoofing | 350+------------------------+---------------------------------------------------+ 351| Impact | High (4) | 352+------------------------+---------------------------------------------------+ 353| Likelihood | Low (2) | 354+------------------------+---------------------------------------------------+ 355| Total Risk Rating | Medium (8) | 356+------------------------+---------------------------------------------------+ 357| Mitigations | | 1) A Realm should not be able to spoof another | 358| | realm. The NSHost must not be able to assign | 359| | | a granule/metadata to a Realm which is | 360| | already assigned to another Realm. | 361+------------------------+---------------------------------------------------+ 362| Mitigations | | 1) Yes. | 363| Implemented? | | This mitigation is inherently supported by | 364| | the RMM ABI. SMC call from realm is always | 365| | | associated to the Realm Descriptor (RD) and | 366| | the RMM ABI does not allow spoofing of RD. | 367| | | NS Host always has to pass the address of a | 368| | valid RD to make requests to the | 369| | | corresponding Realm. RMM maintains a global | 370| | granule array and every granule linked to a | 371| | | Realm has a specific State and reference | 372| | count associated with it. Hence, the NS Host | 373| | | cannot associate an already Realm associated | 374| | granule to another Realm. | 375+------------------------+---------------------------------------------------+ 376| Pending actions? | | None. | 377+------------------------+---------------------------------------------------+ 378 379+------------------------+---------------------------------------------------+ 380| ID | 08 | 381+========================+===================================================+ 382| Threat | | An adversary could execute arbitrary code, | 383| | modify some state variables, change the normal | 384| | | flow of the program or leak sensitive | 385| | information if memory overflows and boundary | 386| | | checks when accessing resources are not properly| 387| | handled. In the particular case in which the | 388| | | control flow can be changed by a stack overflow,| 389| | code execution can also be subverted by an | 390| | | adversary. | 391| | | 392| | | Like in other software, RMM has multiple points | 393| | where memory corruption and security errors can | 394| | | arise. | 395| | | 396| | | Some of the errors include integer overflow, | 397| | buffer overflow, incorrect array boundary checks| 398| | | and incorrect error management. | 399| | Improper use of asserts instead of proper input | 400| | | validations might also result in these kinds of | 401| | errors in release builds. | 402+------------------------+---------------------------------------------------+ 403| Diagram Elements | DF5, DF7 | 404+------------------------+---------------------------------------------------+ 405| Assets | Code Execution, Sensitive Data, Availability | 406+------------------------+---------------------------------------------------+ 407| Threat Agent | RealmCode, HostSoftware | 408+------------------------+---------------------------------------------------+ 409| Threat Type | Tampering, Information Disclosure, | 410| | Elevation of Privilege | 411+------------------------+---------------------------------------------------+ 412| Impact | Medium (3) | 413+------------------------+---------------------------------------------------+ 414| Likelihood | Low (2) | 415+------------------------+---------------------------------------------------+ 416| Total Risk Rating | Medium (6) | 417+------------------------+---------------------------------------------------+ 418| Mitigations | | 1) Use proper input validation. | 419| | | 2) Enable Architecture security features to | 420| | mitigate buffer overflow and ROP/JOP issues. | 421| | | 3) Utilize stack protection mechanism provided | 422| | by the compiler. | 423| | | 4) Design suitable per CPU stack protection, so | 424| | another CPU cannot corrupt stack which does | 425| | | not belong to it. | 426| | | 5) Suitable testing to test bounds of inputs. | 427| | | 6) Employ secure coding guidelines like MISRA to| 428| | remove many of the type safety issues | 429| | | associated with the C language. | 430| | | 7) Use static analyzers to check for common | 431| | issues. Also, make use of model checkers to | 432| | | validate loop bounds and other bounds in the | 433| | source code. | 434+------------------------+---------------------------------------------------+ 435| Mitigations | | 1) Yes. | 436| implemented? | | 2) Yes. | 437| | | RMM Enables many Architecture security | 438| | features like PAuth and BTI but there is | 439| | | ongoing action to enable more architectural | 440| | security features. | 441| | | 3) No. | 442| | | 4) No. | 443| | | 5) Partial. | 444| | | Some tests are present, but more tests needed| 445| | to ensure the bounds are validated. | 446| | | 6) Yes. | 447| | | 7) Partial. | 448| | RMM uses CPPCheck and Coverity Scan to detect| 449| | | issues. RMM also utilizes CMBC to ensure that| 450| | bounds in loops and other program constructs | 451| | | are proper. | 452+------------------------+---------------------------------------------------+ 453| Pending actions? | | Add sanitizers like ASAN, MSAN or UBSAN. | 454| | Implement further Architecture extensions | 455| | | related to security. RMM needs to implement | 456| | per-CPU stack protection and also provide | 457| | | capability to add compiler stack protection | 458| | features as a user option. | 459+------------------------+---------------------------------------------------+ 460 461+------------------------+---------------------------------------------------+ 462| ID | 09 | 463+========================+===================================================+ 464| Threat | | SMC calls can leak sensitive information from | 465| | RMM memory via microarchitectural side channels.| 466| | | 467| | | Microarchitectural side-channel attacks such as | 468| | `Spectre`_ can be used to leak data across | 469| | | security boundaries. An adversary might attempt | 470| | to use this kind of attack to leak sensitive | 471| | | data from RMM memory. | 472| | | 473| | | Also, some SMC calls, such as the ones involving| 474| | encryption when applicable, might take different| 475| | | amount of time to complete depending upon the | 476| | parameters. An adversary might attempt to use | 477| | | that information in order to infer secrets or to| 478| | leak sensitive information. | 479+------------------------+---------------------------------------------------+ 480| Diagram Elements | DF5, DF7 | 481+------------------------+---------------------------------------------------+ 482| Assets | Sensitive Data | 483+------------------------+---------------------------------------------------+ 484| Threat Agent | RealmCode, HostSoftware | 485+------------------------+---------------------------------------------------+ 486| Threat Type | Information Disclosure | 487+------------------------+---------------------------------------------------+ 488| Impact | Medium (3) | 489+------------------------+---------------------------------------------------+ 490| Likelihood | Informational (1) | 491+------------------------+---------------------------------------------------+ 492| Total Risk Rating | Low (3) | 493+------------------------+---------------------------------------------------+ 494| Mitigations | | 1) Enable appropriate speculation side-channel | 495| | mitigations as recommended by the | 496| | | Architecture. | 497| | | 2) Enable appropriate timing side-channel | 498| | protections available in the Architecture. | 499| | | 3) Ensure the software components dealing with | 500| | sensitive data use Data Independent | 501| | | algorithms. | 502| | | 4) Ensure that only required memory is mapped | 503| | when executing a Realm or doing operations in| 504| | | RMM so as to minimize effects of CPU | 505| | speculation. | 506+------------------------+---------------------------------------------------+ 507| Mitigations | | 1) Yes. | 508| implemented? | | 2) Yes. | 509| | | ``FEAT_DIT`` is enabled for RMM during | 510| | attestation initialization and token signing | 511| | phase. | 512| | | 3) Yes. | 513| | | RMM relies on MbedTLS library to use | 514| | algorithms which are data independent when | 515| | | handling sensitive data. | 516| | | 4) Yes. | 517| | | The slot buffer design for dynamically | 518| | mapping memory ensures that only required | 519| | | memory is mapped into RMM. | 520+------------------------+---------------------------------------------------+ 521| Pending actions? | | Review speculation vulnerabilities and ensure | 522| | RMM implements all mitigations provided by the | 523| | | Architecture. | 524| | | 525+------------------------+---------------------------------------------------+ 526 527+------------------------+---------------------------------------------------+ 528| ID | 10 | 529+========================+===================================================+ 530| Threat | | Misconfiguration of the S2 MMU tables may allow | 531| | Realms to access sensitive data belonging to | 532| | | other Realms or incorrect mapping of NS memory | 533| | may allow Realms to corrupt NSHost memory. | 534+------------------------+---------------------------------------------------+ 535| Diagram Elements | DF5, DF7 | 536+------------------------+---------------------------------------------------+ 537| Assets | Sensitive Data, Code execution | 538+------------------------+---------------------------------------------------+ 539| Threat Agent | RealmCode, HostSoftware | 540+------------------------+---------------------------------------------------+ 541| Threat Type | Information Disclosure | 542+------------------------+---------------------------------------------------+ 543| Impact | High (4) | 544+------------------------+---------------------------------------------------+ 545| Likelihood | Low (2) | 546+------------------------+---------------------------------------------------+ 547| Total Risk Rating | Medium (8) | 548+------------------------+---------------------------------------------------+ 549| Mitigations | | 1) Ensure proper implementation of S2 table | 550| | management code in RMM. It should not be | 551| | | possible to trigger misconfiguration of S2 | 552| | tables using RMM ABI. Appropriate tests to | 553| | | ensure that the implementation is robust. | 554| | | 2) The RMM specification mandates the rules for | 555| | assigning memory to a Realm and IPA | 556| | | management. Ensure the rules mandated by the | 557| | RMM specification are validated by suitable | 558| | | tooling. | 559+------------------------+---------------------------------------------------+ 560| Mitigations | | 1) Partially. | 561| implemented? | | There are various tests like kvm-unit-tests, | 562| | TFTF, TFX and ACS to test the | 563| | | implementation. Unit tests of S2 tables need | 564| | to be implemented. Static analysis is in | 565| | | place to detect issues. | 566| | | 2) Partially. | 567| | | Code reviews to ensure the implementation | 568| | complies with the required conditions. | 569| | | Automated checking via CBMC to validate the | 570| | same is also being implemented. | 571+------------------------+---------------------------------------------------+ 572| Pending actions? | | Increase testing coverage of S2 table management| 573| | code in RMM. | 574| | | Integrate CMBC into RMM testing. | 575+------------------------+---------------------------------------------------+ 576 577+------------------------+---------------------------------------------------+ 578| ID | 11 | 579+========================+===================================================+ 580| Threat | | Realm code flow diversion through REC metadata | 581| | manipulation from Host Software. | 582| | | 583| | | An adversary with access to a Realm's REC could | 584| | tamper with the structure content and affect the| 585| | | Realm's execution flow. | 586+------------------------+---------------------------------------------------+ 587| Diagram Elements | DF7 | 588+------------------------+---------------------------------------------------+ 589| Assets | Code Execution | 590+------------------------+---------------------------------------------------+ 591| Threat Agent | HostSoftware | 592+------------------------+---------------------------------------------------+ 593| Threat Type | Tampering | 594+------------------------+---------------------------------------------------+ 595| Impact | High (4) | 596+------------------------+---------------------------------------------------+ 597| Likelihood | Low (2) | 598+------------------------+---------------------------------------------------+ 599| Total Risk Rating | Medium (8) | 600+------------------------+---------------------------------------------------+ 601| Mitigations | | 1) The RMM specification mandates that sensitive| 602| | metadata like REC should be stored in Realm | 603| | | PAS. Also, the specification does not allow | 604| | NSHost to manipulate REC contents via RMI | 605| | | once the associated Realm is Activated. | 606| | Ensure that the RMM specification guidelines | 607| | | are enforced. | 608| | | 2) Map sensitive metadata into RMM S1 tables | 609| | only when manipulating the Realm/REC. Once | 610| | | RMM is finished manipulating the metadata, | 611| | unmap it from S1 tables. Thus the time window| 612| | | when RMM can access the metadata is kept to a| 613| | minimum thus reducing the opportunity to | 614| | | corrupt the metadata. | 615+------------------------+---------------------------------------------------+ 616| Mitigations | | 1) Yes. | 617| implemented? | | 2) Yes. | 618| | | The slot-buffer mechanism in RMM is used to | 619| | map metadata only when needed and it is | 620| | | unmapped when the access is not required. | 621+------------------------+---------------------------------------------------+ 622| Pending actions? | None | 623+------------------------+---------------------------------------------------+ 624 625+------------------------+---------------------------------------------------+ 626| ID | 12 | 627+========================+===================================================+ 628| Threat | | Use of PMU and MPAM statistics to increase the | 629| | the accuracy of side channel attacks. | 630+------------------------+---------------------------------------------------+ 631| Diagram Elements | DF5, DF7 | 632+------------------------+---------------------------------------------------+ 633| Assets | Sensitive Data | 634+------------------------+---------------------------------------------------+ 635| Threat Agent | RealmCode, HostSoftware | 636+------------------------+---------------------------------------------------+ 637| Threat Type | Information Disclosure | 638+------------------------+---------------------------------------------------+ 639| Impact | Medium (3) | 640+------------------------+---------------------------------------------------+ 641| Likelihood | Informational (1) | 642+------------------------+---------------------------------------------------+ 643| Total Risk Rating | Low (3) | 644+------------------------+---------------------------------------------------+ 645| Mitigations | | 1) Save/Restore performance counters on | 646| | on transitions between security domains or | 647| | | between Realms. | 648| | | 2) Configure MPAM so that is either disabled or | 649| | set to default values for Realm world. | 650+------------------------+---------------------------------------------------+ 651| Mitigations | | 1) PMU is saved and restored. | 652| implemented? | | 2) MPAM is not enabled for Realm world. | 653+------------------------+---------------------------------------------------+ 654| Pending actions? | None. | 655+------------------------+---------------------------------------------------+ 656 657+------------------------+---------------------------------------------------+ 658| ID | 13 | 659+========================+===================================================+ 660| Threat | | Misconfiguration of the hardware IPs and | 661| | registers may lead to data leaks or incorrect | 662| | | behaviour that could be damaging on its own as | 663| | well as being exploited by a threatening agent. | 664| | | 665| | | RMM needs to interact with several hardware IPs | 666| | as well as system registers for which it uses | 667| | | its own libraries and/or drivers. | 668| | Misconfiguration of such elements could cause | 669| | | data leaks and/or system malfunction. | 670+------------------------+---------------------------------------------------+ 671| Diagram Elements | DF5, DF7 | 672+------------------------+---------------------------------------------------+ 673| Assets | Sensitive Data, Availability | 674+------------------------+---------------------------------------------------+ 675| Threat Agent | RealmCode, HostSoftware | 676+------------------------+---------------------------------------------------+ 677| Threat Type | Information Disclosure, Denial of Service | 678+------------------------+---------------------------------------------------+ 679| Impact | High (4) | 680+------------------------+---------------------------------------------------+ 681| Likelihood | Low (2) | 682+------------------------+---------------------------------------------------+ 683| Total Risk Rating | Medium (8) | 684+------------------------+---------------------------------------------------+ 685| Mitigations | | 1) Code reviews. | 686| | | 2) Testing on FVPs and other hardware and | 687| | emulation platforms to check for correct | 688| | | behaviour. | 689+------------------------+---------------------------------------------------+ 690| Mitigations | | 1) Yes. | 691| implemented? | | 2) Yes. | 692| | | RMM is tested regularly on FVP and more | 693| | platforms will be added in future as they | 694| | | become available. | 695+------------------------+---------------------------------------------------+ 696| Pending actions? | None | 697+------------------------+---------------------------------------------------+ 698 699-------------- 700 701.. _RMM Boot Interface specification: https://trustedfirmware-a.readthedocs.io/en/latest/components/rmm-el3-comms-spec.html#rmm-boot-interface 702.. _Spectre: https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability 703.. _RMM Locking Guidelines: https://tf-rmm.readthedocs.io/en/latest/design/locking.html 704.. _RMM-EL3 Communication Interface: https://trustedfirmware-a.readthedocs.io/en/latest/components/rmm-el3-comms-spec.html 705