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

1 files changed, 38 insertions, 0 deletions

diff --git a/bl1/bl1.ld.S b/bl1/bl1.ld.S
index be36b4ee..b9554d15 100644
--- a/bl1/bl1.ld.S
+++ b/bl1/bl1.ld.S
@@ -45,6 +45,43 @@ SECTIONS
     ASSERT(. == ALIGN(4096),
            "BL1_RO_BASE address is not aligned on a page boundary.")
 
+#if SEPARATE_CODE_AND_RODATA
+    .text . : {
+        __TEXT_START__ = .;
+        *bl1_entrypoint.o(.text*)
+        *(.text*)
+        *(.vectors)
+        . = NEXT(4096);
+        __TEXT_END__ = .;
+     } >ROM
+
+    .rodata . : {
+        __RODATA_START__ = .;
+        *(.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__ = .;
+
+        /*
+         * 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*)
@@ -69,6 +106,7 @@ SECTIONS
         *(.vectors)
         __RO_END__ = .;
     } >ROM
+#endif
 
     ASSERT(__CPU_OPS_END__ > __CPU_OPS_START__,
            "cpu_ops not defined for this platform.")