39f0b86a76
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> |
||
|---|---|---|
| .. | ||
| fvp_sp_min_setup.c | ||
| sp_min-fvp.mk | ||