- 20 Aug, 2018 1 commit
-
-
Jeenu Viswambharan authored
These changes address most of the required MISRA rules. In the process, some from generic code is also fixed. No functional changes. Change-Id: I6235a355e006f0b1c7c1c4d811b3964a64d0434f Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 08 Jun, 2018 1 commit
-
-
Dimitris Papastamos authored
When dynamic mitigation is used, the SDEI handler is required to execute with the mitigation enabled by default, regardless of the mitigation state for lower ELs. This means that if the kernel or hypervisor explicitly disables the mitigation and then later when the event is dispatched, the dispatcher will remember the mitigation state for the lower ELs but force the mitigation to be on during the SDEI handler execution. When the SDEI handler returns, it will restore the mitigation state. This behaviour is described in "Firmware interfaces for mitigating cache speculation vulnerabilities System Software on Arm Systems"[0]. [0] https://developer.arm.com/cache-speculation-vulnerability-firmware-specification Change-Id: I8dd60b736be0aa9e832b0f92d67a401fdeb417f4 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 23 May, 2018 1 commit
-
-
Dimitris Papastamos authored
Some CPUS may benefit from using a dynamic mitigation approach for CVE-2018-3639. A new SMC interface is defined to allow software executing in lower ELs to enable or disable the mitigation for their execution context. It should be noted that regardless of the state of the mitigation for lower ELs, code executing in EL3 is always mitigated against CVE-2018-3639. NOTE: This change is a compatibility break for any platform using the declare_cpu_ops_workaround_cve_2017_5715 macro. Migrate to the declare_cpu_ops_wa macro instead. Change-Id: I3509a9337ad217bbd96de9f380c4ff8bf7917013 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 04 May, 2018 1 commit
-
-
Jeenu Viswambharan authored
At present, any External Abort routed to EL3 is reported as an unhandled exception and cause a panic. This patch enables ARM Trusted Firmware to handle External Aborts routed to EL3. With this patch, when an External Abort is received at EL3, its handling is delegated to plat_ea_handler() function. Platforms can provide their own implementation of this function. This patch adds a weak definition of the said function that prints out a message and just panics. In order to support handling External Aborts at EL3, the build option HANDLE_EA_EL3_FIRST must be set to 1. Before this patch, HANDLE_EA_EL3_FIRST wasn't passed down to compilation; this patch fixes that too. Change-Id: I4d07b7e65eb191ff72d63b909ae9512478cd01a1 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 29 Jan, 2018 1 commit
-
-
Dimitris Papastamos authored
In the initial implementation of this workaround we used a dedicated workaround context to save/restore state. This patch reduces the footprint as no additional context is needed. Additionally, this patch reduces the memory loads and stores by 20%, reduces the instruction count and exploits static branch prediction to optimize the SMC path. Change-Id: Ia9f6bf06fbf8a9037cfe7f1f1fb32e8aec38ec7d Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
-
- 11 Jan, 2018 1 commit
-
-
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>
-
- 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>
-
- 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 Oct, 2017 1 commit
-
-
David Cunado authored
Currently TF does not initialise the PMCR_EL0 register in the secure context or save/restore the register. In particular, the DP field may not be set to one to prohibit cycle counting in the secure state, even though event counting generally is prohibited via the default setting of MDCR_EL3.SMPE to 0. This patch initialises PMCR_EL0.DP to one in the secure state to prohibit cycle counting and also initialises other fields that have an architectually UNKNOWN reset value. Additionally, PMCR_EL0 is added to the list of registers that are saved and restored during a world switch. Similar changes are made for PMCR for the AArch32 execution state. NOTE: secure world code at lower ELs that assume other values in PMCR_EL0 will be impacted. Change-Id: Iae40e8c0a196d74053accf97063ebc257b4d2f3a Signed-off-by: David Cunado <david.cunado@arm.com>
-
- 22 Jun, 2017 1 commit
-
-
dp-arm authored
SPE is only supported in non-secure state. Accesses to SPE specific registers from SEL1 will trap to EL3. During a world switch, before `TTBR` is modified the SPE profiling buffers are drained. This is to avoid a potential invalid memory access in SEL1. SPE is architecturally specified only for AArch64. Change-Id: I04a96427d9f9d586c331913d815fdc726855f6b0 Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 15 Jun, 2017 1 commit
-
-
Varun Wadekar authored
This patch uses the U() and ULL() macros for constants, to fix some of the signed-ness defects flagged by the MISRA scanner. Signed-off-by: Varun Wadekar <vwadekar@nvidia.com>
-
- 03 May, 2017 1 commit
-
-
dp-arm authored
To make software license auditing simpler, use SPDX[0] license identifiers instead of duplicating the license text in every file. NOTE: Files that have been imported by FreeBSD have not been modified. [0]: https://spdx.org/ Change-Id: I80a00e1f641b8cc075ca5a95b10607ed9ed8761a Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
-
- 18 Jul, 2016 1 commit
-
-
Soby Mathew authored
This patch moves the PSCI services and BL31 frameworks like context management and per-cpu data into new library components `PSCI` and `el3_runtime` respectively. This enables PSCI to be built independently from BL31. A new `psci_lib.mk` makefile is introduced which adds the relevant PSCI library sources and gets included by `bl31.mk`. Other changes which are done as part of this patch are: * The runtime services framework is now moved to the `common/` folder to enable reuse. * The `asm_macros.S` and `assert_macros.S` helpers are moved to architecture specific folder. * The `plat_psci_common.c` is moved from the `plat/common/aarch64/` folder to `plat/common` folder. The original file location now has a stub which just includes the file from new location to maintain platform compatibility. Most of the changes wouldn't affect platform builds as they just involve changes to the generic bl1.mk and bl31.mk makefiles. NOTE: THE `plat_psci_common.c` FILE HAS MOVED LOCATION AND THE STUB FILE AT THE ORIGINAL LOCATION IS NOW DEPRECATED. PLATFORMS SHOULD MODIFY THEIR MAKEFILES TO INCLUDE THE FILE FROM THE NEW LOCATION. Change-Id: I6bd87d5b59424995c6a65ef8076d4fda91ad5e86
-