|
|
|
|
/*
|
|
|
|
|
* Copyright (c) 2013-2023, 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 /* SEPARATE_NOBITS_REGION */
|
|
|
|
|
# define NOBITS RAM
|
|
|
|
|
#endif /* SEPARATE_NOBITS_REGION */
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef PLAT_EXTRA_LD_SCRIPT
|
|
|
|
|
# include <plat.ld.S>
|
|
|
|
|
#endif /* PLAT_EXTRA_LD_SCRIPT */
|
|
|
|
|
|
|
|
|
|
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__ = .;
|
|
|
|
|
|
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
|
|
|
*bl31_entrypoint.o(.text*)
|
Increase type widths to satisfy width requirements
Usually, C has no problem up-converting types to larger bit sizes. MISRA
rule 10.7 requires that you not do this, or be very explicit about this.
This resolves the following required rule:
bl1/aarch64/bl1_context_mgmt.c:81:[MISRA C-2012 Rule 10.7 (required)]<None>
The width of the composite expression "0U | ((mode & 3U) << 2U) | 1U |
0x3c0U" (32 bits) is less that the right hand operand
"18446744073709547519ULL" (64 bits).
This also resolves MISRA defects such as:
bl2/aarch64/bl2arch_setup.c:18:[MISRA C-2012 Rule 12.2 (required)]
In the expression "3U << 20", shifting more than 7 bits, the number
of bits in the essential type of the left expression, "3U", is
not allowed.
Further, MISRA requires that all shifts don't overflow. The definition of
PAGE_SIZE was (1U << 12), and 1U is 8 bits. This caused about 50 issues.
This fixes the violation by changing the definition to 1UL << 12. Since
this uses 32bits, it should not create any issues for aarch32.
This patch also contains a fix for a build failure in the sun50i_a64
platform. Specifically, these misra fixes removed a single and
instruction,
92407e73 and x19, x19, #0xffffffff
from the cm_setup_context function caused a relocation in
psci_cpus_on_start to require a linker-generated stub. This increased the
size of the .text section and caused an alignment later on to go over a
page boundary and round up to the end of RAM before placing the .data
section. This sectionn is of non-zero size and therefore causes a link
error.
The fix included in this reorders the functions during link time
without changing their ording with respect to alignment.
Change-Id: I76b4b662c3d262296728a8b9aab7a33b02087f16
Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
4 years ago
|
|
|
*(SORT_BY_ALIGNMENT(SORT(.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
|
|
|
|
|
|
|
|
# if PLAT_EXTRA_RODATA_INCLUDES
|
|
|
|
|
# include <plat.ld.rodata.inc>
|
|
|
|
|
# endif /* PLAT_EXTRA_RODATA_INCLUDES */
|
|
|
|
|
|
|
|
|
|
RODATA_COMMON
|
|
|
|
|
|
|
|
|
|
. = 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 /* SEPARATE_CODE_AND_RODATA */
|
|
|
|
|
.ro . : {
|
|
|
|
|
__RO_START__ = .;
|
|
|
|
|
|
|
|
|
|
*bl31_entrypoint.o(.text*)
|
|
|
|
|
*(SORT_BY_ALIGNMENT(.text*))
|
|
|
|
|
*(SORT_BY_ALIGNMENT(.rodata*))
|
|
|
|
|
|
|
|
|
|
RODATA_COMMON
|
|
|
|
|
|
|
|
|
|
. = 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
|
|
|
|
|
* that the rest of the current memory page is unused.
|
|
|
|
|
*/
|
|
|
|
|
. = ALIGN(PAGE_SIZE);
|
|
|
|
|
|
|
|
|
|
__RO_END__ = .;
|
|
|
|
|
} >RAM
|
|
|
|
|
#endif /* SEPARATE_CODE_AND_RODATA */
|
|
|
|
|
|
|
|
|
|
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 /* SPM_SHIM_EXCEPTIONS_VMA */
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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 on them, so the actual alignment needed is the
|
|
|
|
|
* page size.
|
|
|
|
|
*
|
|
|
|
|
* 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 /* SPM_MM */
|
|
|
|
|
|
|
|
|
|
__RW_START__ = .;
|
|
|
|
|
|
linker_script: move .data section to bl_common.ld.h
Move the data section to the common header.
I slightly tweaked some scripts as follows:
[1] bl1.ld.S has ALIGN(16). I added DATA_ALIGN macro, which is 1
by default, but overridden by bl1.ld.S. Currently, ALIGN(16)
of the .data section is redundant because commit 412865907699
("Fix boot failures on some builds linked with ld.lld.") padded
out the previous section to work around the issue of LLD version
<= 10.0. This will be fixed in the future release of LLVM, so
I am keeping the proper way to align LMA.
[2] bl1.ld.S and bl2_el3.ld.S define __DATA_RAM_{START,END}__ instead
of __DATA_{START,END}__. I put them out of the .data section.
[3] SORT_BY_ALIGNMENT() is missing tsp.ld.S, sp_min.ld.S, and
mediatek/mt6795/bl31.ld.S. This commit adds SORT_BY_ALIGNMENT()
for all images, so the symbol order in those three will change,
but I do not think it is a big deal.
Change-Id: I215bb23c319f045cd88e6f4e8ee2518c67f03692
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
5 years ago
|
|
|
DATA_SECTION >RAM
|
|
|
|
|
RELA_SECTION >RAM
|
|
|
|
|
|
|
|
|
|
#ifdef BL31_PROGBITS_LIMIT
|
|
|
|
|
ASSERT(. <= BL31_PROGBITS_LIMIT, "BL31 progbits has exceeded its limit.")
|
|
|
|
|
#endif /* BL31_PROGBITS_LIMIT */
|
|
|
|
|
|
|
|
|
|
#if SEPARATE_NOBITS_REGION
|
|
|
|
|
. = 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 /* SEPARATE_NOBITS_REGION */
|
|
|
|
|
|
|
|
|
|
STACK_SECTION >NOBITS
|
linker_script: move bss section to bl_common.ld.h
Move the bss section to the common header. This adds BAKERY_LOCK_NORMAL
and PMF_TIMESTAMP, which previously existed only in BL31. This is not
a big deal because unused data should not be compiled in the first
place. I believe this should be controlled by BL*_SOURCES in Makefiles,
not by linker scripts.
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.
The bss section has bigger alignment. I added BSS_ALIGN for this.
Currently, SORT_BY_ALIGNMENT() is missing in sp_min.ld.S, and with this
change, the BSS symbols in SP_MIN will be sorted by the alignment.
This is not a big deal (or, even better in terms of the image size).
Change-Id: I680ee61f84067a559bac0757f9d03e73119beb33
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
5 years ago
|
|
|
BSS_SECTION >NOBITS
|
|
|
|
|
XLAT_TABLE_SECTION >NOBITS
|
|
|
|
|
|
|
|
|
|
#if USE_COHERENT_MEM
|
|
|
|
|
/*
|
|
|
|
|
* The base address of the coherent memory section must be page-aligned 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 /* USE_COHERENT_MEM */
|
|
|
|
|
|
|
|
|
|
#if SEPARATE_NOBITS_REGION
|
|
|
|
|
__NOBITS_END__ = .;
|
|
|
|
|
|
|
|
|
|
ASSERT(. <= BL31_NOBITS_LIMIT, "BL31 NOBITS region has exceeded its limit.")
|
|
|
|
|
#else /* SEPARATE_NOBITS_REGION */
|
|
|
|
|
__RW_END__ = .;
|
|
|
|
|
__BL31_END__ = .;
|
|
|
|
|
|
|
|
|
|
ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.")
|
|
|
|
|
#endif /* SEPARATE_NOBITS_REGION */
|
|
|
|
|
|
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)
|
|
|
|
|
}
|
|
|
|
|
}
|
