mirror of
https://github.com/ARM-software/arm-trusted-firmware.git
synced 2025-04-17 01:54:22 +00:00
No description
3f4c1e1e7b
Errata implementation involves adding a lot of boilerplate to random
places with just conventions on how to do them. Copy pasting is the
usual method for doing this. The result is an error-prone and verbose
patch that is a nightmare to get through review.
Errata workarounds have a very large degree of similarity - most of them
involve setting a bit at reset. As such most of the boilerplate is not
strictly necessary. To solve this, add a collection of assembly macros
to wrap errata implementations such that only the actual mitigations
need to be written. A new erratum mitigation looks something like:
workaround_reset_start cortex_a77, ERRATUM(1925769), ERRATA_A77_1925769
sysreg_bit_set CORTEX_A77_CPUECTLR_EL1, CORTEX_A77_CPUECTLR_EL1_BIT_8
workaround_reset_end cortex_a77, ERRATUM(1925769)
check_erratum_ls cortex_a77, ERRATUM(1925769), CPU_REV(1, 1)
Note, that the long comment on every mitigation is missing. This is on
purpose, as this new format includes all of its contents into an easily
readable format.
The workaround wrappers add an erratum entry (24 bytes) to a per-cpu
data structure which can then be read by a standard reset function to
apply all errata automatically. This has the added benefit of collecting
all errata TF-A knows about in a central way, which was previously
missing. This can then be used at runtime with the errata ABI.
If an erratum doesn't fit this standard definition (eg. the
CVE_2022_23960), it can progressively be unwrapped to the old
convention. The only differences are that the naming format is slightly
more verbose and a call to add_erratum_entry is needed to inform the
framework about the errata.
Finally, the internal workaround names change a tiny bit, especially
CVEs.
Signed-off-by: Boyan Karatotev <boyan.karatotev@arm.com>
Change-Id: Iac644f85dcf85b8279b25e83baf1e7d08b253b16
|
||
|---|---|---|
| .husky | ||
| bl1 | ||
| bl2 | ||
| bl2u | ||
| bl31 | ||
| bl32 | ||
| common | ||
| docs | ||
| drivers | ||
| fdts | ||
| include | ||
| lib | ||
| licenses | ||
| make_helpers | ||
| plat | ||
| services | ||
| tools | ||
| .checkpatch.conf | ||
| .commitlintrc.js | ||
| .cz.json | ||
| .editorconfig | ||
| .gitignore | ||
| .gitreview | ||
| .nvmrc | ||
| .readthedocs.yaml | ||
| .versionrc.js | ||
| changelog.yaml | ||
| dco.txt | ||
| license.rst | ||
| Makefile | ||
| package-lock.json | ||
| package.json | ||
| poetry.lock | ||
| pyproject.toml | ||
| readme.rst | ||
Trusted Firmware-A ================== Trusted Firmware-A (TF-A) is a reference implementation of secure world software for `Arm A-Profile architectures`_ (Armv8-A and Armv7-A), including an Exception Level 3 (EL3) `Secure Monitor`_. It provides a suitable starting point for productization of secure world boot and runtime firmware, in either the AArch32 or AArch64 execution states. TF-A implements Arm interface standards, including: - `Power State Coordination Interface (PSCI)`_ - `Trusted Board Boot Requirements CLIENT (TBBR-CLIENT)`_ - `SMC Calling Convention`_ - `System Control and Management Interface (SCMI)`_ - `Software Delegated Exception Interface (SDEI)`_ The code is designed to be portable and reusable across hardware platforms and software models that are based on the Armv8-A and Armv7-A architectures. In collaboration with interested parties, we will continue to enhance TF-A with reference implementations of Arm standards to benefit developers working with Armv7-A and Armv8-A TrustZone technology. Users are encouraged to do their own security validation, including penetration testing, on any secure world code derived from TF-A. More Info and Documentation --------------------------- To find out more about Trusted Firmware-A, please `view the full documentation`_ that is available through `trustedfirmware.org`_. -------------- *Copyright (c) 2013-2019, Arm Limited and Contributors. All rights reserved.* .. _Armv7-A and Armv8-A: https://developer.arm.com/products/architecture/a-profile .. _Secure Monitor: http://www.arm.com/products/processors/technologies/trustzone/tee-smc.php .. _Power State Coordination Interface (PSCI): PSCI_ .. _PSCI: http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coordination_Interface_PDD_v1_1_DEN0022D.pdf .. _Trusted Board Boot Requirements CLIENT (TBBR-CLIENT): https://developer.arm.com/docs/den0006/latest/trusted-board-boot-requirements-client-tbbr-client-armv8-a .. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf .. _System Control and Management Interface (SCMI): SCMI_ .. _SCMI: http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/DEN0056A_System_Control_and_Management_Interface.pdf .. _Software Delegated Exception Interface (SDEI): SDEI_ .. _SDEI: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf .. _Arm A-Profile architectures: https://developer.arm.com/architectures/cpu-architecture/a-profile .. _view the full documentation: https://www.trustedfirmware.org/docs/tf-a .. _trustedfirmware.org: http://www.trustedfirmware.org