tree 514f2f2cc44a440cfb52cfd5a51d2ed90bab4ea1
parent 26850d71ec16ba3874522ae286af2b8cb07056f7
author Manish V Badarkhe <Manish.Badarkhe@arm.com> 1647360358 +0000
committer Manish V Badarkhe <Manish.Badarkhe@arm.com> 1651126019 +0100

feat(fvp): update HW_CONFIG DT loading mechanism

Currently, HW-config is loaded into non-secure memory, which mean
a malicious NS-agent could tamper with it. Ideally, this shouldn't
be an issue since no software runs in non-secure world at this time
(non-secure world has not been started yet).

It does not provide a guarantee though since malicious external
NS-agents can take control of this memory region for update/corruption
after BL2 loads it and before BL31/BL32/SP_MIN consumes it. The threat
is mapped to Threat ID#3 (Bypass authentication scenario) in threat
model [1].

Hence modified the code as below -
1. BL2 loads the HW_CONFIG into secure memory
2. BL2 makes a copy of the HW_CONFIG in the non-secure memory at an
   address provided by the newly added property(ns-load-address) in
   the 'hw-config' node of the FW_CONFIG
3. SP_MIN receives the FW_CONFIG address from BL2 via arg1 so that
   it can retrieve details (address and size) of HW_CONFIG from
   FW_CONFIG
4. A secure and non-secure HW_CONFIG address will eventually be used
   by BL31/SP_MIN/BL32 and BL33 components respectively
5. BL31/SP_MIN dynamically maps the Secure HW_CONFIG region and reads
   information from it to local variables (structures) and then
   unmaps it
6. Reduce HW_CONFIG maximum size from 16MB to 1MB; it appears
   sufficient, and it will also create a free space for any future
   components to be added to memory

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

Change-Id: I1d431f3e640ded60616604b1c33aa638b9a1e55e
Signed-off-by: Manish V Badarkhe <Manish.Badarkhe@arm.com>