CTCaer/switch-l4t-atf
1
0
Fork 0
mirror of https://github.com/CTCaer/switch-l4t-atf.git synced 2025-02-12 13:48:23 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Documentation for SEPARATE_CODE_AND_RODATA build flag

Browse Source 
This patch documents the effect, cost and benefits of the
SEPARATE_CODE_AND_RODATA build flag.

Change-Id: Ic8daf0563fa6335930ad6c70b9c35f678e84d39d
This commit is contained in:
Sandrine Bailleux 2016-07-07 14:23:04 +01:00
parent 422a40d9c6
commit 29712f1a92
2 changed files with 90 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

88
docs/firmware-design.md
View File

@ -14,8 +14,9 @@ Contents :
9. [Memory layout of BL images](#9-memory-layout-of-bl-images)
10. [Firmware Image Package (FIP)](#10--firmware-image-package-fip)
11. [Use of coherent memory in Trusted Firmware](#11--use-of-coherent-memory-in-trusted-firmware)
12. [Code Structure](#12--code-structure)
13. [References](#13--references)
12. [Isolating code and read-only data on separate memory pages](#12--isolating-code-and-read-only-data-on-separate-memory-pages)
13. [Code Structure](#13--code-structure)
14. [References](#14--references)
1. Introduction
@ -1768,7 +1769,86 @@ whether coherent memory should be used. If a platform disables
optionally define macro `PLAT_PERCPU_BAKERY_LOCK_SIZE` (see the [Porting
Guide]). Refer to the reference platform code for examples.
12. Code Structure
12. Isolating code and read-only data on separate memory pages
---------------------------------------------------------------
In the ARMv8 VMSA, translation table entries include fields that define the
properties of the target memory region, such as its access permissions. The
smallest unit of memory that can be addressed by a translation table entry is
a memory page. Therefore, if software needs to set different permissions on two
memory regions then it needs to map them using different memory pages.
The default memory layout for each BL image is as follows:
| ... |
+-------------------+
| Read-write data |
+-------------------+ Page boundary
| <Padding> |
+-------------------+
| Exception vectors |
+-------------------+ 2 KB boundary
| <Padding> |
+-------------------+
| Read-only data |
+-------------------+
| Code |
+-------------------+ BLx_BASE
Note: The 2KB alignment for the exception vectors is an architectural
requirement.
The read-write data start on a new memory page so that they can be mapped with
read-write permissions, whereas the code and read-only data below are configured
as read-only.
However, the read-only data are not aligned on a page boundary. They are
contiguous to the code. 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.
TF provides the build flag `SEPARATE_CODE_AND_RODATA` to isolate 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. In this case,
platform code gets a finer-grained view of the image layout and can
appropriately map the code region as executable and the read-only data as
execute-never.
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, this flag also changes the memory layout such that the
code and exception vectors are now contiguous, like so:
| ... |
+-------------------+
| Read-write data |
+-------------------+ Page boundary
| <Padding> |
+-------------------+
| Read-only data |
+-------------------+ Page boundary
| <Padding> |
+-------------------+
| Exception vectors |
+-------------------+ 2 KB boundary
| <Padding> |
+-------------------+
| Code |
+-------------------+ BLx_BASE
With this more condensed memory layout, the separation of read-only data will
add zero or one page to the memory footprint of each BL image. Each platform
should consider the trade-off between memory footprint and security.
This build flag is disabled by default, minimising memory footprint. On ARM
platforms, it is enabled.
13. Code Structure
-------------------
Trusted Firmware code is logically divided between the three boot loader
@ -1812,7 +1892,7 @@ FDTs provide a description of the hardware platform and are used by the Linux
kernel at boot time. These can be found in the `fdts` directory.
13. References
14. References
---------------
1. Trusted Board Boot Requirements CLIENT PDD (ARM DEN 0006B-5). Available

6
docs/user-guide.md
View File

@ -416,6 +416,12 @@ performed.
Enabling this option enables the `ENABLE_PMF` build option as well.
The PMF is used for collecting the statistics.
* `SEPARATE_CODE_AND_RODATA`: Whether code and read-only data should be
isolated on separate memory pages. This is a trade-off between security and
memory usage. See "Isolating code and read-only data on separate memory
pages" section in [Firmware Design]. This flag is disabled by default and
affects all BL images.
#### ARM development platform specific build options
* `ARM_TSP_RAM_LOCATION`: location of the TSP binary. Options: