| /rk3399_ARM-atf/docs/process/ |
| H A D | security-hardening.rst | 15 Do not leak secrets to the normal world
18 The secure world **must not** leak secrets to the normal world, for example in
24 The secure world **should never** crash or become unusable due to receiving too
25 many normal world requests (a *Denial of Service* or *DoS* attack). It should
26 have a mechanism for throttling or ignoring normal world requests.
28 Preventing Secure-world timing information leakage via PMU counters
31 The Secure world needs to implement some defenses to prevent the Non-secure
32 world from making it leak timing information. In general, higher privilege
39 Timing leakage attacks from the Non-secure world
42 Since the Non-secure world has access to the ``PMCR`` register, it can
[all …]
|
| H A D | coding-guidelines.rst | 224 In general, each secure world TF image (BL1, BL2, BL31 and BL32) should be
243 - Internal secure world image state is inconsistent
249 Each secure world image may be provided by a different entity (for example, a
267 The secure world **must not** crash when supplied with bad data from an external
268 source. For example, data from the normal world or a hardware device. Similarly,
269 the secure world **must not** crash if it detects a non-critical problem within
276 - Secure world receives SMC from normal world with bad arguments.
277 - Secure world receives SMC from normal world at an unexpected time.
280 - Secure world receives recoverable error from hardware device. Retrying the
282 - Non-critical secure world service is not functioning correctly.
[all …]
|
| H A D | security.rst | 50 | | normal world to panic secure world |
59 | | world timing information |
|
| /rk3399_ARM-atf/docs/components/ |
| H A D | firmware-update.rst | 31 A common system design will place the ``Update Agent`` in the Secure-world
32 while the ``Client`` executes in the Normal-world.
33 The `PSA FW update specification`_ provides ABIs meant for a Normal-world
69 and also if the system successfully booted the Normal-world image then
71 checking at Normal-world.
81 as authentication failure or non-fuctionality of Normal-world software then the
119 This document describes the secure world FWU design. It is beyond its scope to
120 describe how normal world FWU images should operate. To implement normal world
129 some parts of FWU to be implemented in other secure and normal world images.
138 - Context switching between the normal and secure world during the FWU
[all …]
|
| H A D | realm-management-extension.rst | 16 Root world. In the realm world, a Realm Management Monitor firmware (`RMM`_)
38 A new CPU context for the Realm world has been added. The existing can be used
44 enabled, TF-A runs in the Root world at EL3. Therefore, the boot flow is
46 Realm-world firmware (`RMM`_) is loaded by BL2 in the Realm physical address
56 6. BL31 transfers control to Normal-world software
63 Root world that describes the physical address space assignment of every
72 world. It initializes the `RMM`_ and handles Realm Management Interface (RMI)
100 - Three-world execution: this is the configuration to use if Secure
101 world functionality is not needed.
103 - Four-world execution: this is the configuration to use if both Secure
[all …]
|
| H A D | context-management-library.rst | 14 are not banked per world. When moving between the security states it is the
33 security states (Non-Secure, Secure, Realm). Each world must have its
46 In general, an ideal trusted system should have Secure world-specific configurations
48 need to maintain world-specific context to ensure that register entries from one
49 world do not leak or impact the execution of the CPU in other worlds.
57 for maintaining world-specific context essential for a trusted system.
65 two-world system, comprising of Non-Secure and Secure Worlds. In this case, the
86 Each world (Non-Secure, Secure, and Realm) should have their separate component
87 in EL3 responsible for their respective world context management.
88 Both the Secure and Realm world have associated dispatcher components in EL3
[all …]
|
| H A D | el3-spmc.rst | 48 - BL33 option can specify the TFTF binary or a normal world loader
289 transactions in its world switch routine. It must not be permitted for a VM to
290 use a secure FF-A ID as origin world by spoofing:
292 - A VM-to-SP direct request/response shall set the origin world to be non-secure
293 (FF-A ID bit 15 clear) and destination world to be secure (FF-A ID bit 15
300 message is coming from normal world in this specific code path. Thus the origin
301 endpoint ID must be checked by SPMC for being a normal world ID.
306 The SPMC shall reject the direct message if the claimed world in origin endpoint
310 world ID",
311 - or initiated by an SP and thus origin endpoint ID must be a "secure world ID".
[all …]
|
| H A D | secure-partition-manager-mm.rst | 19 used by Non-secure world applications to access these services. A Trusted OS
47 resources. Essentially, it is a software sandbox in the Secure world that runs
66 services to software components in the Non-secure world and other Secure
92 - Implement a standard interface that is used by the Non-secure world for
115 preempted to give control back to the Normal world).
181 accessing services implemented in the Secure world. The ``MM_COMMUNICATE``
203 The exchange of data between the Non-secure world and the partition takes place
207 to the Non-secure world or discovered through a platform discovery mechanism
208 e.g. ACPI table or device tree. It is possible for the Non-secure world to
215 agreed between the Non-secure world and the Secure Partition. For example, in
[all …]
|
| /rk3399_ARM-atf/docs/security_advisories/ |
| H A D | security-advisory-tfv-2.rst | 6 | | allow normal world to panic secure world |
18 | Impact | Denial of Service (secure world panic) |
28 entrypoint code, which enables debug exceptions from the secure world. This can
32 normal world attacker to induce a panic in the secure world.
35 from the secure world.
|
| H A D | security-advisory-tfv-5.rst | 6 | | secure world timing information |
18 | Impact | Leakage of sensitive secure world timing information |
32 bit is set to zero, the cycle counter (when enabled) counts during secure world
36 normal and secure worlds, normal world code can set ``PMCR_EL0.DP`` to zero to
37 cause leakage of secure world timing information. This register should be added
|
| H A D | security-advisory-tfv-9.rst | 20 | Impact | Potential leakage of secure world data to normal world |
48 Spectre-BHB on behalf of all secure world code, assuming that no secure world
106 world privileged software. Details of ``SMCCC_ARCH_WORKAROUND_3`` can be found
108 implementation also enables the normal world to discover the presence of this
|
| H A D | security-advisory-tfv-8.rst | 15 | Configurations | Multiple normal world SMC clients calling into AArch64 BL31 |
18 | Impact | Leakage of SMC return values from one normal world SMC |
57 In the presence of multiple normal world SMC clients, this behaviour might leak
64 multiple normal world SMC clients lies with EL2 software. When present, EL2
94 * executing in the secure world.
|
| H A D | security-advisory-tfv-6.rst | 20 | Impact | Leakage of secure world data to normal world |
44 predictor as early as possible on entry into the secure world, before any branch
68 (``SMCCC_ARCH_WORKAROUND_1``) for use by normal world privileged software. This
72 the normal world to discover the presence of this firmware service.
111 entry into the secure world. For Cortex-A8, also set ``ACTLR[6]`` to 1 during
132 cannot be used to access secure memory from the non-secure world, and is not
|
| H A D | security-advisory-tfv-13.rst | 22 | Impact | Potential leakage of secure world data to normal world. |
76 Arm has updated the SMC Calling Convention spec so that privileged normal world
|
| H A D | security-advisory-tfv-7.rst | 20 | Impact | Leakage of secure world data to normal world |
36 interfaces into the secure world with attacker-controlled inputs. However, this
42 world execution. The mitigation is enabled by setting an implementation defined
|
| /rk3399_ARM-atf/docs/getting_started/ |
| H A D | image-terminology.rst | 50 which corresponds to the normal world bootloader (e.g. UEFI or U-Boot).
72 is to handle transitions between the normal and secure world.
78 normal world. However, it may refer to a more abstract Secure-EL1 Payload (SP).
88 For example, UEFI or uboot. Its primary purpose is to boot a normal world OS.
147 Typically, this is the first normal world code to execute on the AP during a
153 secure and normal world. The "level" of the BL image is relative to the world
154 it's in so it makes sense to encode "NS" in the normal world images. The absence
155 of "NS" implies a secure world image.
160 This image does the minimum necessary AP secure world configuration required to
167 This image does the minimum necessary SCP secure world configuration required to
[all …]
|
| /rk3399_ARM-atf/docs/plat/qti/ |
| H A D | msm8916.rst | 35 therefore expects the non-secure world (e.g. Linux) to manage more hardware,
47 separate secure world) where this limitation is not a big problem. Booting
59 After initialization the normal world starts at a fixed entry address in EL2/HYP
61 the normal world bootloader was already loaded into RAM by a previous firmware
103 the normal world and the necessary clocks remain enabled.
109 * ``PRELOADED_BL33_BASE``: The entry address for the normal world. Usually
113 reserved in the normal world.
120 a minimal PSCI implementation without a separate secure world.
170 INFO: BL31: Preparing for EL3 exit to normal world
196 INFO: SP_MIN: Preparing exit to normal world
|
| /rk3399_ARM-atf/ |
| H A D | readme.rst | 4 Trusted Firmware-A (TF-A) is a reference implementation of secure world software
7 productization of secure world boot and runtime firmware, in either the AArch32
26 testing, on any secure world code derived from TF-A.
|
| /rk3399_ARM-atf/docs/design/ |
| H A D | trusted-board-boot.rst | 6 normal world bootloader. It does this by establishing a `Chain of Trust` using
91 - **Trusted world key**
94 secure world images (SCP_BL2, BL31 and BL32). The public part is stored in
97 - **Non-trusted world key**
100 non-secure world image (BL33). The public part is stored in one of the
129 public part of the trusted world key and the public part of the non-trusted
130 world key.
134 It is self-signed with the trusted world key. It contains the public part of
144 It is self-signed with the trusted world key. It contains the public part of
154 It is self-signed with the trusted world key. It contains the public part of
[all …]
|
| H A D | alt-boot-flows.rst | 22 - taking care of platform secure world initialization;
69 on TF-A to load it. This may simplify packaging of the normal world code and
70 improve performance in a development environment. When secure world cold boot
|
| /rk3399_ARM-atf/plat/nxp/soc-lx2160a/ |
| H A D | ddr_tbbr.mk | 58 $(if ${TRUSTED_WORLD_KEY},$(eval $(call CERT_ADD_CMD_OPT,${TRUSTED_WORLD_KEY},--trusted-world-key,D…
59 …WORLD_KEY},$(eval $(call CERT_ADD_CMD_OPT,${NON_TRUSTED_WORLD_KEY},--non-trusted-world-key, DDR_)))
|
| /rk3399_ARM-atf/plat/arm/board/tc/fdts/ |
| H A D | tc_spmc_common_sp_manifest.dtsi | 8 * Secure world memory map. For a full view of the DRAM map, see platform_def.h
|
| /rk3399_ARM-atf/docs/ |
| H A D | index.rst | 26 Trusted Firmware-A (TF-A) provides a reference implementation of secure world
42 world boot and runtime firmware, in either the AArch32 or AArch64 execution
46 testing, on any secure world code derived from TF-A.
|
| /rk3399_ARM-atf/plat/arm/board/common/swd_rotpk/ |
| H A D | README | 1 This directory contains some development keys to be used as the secure world
|
| /rk3399_ARM-atf/make_helpers/tbbr/ |
| H A D | tbbr_tools.mk | 89 $(if ${TRUSTED_WORLD_KEY},$(eval $(call CERT_ADD_CMD_OPT,${TRUSTED_WORLD_KEY},--trusted-world-key)))
90 …USTED_WORLD_KEY},$(eval $(call CERT_ADD_CMD_OPT,${NON_TRUSTED_WORLD_KEY},--non-trusted-world-key)))
|