Hi All,
Currently, in Arm platforms, BL2 loads HW config in the non-secure memory so that it can be consumed by both non-secure
components (BL33) and secure (BL31, BL32) components.
In most cases, this shouldn't be an issue since no software runs in non-secure world at this time (i.e. non-secure world has not
been started yet) However, it doesn't provide a guarantee though since any malicious external NS-agents (such as an external
debugger)can take control of this memory region for update/corruption after BL2 loads this region and before BL31 consumes
it. Consider below scenario:
1. BL2 loads HW_CONFIG from flash to NS DRAM. 2. BL2 authenticates HW_CONFIG in NS DRAM. 3. A malicious non-secure agent modifies the contents of HW_CONFIG in NS DRAM, such that it induces a different
behaviour in BL31.
1. BL31 consumes HW_CONFIG without noticing it has changed.
To overcome this issue, I created a patch [1] to load the HW-config into secure memory, and that eventually will be used by
BL31/sp_min and BL32 components. Additionally, BL31/sp_min copies the HW-config present in secure memory to a non-secure
location before passing it on to BL33. In order to accomplish this, mapped secure DRAM in BL31/sp_min and BL32, and non-secure
DRAM in BL31/sp_min.
I believe some platforms may have similar kind of issue i.e. HW config placed in non-secure memory consumed by both secure and
non-secure components. It is appreciated if you review the patch [1] I posted and provide feedback.
This patch [1] also mitigates threat ID #3 for FVP platform as per the TF-A threat model [2] (Bypass image authentication scenario).
[1]: https://review.trustedfirmware.org/q/topic:%22refactor-hw-config-load%22+(st...)
[2]: https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model...
Thanks,
Manish Badarkhe