arm-trusted-firmware/plat/arm/board/fvp/fdts/fvp_fw_config.dts

56 lines
1.1 KiB
Plaintext
Raw Normal View History

/*
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>
2022-03-15 16:05:58 +00:00
* Copyright (c) 2019-2022, Arm Limited. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
#include <common/tbbr/tbbr_img_def.h>
/dts-v1/;
/ {
dtb-registry {
compatible = "fconf,dyn_cfg-dtb_registry";
tb_fw-config {
load-address = <0x0 0x4001300>;
max-size = <0x1800>;
id = <TB_FW_CONFIG_ID>;
};
hw-config {
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>
2022-03-15 16:05:58 +00:00
load-address = <0x0 0x07f00000>;
max-size = <0x00100000>;
id = <HW_CONFIG_ID>;
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>
2022-03-15 16:05:58 +00:00
ns-load-address = <0x0 0x82000000>;
};
/*
* Load SoC and TOS firmware configs at the base of
* non shared SRAM. The runtime checks ensure we don't
* overlap BL2, BL31 or BL32. The NT firmware config
* is loaded at base of DRAM.
*/
soc_fw-config {
load-address = <0x0 0x04001300>;
max-size = <0x200>;
id = <SOC_FW_CONFIG_ID>;
};
/* If required, SPD should enable loading of trusted OS fw config */
#if defined(SPD_tspd) || defined(SPD_spmd)
tos_fw-config {
load-address = <0x0 0x04001500>;
max-size = <0xB00>;
id = <TOS_FW_CONFIG_ID>;
};
#endif
nt_fw-config {
load-address = <0x0 0x80000000>;
max-size = <0x200>;
id = <NT_FW_CONFIG_ID>;
};
};
};