|
|
|
/*
|
|
|
|
* Copyright (c) 2013-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(bl1_entrypoint)
|
|
|
|
|
|
|
|
MEMORY {
|
|
|
|
ROM (rx): ORIGIN = BL1_RO_BASE, LENGTH = BL1_RO_LIMIT - BL1_RO_BASE
|
|
|
|
RAM (rwx): ORIGIN = BL1_RW_BASE, LENGTH = BL1_RW_LIMIT - BL1_RW_BASE
|
|
|
|
}
|
|
|
|
|
|
|
|
SECTIONS
|
|
|
|
{
|
|
|
|
. = BL1_RO_BASE;
|
|
|
|
ASSERT(. == ALIGN(PAGE_SIZE),
|
|
|
|
"BL1_RO_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__ = .;
|
|
|
|
*bl1_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__ = .;
|
|
|
|
} >ROM
|
|
|
|
|
|
|
|
/* .ARM.extab and .ARM.exidx are only added because Clang need them */
|
|
|
|
.ARM.extab . : {
|
|
|
|
*(.ARM.extab* .gnu.linkonce.armextab.*)
|
|
|
|
} >ROM
|
|
|
|
|
|
|
|
.ARM.exidx . : {
|
|
|
|
*(.ARM.exidx* .gnu.linkonce.armexidx.*)
|
|
|
|
} >ROM
|
|
|
|
|
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*))
|
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
|
|
|
|
|
|
|
/* Ensure 8-byte alignment for descriptors and ensure inclusion */
|
|
|
|
. = ALIGN(8);
|
|
|
|
__PARSER_LIB_DESCS_START__ = .;
|
|
|
|
KEEP(*(.img_parser_lib_descs))
|
|
|
|
__PARSER_LIB_DESCS_END__ = .;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure 8-byte alignment for cpu_ops so that its fields are also
|
|
|
|
* aligned. Also ensure cpu_ops inclusion.
|
|
|
|
*/
|
|
|
|
. = ALIGN(8);
|
|
|
|
__CPU_OPS_START__ = .;
|
|
|
|
KEEP(*(cpu_ops))
|
|
|
|
__CPU_OPS_END__ = .;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* No need to pad out the .rodata section to a page boundary. Next is
|
|
|
|
* the .data section, which can mapped in ROM with the same memory
|
|
|
|
* attributes as the .rodata section.
|
|
|
|
*/
|
|
|
|
__RODATA_END__ = .;
|
|
|
|
} >ROM
|
|
|
|
#else
|
|
|
|
ro . : {
|
|
|
|
__RO_START__ = .;
|
|
|
|
*bl1_entrypoint.o(.text*)
|
|
|
|
*(SORT_BY_ALIGNMENT(.text*))
|
|
|
|
*(SORT_BY_ALIGNMENT(.rodata*))
|
|
|
|
|
|
|
|
/* Ensure 8-byte alignment for descriptors and ensure inclusion */
|
|
|
|
. = ALIGN(8);
|
|
|
|
__PARSER_LIB_DESCS_START__ = .;
|
|
|
|
KEEP(*(.img_parser_lib_descs))
|
|
|
|
__PARSER_LIB_DESCS_END__ = .;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Ensure 8-byte alignment for cpu_ops so that its fields are also
|
|
|
|
* aligned. Also ensure cpu_ops inclusion.
|
|
|
|
*/
|
|
|
|
. = ALIGN(8);
|
|
|
|
__CPU_OPS_START__ = .;
|
|
|
|
KEEP(*(cpu_ops))
|
|
|
|
__CPU_OPS_END__ = .;
|
|
|
|
|
|
|
|
*(.vectors)
|
|
|
|
__RO_END__ = .;
|
|
|
|
} >ROM
|
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.")
|
|
|
|
|
|
|
|
. = BL1_RW_BASE;
|
|
|
|
ASSERT(BL1_RW_BASE == ALIGN(PAGE_SIZE),
|
|
|
|
"BL1_RW_BASE address is not aligned on a page boundary.")
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The .data section gets copied from ROM to RAM at runtime.
|
|
|
|
* Its LMA should be 16-byte aligned to allow efficient copying of 16-bytes
|
|
|
|
* aligned regions in it.
|
|
|
|
* Its VMA must be page-aligned as it marks the first read/write page.
|
|
|
|
*
|
|
|
|
* It 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 . : ALIGN(16) {
|
|
|
|
__DATA_RAM_START__ = .;
|
|
|
|
*(SORT_BY_ALIGNMENT(.data*))
|
|
|
|
__DATA_RAM_END__ = .;
|
|
|
|
} >RAM AT>ROM
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
|
__BL1_RAM_START__ = ADDR(.data);
|
|
|
|
__BL1_RAM_END__ = .;
|
|
|
|
|
|
|
|
__DATA_ROM_START__ = LOADADDR(.data);
|
|
|
|
__DATA_SIZE__ = SIZEOF(.data);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The .data section is the last PROGBITS section so its end marks the end
|
|
|
|
* of BL1's actual content in Trusted ROM.
|
|
|
|
*/
|
|
|
|
__BL1_ROM_END__ = __DATA_ROM_START__ + __DATA_SIZE__;
|
|
|
|
ASSERT(__BL1_ROM_END__ <= BL1_RO_LIMIT,
|
|
|
|
"BL1's ROM content has exceeded its limit.")
|
|
|
|
|
|
|
|
__BSS_SIZE__ = SIZEOF(.bss);
|
|
|
|
|
|
|
|
#if USE_COHERENT_MEM
|
|
|
|
__COHERENT_RAM_UNALIGNED_SIZE__ =
|
|
|
|
__COHERENT_RAM_END_UNALIGNED__ - __COHERENT_RAM_START__;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
ASSERT(. <= BL1_RW_LIMIT, "BL1's RW section has exceeded its limit.")
|
|
|
|
}
|