|
|
|
/*
|
|
|
|
* Copyright (c) 2013-2018, ARM Limited and Contributors. All rights reserved.
|
|
|
|
*
|
|
|
|
* SPDX-License-Identifier: BSD-3-Clause
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <platform_def.h>
|
|
|
|
#include <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
|
|
|
|
}
|
|
|
|
|
|
|
|
#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.")
|
|
|
|
|
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*)
|
|
|
|
*(.text*)
|
|
|
|
*(.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__ = .;
|
|
|
|
*(.rodata*)
|
|
|
|
|
|
|
|
/* Ensure 8-byte alignment for descriptors and ensure inclusion */
|
|
|
|
. = ALIGN(8);
|
|
|
|
__RT_SVC_DESCS_START__ = .;
|
|
|
|
KEEP(*(rt_svc_descs))
|
|
|
|
__RT_SVC_DESCS_END__ = .;
|
|
|
|
|
|
|
|
#if ENABLE_PMF
|
|
|
|
/* Ensure 8-byte alignment for descriptors and ensure inclusion */
|
|
|
|
. = ALIGN(8);
|
|
|
|
__PMF_SVC_DESCS_START__ = .;
|
|
|
|
KEEP(*(pmf_svc_descs))
|
|
|
|
__PMF_SVC_DESCS_END__ = .;
|
|
|
|
#endif /* ENABLE_PMF */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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__ = .;
|
|
|
|
|
|
|
|
/* Place pubsub sections for events */
|
|
|
|
. = ALIGN(8);
|
|
|
|
#include <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*)
|
|
|
|
*(.text*)
|
|
|
|
*(.rodata*)
|
|
|
|
|
|
|
|
/* Ensure 8-byte alignment for descriptors and ensure inclusion */
|
|
|
|
. = ALIGN(8);
|
|
|
|
__RT_SVC_DESCS_START__ = .;
|
|
|
|
KEEP(*(rt_svc_descs))
|
|
|
|
__RT_SVC_DESCS_END__ = .;
|
|
|
|
|
|
|
|
#if ENABLE_PMF
|
|
|
|
/* Ensure 8-byte alignment for descriptors and ensure inclusion */
|
|
|
|
. = ALIGN(8);
|
|
|
|
__PMF_SVC_DESCS_START__ = .;
|
|
|
|
KEEP(*(pmf_svc_descs))
|
|
|
|
__PMF_SVC_DESCS_END__ = .;
|
|
|
|
#endif /* ENABLE_PMF */
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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__ = .;
|
|
|
|
|
|
|
|
/* Place pubsub sections for events */
|
|
|
|
. = ALIGN(8);
|
|
|
|
#include <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 ENABLE_SPM
|
|
|
|
/*
|
|
|
|
* 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__ = .;
|
|
|
|
} >RAM
|
|
|
|
#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__ = .;
|
|
|
|
*(.data*)
|
|
|
|
__DATA_END__ = .;
|
|
|
|
} >RAM
|
|
|
|
|
|
|
|
#ifdef BL31_PROGBITS_LIMIT
|
|
|
|
ASSERT(. <= BL31_PROGBITS_LIMIT, "BL31 progbits has exceeded its limit.")
|
|
|
|
#endif
|
|
|
|
|
|
|
|
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 (NOLOAD) : ALIGN(16) {
|
|
|
|
__BSS_START__ = .;
|
|
|
|
*(.bss*)
|
|
|
|
*(COMMON)
|
|
|
|
#if !USE_COHERENT_MEM
|
|
|
|
/*
|
|
|
|
* Bakery locks are stored in normal .bss memory
|
|
|
|
*
|
|
|
|
* Each lock's data is spread across multiple cache lines, one per CPU,
|
|
|
|
* but multiple locks can share the same cache line.
|
|
|
|
* The compiler will allocate enough memory for one CPU's bakery locks,
|
|
|
|
* the remaining cache lines are allocated by the linker script
|
|
|
|
*/
|
|
|
|
. = ALIGN(CACHE_WRITEBACK_GRANULE);
|
|
|
|
__BAKERY_LOCK_START__ = .;
|
|
|
|
*(bakery_lock)
|
|
|
|
. = ALIGN(CACHE_WRITEBACK_GRANULE);
|
|
|
|
__PERCPU_BAKERY_LOCK_SIZE__ = ABSOLUTE(. - __BAKERY_LOCK_START__);
|
|
|
|
. = . + (__PERCPU_BAKERY_LOCK_SIZE__ * (PLATFORM_CORE_COUNT - 1));
|
|
|
|
__BAKERY_LOCK_END__ = .;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If BL31 doesn't use any bakery lock then __PERCPU_BAKERY_LOCK_SIZE__
|
|
|
|
* will be zero. For this reason, the only two valid values for
|
|
|
|
* __PERCPU_BAKERY_LOCK_SIZE__ are 0 or the platform defined value
|
|
|
|
* PLAT_PERCPU_BAKERY_LOCK_SIZE.
|
|
|
|
*/
|
|
|
|
#ifdef PLAT_PERCPU_BAKERY_LOCK_SIZE
|
|
|
|
ASSERT((__PERCPU_BAKERY_LOCK_SIZE__ == 0) || (__PERCPU_BAKERY_LOCK_SIZE__ == PLAT_PERCPU_BAKERY_LOCK_SIZE),
|
|
|
|
"PLAT_PERCPU_BAKERY_LOCK_SIZE does not match bakery lock requirements");
|
|
|
|
#endif
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#if ENABLE_PMF
|
|
|
|
/*
|
|
|
|
* Time-stamps are stored in normal .bss memory
|
|
|
|
*
|
|
|
|
* The compiler will allocate enough memory for one CPU's time-stamps,
|
|
|
|
* the remaining memory for other CPU's is allocated by the
|
|
|
|
* linker script
|
|
|
|
*/
|
|
|
|
. = ALIGN(CACHE_WRITEBACK_GRANULE);
|
|
|
|
__PMF_TIMESTAMP_START__ = .;
|
|
|
|
KEEP(*(pmf_timestamp_array))
|
|
|
|
. = ALIGN(CACHE_WRITEBACK_GRANULE);
|
|
|
|
__PMF_PERCPU_TIMESTAMP_END__ = .;
|
|
|
|
__PERCPU_TIMESTAMP_SIZE__ = ABSOLUTE(. - __PMF_TIMESTAMP_START__);
|
|
|
|
. = . + (__PERCPU_TIMESTAMP_SIZE__ * (PLATFORM_CORE_COUNT - 1));
|
|
|
|
__PMF_TIMESTAMP_END__ = .;
|
|
|
|
#endif /* ENABLE_PMF */
|
|
|
|
__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__ = .;
|
|
|
|
/*
|
|
|
|
* 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__ = .;
|
|
|
|
} >RAM
|
|
|
|
#endif
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Define a linker symbol to mark end of the RW memory area for this
|
|
|
|
* image.
|
|
|
|
*/
|
|
|
|
__RW_END__ = .;
|
|
|
|
__BL31_END__ = .;
|
|
|
|
|
|
|
|
__BSS_SIZE__ = SIZEOF(.bss);
|
|
|
|
#if USE_COHERENT_MEM
|
|
|
|
__COHERENT_RAM_UNALIGNED_SIZE__ =
|
|
|
|
__COHERENT_RAM_END_UNALIGNED__ - __COHERENT_RAM_START__;
|
|
|
|
#endif
|
|
|
|
|
|
|
|
ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.")
|
|
|
|
}
|