2013-10-25 09:08:21 +01:00
|
|
|
/*
|
2022-02-14 17:06:09 +00:00
|
|
|
* Copyright (c) 2013-2022, ARM Limited and Contributors. All rights reserved.
|
2013-10-25 09:08:21 +01:00
|
|
|
*
|
2017-05-03 09:38:09 +01:00
|
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
2013-10-25 09:08:21 +01:00
|
|
|
*/
|
|
|
|
|
|
2018-11-08 10:20:19 +00:00
|
|
|
#ifndef BL_COMMON_H
|
|
|
|
|
#define BL_COMMON_H
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2018-12-14 00:18:21 +00:00
|
|
|
#include <common/ep_info.h>
|
|
|
|
|
#include <common/param_header.h>
|
|
|
|
|
#include <lib/utils_def.h>
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2019-07-09 21:49:11 +01:00
|
|
|
#ifndef __ASSEMBLER__
|
2019-05-29 05:03:58 +01:00
|
|
|
#include <stddef.h>
|
|
|
|
|
#include <stdint.h>
|
|
|
|
|
#include <lib/cassert.h>
|
2019-07-09 21:49:11 +01:00
|
|
|
#endif /* __ASSEMBLER__ */
|
2019-05-29 05:03:58 +01:00
|
|
|
|
|
|
|
|
#include <export/common/bl_common_exp.h>
|
|
|
|
|
|
2018-10-04 09:55:23 +01:00
|
|
|
#define UP U(1)
|
|
|
|
|
#define DOWN U(0)
|
2013-10-25 09:08:21 +01:00
|
|
|
|
|
|
|
|
/*******************************************************************************
|
2014-06-24 14:02:34 +01:00
|
|
|
* Constants to identify the location of a memory region in a given memory
|
|
|
|
|
* layout.
|
|
|
|
|
******************************************************************************/
|
2018-10-04 09:55:23 +01:00
|
|
|
#define TOP U(0x1)
|
|
|
|
|
#define BOTTOM U(0x0)
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2015-10-02 17:56:48 +01:00
|
|
|
/*******************************************************************************
|
|
|
|
|
* Constants to indicate type of exception to the common exception handler.
|
|
|
|
|
******************************************************************************/
|
2018-10-04 09:55:23 +01:00
|
|
|
#define SYNC_EXCEPTION_SP_EL0 U(0x0)
|
|
|
|
|
#define IRQ_SP_EL0 U(0x1)
|
|
|
|
|
#define FIQ_SP_EL0 U(0x2)
|
|
|
|
|
#define SERROR_SP_EL0 U(0x3)
|
|
|
|
|
#define SYNC_EXCEPTION_SP_ELX U(0x4)
|
|
|
|
|
#define IRQ_SP_ELX U(0x5)
|
|
|
|
|
#define FIQ_SP_ELX U(0x6)
|
|
|
|
|
#define SERROR_SP_ELX U(0x7)
|
|
|
|
|
#define SYNC_EXCEPTION_AARCH64 U(0x8)
|
|
|
|
|
#define IRQ_AARCH64 U(0x9)
|
|
|
|
|
#define FIQ_AARCH64 U(0xa)
|
|
|
|
|
#define SERROR_AARCH64 U(0xb)
|
|
|
|
|
#define SYNC_EXCEPTION_AARCH32 U(0xc)
|
|
|
|
|
#define IRQ_AARCH32 U(0xd)
|
|
|
|
|
#define FIQ_AARCH32 U(0xe)
|
|
|
|
|
#define SERROR_AARCH32 U(0xf)
|
2015-10-02 17:56:48 +01:00
|
|
|
|
2019-01-11 22:47:48 +00:00
|
|
|
/*
|
|
|
|
|
* Mapping to connect linker symbols from .ld.S with their counterparts
|
|
|
|
|
* from .scat for the BL31 image
|
|
|
|
|
*/
|
|
|
|
|
#if defined(USE_ARM_LINK)
|
|
|
|
|
#define __BL31_END__ Load$$LR$$LR_END$$Base
|
|
|
|
|
#define __BSS_START__ Load$$LR$$LR_BSS$$Base
|
|
|
|
|
#define __BSS_END__ Load$$LR$$LR_BSS$$Limit
|
|
|
|
|
#define __BSS_SIZE__ Load$$LR$$LR_BSS$$Length
|
|
|
|
|
#define __COHERENT_RAM_START__ Load$$LR$$LR_COHERENT_RAM$$Base
|
|
|
|
|
#define __COHERENT_RAM_END_UNALIGNED__ Load$$__COHERENT_RAM_EPILOGUE_UNALIGNED__$$Base
|
|
|
|
|
#define __COHERENT_RAM_END__ Load$$LR$$LR_COHERENT_RAM$$Limit
|
|
|
|
|
#define __COHERENT_RAM_UNALIGNED_SIZE__ Load$$__COHERENT_RAM__$$Length
|
|
|
|
|
#define __CPU_OPS_START__ Load$$__CPU_OPS__$$Base
|
|
|
|
|
#define __CPU_OPS_END__ Load$$__CPU_OPS__$$Limit
|
|
|
|
|
#define __DATA_START__ Load$$__DATA__$$Base
|
|
|
|
|
#define __DATA_END__ Load$$__DATA__$$Limit
|
|
|
|
|
#define __GOT_START__ Load$$__GOT__$$Base
|
|
|
|
|
#define __GOT_END__ Load$$__GOT__$$Limit
|
|
|
|
|
#define __PERCPU_BAKERY_LOCK_START__ Load$$__BAKERY_LOCKS__$$Base
|
|
|
|
|
#define __PERCPU_BAKERY_LOCK_END__ Load$$__BAKERY_LOCKS_EPILOGUE__$$Base
|
|
|
|
|
#define __PMF_SVC_DESCS_START__ Load$$__PMF_SVC_DESCS__$$Base
|
|
|
|
|
#define __PMF_SVC_DESCS_END__ Load$$__PMF_SVC_DESCS__$$Limit
|
|
|
|
|
#define __PMF_TIMESTAMP_START__ Load$$__PMF_TIMESTAMP__$$Base
|
|
|
|
|
#define __PMF_TIMESTAMP_END__ Load$$__PER_CPU_TIMESTAMPS__$$Limit
|
|
|
|
|
#define __PMF_PERCPU_TIMESTAMP_END__ Load$$__PMF_TIMESTAMP_EPILOGUE__$$Base
|
|
|
|
|
#define __RELA_END__ Load$$__RELA__$$Limit
|
|
|
|
|
#define __RELA_START__ Load$$__RELA__$$Base
|
|
|
|
|
#define __RODATA_START__ Load$$__RODATA__$$Base
|
|
|
|
|
#define __RODATA_END__ Load$$__RODATA_EPILOGUE__$$Base
|
|
|
|
|
#define __RT_SVC_DESCS_START__ Load$$__RT_SVC_DESCS__$$Base
|
|
|
|
|
#define __RT_SVC_DESCS_END__ Load$$__RT_SVC_DESCS__$$Limit
|
2022-02-14 17:06:09 +00:00
|
|
|
#if SPMC_AT_EL3
|
|
|
|
|
#define __EL3_LP_DESCS_START__ Load$$__EL3_LP_DESCS__$$Base
|
|
|
|
|
#define __EL3_LP_DESCS_END__ Load$$__EL3_LP_DESCS__$$Limit
|
|
|
|
|
#endif
|
2019-01-11 22:47:48 +00:00
|
|
|
#define __RW_START__ Load$$LR$$LR_RW_DATA$$Base
|
|
|
|
|
#define __RW_END__ Load$$LR$$LR_END$$Base
|
|
|
|
|
#define __SPM_SHIM_EXCEPTIONS_START__ Load$$__SPM_SHIM_EXCEPTIONS__$$Base
|
|
|
|
|
#define __SPM_SHIM_EXCEPTIONS_END__ Load$$__SPM_SHIM_EXCEPTIONS_EPILOGUE__$$Base
|
|
|
|
|
#define __STACKS_START__ Load$$__STACKS__$$Base
|
|
|
|
|
#define __STACKS_END__ Load$$__STACKS__$$Limit
|
|
|
|
|
#define __TEXT_START__ Load$$__TEXT__$$Base
|
|
|
|
|
#define __TEXT_END__ Load$$__TEXT_EPILOGUE__$$Base
|
|
|
|
|
#endif /* USE_ARM_LINK */
|
|
|
|
|
|
2019-07-09 21:49:11 +01:00
|
|
|
#ifndef __ASSEMBLER__
|
2018-12-14 00:18:21 +00:00
|
|
|
|
2015-04-27 11:49:22 +01:00
|
|
|
/*
|
|
|
|
|
* Declarations of linker defined symbols to help determine memory layout of
|
|
|
|
|
* BL images
|
|
|
|
|
*/
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
2016-07-08 14:37:40 +01:00
|
|
|
#if SEPARATE_CODE_AND_RODATA
|
2019-01-25 13:28:38 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __TEXT_START__, BL_CODE_BASE);
|
|
|
|
|
IMPORT_SYM(uintptr_t, __TEXT_END__, BL_CODE_END);
|
|
|
|
|
IMPORT_SYM(uintptr_t, __RODATA_START__, BL_RO_DATA_BASE);
|
|
|
|
|
IMPORT_SYM(uintptr_t, __RODATA_END__, BL_RO_DATA_END);
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
2016-07-08 14:37:40 +01:00
|
|
|
#else
|
2019-01-25 13:28:38 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __RO_START__, BL_CODE_BASE);
|
|
|
|
|
IMPORT_SYM(uintptr_t, __RO_END__, BL_CODE_END);
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
2016-07-08 14:37:40 +01:00
|
|
|
#endif
|
2020-12-14 02:42:22 +00:00
|
|
|
#if SEPARATE_NOBITS_REGION
|
|
|
|
|
IMPORT_SYM(uintptr_t, __NOBITS_START__, BL_NOBITS_BASE);
|
|
|
|
|
IMPORT_SYM(uintptr_t, __NOBITS_END__, BL_NOBITS_END);
|
|
|
|
|
#endif
|
2020-01-17 04:45:47 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __RW_END__, BL_END);
|
Introduce SEPARATE_CODE_AND_RODATA build flag
At the moment, all BL images share a similar memory layout: they start
with their code section, followed by their read-only data section.
The two sections are contiguous in memory. Therefore, the end of the
code section and the beginning of the read-only data one might share
a memory page. This forces both to be mapped with the same memory
attributes. As the code needs to be executable, this means that the
read-only data stored on the same memory page as the code are
executable as well. This could potentially be exploited as part of
a security attack.
This patch introduces a new build flag called
SEPARATE_CODE_AND_RODATA, which isolates the code and read-only data
on separate memory pages. This in turn allows independent control of
the access permissions for the code and read-only data.
This has an impact on memory footprint, as padding bytes need to be
introduced between the code and read-only data to ensure the
segragation of the two. To limit the memory cost, the memory layout
of the read-only section has been changed in this case.
- When SEPARATE_CODE_AND_RODATA=0, the layout is unchanged, i.e.
the read-only section still looks like this (padding omitted):
| ... |
+-------------------+
| Exception vectors |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script provides the limits of the whole
read-only section.
- When SEPARATE_CODE_AND_RODATA=1, the exception vectors and
read-only data are swapped, such that the code and exception
vectors are contiguous, followed by the read-only data. This
gives the following new layout (padding omitted):
| ... |
+-------------------+
| Read-only data |
+-------------------+
| Exception vectors |
+-------------------+
| Code |
+-------------------+ BLx_BASE
In this case, the linker script now exports 2 sets of addresses
instead: the limits of the code and the limits of the read-only
data. Refer to the Firmware Design guide for more details. This
provides platform code with a finer-grained view of the image
layout and allows it to map these 2 regions with the appropriate
access permissions.
Note that SEPARATE_CODE_AND_RODATA applies to all BL images.
Change-Id: I936cf80164f6b66b6ad52b8edacadc532c935a49
2016-07-08 14:37:40 +01:00
|
|
|
|
2018-12-18 13:49:46 +00:00
|
|
|
#if defined(IMAGE_BL1)
|
2019-01-25 13:28:38 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __BL1_ROM_END__, BL1_ROM_END);
|
2018-12-18 13:49:46 +00:00
|
|
|
|
2019-01-25 13:28:38 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __BL1_RAM_START__, BL1_RAM_BASE);
|
|
|
|
|
IMPORT_SYM(uintptr_t, __BL1_RAM_END__, BL1_RAM_LIMIT);
|
2018-12-18 13:49:46 +00:00
|
|
|
#elif defined(IMAGE_BL2)
|
2019-01-25 13:28:38 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __BL2_END__, BL2_END);
|
2016-12-25 14:36:24 +00:00
|
|
|
#elif defined(IMAGE_BL2U)
|
2019-01-25 13:28:38 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __BL2U_END__, BL2U_END);
|
2016-12-25 14:36:24 +00:00
|
|
|
#elif defined(IMAGE_BL31)
|
2019-01-25 13:28:38 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __BL31_START__, BL31_START);
|
|
|
|
|
IMPORT_SYM(uintptr_t, __BL31_END__, BL31_END);
|
2016-12-25 14:36:24 +00:00
|
|
|
#elif defined(IMAGE_BL32)
|
2019-01-25 13:28:38 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __BL32_END__, BL32_END);
|
2021-07-12 00:33:20 +01:00
|
|
|
#elif defined(IMAGE_RMM)
|
|
|
|
|
IMPORT_SYM(uintptr_t, __RMM_END__, RMM_END);
|
2015-04-27 11:49:22 +01:00
|
|
|
#endif /* IMAGE_BLX */
|
|
|
|
|
|
2018-12-18 13:49:46 +00:00
|
|
|
/* The following symbols are only exported from the BL2 at EL3 linker script. */
|
|
|
|
|
#if BL2_IN_XIP_MEM && defined(IMAGE_BL2)
|
2019-01-25 13:28:38 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __BL2_ROM_END__, BL2_ROM_END);
|
2018-12-18 13:49:46 +00:00
|
|
|
|
2019-01-25 13:28:38 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __BL2_RAM_START__, BL2_RAM_BASE);
|
|
|
|
|
IMPORT_SYM(uintptr_t, __BL2_RAM_END__, BL2_RAM_END);
|
2018-12-18 13:49:46 +00:00
|
|
|
#endif /* BL2_IN_XIP_MEM */
|
|
|
|
|
|
2018-03-21 11:40:57 +00:00
|
|
|
/*
|
|
|
|
|
* The next 2 constants identify the extents of the coherent memory region.
|
|
|
|
|
* These addresses are used by the MMU setup code and therefore they must be
|
|
|
|
|
* page-aligned. It is the responsibility of the linker script to ensure that
|
|
|
|
|
* __COHERENT_RAM_START__ and __COHERENT_RAM_END__ linker symbols refer to
|
|
|
|
|
* page-aligned addresses.
|
|
|
|
|
*/
|
2015-04-27 11:49:22 +01:00
|
|
|
#if USE_COHERENT_MEM
|
2019-01-25 13:28:38 +00:00
|
|
|
IMPORT_SYM(uintptr_t, __COHERENT_RAM_START__, BL_COHERENT_RAM_BASE);
|
|
|
|
|
IMPORT_SYM(uintptr_t, __COHERENT_RAM_END__, BL_COHERENT_RAM_END);
|
2015-04-27 11:49:22 +01:00
|
|
|
#endif
|
|
|
|
|
|
2013-10-25 09:08:21 +01:00
|
|
|
/*******************************************************************************
|
|
|
|
|
* Structure used for telling the next BL how much of a particular type of
|
|
|
|
|
* memory is available for its use and how much is already used.
|
|
|
|
|
******************************************************************************/
|
2014-04-10 15:37:22 +01:00
|
|
|
typedef struct meminfo {
|
2016-06-16 14:52:04 +01:00
|
|
|
uintptr_t total_base;
|
2014-06-24 14:02:34 +01:00
|
|
|
size_t total_size;
|
2014-04-10 15:37:22 +01:00
|
|
|
} meminfo_t;
|
2013-10-25 09:08:21 +01:00
|
|
|
|
|
|
|
|
/*******************************************************************************
|
|
|
|
|
* Function & variable prototypes
|
|
|
|
|
******************************************************************************/
|
2016-09-12 16:08:41 +01:00
|
|
|
int load_auth_image(unsigned int image_id, image_info_t *image_data);
|
|
|
|
|
|
2018-03-26 12:43:37 +01:00
|
|
|
#if TRUSTED_BOARD_BOOT && defined(DYN_DISABLE_AUTH)
|
|
|
|
|
/*
|
|
|
|
|
* API to dynamically disable authentication. Only meant for development
|
|
|
|
|
* systems.
|
|
|
|
|
*/
|
|
|
|
|
void dyn_disable_auth(void);
|
|
|
|
|
#endif
|
|
|
|
|
|
2016-09-12 16:08:41 +01:00
|
|
|
extern const char build_message[];
|
|
|
|
|
extern const char version_string[];
|
|
|
|
|
|
2015-09-28 17:03:06 +01:00
|
|
|
void print_entry_point_info(const entry_point_info_t *ep_info);
|
2018-02-12 12:36:17 +00:00
|
|
|
uintptr_t page_align(uintptr_t value, unsigned dir);
|
2015-09-28 17:03:06 +01:00
|
|
|
|
2018-10-19 16:44:18 +01:00
|
|
|
struct mmap_region;
|
|
|
|
|
|
|
|
|
|
void setup_page_tables(const struct mmap_region *bl_regions,
|
|
|
|
|
const struct mmap_region *plat_regions);
|
|
|
|
|
|
2019-02-19 11:53:51 +00:00
|
|
|
void bl_handle_pauth(void);
|
|
|
|
|
|
2019-07-09 21:49:11 +01:00
|
|
|
#endif /*__ASSEMBLER__*/
|
2013-10-25 09:08:21 +01:00
|
|
|
|
2018-11-08 10:20:19 +00:00
|
|
|
#endif /* BL_COMMON_H */
|
