arm-trusted-firmware/plat/arm/board/fvp/sp_min/fvp_sp_min_setup.c

122 lines
3.8 KiB
C
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) 2016-2022, Arm Limited and Contributors. All rights reserved.
*
* SPDX-License-Identifier: BSD-3-Clause
*/
#include <assert.h>
#include <bl32/sp_min/platform_sp_min.h>
#include <common/debug.h>
#include <lib/fconf/fconf.h>
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
#include <lib/fconf/fconf_dyn_cfg_getter.h>
#include <plat/arm/common/plat_arm.h>
#include "../fvp_private.h"
void plat_arm_sp_min_early_platform_setup(u_register_t arg0, u_register_t arg1,
u_register_t arg2, u_register_t arg3)
{
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
const struct dyn_cfg_dtb_info_t *tos_fw_config_info __unused;
/* Initialize the console to provide early debug support */
arm_console_boot_init();
#if !RESET_TO_SP_MIN && !BL2_AT_EL3
INFO("SP_MIN FCONF: FW_CONFIG address = %lx\n", (uintptr_t)arg1);
/* Fill the properties struct with the info from the config dtb */
fconf_populate("FW_CONFIG", arg1);
tos_fw_config_info = FCONF_GET_PROPERTY(dyn_cfg, dtb, TOS_FW_CONFIG_ID);
if (tos_fw_config_info != NULL) {
arg1 = tos_fw_config_info->config_addr;
}
#endif /* !RESET_TO_SP_MIN && !BL2_AT_EL3 */
arm_sp_min_early_platform_setup((void *)arg0, arg1, arg2, (void *)arg3);
/* Initialize the platform config for future decision making */
fvp_config_setup();
/*
* Initialize the correct interconnect for this cluster during cold
* boot. No need for locks as no other CPU is active.
*/
fvp_interconnect_init();
/*
* Enable coherency in interconnect for the primary CPU's cluster.
* Earlier bootloader stages might already do this (e.g. Trusted
* Firmware's BL1 does it) but we can't assume so. There is no harm in
* executing this code twice anyway.
* FVP PSCI code will enable coherency for other clusters.
*/
fvp_interconnect_enable();
}
void sp_min_plat_arch_setup(void)
{
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
int rc __unused;
const struct dyn_cfg_dtb_info_t *hw_config_info __unused;
uintptr_t hw_config_base_align __unused;
size_t mapped_size_align __unused;
arm_sp_min_plat_arch_setup();
/*
* For RESET_TO_SP_MIN systems, SP_MIN(BL32) is the first bootloader
* to run. So there is no BL2 to load the HW_CONFIG dtb into memory
* before control is passed to SP_MIN.
* Also, BL2 skips loading HW_CONFIG dtb for BL2_AT_EL3 builds.
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
* The code below relies on dynamic mapping capability, which is not
* supported by xlat tables lib V1.
* TODO: remove the ARM_XLAT_TABLES_LIB_V1 check when its support
* gets deprecated.
*/
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
#if !RESET_TO_SP_MIN && !BL2_AT_EL3 && !ARM_XLAT_TABLES_LIB_V1
hw_config_info = FCONF_GET_PROPERTY(dyn_cfg, dtb, HW_CONFIG_ID);
assert(hw_config_info != NULL);
assert(hw_config_info->config_addr != 0UL);
INFO("SP_MIN FCONF: HW_CONFIG address = %p\n",
(void *)hw_config_info->config_addr);
/*
* Preferrably we expect this address and size are page aligned,
* but if they are not then align it.
*/
hw_config_base_align = page_align(hw_config_info->config_addr, DOWN);
mapped_size_align = page_align(hw_config_info->config_max_size, UP);
if ((hw_config_info->config_addr != hw_config_base_align) &&
(hw_config_info->config_max_size == mapped_size_align)) {
mapped_size_align += PAGE_SIZE;
}
/*
* map dynamically HW config region with its aligned base address and
* size
*/
rc = mmap_add_dynamic_region((unsigned long long)hw_config_base_align,
hw_config_base_align,
mapped_size_align,
MT_RO_DATA);
if (rc != 0) {
ERROR("Error while mapping HW_CONFIG device tree (%d).\n", rc);
panic();
}
/* Populate HW_CONFIG device tree with the mapped address */
fconf_populate("HW_CONFIG", hw_config_info->config_addr);
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
/* unmap the HW_CONFIG memory region */
rc = mmap_remove_dynamic_region(hw_config_base_align, mapped_size_align);
if (rc != 0) {
ERROR("Error while unmapping HW_CONFIG device tree (%d).\n",
rc);
panic();
}
#endif /* !RESET_TO_SP_MIN && !BL2_AT_EL3 && !ARM_XLAT_TABLES_LIB_V1 */
}