- 29 Jan, 2018 1 commit
-
-
Dimitris Papastamos authored
SMCCC v1.1 comes with a relaxed calling convention for AArch64 callers. The caller only needs to save x0-x3 before doing an SMC call. This patch adds support for SMCCC_VERSION and SMCCC_ARCH_FEATURES. Refer to "Firmware Interfaces for mitigating CVE_2017_5715 System Software on Arm Systems"[0] for more information. [0] https://developer.arm.com/-/media/developer/pdf/ARM%20DEN%200070A%20Firmware%20interfaces%20for%20mitigating%20CVE-2017-5715_V1.0.pdf Change-Id: If5b1c55c17d6c5c7cb9c2c3ed355d3a91cdad0a9 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 19 Jan, 2018 1 commit
-
-
Julius Werner authored
This patch adds the foundation for a platform-independent coreboot support library that can be shared by all platforms that boot BL31 from coreboot (acting as BL2). It adds code to parse the "coreboot table", a data structure that coreboot uses to communicate different kinds of information to later-stage firmware and certain OS drivers. As a first small use case for this information, allow platforms to access the serial console configuration used by coreboot, removing the need to hardcode base address and divisors and allowing Trusted Firmware to benefit from coreboot's user configuration (e.g. which UART to pick and which baud rate to use). Change-Id: I2bfb39cd2609ce6640b844ab68df6c9ae3f28e9e Signed-off-by: Julius Werner <jwerner@chromium.org>
-
- 18 Jan, 2018 3 commits
-
-
Dimitris Papastamos authored
A per-cpu vbar is installed that implements the workaround by invalidating the branch target buffer (BTB) directly in the case of A9 and A17 and indirectly by invalidating the icache in the case of A15. For Cortex A57 and A72 there is currently no workaround implemented when EL3 is in AArch32 mode so report it as missing. For other vulnerable CPUs (e.g. Cortex A73 and Cortex A75), there are no changes since there is currently no upstream AArch32 EL3 support for these CPUs. Change-Id: Ib42c6ef0b3c9ff2878a9e53839de497ff736258f Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
This patch introduces two workarounds for ARMv7 systems. The workarounds need to be applied prior to any `branch` instruction in secure world. This is achieved using a custom vector table where each entry is an `add sp, sp, #1` instruction. On entry to monitor mode, once the sequence of `ADD` instructions is executed, the branch target buffer (BTB) is invalidated. The bottom bits of `SP` are then used to decode the exception entry type. A side effect of this change is that the exception vectors are installed before the CPU specific reset function. This is now consistent with how it is done on AArch64. Note, on AArch32 systems, the exception vectors are typically tightly integrated with the secure payload (e.g. the Trusted OS). This workaround will need porting to each secure payload that requires it. The patch to modify the AArch32 per-cpu vbar to the corresponding workaround vector table according to the CPU type will be done in a later patch. Change-Id: I5786872497d359e496ebe0757e8017fa98f753fa Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Roberto Vargas authored
This patch enables BL2 to execute at the highest exception level without any dependancy on TF BL1. This enables platforms which already have a non-TF Boot ROM to directly load and execute BL2 and subsequent BL stages without need for BL1. This is not currently possible because BL2 executes at S-EL1 and cannot jump straight to EL3. Change-Id: Ief1efca4598560b1b8c8e61fbe26d1f44e929d69 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 16 Jan, 2018 1 commit
-
-
Masahiro Yamada authored
typedef mem_region_t mem_region_t; ... seems to work because they belong to different name-spaces, but humans are confused even if compilers are not. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
-
- 11 Jan, 2018 7 commits
-
-
Dimitris Papastamos authored
Change-Id: I504d3f65ca5829bc1f4ebadb764931f8379ee81f Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
On some systems, the AMU counters might reset to 0 when a CPU powerdown happens. This behaviour conflicts with the intended use-case of AMU as lower ELs are only expected to see non-decreasing counter values. Change-Id: If25519965d4e6e47e09225d0e732947986cbb5ec Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
Add some AMU helper functions to allow configuring, reading and writing of the Group 0 and Group 1 counters. Documentation for these helpers will come in a separate patch. Change-Id: I656e070d2dae830c22414f694aa655341d4e2c40 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
A new platform macro `PLAT_AMU_GROUP1_COUNTERS_MASK` controls which group 1 counters 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. A related platform macro `PLAT_AMU_GROUP1_NR_COUNTERS` is used by generic code to allocate an array to save and restore the counters on CPU suspend. Change-Id: I6d135badf4846292de931a43bb563077f42bb47b Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
The suspend hook is published at the start of a CPU powerdown operation. The resume hook is published at the end of a CPU powerup operation. Change-Id: I50c05e2dde0d33834095ac41b4fcea4c161bb434 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
If the CSV2 field reads as 1 then branch targets trained in one context cannot affect speculative execution in a different context. In that case skip the workaround on Cortex A75. Change-Id: I4d5504cba516a67311fb5f0657b08f72909cbd38 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
Invalidate the Branch Target Buffer (BTB) on entry to EL3 by temporarily dropping into AArch32 Secure-EL1 and executing the `BPIALL` instruction. This is achieved by using 3 vector tables. There is the runtime vector table which is used to handle exceptions and 2 additional tables which are required to implement this workaround. The additional tables are `vbar0` and `vbar1`. The sequence of events for handling a single exception is as follows: 1) Install vector table `vbar0` which saves the CPU context on entry to EL3 and sets up the Secure-EL1 context to execute in AArch32 mode with the MMU disabled and I$ enabled. This is the default vector table. 2) Before doing an ERET into Secure-EL1, switch vbar to point to another vector table `vbar1`. This is required to restore EL3 state when returning from the workaround, before proceeding with normal EL3 exception handling. 3) While in Secure-EL1, the `BPIALL` instruction is executed and an SMC call back to EL3 is performed. 4) On entry to EL3 from Secure-EL1, the saved context from step 1) is restored. The vbar is switched to point to `vbar0` in preparation to handle further exceptions. Finally a branch to the runtime vector table entry is taken to complete the handling of the original exception. This workaround is enabled by default on the affected CPUs. NOTE ==== There are 4 different stubs in Secure-EL1. Each stub corresponds to an exception type such as Sync/IRQ/FIQ/SError. Each stub will move a different value in `R0` before doing an SMC call back into EL3. Without this piece of information it would not be possible to know what the original exception type was as we cannot use `ESR_EL3` to distinguish between IRQs and FIQs. Change-Id: I90b32d14a3735290b48685d43c70c99daaa4b434 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 12 Dec, 2017 1 commit
-
-
Julius Werner authored
In assembly code it can be useful to have a constant for the width of a register in the current architecture, so this patch adds one to <utils_def.h> and replaces the existing custom one in crash_reporting.S with that. It also fixes up the BIT() macro in the same file so that it can be safely used in assembly code. Change-Id: I10513a311f3379e767396e6ddfbae8d2d8201464 Signed-off-by: Julius Werner <jwerner@chromium.org>
-
- 06 Dec, 2017 1 commit
-
-
Antonio Nino Diaz authored
A new platform define, `PLAT_SP_IMAGE_XLAT_SECTION_NAME`, has been introduced to select the section where the translation tables used by the S-EL1/S-EL0 are placed. This define has been used to move the translation tables to DRAM secured by TrustZone. Most of the extra needed space in BL31 when SPM is enabled is due to the large size of the translation tables. By moving them to this memory region we can save 44 KiB. A new argument has been added to REGISTER_XLAT_CONTEXT2() to specify the region where the translation tables have to be placed by the linker. Change-Id: Ia81709b4227cb8c92601f0caf258f624c0467719 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 30 Nov, 2017 1 commit
-
-
David Cunado authored
This patch adds a new build option, ENABLE_SVE_FOR_NS, which when set to one EL3 will check to see if the Scalable Vector Extension (SVE) is implemented when entering and exiting the Non-secure world. If SVE is implemented, EL3 will do the following: - Entry to Non-secure world: SIMD, FP and SVE functionality is enabled. - Exit from Non-secure world: SIMD, FP and SVE functionality is disabled. As SIMD and FP registers are part of the SVE Z-registers then any use of SIMD / FP functionality would corrupt the SVE registers. The build option default is 1. The SVE functionality is only supported on AArch64 and so the build option is set to zero when the target archiecture is AArch32. This build option is not compatible with the CTX_INCLUDE_FPREGS - an assert will be raised on platforms where SVE is implemented and both ENABLE_SVE_FOR_NS and CTX_INCLUDE_FPREGS are set to 1. Also note this change prevents secure world use of FP&SIMD registers on SVE-enabled platforms. Existing Secure-EL1 Payloads will not work on such platforms unless ENABLE_SVE_FOR_NS is set to 0. Additionally, on the first entry into the Non-secure world the SVE functionality is enabled and the SVE Z-register length is set to the maximum size allowed by the architecture. This includes the use case where EL2 is implemented but not used. Change-Id: Ie2d733ddaba0b9bef1d7c9765503155188fe7dae Signed-off-by: David Cunado <david.cunado@arm.com>
-
- 29 Nov, 2017 3 commits
-
-
Dimitris Papastamos authored
The `ENABLE_AMU` build option can be used to enable the architecturally defined AMU counters. At present, there is no support for the auxiliary counter group. Change-Id: Ifc7532ef836f83e629f2a146739ab61e75c4abc8 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
The `ENABLE_AMU` build option can be used to enable the architecturally defined AMU counters. At present, there is no support for the auxiliary counter group. Change-Id: I7ea0c0a00327f463199d1b0a481f01dadb09d312 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
Dimitris Papastamos authored
The Cortex A75 has 5 AMU counters. The first three counters are fixed and the remaining two are programmable. A new build option is introduced, `ENABLE_AMU`. When set, the fixed counters will be enabled for use by lower ELs. The programmable counters are currently disabled. Change-Id: I4bd5208799bb9ed7d2596e8b0bfc87abbbe18740 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 20 Nov, 2017 1 commit
-
-
Dimitris Papastamos authored
Factor out SPE operations in a separate file. Use the publish subscribe framework to drain the SPE buffers before entering secure world. Additionally, enable SPE before entering normal world. A side effect of this change is that the profiling buffers are now only drained when a transition from normal world to secure world happens. Previously they were drained also on return from secure world, which is unnecessary as SPE is not supported in S-EL1. Change-Id: I17582c689b4b525770dbb6db098b3a0b5777b70a Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 17 Nov, 2017 1 commit
-
-
Antonio Nino Diaz authored
If an implementation of ARMv8.2 includes ARMv8.2-LPA, the value 0b0110 is permitted in ID_AA64MMFR0_EL1.PARange, which means that the Physical Address range supported is 52 bits (4 PiB). It is a reserved value otherwise. Change-Id: Ie0147218e9650aa09f0034a9ee03c1cca8db908a Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 15 Nov, 2017 1 commit
-
-
David Cunado authored
The FPEXC32_EL2 register controls SIMD and FP functionality when the lower ELs are executing in AArch32 mode. It is architecturally mapped to AArch32 system register FPEXC. This patch removes FPEXC32_EL2 register from the System Register context and adds it to the floating-point context. EL3 only saves / restores the floating-point context if the build option CTX_INCLUDE_FPREGS is set to 1. The rationale for this change is that if the Secure world is using FP functionality and EL3 is not managing the FP context, then the Secure world will save / restore the appropriate FP registers. NOTE - this is a break in behaviour in the unlikely case that CTX_INCLUDE_FPREGS is set to 0 and the platform contains an AArch32 Secure Payload that modifies FPEXC, but does not save and restore this register Change-Id: Iab80abcbfe302752d52b323b4abcc334b585c184 Signed-off-by: David Cunado <david.cunado@arm.com>
-
- 13 Nov, 2017 2 commits
-
-
Jeenu Viswambharan authored
Provide a strong definition for plat_sdei_validate_sdei_entrypoint() which translates client address to Physical Address, and then validating the address to be present in DRAM. Change-Id: Ib93eb66b413d638aa5524d1b3de36aa16d38ea11 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
EHF is a framework that allows dispatching of EL3 interrupts to their respective handlers in EL3. This framework facilitates the firmware-first error handling policy in which asynchronous exceptions may be routed to EL3. Such exceptions may be handed over to respective exception handlers. Individual handlers might further delegate exception handling to lower ELs. The framework associates the delegated execution to lower ELs with a priority value. For interrupts, this corresponds to the priorities programmed in GIC; for other types of exceptions, viz. SErrors or Synchronous External Aborts, individual dispatchers shall explicitly associate delegation to a secure priority. In order to prevent lower priority interrupts from preempting higher priority execution, the framework provides helpers to control preemption by virtue of programming Priority Mask register in the interrupt controller. This commit allows for handling interrupts targeted at EL3. Exception handlers own interrupts by assigning them a range of secure priorities, and registering handlers for each priority range it owns. Support for exception handling in BL31 image is enabled by setting the build option EL3_EXCEPTION_HANDLING=1. Documentation to follow. NOTE: The framework assumes the priority scheme supported by platform interrupt controller is compliant with that of ARM GIC architecture (v2 or later). Change-Id: I7224337e4cea47c6ca7d7a4ca22a3716939f7e42 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 08 Nov, 2017 11 commits
-
-
Antonio Nino Diaz authored
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 e.g. ARM Trusted Firmware to be granted access to system and processor resources. Essentially, it is a software sandbox that runs under the control of privileged software in the Secure World and accesses the following system resources: - Memory and device regions in the system address map. - PE system registers. - A range of asynchronous exceptions e.g. interrupts. - A range of synchronous exceptions e.g. SMC function identifiers. A Secure Partition enables privileged firmware to implement only the absolutely essential secure services in EL3 and instantiate the rest in a partition. Since the partition executes in S-EL0, its implementation cannot be overly complex. The component in ARM Trusted Firmware responsible for managing a Secure Partition is called the Secure Partition Manager (SPM). The SPM is responsible for the following: - Validating and allocating resources requested by a Secure Partition. - Implementing a well defined interface that is used for initialising a Secure Partition. - Implementing a well defined interface that is used by the normal world and other secure services for accessing the services exported by a Secure Partition. - Implementing a well defined interface that is used by a Secure Partition to fulfil service requests. - Instantiating the software execution environment required by a Secure Partition to fulfil a service request. Change-Id: I6f7862d6bba8732db5b73f54e789d717a35e802f Co-authored-by: Douglas Raillard <douglas.raillard@arm.com> Co-authored-by: Sandrine Bailleux <sandrine.bailleux@arm.com> Co-authored-by: Achin Gupta <achin.gupta@arm.com> Co-authored-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com> Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Antonio Nino Diaz authored
This function can be useful to setup TCR_ELx by callers that don't use the translation tables library to setup the system registers related to them. By making it common, it can be reused whenever it is needed without duplicating code. Change-Id: Ibfada9e846d2a6cd113b1925ac911bb27327d375 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
Etienne Carriere authored
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
-
Etienne Carriere authored
ARMv7-A Virtualization extensions brings new instructions and resources that were supported by later architectures. Reference ARM ARM Issue C.c [DDI0406C_C]. ERET and extended MSR/MRS instructions, as specified in [DDI0406C_C] in ID_PFR1 description of bits[15:12] (Virtualization Extensions): A value of 0b0001 implies implementation of the HVC, ERET, MRS (Banked register), and MSR (Banked register) instructions. The ID_ISARs do not identify whether these instructions are implemented. UDIV/SDIV were introduced with the Virtualization extensions, even if not strictly related to the virtualization extensions. If ARMv7 based platform does not set ARM_CORTEX_Ax=yes, platform shall define ARMV7_SUPPORTS_VIRTUALIZATION to enable virtualization extension related resources. Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
-
Etienne Carriere authored
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
-
Etienne Carriere authored
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
-
Etienne Carriere authored
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
-
Etienne Carriere authored
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
-
Etienne Carriere authored
As Cortex-A9 needs to manually enable program flow prediction, do not reset SCTLR[Z] at entry. Platform should enable it only once MMU is enabled. Change-Id: I34e1ee2da73221903f7767f23bc6fc10ad01e3de Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
-
Etienne Carriere authored
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
-
Etienne Carriere authored
Signed-off-by: Etienne Carriere <etienne.carriere@linaro.org>
-
- 01 Nov, 2017 1 commit
-
-
Roberto Vargas authored
These macros are only defined for corresponding image, and they are undefined for other images. It means that we have to use ifdef or defined() instead of relying on being 0 by default. Change-Id: Iad11efab9830ddf471599b46286e1c56581ef5a7 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
-
- 31 Oct, 2017 2 commits
-
-
Joel Hutton authored
Change sizeof call so it references a static type instead of return of a function in order to be MISRA compliant. Change-Id: I6f1adb206073d6cd200156e281b8d76249e3af0e Signed-off-by: Joel Hutton <joel.hutton@arm.com>
-
Dimitris Papastamos authored
Add events that trigger before entry to normal/secure world. The events trigger after the normal/secure context has been restored. Similarly add events that trigger after leaving normal/secure world. The events trigger after the normal/secure context has been saved. Change-Id: I1b48a7ea005d56b1f25e2b5313d77e67d2f02bc5 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 23 Oct, 2017 2 commits
-
-
Jeenu Viswambharan authored
This allows other EL3 components to subscribe to CPU on events. Update Firmware Design guide to list psci_cpu_on_finish as an available event. Change-Id: Ida774afe0f9cdce4021933fcc33a9527ba7aaae2 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
This light-weight framework enables some EL3 components to publish events which other EL3 components can subscribe to. Publisher can optionally pass opaque data for subscribers. The order in which subscribers are called is not defined. Firmware design updated. Change-Id: I24a3a70b2b1dedcb1f73cf48313818aebf75ebb6 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-