|
|
|
/*
|
|
|
|
* Copyright (c) 2013-2020, ARM Limited and Contributors. All rights reserved.
|
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <common/bl_common.ld.h>
|
|
|
|
#include <lib/xlat_tables/xlat_tables_defs.h>
|
|
|
|
|
|
|
|
OUTPUT_FORMAT(PLATFORM_LINKER_FORMAT)
|
|
|
|
OUTPUT_ARCH(PLATFORM_LINKER_ARCH)
|
|
|
|
ENTRY(bl31_entrypoint)
|
|
|
|
|
|
|
|
|
|
|
|
MEMORY {
|
|
|
|
RAM (rwx): ORIGIN = BL31_BASE, LENGTH = BL31_LIMIT - BL31_BASE
|
|
|
|
#if SEPARATE_NOBITS_REGION
|
|
|
|
NOBITS (rw!a): ORIGIN = BL31_NOBITS_BASE, LENGTH = BL31_NOBITS_LIMIT - BL31_NOBITS_BASE
|
|
|
|
#else
|
|
|
|
#define NOBITS RAM
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
|
|
|
#ifdef PLAT_EXTRA_LD_SCRIPT
|
|
|
|
#include <plat.ld.S>
|
|
|
|
#endif
|
|
|
|
|
|
|
|
SECTIONS
|
|
|
|
{
|
|
|
|
. = BL31_BASE;
|
|
|
|
ASSERT(. == ALIGN(PAGE_SIZE),
|
|
|
|
"BL31_BASE address is not aligned on a page boundary.")
|
|
|
|
|
|
|
|
__BL31_START__ = .;
|
|
|
|
|
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
8 years ago
|
|
|
#if SEPARATE_CODE_AND_RODATA
|
|
|
|
.text . : {
|
|
|
|
__TEXT_START__ = .;
|
|
|
|
*bl31_entrypoint.o(.text*)
|
|
|
|
*(SORT_BY_ALIGNMENT(.text*))
|
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
8 years ago
|
|
|
*(.vectors)
|
|
|
|
. = ALIGN(PAGE_SIZE);
|
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
8 years ago
|
|
|
__TEXT_END__ = .;
|
|
|
|
} >RAM
|
|
|
|
|
|
|
|
.rodata . : {
|
|
|
|
__RODATA_START__ = .;
|
|
|
|
*(SORT_BY_ALIGNMENT(.rodata*))
|
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
8 years ago
|
|
|
|
linker_script: replace common read-only data with RODATA_COMMON
The common section data are repeated in many linker scripts (often
twice in each script to support SEPARATE_CODE_AND_RODATA). When you
add a new read-only data section, you end up with touching lots of
places.
After this commit, you will only need to touch bl_common.ld.h when
you add a new section to RODATA_COMMON.
Replace a series of RO section with RODATA_COMMON, which contains
6 sections, some of which did not exist before.
This is not a big deal because unneeded data should not be compiled
in the first place. I believe this should be controlled by BL*_SOURCES
in Makefiles, not by linker scripts.
When I was working on this commit, the BL1 image size increased
due to the fconf_populator. Commit c452ba159c14 ("fconf: exclude
fconf_dyn_cfg_getter.c from BL1_SOURCES") fixed this issue.
I investigated BL1, BL2, BL2U, BL31 for plat=fvp, and BL2-AT-EL3,
BL31, BL31 for plat=uniphier. I did not see any more unexpected
code addition.
Change-Id: I5d14d60dbe3c821765bce3ae538968ef266f1460
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
5 years ago
|
|
|
RODATA_COMMON
|
|
|
|
|
|
|
|
/* Place pubsub sections for events */
|
|
|
|
. = ALIGN(8);
|
|
|
|
#include <lib/el3_runtime/pubsub_events.h>
|
|
|
|
|
|
|
|
. = ALIGN(PAGE_SIZE);
|
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
8 years ago
|
|
|
__RODATA_END__ = .;
|
|
|
|
} >RAM
|
|
|
|
#else
|
|
|
|
ro . : {
|
|
|
|
__RO_START__ = .;
|
|
|
|
*bl31_entrypoint.o(.text*)
|
|
|
|
*(SORT_BY_ALIGNMENT(.text*))
|
|
|
|
*(SORT_BY_ALIGNMENT(.rodata*))
|
|
|
|
|
linker_script: replace common read-only data with RODATA_COMMON
The common section data are repeated in many linker scripts (often
twice in each script to support SEPARATE_CODE_AND_RODATA). When you
add a new read-only data section, you end up with touching lots of
places.
After this commit, you will only need to touch bl_common.ld.h when
you add a new section to RODATA_COMMON.
Replace a series of RO section with RODATA_COMMON, which contains
6 sections, some of which did not exist before.
This is not a big deal because unneeded data should not be compiled
in the first place. I believe this should be controlled by BL*_SOURCES
in Makefiles, not by linker scripts.
When I was working on this commit, the BL1 image size increased
due to the fconf_populator. Commit c452ba159c14 ("fconf: exclude
fconf_dyn_cfg_getter.c from BL1_SOURCES") fixed this issue.
I investigated BL1, BL2, BL2U, BL31 for plat=fvp, and BL2-AT-EL3,
BL31, BL31 for plat=uniphier. I did not see any more unexpected
code addition.
Change-Id: I5d14d60dbe3c821765bce3ae538968ef266f1460
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
5 years ago
|
|
|
RODATA_COMMON
|
|
|
|
|
|
|
|
/* Place pubsub sections for events */
|
|
|
|
. = ALIGN(8);
|
|
|
|
#include <lib/el3_runtime/pubsub_events.h>
|
|
|
|
|
|
|
|
*(.vectors)
|
|
|
|
__RO_END_UNALIGNED__ = .;
|
|
|
|
/*
|
|
|
|
* Memory page(s) mapped to this section will be marked as read-only,
|
|
|
|
* executable. No RW data from the next section must creep in.
|
|
|
|
* Ensure the rest of the current memory page is unused.
|
|
|
|
*/
|
|
|
|
. = ALIGN(PAGE_SIZE);
|
|
|
|
__RO_END__ = .;
|
|
|
|
} >RAM
|
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
8 years ago
|
|
|
#endif
|
|
|
|
|
|
|
|
ASSERT(__CPU_OPS_END__ > __CPU_OPS_START__,
|
|
|
|
"cpu_ops not defined for this platform.")
|
|
|
|
|
|
|
|
#if SPM_MM
|
|
|
|
#ifndef SPM_SHIM_EXCEPTIONS_VMA
|
|
|
|
#define SPM_SHIM_EXCEPTIONS_VMA RAM
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Exception vectors of the SPM shim layer. They must be aligned to a 2K
|
|
|
|
* address, but we need to place them in a separate page so that we can set
|
|
|
|
* individual permissions to them, so the actual alignment needed is 4K.
|
|
|
|
*
|
|
|
|
* There's no need to include this into the RO section of BL31 because it
|
|
|
|
* doesn't need to be accessed by BL31.
|
|
|
|
*/
|
|
|
|
spm_shim_exceptions : ALIGN(PAGE_SIZE) {
|
|
|
|
__SPM_SHIM_EXCEPTIONS_START__ = .;
|
|
|
|
*(.spm_shim_exceptions)
|
|
|
|
. = ALIGN(PAGE_SIZE);
|
|
|
|
__SPM_SHIM_EXCEPTIONS_END__ = .;
|
|
|
|
} >SPM_SHIM_EXCEPTIONS_VMA AT>RAM
|
|
|
|
|
|
|
|
PROVIDE(__SPM_SHIM_EXCEPTIONS_LMA__ = LOADADDR(spm_shim_exceptions));
|
|
|
|
. = LOADADDR(spm_shim_exceptions) + SIZEOF(spm_shim_exceptions);
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Define a linker symbol to mark start of the RW memory area for this
|
|
|
|
* image.
|
|
|
|
*/
|
|
|
|
__RW_START__ = . ;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* .data must be placed at a lower address than the stacks if the stack
|
|
|
|
* protector is enabled. Alternatively, the .data.stack_protector_canary
|
|
|
|
* section can be placed independently of the main .data section.
|
|
|
|
*/
|
|
|
|
.data . : {
|
|
|
|
__DATA_START__ = .;
|
|
|
|
*(SORT_BY_ALIGNMENT(.data*))
|
|
|
|
__DATA_END__ = .;
|
|
|
|
} >RAM
|
|
|
|
|
|
|
|
/*
|
|
|
|
* .rela.dyn needs to come after .data for the read-elf utility to parse
|
|
|
|
* this section correctly. Ensure 8-byte alignment so that the fields of
|
|
|
|
* RELA data structure are aligned.
|
|
|
|
*/
|
|
|
|
. = ALIGN(8);
|
|
|
|
__RELA_START__ = .;
|
|
|
|
.rela.dyn . : {
|
|
|
|
} >RAM
|
|
|
|
__RELA_END__ = .;
|
|
|
|
|
|
|
|
#ifdef BL31_PROGBITS_LIMIT
|
|
|
|
ASSERT(. <= BL31_PROGBITS_LIMIT, "BL31 progbits has exceeded its limit.")
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if SEPARATE_NOBITS_REGION
|
|
|
|
/*
|
|
|
|
* Define a linker symbol to mark end of the RW memory area for this
|
|
|
|
* image.
|
|
|
|
*/
|
|
|
|
. = ALIGN(PAGE_SIZE);
|
|
|
|
__RW_END__ = .;
|
|
|
|
__BL31_END__ = .;
|
|
|
|
|
|
|
|
ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.")
|
|
|
|
|
|
|
|
. = BL31_NOBITS_BASE;
|
|
|
|
ASSERT(. == ALIGN(PAGE_SIZE),
|
|
|
|
"BL31 NOBITS base address is not aligned on a page boundary.")
|
|
|
|
|
|
|
|
__NOBITS_START__ = .;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
stacks (NOLOAD) : {
|
|
|
|
__STACKS_START__ = .;
|
|
|
|
*(tzfw_normal_stacks)
|
|
|
|
__STACKS_END__ = .;
|
|
|
|
} >NOBITS
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The .bss section gets initialised to 0 at runtime.
|
|
|
|
* Its base address should be 16-byte aligned for better performance of the
|
|
|
|
* zero-initialization code.
|
|
|
|
*/
|
|
|
|
.bss (NOLOAD) : ALIGN(16) {
|
|
|
|
__BSS_START__ = .;
|
|
|
|
*(SORT_BY_ALIGNMENT(.bss*))
|
|
|
|
*(COMMON)
|
|
|
|
BAKERY_LOCK_NORMAL
|
|
|
|
PMF_TIMESTAMP
|
|
|
|
__BSS_END__ = .;
|
|
|
|
} >NOBITS
|
|
|
|
|
|
|
|
XLAT_TABLE_SECTION >NOBITS
|
|
|
|
|
|
|
|
#if USE_COHERENT_MEM
|
|
|
|
/*
|
|
|
|
* The base address of the coherent memory section must be page-aligned (4K)
|
|
|
|
* to guarantee that the coherent data are stored on their own pages and
|
|
|
|
* are not mixed with normal data. This is required to set up the correct
|
|
|
|
* memory attributes for the coherent data page tables.
|
|
|
|
*/
|
|
|
|
coherent_ram (NOLOAD) : ALIGN(PAGE_SIZE) {
|
|
|
|
__COHERENT_RAM_START__ = .;
|
|
|
|
/*
|
|
|
|
* Bakery locks are stored in coherent memory
|
|
|
|
*
|
|
|
|
* Each lock's data is contiguous and fully allocated by the compiler
|
|
|
|
*/
|
|
|
|
*(bakery_lock)
|
|
|
|
*(tzfw_coherent_mem)
|
|
|
|
__COHERENT_RAM_END_UNALIGNED__ = .;
|
|
|
|
/*
|
|
|
|
* Memory page(s) mapped to this section will be marked
|
|
|
|
* as device memory. No other unexpected data must creep in.
|
|
|
|
* Ensure the rest of the current memory page is unused.
|
|
|
|
*/
|
|
|
|
. = ALIGN(PAGE_SIZE);
|
|
|
|
__COHERENT_RAM_END__ = .;
|
|
|
|
} >NOBITS
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if SEPARATE_NOBITS_REGION
|
|
|
|
/*
|
|
|
|
* Define a linker symbol to mark end of the NOBITS memory area for this
|
|
|
|
* image.
|
|
|
|
*/
|
|
|
|
__NOBITS_END__ = .;
|
|
|
|
|
|
|
|
ASSERT(. <= BL31_NOBITS_LIMIT, "BL31 NOBITS region has exceeded its limit.")
|
|
|
|
#else
|
|
|
|
/*
|
|
|
|
* Define a linker symbol to mark end of the RW memory area for this
|
|
|
|
* image.
|
|
|
|
*/
|
|
|
|
__RW_END__ = .;
|
|
|
|
__BL31_END__ = .;
|
|
|
|
|
BL31: discard .dynsym .dynstr .hash sections to make ENABLE_PIE work
When I tried ENABLE_PIE for my PLAT=uniphier platform, BL31 crashed
at its entry. When it is built with ENABLE_PIE=1, some sections are
inserted before the executable code.
$ make PLAT=uniphier CROSS_COMPILE=aarch64-linux-gnu- ENABLE_PIE=1 bl31
$ aarch64-linux-gnu-objdump -h build/uniphier/release/bl31/bl31.elf | head -n 13
build/uniphier/release/bl31/bl31.elf: file format elf64-littleaarch64
Sections:
Idx Name Size VMA LMA File off Algn
0 .dynsym 000002a0 0000000081000000 0000000081000000 00010000 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
1 .dynstr 000002a0 00000000810002a0 00000000810002a0 000102a0 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
2 .hash 00000124 0000000081000540 0000000081000540 00010540 2**3
CONTENTS, ALLOC, LOAD, READONLY, DATA
3 ro 0000699c 0000000081000664 0000000081000664 00010664 2**11
CONTENTS, ALLOC, LOAD, CODE
The previous stage loader generally jumps over to the base address of
BL31, where no valid instruction exists.
I checked the linker script of Linux (arch/arm64/kernel/vmlinux.lds.S)
and U-Boot (arch/arm/cpu/armv8/u-boot.lds), both of which support
relocation. They simply discard those sections.
Do similar in TF-A too.
Change-Id: I6c33e9143856765d4ffa24f3924b0ab51a17cde9
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
5 years ago
|
|
|
/DISCARD/ : {
|
|
|
|
*(.dynsym .dynstr .hash .gnu.hash)
|
|
|
|
}
|
|
|
|
|
|
|
|
ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.")
|
|
|
|
#endif
|
|
|
|
}
|