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+(status:open%20OR%20status:merged)

[2]: https://trustedfirmware-a.readthedocs.io/en/latest/threat_model/threat_model.html

 

Thanks,

Manish Badarkhe