arm-trusted-firmware/plat/arm/board/fvp/fvp_bl2_setup.c

106 lines
3.1 KiB
C
Raw Normal View History

2013-10-25 09:08:21 +01:00
/*
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) 2013-2022, Arm Limited and Contributors. All rights reserved.
2013-10-25 09:08:21 +01:00
*
* SPDX-License-Identifier: BSD-3-Clause
2013-10-25 09:08:21 +01:00
*/
#include <assert.h>
#include <common/debug.h>
#include <common/desc_image_load.h>
#include <drivers/arm/sp804_delay_timer.h>
#include <lib/fconf/fconf.h>
#include <lib/fconf/fconf_dyn_cfg_getter.h>
#include <plat/arm/common/plat_arm.h>
#include <plat/common/platform.h>
#include <platform_def.h>
#include "fvp_private.h"
2013-10-25 09:08:21 +01:00
void bl2_early_platform_setup2(u_register_t arg0, u_register_t arg1, u_register_t arg2, u_register_t arg3)
2013-10-25 09:08:21 +01:00
{
arm_bl2_early_platform_setup((uintptr_t)arg0, (meminfo_t *)arg1);
2013-10-25 09:08:21 +01:00
/* Initialize the platform config for future decision making */
fvp_config_setup();
}
void bl2_platform_setup(void)
{
arm_bl2_platform_setup();
/* Initialize System level generic or SP804 timer */
fvp_timer_init();
}
/*******************************************************************************
* This function returns the list of executable images
******************************************************************************/
struct bl_params *plat_get_next_bl_params(void)
{
struct bl_params *arm_bl_params;
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 *hw_config_info __unused;
bl_mem_params_node_t *param_node __unused;
arm_bl_params = arm_get_next_bl_params();
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 !BL2_AT_EL3 && !EL3_PAYLOAD_BASE
const struct dyn_cfg_dtb_info_t *fw_config_info;
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
uintptr_t fw_config_base = 0UL;
entry_point_info_t *ep_info;
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 __aarch64__
/* Get BL31 image node */
param_node = get_bl_mem_params_node(BL31_IMAGE_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
#else /* aarch32 */
/* Get SP_MIN image node */
param_node = get_bl_mem_params_node(BL32_IMAGE_ID);
#endif /* __aarch64__ */
assert(param_node != NULL);
/* get fw_config load address */
fw_config_info = FCONF_GET_PROPERTY(dyn_cfg, dtb, FW_CONFIG_ID);
assert(fw_config_info != NULL);
fw_config_base = fw_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
assert(fw_config_base != 0UL);
/*
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
* Get the entry point info of next executable image and override
* arg1 of entry point info with fw_config base address
*/
ep_info = &param_node->ep_info;
ep_info->args.arg1 = (uint32_t)fw_config_base;
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
/* grab NS HW config address */
hw_config_info = FCONF_GET_PROPERTY(dyn_cfg, dtb, HW_CONFIG_ID);
assert(hw_config_info != NULL);
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
/* To retrieve actual size of the HW_CONFIG */
param_node = get_bl_mem_params_node(HW_CONFIG_ID);
assert(param_node != NULL);
/* Copy HW config from Secure address to NS address */
memcpy((void *)hw_config_info->ns_config_addr,
(void *)hw_config_info->config_addr,
(size_t)param_node->image_info.image_size);
/*
* Ensure HW-config device tree committed to memory, as there is
* a possibility to use HW-config without cache and MMU enabled
* at BL33
*/
flush_dcache_range(hw_config_info->ns_config_addr,
param_node->image_info.image_size);
param_node = get_bl_mem_params_node(BL33_IMAGE_ID);
assert(param_node != NULL);
/* Update BL33's ep info with NS HW config address */
param_node->ep_info.args.arg1 = hw_config_info->ns_config_addr;
#endif /* !BL2_AT_EL3 && !EL3_PAYLOAD_BASE */
return arm_bl_params;
}