|
|
|
/*
|
|
|
|
* Copyright (c) 2015-2019, ARM Limited and Contributors. All rights reserved.
|
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <platform_def.h>
|
|
|
|
|
|
|
|
#include <lib/xlat_tables/xlat_tables_defs.h>
|
|
|
|
|
|
|
|
OUTPUT_FORMAT(PLATFORM_LINKER_FORMAT)
|
|
|
|
OUTPUT_ARCH(PLATFORM_LINKER_ARCH)
|
|
|
|
ENTRY(bl2u_entrypoint)
|
|
|
|
|
|
|
|
MEMORY {
|
|
|
|
RAM (rwx): ORIGIN = BL2U_BASE, LENGTH = BL2U_LIMIT - BL2U_BASE
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
|
|
SECTIONS
|
|
|
|
{
|
|
|
|
. = BL2U_BASE;
|
|
|
|
ASSERT(. == ALIGN(PAGE_SIZE),
|
|
|
|
"BL2U_BASE address is not aligned on a page boundary.")
|
|
|
|
|
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__ = .;
|
|
|
|
*bl2u_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
|
|
|
|
|
|
|
|
/* .ARM.extab and .ARM.exidx are only added because Clang need them */
|
|
|
|
.ARM.extab . : {
|
|
|
|
*(.ARM.extab* .gnu.linkonce.armextab.*)
|
|
|
|
} >RAM
|
|
|
|
|
|
|
|
.ARM.exidx . : {
|
|
|
|
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
|
|
|
|
} >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
|
|
|
.rodata . : {
|
|
|
|
__RODATA_START__ = .;
|
|
|
|
*(SORT_BY_ALIGNMENT(.rodata*))
|
|
|
|
. = 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__ = .;
|
|
|
|
*bl2u_entrypoint.o(.text*)
|
|
|
|
*(SORT_BY_ALIGNMENT(.text*))
|
|
|
|
*(SORT_BY_ALIGNMENT(.rodata*))
|
|
|
|
|
|
|
|
*(.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
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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
|
|
|
|
|
|
|
|
stacks (NOLOAD) : {
|
|
|
|
__STACKS_START__ = .;
|
|
|
|
*(tzfw_normal_stacks)
|
|
|
|
__STACKS_END__ = .;
|
|
|
|
} >RAM
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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 : ALIGN(16) {
|
|
|
|
__BSS_START__ = .;
|
|
|
|
*(SORT_BY_ALIGNMENT(.bss*))
|
|
|
|
*(COMMON)
|
|
|
|
__BSS_END__ = .;
|
|
|
|
} >RAM
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The xlat_table section is for full, aligned page tables (4K).
|
|
|
|
* Removing them from .bss avoids forcing 4K alignment on
|
|
|
|
* the .bss section. The tables are initialized to zero by the translation
|
|
|
|
* tables library.
|
|
|
|
*/
|
|
|
|
xlat_table (NOLOAD) : {
|
|
|
|
*(xlat_table)
|
|
|
|
} >RAM
|
|
|
|
|
|
|
|
#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__ = .;
|
|
|
|
*(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__ = .;
|
|
|
|
} >RAM
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Define a linker symbol to mark end of the RW memory area for this
|
|
|
|
* image.
|
|
|
|
*/
|
|
|
|
__RW_END__ = .;
|
|
|
|
__BL2U_END__ = .;
|
|
|
|
|
|
|
|
__BSS_SIZE__ = SIZEOF(.bss);
|
|
|
|
|
|
|
|
ASSERT(. <= BL2U_LIMIT, "BL2U image has exceeded its limit.")
|
|
|
|
}
|