diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/cpu-specific-build-macros.rst | 10 | ||||
| -rw-r--r-- | docs/diagrams/secure_sw_stack_sp.png | bin | 0 -> 34909 bytes | |||
| -rw-r--r-- | docs/diagrams/secure_sw_stack_tos.png | bin | 0 -> 34202 bytes | |||
| -rw-r--r-- | docs/firmware-design.rst | 65 | ||||
| -rw-r--r-- | docs/plat/socionext-uniphier.rst | 84 | ||||
| -rw-r--r-- | docs/porting-guide.rst | 83 | ||||
| -rw-r--r-- | docs/secure-partition-manager-design.rst | 825 | ||||
| -rw-r--r-- | docs/spm-user-guide.rst | 59 | ||||
| -rw-r--r-- | docs/user-guide.rst | 21 |
9 files changed, 1030 insertions, 117 deletions
diff --git a/docs/cpu-specific-build-macros.rst b/docs/cpu-specific-build-macros.rst index f74b45933..014817d39 100644 --- a/docs/cpu-specific-build-macros.rst +++ b/docs/cpu-specific-build-macros.rst @@ -11,6 +11,15 @@ This document describes the various build options present in the CPU specific operations framework to enable errata workarounds and to enable optimizations for a specific CPU on a platform. +Security Vulnerability Workarounds +---------------------------------- + +ARM Trusted Firmware exports a series of build flags which control which +security vulnerability workarounds should be applied at runtime. + +- ``WORKAROUND_CVE_2017_5715``: Enables the security workaround for + `CVE-2017-5715`_. Defaults to 1. + CPU Errata Workarounds ---------------------- @@ -142,6 +151,7 @@ architecture that can be enabled by the platform as desired. *Copyright (c) 2014-2016, ARM Limited and Contributors. All rights reserved.* +.. _CVE-2017-5715: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5715 .. _Cortex-A53 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm048406/Cortex_A53_MPCore_Software_Developers_Errata_Notice.pdf .. _Cortex-A57 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm049219/cortex_a57_mpcore_software_developers_errata_notice.pdf .. _Cortex-A72 MPCore Software Developers Errata Notice: http://infocenter.arm.com/help/topic/com.arm.doc.epm012079/index.html diff --git a/docs/diagrams/secure_sw_stack_sp.png b/docs/diagrams/secure_sw_stack_sp.png Binary files differnew file mode 100644 index 000000000..5cb2ca7a2 --- /dev/null +++ b/docs/diagrams/secure_sw_stack_sp.png diff --git a/docs/diagrams/secure_sw_stack_tos.png b/docs/diagrams/secure_sw_stack_tos.png Binary files differnew file mode 100644 index 000000000..1f2d55506 --- /dev/null +++ b/docs/diagrams/secure_sw_stack_tos.png diff --git a/docs/firmware-design.rst b/docs/firmware-design.rst index 405964d24..1f8fcc862 100644 --- a/docs/firmware-design.rst +++ b/docs/firmware-design.rst @@ -418,6 +418,63 @@ BL2 execution continues as follows: #. BL1 passes control to BL31 at the specified entrypoint at EL3. +Running BL2 at EL3 execution level +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Some platforms have a non-TF Boot ROM that expects the next boot stage +to execute at EL3. On these platforms, TF BL1 is a waste of memory +as its only purpose is to ensure TF BL2 is entered at S-EL1. To avoid +this waste, a special mode enables BL2 to execute at EL3, which allows +a non-TF Boot ROM to load and jump directly to BL2. This mode is selected +when the build flag BL2_AT_EL3 is enabled. The main differences in this +mode are: + +#. BL2 includes the reset code and the mailbox mechanism to differentiate + cold boot and warm boot. It runs at EL3 doing the arch + initialization required for EL3. + +#. BL2 does not receive the meminfo information from BL1 anymore. This + information can be passed by the Boot ROM or be internal to the + BL2 image. + +#. Since BL2 executes at EL3, BL2 jumps directly to the next image, + instead of invoking the RUN_IMAGE SMC call. + + +We assume 3 different types of BootROM support on the platform: + +#. The Boot ROM always jumps to the same address, for both cold + and warm boot. In this case, we will need to keep a resident part + of BL2 whose memory cannot be reclaimed by any other image. The + linker script defines the symbols __TEXT_RESIDENT_START__ and + __TEXT_RESIDENT_END__ that allows the platform to configure + correctly the memory map. +#. The platform has some mechanism to indicate the jump address to the + Boot ROM. Platform code can then program the jump address with + psci_warmboot_entrypoint during cold boot. +#. The platform has some mechanism to program the reset address using + the PROGRAMMABLE_RESET_ADDRESS feature. Platform code can then + program the reset address with psci_warmboot_entrypoint during + cold boot, bypassing the boot ROM for warm boot. + +In the last 2 cases, no part of BL2 needs to remain resident at +runtime. In the first 2 cases, we expect the Boot ROM to be able to +differentiate between warm and cold boot, to avoid loading BL2 again +during warm boot. + +This functionality can be tested with FVP loading the image directly +in memory and changing the address where the system jumps at reset. +For example: + + -C cluster0.cpu0.RVBAR=0x4014000 + --data cluster0.cpu0=bl2.bin@0x4014000 + +With this configuration, FVP is like a platform of the first case, +where the Boot ROM jumps always to the same address. For simplification, +BL32 is loaded in DRAM in this case, to avoid other images reclaiming +BL2 memory. + + AArch64 BL31 ~~~~~~~~~~~~ @@ -1868,9 +1925,11 @@ Firmware Image Package layout The FIP layout consists of a table of contents (ToC) followed by payload data. The ToC itself has a header followed by one or more table entries. The ToC is -terminated by an end marker entry. All ToC entries describe some payload data -that has been appended to the end of the binary package. With the information -provided in the ToC entry the corresponding payload data can be retrieved. +terminated by an end marker entry, and since the size of the ToC is 0 bytes, +the offset equals the total size of the FIP file. All ToC entries describe some +payload data that has been appended to the end of the binary package. With the +information provided in the ToC entry the corresponding payload data can be +retrieved. :: diff --git a/docs/plat/socionext-uniphier.rst b/docs/plat/socionext-uniphier.rst index fb6ebe5ef..2c652ac9e 100644 --- a/docs/plat/socionext-uniphier.rst +++ b/docs/plat/socionext-uniphier.rst @@ -1,11 +1,12 @@ ARM Trusted Firmware for Socionext UniPhier SoCs ================================================ + Socionext UniPhier ARMv8-A SoCs use ARM Trusted Firmware as the secure world firmware, supporting BL1, BL2, and BL31. UniPhier SoC family implements its internal boot ROM, so BL1 is used as pseudo -ROM (i.e. runs in RAM). The internal boot ROM loads 64KB `1`_ image from a +ROM (i.e. runs in RAM). The internal boot ROM loads 64KB [1]_ image from a non-volatile storage to the on-chip SRAM. Unfortunately, BL1 does not fit in the 64KB limit if `Trusted Board Boot`_ (TBB) is enabled. To solve this problem, Socionext provides a first stage loader called `UniPhier BL`_. This loader runs @@ -23,35 +24,33 @@ the UniPhier BL. The concatenation of the UniPhier BL and the compressed BL1 fits in the 64KB limit. The concatenated image is loaded by the boot ROM (and verified if the chip fuses are blown). -:: - - to the lowest common denominator. Boot Flow --------- -#. The Boot ROM +1. The Boot ROM + + This is hard-wired ROM, so never corrupted. It loads the UniPhier BL (with + compressed-BL1 appended) into the on-chip SRAM. If the SoC fuses are blown, + the image is verified by the SoC's own method. -This is hard-wired ROM, so never corrupted. It loads the UniPhier BL (with -compressed-BL1 appended) into the on-chip SRAM. If the SoC fuses are blown, -the image is verified by the SoC's own method. +2. UniPhier BL -#. UniPhier BL + This runs in the on-chip SRAM. After the minimum SoC initialization and DRAM + setup, it decompresses the appended BL1 image into the DRAM, then jumps to + the BL1 entry. -This runs in the on-chip SRAM. After the minimum SoC initialization and DRAM -setup, it decompresses the appended BL1 image into the DRAM, then jumps to -the BL1 entry. +3. BL1 -#. BL1 + This runs in the DRAM. It extracts BL2 from FIP (Firmware Image Package). + If TBB is enabled, the BL2 is authenticated by the standard mechanism of ARM + Trusted Firmware. -This runs in the DRAM. It extracts BL2 from FIP (Firmware Image Package). -If TBB is enabled, the BL2 is authenticated by the standard mechanism of ARM -Trusted Firmware. +4. BL2, BL31, and more -#. BL2, BL31, and more + They all run in the DRAM, and are authenticated by the standard mechanism if + TBB is enabled. See `Firmware Design`_ for details. -They all run in the DRAM, and are authenticated by the standard mechanism if -TBB is enabled. See `Firmware Design`_ for details. Basic Build ----------- @@ -63,59 +62,52 @@ For a non-secure boot loader (aka BL33), U-Boot is well supported for UniPhier SoCs. The U-Boot image (``u-boot.bin``) must be built in advance. For the build procedure of U-Boot, refer to the document in the `U-Boot`_ project. -To build minimum functionality for UniPhier (without TBB): - -:: +To build minimum functionality for UniPhier (without TBB):: make CROSS_COMPILE=<gcc-prefix> PLAT=uniphier BL33=<path-to-BL33> bl1_gzip fip Output images: -- ``bl1.bin.gzip`` -- ``fip.bin`` +- ``bl1.bin.gzip`` +- ``fip.bin`` + Optional features ----------------- -- Trusted Board Boot +- Trusted Board Boot -`mbed TLS`_ is needed as the cryptographic and image parser modules. -Refer to the `User Guide`_ for the appropriate version of mbed TLS. + `mbed TLS`_ is needed as the cryptographic and image parser modules. + Refer to the `User Guide`_ for the appropriate version of mbed TLS. -To enable TBB, add the following options to the build command: - -:: + To enable TBB, add the following options to the build command:: TRUSTED_BOARD_BOOT=1 GENERATE_COT=1 MBEDTLS_DIR=<path-to-mbedtls> -- System Control Processor (SCP) - -If desired, FIP can include an SCP BL2 image. If BL2 finds an SCP BL2 image -in FIP, BL2 loads it into DRAM and kicks the SCP. Most of UniPhier boards -still work without SCP, but SCP provides better power management support. +- System Control Processor (SCP) -To include SCP\_BL2, add the following option to the build command: + If desired, FIP can include an SCP BL2 image. If BL2 finds an SCP BL2 image + in FIP, BL2 loads it into DRAM and kicks the SCP. Most of UniPhier boards + still work without SCP, but SCP provides better power management support. -:: + To include SCP BL2, add the following option to the build command:: SCP_BL2=<path-to-SCP> -- BL32 (Secure Payload) - -To enable BL32, add the following option to the build command: +- BL32 (Secure Payload) -:: + To enable BL32, add the following options to the build command:: SPD=<spd> BL32=<path-to-BL32> -If you use TSP for BL32, ``BL32=<path-to-BL32>`` is not required. Just add the -following: - -:: + If you use TSP for BL32, ``BL32=<path-to-BL32>`` is not required. Just add the + following:: SPD=tspd -.. _1: Some%20SoCs%20can%20load%2080KB,%20but%20the%20software%20implementation%20must%20be%20aligned + +.. [1] Some SoCs can load 80KB, but the software implementation must be aligned + to the lowest common denominator. .. _Trusted Board Boot: ../trusted-board-boot.rst .. _UniPhier BL: https://github.com/uniphier/uniphier-bl .. _Firmware Design: ../firmware-design.rst diff --git a/docs/porting-guide.rst b/docs/porting-guide.rst index 10a6da7e4..7683ded0e 100644 --- a/docs/porting-guide.rst +++ b/docs/porting-guide.rst @@ -549,6 +549,22 @@ behaviour of the ``assert()`` function (for example, to save memory). doesn't print anything to the console. If ``PLAT_LOG_LEVEL_ASSERT`` isn't defined, it defaults to ``LOG_LEVEL``. +If the platform port uses the Activity Monitor Unit, the following constants +may be defined: + +- **PLAT\_AMU\_GROUP1\_COUNTERS\_MASK** + This mask reflects the set of group counters that should be enabled. The + maximum number of group 1 counters supported by AMUv1 is 16 so the mask + can be at most 0xffff. If the platform does not define this mask, no group 1 + counters are enabled. If the platform defines this mask, the following + constant needs to also be defined. + +- **PLAT\_AMU\_GROUP1\_NR\_COUNTERS** + This value is used to allocate an array to save and restore the counters + specified by ``PLAT_AMU_GROUP1_COUNTERS_MASK`` on CPU suspend. + This value should be equal to the highest bit position set in the + mask, plus 1. The maximum number of group 1 counters in AMUv1 is 16. + File : plat\_macros.S [mandatory] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -1128,6 +1144,9 @@ This function executes with the MMU and data caches enabled. It is responsible for performing any remaining platform-specific setup that can occur after the MMU and data cache have been enabled. +if support for multiple boot sources is required, it initializes the boot +sequence used by plat\_try\_next\_boot\_source(). + In ARM standard platforms, this function initializes the storage abstraction layer used to load the next bootloader image. @@ -1624,6 +1643,70 @@ element in the boot sequence. If there are no more boot sources then it must return 0, otherwise it must return 1. The default implementation of this always returns 0. +Boot Loader Stage 2 (BL2) at EL3 +-------------------------------- + +When the platform has a non-TF Boot ROM it is desirable to jump +directly to BL2 instead of TF BL1. In this case BL2 is expected to +execute at EL3 instead of executing at EL1. Refer to the `Firmware +Design`_ for more information. + +All mandatory functions of BL2 must be implemented, except the functions +bl2\_early\_platform\_setup and bl2\_el3\_plat\_arch\_setup, because +their work is done now by bl2\_el3\_early\_platform\_setup and +bl2\_el3\_plat\_arch\_setup. These functions should generally implement +the bl1\_plat\_xxx() and bl2\_plat\_xxx() functionality combined. + + +Function : bl2\_el3\_early\_platform\_setup() [mandatory] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:: + Argument : u_register_t, u_register_t, u_register_t, u_register_t + Return : void + +This function executes with the MMU and data caches disabled. It is only called +by the primary CPU. This function receives four parameters which can be used +by the platform to pass any needed information from the Boot ROM to BL2. + +On ARM standard platforms, this function does the following: + +- Initializes a UART (PL011 console), which enables access to the ``printf`` + family of functions in BL2. + +- Initializes the storage abstraction layer used to load further bootloader + images. It is necessary to do this early on platforms with a SCP\_BL2 image, + since the later ``bl2_platform_setup`` must be done after SCP\_BL2 is loaded. + +- Initializes the private variables that define the memory layout used. + +Function : bl2\_el3\_plat\_arch\_setup() [mandatory] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:: + Argument : void + Return : void + +This function executes with the MMU and data caches disabled. It is only called +by the primary CPU. + +The purpose of this function is to perform any architectural initialization +that varies across platforms. + +On ARM standard platforms, this function enables the MMU. + +Function : bl2\_el3\_plat\_prepare\_exit() [optional] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +:: + Argument : void + Return : void + +This function is called prior to exiting BL2 and run the next image. +It should be used to perform platform specific clean up or bookkeeping +operations before transferring control to the next image. This function +runs with MMU disabled. + FWU Boot Loader Stage 2 (BL2U) ------------------------------ diff --git a/docs/secure-partition-manager-design.rst b/docs/secure-partition-manager-design.rst new file mode 100644 index 000000000..05d4e8bb6 --- /dev/null +++ b/docs/secure-partition-manager-design.rst @@ -0,0 +1,825 @@ +******************************* +Secure Partition Manager Design +******************************* + +.. section-numbering:: + :suffix: . + +.. contents:: + +Background +========== + +In some market segments that primarily deal with client-side devices like mobile +phones, tablets, STBs and embedded devices, a Trusted OS instantiates trusted +applications to provide security services like DRM, secure payment and +authentication. The Global Platform TEE Client API specification defines the API +used by Non-secure world applications to access these services. A Trusted OS +fulfils the requirements of a security service as described above. + +Management services are typically implemented at the highest level of privilege +in the system (i.e. EL3 in Arm Trusted Firmware). The service requirements are +fulfilled by the execution environment provided by Arm Trusted Firmware. + +The following diagram illustrates the corresponding software stack: + +|Image 1| + +In other market segments that primarily deal with server-side devices (e.g. data +centres and enterprise servers) the secure software stack typically does not +include a Global Platform Trusted OS. Security functions are accessed through +other interfaces (e.g. ACPI TCG TPM interface, UEFI runtime variable service). + +Placement of management and security functions with diverse requirements in a +privileged Exception Level (i.e. EL3 or S-EL1) makes security auditing of +firmware more difficult and does not allow isolation of unrelated services from +each other either. + +Introduction +============ + +A **Secure Partition** is a software execution environment instantiated in +S-EL0 that can be used to implement simple management and security services. +Since S-EL0 is an unprivileged Exception Level, a Secure Partition relies on +privileged firmware (i.e. Arm Trusted Firmware) to be granted access to system +and processor resources. Essentially, it is a software sandbox in the Secure +world that runs under the control of privileged software, provides one or more +services and accesses the following system resources: + +- Memory and device regions in the system address map. + +- PE system registers. + +- A range of synchronous exceptions (e.g. SMC function identifiers). + +Note that currently the Arm Trusted Firmware only supports handling one Secure +Partition. + +A Secure Partition enables Arm Trusted Firmware to implement only the essential +secure services in EL3 and instantiate the rest in a partition in S-EL0. +Furthermore, multiple Secure Partitions can be used to isolate unrelated +services from each other. + +The following diagram illustrates the place of a Secure Partition in a typical +ARMv8-A software stack. A single or multiple Secure Partitions provide secure +services to software components in the Non-secure world and other Secure +Partitions. + +|Image 2| + +The Arm Trusted Firmware build system is responsible for including the Secure +Partition image in the FIP. During boot, BL2 includes support to authenticate +and load the Secure Partition image. A BL31 component called **Secure Partition +Manager (SPM)** is responsible for managing the partition. This is semantically +similar to a hypervisor managing a virtual machine. + +The SPM is responsible for the following actions during boot: + +- Allocate resources requested by the Secure Partition. + +- Perform architectural and system setup required by the Secure Partition to + fulfil a service request. + +- Implement a standard interface that is used for initialising a Secure + Partition. + +The SPM is responsible for the following actions during runtime: + +- Implement a standard interface that is used by a Secure Partition to fulfil + service requests. + +- Implement a standard interface that is used by the Non-secure world for + accessing the services exported by a Secure Partition. A service can be + invoked through a SMC. + +Alternatively, a partition can be viewed as a thread of execution running under +the control of the SPM. Hence common programming concepts described below are +applicable to a partition. + +Description +=========== + +The previous section introduced some general aspects of the software +architecture of a Secure Partition. This section describes the specific choices +made in the current implementation of this software architecture. Subsequent +revisions of the implementation will include a richer set of features that +enable a more flexible architecture. + +Building Arm Trusted Firmware with Secure Partition support +----------------------------------------------------------- + +SPM is supported on the Arm FVP exclusively at the moment. The current +implementation supports inclusion of only a single Secure Partition in which a +service always runs to completion (e.g. the requested services cannot be +preempted to give control back to the Normal world). + +It is not currently possible for BL31 to integrate SPM support and a Secure +Payload Dispatcher (SPD) at the same time; they are mutually exclusive. In the +SPM bootflow, a Secure Partition image executing at S-EL0 replaces the Secure +Payload image executing at S-EL1 (e.g. a Trusted OS). Both are referred to as +BL32. + +A working prototype of a SP has been implemented by re-purposing the EDK2 code +and tools, leveraging the concept of the *Standalone Management Mode (MM)* in +the UEFI specification (see the PI v1.6 Volume 4: Management Mode Core +Interface). This will be referred to as the *Standalone MM Secure Partition* in +the rest of this document. + +To enable SPM support in the TF, the source code must be compiled with the build +flag ``ENABLE_SPM=1``. On Arm platforms the build option ``ARM_BL31_IN_DRAM`` +can be used to select the location of BL31, both SRAM and DRAM are supported. +Also, the location of the binary that contains the BL32 image +(``BL32=path/to/image.bin``) must be specified. + +First, build the Standalone MM Secure Partition. To build it, refer to the +`instructions in the EDK2 repository`_. + +Then build TF with SPM support and include the Standalone MM Secure Partition +image in the FIP: + +:: + + BL32=path/to/standalone/mm/sp BL33=path/to/bl33.bin \ + make PLAT=fvp ENABLE_SPM=1 fip all + +Describing Secure Partition resources +------------------------------------- + +Arm Trusted Firmware exports a porting interface that enables a platform to +specify the system resources required by the Secure Partition. Some instructions +are given below. However, this interface is under development and it may change +as new features are implemented. + +- A Secure Partition is considered a BL32 image, so the same defines that apply + to BL32 images apply to a Secure Partition: ``BL32_BASE`` and ``BL32_LIMIT``. + +- The following defines are needed to allocate space for the translation tables + used by the Secure Partition: ``PLAT_SP_IMAGE_MMAP_REGIONS`` and + ``PLAT_SP_IMAGE_MAX_XLAT_TABLES``. + +- The functions ``plat_get_secure_partition_mmap()`` and + ``plat_get_secure_partition_boot_info()`` have to be implemented. The file + ``plat/arm/board/fvp/fvp_common.c`` can be used as an example. It uses the + defines in ``include/plat/arm/common/arm_spm_def.h``. + + - ``plat_get_secure_partition_mmap()`` returns an array of mmap regions that + describe the memory regions that the SPM needs to allocate for a Secure + Partition. + + - ``plat_get_secure_partition_boot_info()`` returns a + ``secure_partition_boot_info_t`` struct that is populated by the platform + with information about the memory map of the Secure Partition. + +For an example of all the changes in context, you may refer to commit +``e29efeb1b4``, in which the port for FVP was introduced. + +Accessing Secure Partition services +----------------------------------- + +The `SMC Calling Convention`_ (*ARM DEN 0028B*) describes SMCs as a conduit for +accessing services implemented in the Secure world. The ``MM_COMMUNICATE`` +interface defined in the `Management Mode Interface Specification`_ (*ARM DEN +0060A*) is used to invoke a Secure Partition service as a Fast Call. + +The mechanism used to identify a service within the partition depends on the +service implementation. It is assumed that the caller of the service will be +able to discover this mechanism through standard platform discovery mechanisms +like ACPI and Device Trees. For example, *Volume 4: Platform Initialisation +Specification v1.6. Management Mode Core Interface* specifies that a GUID is +used to identify a management mode service. A client populates the GUID in the +``EFI_MM_COMMUNICATE_HEADER``. The header is populated in the communication +buffer shared with the Secure Partition. + +A Fast Call appears to be atomic from the perspective of the caller and returns +when the requested operation has completed. A service invoked through the +``MM_COMMUNICATE`` SMC will run to completion in the partition on a given CPU. +The SPM is responsible for guaranteeing this behaviour. This means that there +can only be a single outstanding Fast Call in a partition on a given CPU. + +Exchanging data with the Secure Partition +----------------------------------------- + +The exchange of data between the Non-secure world and the partition takes place +through a shared memory region. The location of data in the shared memory area +is passed as a parameter to the ``MM_COMMUNICATE`` SMC. The shared memory area +is statically allocated by the SPM and is expected to be either implicitly known +to the Non-secure world or discovered through a platform discovery mechanism +e.g. ACPI table or device tree. It is possible for the Non-secure world to +exchange data with a partition only if it has been populated in this shared +memory area. The shared memory area is implemented as per the guidelines +specified in Section 3.2.3 of the `Management Mode Interface Specification`_ +(*ARM DEN 0060A*). + +The format of data structures used to encapsulate data in the shared memory is +agreed between the Non-secure world and the Secure Partition. For example, in +the `Management Mode Interface specification`_ (*ARM DEN 0060A*), Section 4 +describes that the communication buffer shared between the Non-secure world and +the Management Mode (MM) in the Secure world must be of the type +``EFI_MM_COMMUNICATE_HEADER``. This data structure is defined in *Volume 4: +Platform Initialisation Specification v1.6. Management Mode Core Interface*. +Any caller of a MM service will have to use the ``EFI_MM_COMMUNICATE_HEADER`` +data structure. + +Runtime model of the Secure Partition +===================================== + +This section describes how the Secure Partition interfaces with the SPM. + +Interface with SPM +------------------ + +In order to instantiate one or more secure services in the Secure Partition in +S-EL0, the SPM should define the following types of interfaces: + +- Interfaces that enable access to privileged operations from S-EL0. These + operations typically require access to system resources that are either shared + amongst multiple software components in the Secure world or cannot be directly + accessed from an unprivileged Exception Level. + +- Interfaces that establish the control path between the SPM and the Secure + Partition. + +This section describes the APIs currently exported by the SPM that enable a +Secure Partition to initialise itself and export its services in S-EL0. These +interfaces are not accessible from the Non-secure world. + +Conduit +^^^^^^^ + +The `SMC Calling Convention`_ (*ARM DEN 0028B*) specification describes the SMC +and HVC conduits for accessing firmware services and their availability +depending on the implemented Exception levels. In S-EL0, the Supervisor Call +exception (SVC) is the only architectural mechanism available for unprivileged +software to make a request for an operation implemented in privileged software. +Hence, the SVC conduit must be used by the Secure Partition to access interfaces +implemented by the SPM. + +A SVC causes an exception to be taken to S-EL1. Arm Trusted Firmware assumes +ownership of S-EL1 and installs a simple exception vector table in S-EL1 that +relays a SVC request from a Secure Partition as a SMC request to the SPM in EL3. +Upon servicing the SMC request, Arm Trusted Firmware returns control directly to +S-EL0 through an ERET instruction. + +Calling conventions +^^^^^^^^^^^^^^^^^^^ + +The `SMC Calling Convention`_ (*ARM DEN 0028B*) specification describes the +32-bit and 64-bit calling conventions for the SMC and HVC conduits. The SVC +conduit introduces the concept of SVC32 and SVC64 calling conventions. The SVC32 +and SVC64 calling conventions are equivalent to the 32-bit (SMC32) and the +64-bit (SMC64) calling conventions respectively. + +Communication initiated by SPM +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A service request is initiated from the SPM through an exception return +instruction (ERET) to S-EL0. Later, the Secure Partition issues an SVC +instruction to signal completion of the request. Some example use cases are +given below: + +- A request to initialise the Secure Partition during system boot. + +- A request to handle a runtime service request. + +Communication initiated by Secure Partition +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +A request is initiated from the Secure Partition by executing a SVC instruction. +An ERET instruction is used by Arm Trusted Firmware to return to S-EL0 with the +result of the request. + +For instance, a request to perform privileged operations on behalf of a +partition (e.g. management of memory attributes in the translation tables for +the Secure EL1&0 translation regime). + +Interfaces +^^^^^^^^^^ + +The current implementation reserves function IDs for Fast Calls in the Standard +Secure Service calls range (see `SMC Calling Convention`_ (*ARM DEN 0028B*) +specification) for each API exported by the SPM. This section defines the +function prototypes for each function ID. The function IDs specify whether one +or both of the SVC32 and SVC64 calling conventions can be used to invoke the +corresponding interface. + +Secure Partition Event Management +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +The Secure Partition provides an Event Management interface that is used by the +SPM to delegate service requests to the Secure Partition. The interface also +allows the Secure Partition to: + +- Register with the SPM a service that it provides. +- Indicate completion of a service request delagated by the SPM + +Miscellaneous interfaces +------------------------ + +``SPM_VERSION_AARCH32`` +^^^^^^^^^^^^^^^^^^^^^^^ + +- Description + + Returns the version of the interface exported by SPM. + +- Parameters + + - **uint32** - Function ID + + - SVC32 Version: **0x84000060** + +- Return parameters + + - **int32** - Status + + On success, the format of the value is as follows: + + - Bit [31]: Must be 0 + - Bits [30:16]: Major Version. Must be 0 for this revision of the SPM + interface. + - Bits [15:0]: Minor Version. Must be 1 for this revision of the SPM + interface. + + On error, the format of the value is as follows: + + - ``NOT_SUPPORTED``: SPM interface is not supported or not available for the + client. + +- Usage + + This function returns the version of the Secure Partition Manager + implementation. The major version is 0 and the minor version is 1. The version + number is a 31-bit unsigned integer, with the upper 15 bits denoting the major + revision, and the lower 16 bits denoting the minor revision. The following + rules apply to the version numbering: + + - Different major revision values indicate possibly incompatible functions. + + - For two revisions, A and B, for which the major revision values are + identical, if the minor revision value of revision B is greater than the + minor revision value of revision A, then every function in revision A must + work in a compatible way with revision B. However, it is possible for + revision B to have a higher function count than revision A. + +- Implementation responsibilities + + If this function returns a valid version number, all the functions that are + described subsequently must be implemented, unless it is explicitly stated + that a function is optional. + +See `Error Codes`_ for integer values that are associated with each return +code. + +Secure Partition Initialisation +------------------------------- + +The SPM is responsible for initialising the architectural execution context to +enable initialisation of a service in S-EL0. The responsibilities of the SPM are +listed below. At the end of initialisation, the partition issues a +``SP_EVENT_COMPLETE_AARCH64`` call (described later) to signal readiness for +handling requests for services implemented by the Secure Partition. The +initialisation event is executed as a Fast Call. + +Entry point invocation +^^^^^^^^^^^^^^^^^^^^^^ + +The entry point for service requests that should be handled as Fast Calls is +used as the target of the ERET instruction to start initialisation of the Secure +Partition. + +Architectural Setup +^^^^^^^^^^^^^^^^^^^ + +At cold boot, system registers accessible from S-EL0 will be in their reset +state unless otherwise specified. The SPM will perform the following +architectural setup to enable execution in S-EL0 + +MMU setup +^^^^^^^^^ + +The platform port of a Secure Partition specifies to the SPM a list of regions +that it needs access to and their attributes. The SPM validates this resource +description and initialises the Secure EL1&0 translation regime as follows. + +1. Device regions are mapped with nGnRE attributes and Execute Never + instruction access permissions. + +2. Code memory regions are mapped with RO data and Executable instruction access + permissions. + +3. Read Only data memory regions are mapped with RO data and Execute Never + instruction access permissions. + +4. Read Write data memory regions are mapped with RW data and Execute Never + instruction access permissions. + +5. If the resource description does not explicitly describe the type of memory + regions then all memory regions will be marked with Code memory region + attributes. + +6. The ``UXN`` and ``PXN`` bits are set for regions that are not executable by + S-EL0 or S-EL1. + +System Register Setup +^^^^^^^^^^^^^^^^^^^^^ + +System registers that influence software execution in S-EL0 are setup by the SPM +as follows: + +1. ``SCTLR_EL1`` + + - ``UCI=1`` + - ``EOE=0`` + - ``WXN=1`` + - ``nTWE=1`` + - ``nTWI=1`` + - ``UCT=1`` + - ``DZE=1`` + - ``I=1`` + - ``UMA=0`` + - ``SA0=1`` + - ``C=1`` + - ``A=1`` + - ``M=1`` + +2. ``CPACR_EL1`` + + - ``FPEN=b'11`` + +3. ``PSTATE`` + + - ``D,A,I,F=1`` + - ``CurrentEL=0`` (EL0) + - ``SpSel=0`` (Thread mode) + - ``NRW=0`` (AArch64) + +General Purpose Register Setup +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +SPM will invoke the entry point of a service by executing an ERET instruction. +This transition into S-EL0 is special since it is not in response to a previous +request through a SVC instruction. This is the first entry into S-EL0. The +general purpose register usage at the time of entry will be as specified in the +"Return State" column of Table 3-1 in Section 3.1 "Register use in AArch64 SMC +calls" of the `SMC Calling Convention`_ (*ARM DEN 0028B*) specification. In +addition, certain other restrictions will be applied as described below. + +1. ``SP_EL0`` + + A non-zero value will indicate that the SPM has initialised the stack pointer + for the current CPU. + + The value will be 0 otherwise. + +2. ``X4-X30`` + + The values of these registers will be 0. + +3. ``X0-X3`` + + Parameters passed by the SPM. + + - ``X0``: Virtual address of a buffer shared between EL3 and S-EL0. The + buffer will be mapped in the Secure EL1&0 translation regime with read-only + memory attributes described earlier. + + - ``X1``: Size of the buffer in bytes. + + - ``X2``: Cookie value (*IMPLEMENTATION DEFINED*). + + - ``X3``: Cookie value (*IMPLEMENTATION DEFINED*). + +Runtime Event Delegation +------------------------ + +The SPM receives requests for Secure Partition services through a synchronous +invocation (i.e. a SMC from the Non-secure world). These requests are delegated +to the partition by programming a return from the last +``SP_EVENT_COMPLETE_AARCH64`` call received from the partition. The last call +was made to signal either completion of Secure Partition initialisation or +completion of a partition service request. + +``SP_EVENT_COMPLETE_AARCH64`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- Description + + Signal completion of the last SP service request. + +- Parameters + + - **uint32** - Function ID + + - SVC64 Version: **0xC4000061** + + - **int32** - Event Status Code + + Zero or a positive value indicates that the event was handled successfully. + The values depend upon the original event that was delegated to the Secure + partition. They are described as follows. + + - ``SUCCESS`` : Used to indicate that the Secure Partition was initialised + or a runtime request was handled successfully. + + - Any other value greater than 0 is used to pass a specific Event Status + code in response to a runtime event. + + A negative value indicates an error. The values of Event Status code depend + on the original event. + +- Return parameters + + - **int32** - Event ID/Return Code + + Zero or a positive value specifies the unique ID of the event being + delegated to the partition by the SPM. + + In the current implementation, this parameter contains the function ID of + the ``MM_COMMUNICATE`` SMC. This value indicates to the partition that an + event has been delegated to it in response to an ``MM_COMMUNICATE`` request + from the Non-secure world. + + A negative value indicates an error. The format of the value is as follows: + + - ``NOT_SUPPORTED``: Function was called from the Non-secure world. + + See `Error Codes`_ for integer values that are associated with each return + code. + + - **uint32** - Event Context Address + + Address of a buffer shared between the SPM and Secure Partition to pass + event specific information. The format of the data populated in the buffer + is implementation defined. + + The buffer is mapped in the Secure EL1&0 translation regime with read-only + memory attributes described earlier. + + For the SVC64 version, this parameter is a 64-bit Virtual Address (VA). + + For the SVC32 version, this parameter is a 32-bit Virtual Address (VA). + + - **uint32** - Event context size + + Size of the memory starting at Event Address. + + - **uint32/uint64** - Event Cookie + + This is an optional parameter. If unused its value is SBZ. + +- Usage + + This function signals to the SPM that the handling of the last event delegated + to a partition has completed. The partition is ready to handle its next event. + A return from this function is in response to the next event that will be + delegated to the partition. The return parameters describe the next event. + +- Caller responsibilities + + A Secure Partition must only call ``SP_EVENT_COMPLETE_AARCH64`` to signal + completion of a request that was delegated to it by the SPM. + +- Callee responsibilities + + When the SPM receives this call from a Secure Partition, the corresponding + syndrome information can be used to return control through an ERET + instruction, to the instruction immediately after the call in the Secure + Partition context. This syndrome information comprises of general purpose and + system register values when the call was made. + + The SPM must save this syndrome information and use it to delegate the next + event to the Secure Partition. The return parameters of this interface must + specify the properties of the event and be populated in ``X0-X3/W0-W3`` + registers. + +Secure Partition Memory Management +---------------------------------- + +A Secure Partition executes at S-EL0, which is an unprivileged Exception Level. +The SPM is responsible for enabling access to regions of memory in the system +address map from a Secure Partition. This is done by mapping these regions in +the Secure EL1&0 Translation regime with appropriate memory attributes. +Attributes refer to memory type, permission, cacheability and shareability +attributes used in the Translation tables. The definitions of these attributes +and their usage can be found in the `ARMv8 ARM`_ (*ARM DDI 0487*). + +All memory required by the Secure Partition is allocated upfront in the SPM, +even before handing over to the Secure Partition for the first time. The initial +access permissions of the memory regions are statically provided by the platform +port and should allow the Secure Partition to run its initialisation code. + +However, they might not suit the final needs of the Secure Partition because its +final memory layout might not be known until the Secure Partition initialises +itself. As the Secure Partition initialises its runtime environment it might, +for example, load dynamically some modules. For instance, a Secure Partition +could implement a loader for a standard executable file format (e.g. an PE-COFF +loader for loading executable files at runtime). These executable files will be +a part of the Secure Partition image. The location of various sections in an +executable file and their permission attributes (e.g. read-write data, read-only +data and code) will be known only when the file is loaded into memory. + +In this case, the Secure Partition needs a way to change the access permissions +of its memory regions. The SPM provides this feature through the +``SP_MEMORY_ATTRIBUTES_SET_AARCH64`` SVC interface. This interface is available +to the Secure Partition during a specific time window: from the first entry into +the Secure Partition up to the first ``SP_EVENT_COMPLETE`` call that signals the +Secure Partition has finished its initialisation. Once the initialisation is +complete, the SPM does not allow changes to the memory attributes. + +This section describes the standard SVC interface that is implemented by the SPM +to determine and change permission attributes of memory regions that belong to a +Secure Partition. + +``SP_MEMORY_ATTRIBUTES_GET_AARCH64`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- Description + + Request the permission attributes of a memory region from S-EL0. + +- Parameters + + - **uint32** Function ID + + - SVC64 Version: **0xC4000064** + + - **uint64** Base Address + + This parameter is a 64-bit Virtual Address (VA). + + There are no alignment restrictions on the Base Address. The permission + attributes of the translation granule it lies in are returned. + +- Return parameters + + - **int32** - Memory Attributes/Return Code + + On success the format of the Return Code is as follows: + + - Bits[1:0] : Data access permission + + - b'00 : No access + - b'01 : Read-Write access + - b'10 : Reserved + - b'11 : Read-only access + + - Bit[2]: Instruction access permission + + - b'0 : Executable + - b'1 : Non-executable + + - Bit[30:3] : Reserved. SBZ. + + - Bit[31] : Must be 0 + + On failure the following error codes are returned: + + - ``INVALID_PARAMETERS``: The Secure Partition is not allowed to access the + memory region the Base Address lies in. + + - ``NOT_SUPPORTED`` : The SPM does not support retrieval of attributes of + any memory page that is accessible by the Secure Partition, or the + function was called from the Non-secure world. Also returned if it is + used after ``SP_EVENT_COMPLETE_AARCH64``. + + See `Error Codes`_ for integer values that are associated with each return + code. + +- Usage + + This function is used to request the permission attributes for S-EL0 on a + memory region accessible from a Secure Partition. The size of the memory + region is equal to the Translation Granule size used in the Secure EL1&0 + translation regime. Requests to retrieve other memory region attributes are + not currently supported. + +- Caller responsibilities + + The caller must obtain the Translation Granule Size of the Secure EL1&0 + translation regime from the SPM through an implementation defined method. + +- Callee responsibilities + + The SPM must not return the memory access controls for a page of memory that + is not accessible from a Secure Partition. + +``SP_MEMORY_ATTRIBUTES_SET_AARCH64`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +- Description + + Set the permission attributes of a memory region from S-EL0. + +- Parameters + + - **uint32** - Function ID + + - SVC64 Version: **0xC4000065** + + - **uint64** - Base Address + + This parameter is a 64-bit Virtual Address (VA). + + The alignment of the Base Address must be greater than or equal to the size + of the Translation Granule Size used in the Secure EL1&0 translation + regime. + + - **uint32** - Page count + + Number of pages starting from the Base Address whose memory attributes + should be changed. The page size is equal to the Translation Granule Size. + + - **uint32** - Memory Access Controls + + - Bits[1:0] : Data access permission + + - b'00 : No access + - b'01 : Read-Write access + - b'10 : Reserved + - b'11 : Read-only access + + - Bit[2] : Instruction access permission + + - b'0 : Executable + - b'1 : Non-executable + + - Bits[31:3] : Reserved. SBZ. + + A combination of attributes that mark the region with RW and Executable + permissions is prohibited. A request to mark a device memory region with + Executable permissions is prohibited. + +- Return parameters + + - **int32** - Return Code + + - ``SUCCESS``: The Memory Access Controls were changed successfully. + + - ``DENIED``: The SPM is servicing a request to change the attributes of a + memory region that overlaps with the region specified in this request. + + - ``INVALID_PARAMETER``: An invalid combination of Memory Access Controls + has been specified. The Base Address is not correctly aligned. The Secure + Partition is not allowed to access part or all of the memory region + specified in the call. + + - ``NO_MEMORY``: The SPM does not have memory resources to change the + attributes of the memory region in the translation tables. + + - ``NOT_SUPPORTED``: The SPM does not permit change of attributes of any + memory region that is accessible by the Secure Partition. Function was + called from the Non-secure world. Also returned if it is used after + ``SP_EVENT_COMPLETE_AARCH64``. + + See `Error Codes`_ for integer values that are associated with each return + code. + +- Usage + + This function is used to change the permission attributes for S-EL0 on a + memory region accessible from a Secure Partition. The size of the memory + region is equal to the Translation Granule size used in the Secure EL1&0 + translation regime. Requests to change other memory region attributes are not + currently supported. + + This function is only available at boot time. This interface is revoked after + the Secure Partition sends the first ``SP_EVENT_COMPLETE_AARCH64`` to signal + that it is initialised and ready to receive run-time requests. + +- Caller responsibilities + + The caller must obtain the Translation Granule Size of the Secure EL1&0 + translation regime from the SPM through an implementation defined method. + +- Callee responsibilities + + The SPM must preserve the original memory access controls of the region of + memory in case of an unsuccessful call. The SPM must preserve the consistency + of the S-EL1 translation regime if this function is called on different PEs + concurrently and the memory regions specified overlap. + +Error Codes +----------- + +.. csv-table:: + :header: "Name", "Value" + + ``SUCCESS``,0 + ``NOT_SUPPORTED``,-1 + ``INVALID_PARAMETER``,-2 + ``DENIED``,-3 + ``NO_MEMORY``,-5 + ``NOT_PRESENT``,-7 + +-------------- + +*Copyright (c) 2017, Arm Limited and Contributors. All rights reserved.* + +.. _ARMv8 ARM: https://developer.arm.com/docs/ddi0487/latest/arm-architecture-reference-manual-armv8-for-armv8-a-architecture-profile +.. _instructions in the EDK2 repository: https://github.com/tianocore/edk2-staging/blob/AArch64StandaloneMm/HowtoBuild.MD +.. _Management Mode Interface Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0060a/DEN0060A_ARM_MM_Interface_Specification.pdf +.. _SDEI Specification: http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf +.. _SMC Calling Convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_SMC_Calling_Convention.pdf + +.. |Image 1| image:: diagrams/secure_sw_stack_tos.png +.. |Image 2| image:: diagrams/secure_sw_stack_sp.png diff --git a/docs/spm-user-guide.rst b/docs/spm-user-guide.rst deleted file mode 100644 index a3b64d931..000000000 --- a/docs/spm-user-guide.rst +++ /dev/null @@ -1,59 +0,0 @@ -ARM Trusted Firmware - SPM User Guide -===================================== - -.. section-numbering:: - :suffix: . - -.. contents:: - - -This document briefly presents the Secure Partition Management (SPM) support in -the Arm Trusted Firmware (TF), specifically focusing on how to build Arm TF with -SPM support. - -Overview of the SPM software stack ----------------------------------- - -SPM is supported on the Arm FVP exclusively at the moment. - -It is not currently possible for BL31 to integrate SPM support and a Secure -Payload Dispatcher (SPD) at the same time; they are mutually exclusive. In the -SPM bootflow, a Secure Partition (SP) image executing at Secure-EL0 replaces the -Secure Payload image executing at Secure-EL1 (e.g. a Trusted OS). Both are -referred to as BL32. - -A working prototype of a SP has been implemented by repurposing the EDK2 code -and tools, leveraging the concept of the *Standalone Management Mode (MM)* in -the UEFI specification (see the PI v1.6 Volume 4: Management Mode Core -Interface). This will be referred to as the *Standalone MM Secure Partition* in -the rest of this document. - - -Building TF with SPM support ----------------------------- - -To enable SPM support in the TF, the source code must be compiled with the build -flag ``ENABLE_SPM=1``. On Arm platforms the build option ``ARM_BL31_IN_DRAM`` -can be used to select the location of BL31, both SRAM and DRAM are supported. - - -Using the Standalone MM SP -~~~~~~~~~~~~~~~~~~~~~~~~~~ - -First, build the Standalone MM Secure Partition. To build it, refer to the -`instructions in the EDK2 repository`_. - -Then build TF with SPM support and include the Standalone MM Secure Partition -image in the FIP: - -:: - - BL32=path/to/standalone/mm/sp BL33=path/to/bl33.bin \ - make PLAT=fvp ENABLE_SPM=1 fip all - - --------------- - -*Copyright (c) 2017, ARM Limited and Contributors. All rights reserved.* - -.. _instructions in the EDK2 repository: https://github.com/tianocore/edk2-staging/blob/AArch64StandaloneMm/HowtoBuild.MD diff --git a/docs/user-guide.rst b/docs/user-guide.rst index 13f096419..ed5ba1842 100644 --- a/docs/user-guide.rst +++ b/docs/user-guide.rst @@ -55,7 +55,7 @@ command: sudo apt-get install build-essential gcc make git libssl-dev -ARM TF has been tested with `Linaro Release 17.04`_. +ARM TF has been tested with `Linaro Release 17.10`_. Download and install the AArch32 or AArch64 little-endian GCC cross compiler. The `Linaro Release Notes`_ documents which version of the compiler to use for a @@ -245,6 +245,9 @@ Common build options BL2U image. In this case, the BL2U in the ARM Trusted Firmware will not be built. +- ``BL2_AT_EL3``: This is an optional build option that enables the use of + BL2 at EL3 execution level. + - ``BL31``: This is an optional build option which specifies the path to BL31 image for the ``fip`` target. In this case, the BL31 in the ARM Trusted Firmware will not be built. @@ -1006,7 +1009,7 @@ images with support for these features: modules by checking out a recent version of the `mbed TLS Repository`_. It is important to use a version that is compatible with TF and fixes any known security vulnerabilities. See `mbed TLS Security Center`_ for more - information. The latest version of TF is tested with tag ``mbedtls-2.4.2``. + information. The latest version of TF is tested with tag ``mbedtls-2.6.0``. The ``drivers/auth/mbedtls/mbedtls_*.mk`` files contain the list of mbed TLS source files the modules depend upon. @@ -1475,10 +1478,10 @@ Running the software on FVP The latest version of the AArch64 build of ARM Trusted Firmware has been tested on the following ARM FVPs (64-bit host machine only). -NOTE: Unless otherwise stated, the model version is Version 11.1 Build 11.1.22. +NOTE: Unless otherwise stated, the model version is Version 11.2 Build 11.2.33. - ``Foundation_Platform`` -- ``FVP_Base_AEMv8A-AEMv8A`` (Version 8.7, Build 0.8.8702) +- ``FVP_Base_AEMv8A-AEMv8A`` (Version 9.0, Build 0.8.9005) - ``FVP_Base_Cortex-A35x4`` - ``FVP_Base_Cortex-A53x4`` - ``FVP_Base_Cortex-A57x4-A53x4`` @@ -1491,7 +1494,7 @@ NOTE: Unless otherwise stated, the model version is Version 11.1 Build 11.1.22. The latest version of the AArch32 build of ARM Trusted Firmware has been tested on the following ARM FVPs (64-bit host machine only). -- ``FVP_Base_AEMv8A-AEMv8A`` (Version 8.7, Build 0.8.8702) +- ``FVP_Base_AEMv8A-AEMv8A`` (Version 9.0, Build 0.8.9005) - ``FVP_Base_Cortex-A32x4`` NOTE: The build numbers quoted above are those reported by launching the FVP @@ -1868,10 +1871,10 @@ wakeup interrupt from RTC. .. _Linaro: `Linaro Release Notes`_ .. _Linaro Release: `Linaro Release Notes`_ -.. _Linaro Release Notes: https://community.arm.com/tools/dev-platforms/b/documents/posts/linaro-release-notes-deprecated -.. _Linaro Release 17.04: https://community.arm.com/tools/dev-platforms/b/documents/posts/linaro-release-notes-deprecated#LinaroRelease17.04 -.. _Linaro instructions: https://community.arm.com/dev-platforms/b/documents/posts/instructions-for-using-the-linaro-software-deliverables -.. _Instructions for using Linaro's deliverables on Juno: https://community.arm.com/dev-platforms/b/documents/posts/using-linaros-deliverables-on-juno +.. _Linaro Release Notes: https://community.arm.com/dev-platforms/w/docs/226/old-linaro-release-notes +.. _Linaro Release 17.10: https://community.arm.com/dev-platforms/w/docs/226/old-linaro-release-notes#1710 +.. _Linaro instructions: https://community.arm.com/dev-platforms/w/docs/304/linaro-software-deliverables +.. _Instructions for using Linaro's deliverables on Juno: https://community.arm.com/dev-platforms/w/docs/303/juno .. _ARM Platforms Portal: https://community.arm.com/dev-platforms/ .. _Development Studio 5 (DS-5): http://www.arm.com/products/tools/software-tools/ds-5/index.php .. _Dia: https://wiki.gnome.org/Apps/Dia/Download |
