Lines Matching refs:to
19 Trustedfirmware.org [Security-Incident-Process]_ to contact TF-M security
29 Root of Trust (RoT) service. Those RoT services belong to diverse RoT
40 The threat modeling in this document follows the process listed below to
50 process is to firstly investigate the TOE which could be a system, solution or
51 use case. This first step helps to identify the assets to be protected in TOE.
53 According to TOE and assets, Trust Boundaries can be determined. The Data Flow
54 Diagram (DFD) across Trust Boundaries is then defined to help identify the
66 Non-secure Processing Environment (NSPE). For more details, please refer to
76 Refer to dedicated threat models for the specific TOE definitions.
107 - Certificate for connecting to cloud
109 - Keys to encrypt/decrypt the videos and photos
115 The Trust Boundary isolates SPE from NSPE, according to the TOE definition in
116 `Target of Evaluation`_. The Trust Boundary mapped to block diagram is shown
120 This threat model only focuses on the data flows related to TF-M.
136 | | control to Non-secure state. |
145 | | in Non-secure Callable region to trigger a transition from |
146 | | Non-secure state to Secure state. |
149 | | to secure core via mailbox. |
152 | | output data to NS. |
156 | | to access NSPE memory. |
158 | ``DF4`` | TF-M returns RoT service results to NSPE after NS request to |
162 | | from Secure state back to Non-secure state. |
164 | | On dual-cpu platforms, secure core returns the result to |
178 Proper isolation must be configured to prevent NSPE directly accessing SPE.
180 Threats irrelevant to data flows in
212 CVSS scores can be mapped to qualitative severity ratings defined in CVSS 3.1
217 the constant and general severity of a threat according to its intrinsic
220 The *Impacted Component* defined in [CVSS_SPEC]_ refers to the assets listed in
229 Threats are identified following ``STRIDE`` model. Please refer to [STRIDE]_ for
234 representation of the CVSS metric values used to score the threat. Refer to
244 please refer to the dedicated threat model document.
259 | Justification | An attack may tamper the NS image to inject malicious code |
263 | Mitigation | By default TF-M relies on MCUBoot to validate NS image. |
265 | | completed in secure boot before jumping to NS entry or |
267 | | Refer to [SECURE-BOOT]_ for more details. |
288 | | which has been deprecated due to known security issues. |
296 | Mitigation | TF-M relies on MCUBoot to perform anti-rollback |
299 | | TF-M defines a non-volatile counter API to support |
302 | | For more details, refer to [ROLLBACK-PROTECT]_. |
321 | | disallowed to. |
329 | Mitigation | SPE must complete and enable proper isolation to protect |
331 | | to NS entry or booting up NS core. |
358 | | it is disallowed to. |
364 | | those device and peripherals and may be able to tamper |
370 | | isolation to protect critical devices and peripherals from |
371 | | being accessed by NSPE, before jumping to NS entry or |
407 | | the system to NSPE on single Armv8-M platform. |
429 | Description | An attacker may block NS to boot up |
431 | Justification | An attacker may block NS to boot up, such as by corrupting |
432 | | NS image, to stop the whole system from performing normal |
440 | | It relies on NSPE and platform specific implementation to |
462 | | to access secure data which NSPE must not directly access. |
464 | Justification | [FF-M]_ defines ``Client ID`` to distinguish clients which |
470 | | ``Client ID`` to pretend as a secure client to access |
493 | | (Time-Of-Check-to-Time-Of-Use (TOCTOU)). |
497 | | chance to tamper the content after the validation |
499 | | according to the corrupted parameters and it may cause |
506 | | from NSPE into SPE. It prevents an attack from NSPE to |
521 | Description | A malicious NS application may request to tamper data |
522 | | belonging to SPE. |
524 | Justification | A malicious NS application may request SPE RoT services to |
525 | | write malicious value to SPE data. The malicious NS |
526 | | application may try to tamper SPE assets, such as keys, or |
527 | | modify configurations in SPE. The SPE data belongs to |
532 | Mitigation | TF-M executes memory access check to all the RoT service |
533 | | requests. If a request doesn't have enough permission to |
552 | Justification | A malicious NS application may call a RoT service to |
553 | | access critical data in SPE, which it is disallowed to, |
554 | | via a non-public vulnerability. It may refuse to admit |
559 | Mitigation | TF-M implements an event logging secure service to record |
560 | | the critical events, such as the access to critical data. |
574 | Description | A malicious NS application may request to read data |
575 | | belonging to SPE. |
577 | Justification | A malicious NS application may request SPE RoT services to |
578 | | copy SPE data to NS memory. The SPE data belongs to |
579 | | components in SPE and must not be disclosed to NSPE, such |
584 | Mitigation | TF-M executes memory access check to all the RoT service |
585 | | requests. If a request doesn't have enough permission to |
601 | Description | A malicious NS application may request to control secure |
605 | Justification | A malicious NS application may request RoT services to |
611 | Mitigation | TF-M performs client check to validate whether the client |
612 | | has the permission to access the secure device and |
628 | | services to block secure service requests from other NS |
638 | | services frequently, it may block other NS applications to |
643 | Mitigation | TF-M is unable to manage behavior of NS applications. |
647 | | It relies on NS OS to enhance scheduling policy and |
648 | | prevent a single NS application to occupy entire CPU time. |
667 | Justification | SPE may be unable to achieve full knowledge of NS memory |
668 | | mapping. SPE may fail to capture those invalid NS memory |
673 | | addresses later to read or write data. It may trigger a |
674 | | system error to crash the whole system immediately. |
678 | | may manipulate SPE to access that address instead. |
682 | Mitigation | TF-M executes memory access check to the memory addresses |
686 | | instructions to execute memory address check. If a NS |
700 | | check to replace the default one. It relies on platform |
701 | | specific implementation to capture invalid memory address. |
715 RoT services can either directly access NS memory or rely on TF-M SPM to obtain NS input data and
716 send response data back to NS memory.
740 | Mitigation | If RoT services request SPM to read and write NS data. |
741 | | TF-M SPM follows [FF-M]_ to copy the NS input data into |
749 | | required to review and confirm the implementation of the |
769 | | vectors, to tamper secure memory which the NS application |
772 | Justification | [FF-M]_ limits the total number of input/output vectors to |
779 | | parameter structure to bypass TF-M validation on those |
785 | | to the secure memory addresses in parameter structure, the |
790 | Mitigation | It should be avoided to embed memory addresses into a |
793 | | recommended to split this request into two or multiple |
797 | | If RoT services request SPM to read and write NS data. |
799 | | invalid addresses to mitigate this threat. |
802 | | required to review and confirm the implementation of RoT |
817 | Description | Similar to TFM-GENERIC-SECURE-SERVICE-RW-T-2_, a malicious |
820 | | to read secure data which the NS application must not |
823 | Justification | Similar to the description in |
827 | | check, the RoT service may copy secure data to NSPE |
828 | | according to the secure memory addresses in structure, |
833 | Mitigation | It should be avoided to embed memory addresses into a |
836 | | recommended to split this request into two or multiple |
840 | | If RoT services request SPM to read and write NS data. |
842 | | invalid addresses to mitigate this threat. |
845 | | required to review and confirm the implementation of RoT |
860 failure error code to NS application.
863 general purpose register and returns to Non-secure state.
865 On dual-cpu platforms, TF-M writes the return code to NSPE mailbox message queue
876 | | ``BXNS`` to switch Armv8-M back to Non-secure state. |
885 | | purpose registers not banked before switching into NSPE to |
888 | | When FPU is enabled in TF-M, secure FP context belonging to|
892 | | into NSPE to prevent NSPE from probing secure FP context. |
922 | | switching to Non-secure state while taking NS interrupts. |
927 | | hardware automatically when NS interrupts occur, to prevent|
929 | | to Armv8-M Architecture Reference Manual[ARM arm]_ for |
950 | | to block SPE execution. |
953 | | malicious NS application or hijack a NS hardware to |
954 | | frequently trigger spurious NS interrupts to keep |
955 | | preempting SPE and block SPE to perform normal secure |
983 | | switches back to Non-secure state on Secure interrupt |
987 | | registers while returning to Non-secure state during |
999 | | NSPE context from secure stack to overwrite secure context |
1003 | | context from non-secure stack to overwrite other registers |
1011 | | during S exception return, to prevent NSPE from probing |
1012 | | secure FP context in FP registers. Refer to Armv8-M |
1024 This section collects threats irrelevant to the valid TF-M data flows shown
1040 | | creating a fake exception return stack frame to |
1042 | | world software to manipulate the Secure Stacks, and |
1045 | | Refer to [STACK-SEAL]_ for details. |
1052 | | Refer to [ADVISORY-TFMV-1]_ for details on analysis and |
1068 | | IPC model to behave unexpectedly. |
1080 | Mitigation | TF-M has enhanced implementation to mitigate this |
1083 | | Refer to [ADVISORY-TFMV-2]_ for details on analysis and |
1098 | Description | Secure data in FP registers may be disclosed to NSPE when |
1099 | | VLLDM instruction is abandoned due to an exception mid-way.|
1101 | Justification | Refer to [VLLDM Vulnerability]_ for details. |
1106 | | TF-M configures NSACR to disable NSPE to access FPU. |
1110 | | Refer to [VLLDM Vulnerability]_, for details on analysis |
1134 | v1.2 | Update details to align FP support in NSPE. | TF-M v1.5.0 |