6a0da73647
This patch adds architectural features detection procedure to ensure
features enabled are present in the given hardware implementation.
It verifies whether the architecture build flags passed during
compilation match the respective features by reading their ID
registers. It reads through all the enabled feature specific ID
registers at once and panics in case of mismatch(feature enabled
but not implemented in PE).
Feature flags are used at sections (context_management,
save and restore routines of registers) during context switch.
If the enabled feature flag is not supported by the PE, it causes an
exception while saving or restoring the registers guarded by them.
With this mechanism, the build flags are validated at an early
phase prior to their usage, thereby preventing any undefined action
under their control.
This implementation is based on tristate approach for each feature and
currently FEAT_STATE=0 and FEAT_STATE=1 are covered as part of this
patch. FEAT_STATE=2 is planned for phase-2 implementation and will be
taken care separately.
The patch has been explicitly tested, by adding a new test_config
with build config enabling majority of the features and detected
all of them under FVP launched with parameters enabling v8.7 features.
Note: This is an experimental procedure and the mechanism itself is
guarded by a macro "FEATURE_DETECTION", which is currently being
disabled by default.
The "FEATURE_DETECTION" macro is documented and the platforms are
encouraged to make use of this diagnostic tool by enabling this
"FEATURE_DETECTION" flag explicitly and get used to its behaviour
during booting before the procedure gets mandated.
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: Ia23d95430fe82d417a938b672bfb5edc401b0f43
|
||
|---|---|---|
| .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 | ||
| .versionrc.js | ||
| Makefile | ||
| changelog.yaml | ||
| dco.txt | ||
| license.rst | ||
| package-lock.json | ||
| package.json | ||
| readme.rst | ||
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.