summaryrefslogtreecommitdiff
path: root/bl31
AgeCommit message (Collapse)Author
2018-07-19RAS: Introduce handler for EL3 EAsJeenu Viswambharan
External Aborts while executing in EL3 is fatal in nature. This patch allows for the platform to define a handler for External Aborts received while executing in EL3. A default implementation is added which falls back to platform unhandled exception. Change-Id: I466f2c8113a33870f2c7d2d8f2bf20437d9fd354 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-07-19RAS: Introduce handler for Double FaultsJeenu Viswambharan
Double fault is when the PE receives another error whilst one is being handled. To detect double fault condition, a per-CPU flag is introduced to track the status of error handling. The flag is checked/modified while temporarily masking external aborts on the PE. This patch routes double faults to a separate platform-defined handler. Change-Id: I70e9b7ba4c817273c55a0af978d9755ff32cc702 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-07-19RAS: Introduce handler for Uncontainable errorsJeenu Viswambharan
Uncontainable errors are the most severe form of errors, which typically mean that the system state can't be trusted any more. This further means that normal error recovery process can't be followed, and an orderly shutdown of the system is often desirable. This patch allows for the platform to define a handler for Uncontainable errors received. Due to the nature of Uncontainable error, the handler is expected to initiate an orderly shutdown of the system, and therefore is not expected to return. A default implementation is added which falls back to platform unhandled exception. Also fix ras_arch.h header guards. Change-Id: I072e336a391a0b382e77e627eb9e40729d488b55 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-07-17RAS: Validate stack pointer after error handlingJeenu Viswambharan
RAS handling flows might involve using setjmp/longjump calls introduced in earlier patches; therefore, it'd be good to make sure the stack has been unwound completely after the handling. This patch inserts ASM assertions on the RAS handling path to validate stack. Change-Id: I59d40d3122010c977cdeab3cce3160f3909e7e69 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-07-17RAS: Move EA handling to a separate fileJeenu Viswambharan
A new file ea_delegate.S is introduced, and all EA-related functions are moved into it. This makes runtime_exceptions.S less crowded and reads better. No functional changes. Change-Id: I64b653b3931984cffd420563f8e8d1ba263f329f Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-07-11Add end_vector_entry assembler macroRoberto Vargas
Check_vector_size checks if the size of the vector fits in the size reserved for it. This check creates problems in the Clang assembler. A new macro, end_vector_entry, is added and check_vector_size is deprecated. This new macro fills the current exception vector until the next exception vector. If the size of the current vector is bigger than 32 instructions then it gives an error. Change-Id: Ie8545cf1003a1e31656a1018dd6b4c28a4eaf671 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-07-11Use ALIGN instead of NEXT in linker scriptsRoberto Vargas
Clang linker doesn't support NEXT. As we are not using the MEMORY command to define discontinuous memory for the output file in any of the linker scripts, ALIGN and NEXT are equivalent. Change-Id: I867ffb9c9a76d4e81c9ca7998280b2edf10efea0 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-06-27DynamIQ: Enable MMU without using stackJeenu Viswambharan
Having an active stack while enabling MMU has shown coherency problems. This patch builds on top of translation library changes that introduces MMU-enabling without using stacks. Previously, with HW_ASSISTED_COHERENCY, data caches were disabled while enabling MMU only because of active stack. Now that we can enable MMU without using stack, we can enable both MMU and data caches at the same time. NOTE: Since this feature depends on using translation table library v2, disallow using translation table library v1 with HW_ASSISTED_COHERENCY. Fixes ARM-software/tf-issues#566 Change-Id: Ie55aba0c23ee9c5109eb3454cb8fa45d74f8bbb2 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-06-21SDEI: Make dispatches synchronousJeenu Viswambharan
SDEI event dispatches currently only sets up the Non-secure context before returning to the caller. The actual dispatch only happens upon exiting EL3 next time. However, for various error handling scenarios, it's beneficial to have the dispatch happen synchronously. I.e. when receiving SDEI interrupt, or for a successful sdei_dispatch_event() call, the event handler is executed; and upon the event completion, dispatcher execution resumes after the point of dispatch. The jump primitives introduced in the earlier patch facilitates this feature. With this patch: - SDEI interrupts and calls to sdei_dispatch_event prepares the NS context for event dispatch, then sets a jump point, and immediately exits EL3. This results in the client handler executing in Non-secure. - When the SDEI client completes the dispatched event, the SDEI dispatcher does a longjmp to the jump pointer created earlier. For the caller of the sdei_dispatch_event() in particular, this would appear as if call returned successfully. The dynamic workaround for CVE_2018_3639 is slightly shifted around as part of related minor refactoring. It doesn't affect the workaround functionality. Documentation updated. NOTE: This breaks the semantics of the explicit dispatch API, and any exiting usages should be carefully reviewed. Change-Id: Ib9c876d27ea2af7fb22de49832e55a0da83da3f9 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-06-21BL31: Introduce jump primitivesJeenu Viswambharan
This patch introduces setjmp() and ongjmp() primitives to enable standard setjmp/longjmp style execution. Both APIs parameters take a pointer to struct jmpbuf type, which hosts CPU registers saved/restored during jump. As per the standard usage: - setjmp() return 0 when a jump is setup; and a non-zero value when returning from jump. - The caller of setjmp() must not return, or otherwise update stack pointer since. Change-Id: I4af1d32e490cfa547979631b762b4cba188d0551 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-06-13SPM: Treat SP xlat tables the same as othersSandrine Bailleux
The translation tables allocated for the Secure Partition do not need to be treated as a special case. They can be put amongst the other tables mapping BL31's general purpose memory. They will be mapped with the same attributes as them, which is fine. The explicit alignment constraint in BL31's linker script to pad the last page of memory allocated to the Secure Partition's translation tables is useless too, as page tables are per se pages, thus their end address is naturally aligned on a page-boundary. In fact, this patch does not change the existing behaviour. Since patch 22282bb68a31 ("SPM: Move all SP-related info to SP context struct"), the secure_partition.c file has been renamed into sp_xlat.c but the linker script has not been properly updated. As a result, the SP translation tables are not specifically put at the start of the xlat_table linker section, the __SP_IMAGE_XLAT_TABLES_START__/_END__ symbols have the same value, the size of the resulting mmap_region covering these xlat tables is 0 and so it is ignored. Change-Id: I4cf0a4cc090298811cca53fc9cee74df0f2b1512 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
2018-05-23Rename symbols and files relating to CVE-2017-5715Dimitris Papastamos
This patch renames symbols and files relating to CVE-2017-5715 to make it easier to introduce new symbols and files for new CVE mitigations. Change-Id: I24c23822862ca73648c772885f1690bed043dbc7 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2018-05-04AArch64: Introduce RAS handlingJeenu Viswambharan
RAS extensions are mandatory for ARMv8.2 CPUs, but are also optional extensions to base ARMv8.0 architecture. This patch adds build system support to enable RAS features in ARM Trusted Firmware. A boolean build option RAS_EXTENSION is introduced for this. With RAS_EXTENSION, an Exception Synchronization Barrier (ESB) is inserted at all EL3 vector entry and exit. ESBs will synchronize pending external aborts before entering EL3, and therefore will contain and attribute errors to lower EL execution. Any errors thus synchronized are detected via. DISR_EL1 register. When RAS_EXTENSION is set to 1, HANDLE_EL3_EA_FIRST must also be set to 1. Change-Id: I38a19d84014d4d8af688bd81d61ba582c039383a Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-05-04AArch64: Introduce External Abort handlingJeenu Viswambharan
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>
2018-05-04AArch64: Refactor GP register restore to separate functionJeenu Viswambharan
At present, the function that restores general purpose registers also does ERET. Refactor the restore code to restore general purpose registers without ERET to complement the save function. The macro save_x18_to_x29_sp_el0 was used only once, and is therefore removed, and its contents expanded inline for readability. No functional changes, but with this patch: - The SMC return path will incur an branch-return and an additional register load. - The unknown SMC path restores registers x0 to x3. Change-Id: I7a1a63e17f34f9cde810685d70a0ad13ca3b7c50 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-04-23Add support for the SMC Calling Convention 2.0Antonio Nino Diaz
Due to differences in the bitfields of the SMC IDs, it is not possible to support SMCCC 1.X and 2.0 at the same time. The behaviour of `SMCCC_MAJOR_VERSION` has changed. Now, it is a build option that specifies the major version of the SMCCC that the Trusted Firmware supports. The only two allowed values are 1 and 2, and it defaults to 1. The value of `SMCCC_MINOR_VERSION` is derived from it. Note: Support for SMCCC v2.0 is an experimental feature to enable prototyping of secure partition specifications. Support for this convention is disabled by default and could be removed without notice. Change-Id: I88abf9ccf08e9c66a13ce55c890edea54d9f16a7 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-03-14Fixup `SMCCC_ARCH_FEATURES` semanticsDimitris Papastamos
When querying `SMCCC_ARCH_WORKAROUND_1` through `SMCCC_ARCH_FEATURES`, return either: * -1 to indicate the PE on which `SMCCC_ARCH_FEATURES` is called requires firmware mitigation for CVE-2017-5715 but the mitigation is not compiled in. * 0 to indicate that firmware mitigation is required, or * 1 to indicate that no firmware mitigation is required. This patch complies with v1.2 of the firmware interfaces specification (ARM DEN 0070A). Change-Id: Ibc32d6620efdac6c340758ec502d95554a55f02a Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2018-03-01Suppress spurious deprecated declaration warningsDan Handley
Some generic compatibility functions emit deprecated declaration warnings even when platforms do not use the deprecated functions directly. This can be confusing. Suppress these warnings by using: `#pragma GCC diagnostic ignored "-Wdeprecated-declarations"` Also emit a runtime warning if the weak plat/common implemntation of plat_get_syscnt_freq2() is used, as this implies the platform has not migrated from plat_get_syscnt_freq(). The deprecated declaration warnings only help detect when platforms are calling deprecated functions, not when they are defining deprecated functions. Fixes ARM-software/tf-issues#550 Change-Id: Id14a92279c2634c1e76db8ef210da8affdbb2a5d Signed-off-by: Dan Handley <dan.handley@arm.com>
2018-02-28Merge pull request #1282 from robertovargas-arm/misra-changesdavidcunado-arm
Misra changes
2018-02-28Fix MISRA rule 8.4 in common codeRoberto Vargas
Rule 8.4: A compatible declaration shall be visible when an object or function with external linkage is defined. Change-Id: I26e042cb251a6f9590afa1340fdac73e42f23979 Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-02-28Fix MISRA rule 8.3 in common codeRoberto Vargas
Rule 8.3: All declarations of an object or function shall use the same names and type qualifiers. Change-Id: Iff384187c74a598a4e73f350a1893b60e9d16cec Signed-off-by: Roberto Vargas <roberto.vargas@arm.com>
2018-02-28Merge pull request #1286 from antonio-nino-diaz-arm/an/mmu-mismatchdavidcunado-arm
Clarify comments in xlat tables lib and fixes related to the TLB
2018-02-28Merge pull request #1284 from jeenu-arm/tspd-ehfdavidcunado-arm
TSPD and EHF
2018-02-27EHF: Introduce preempted return code parameter to ehf_allow_ns_preemption()Jeenu Viswambharan
When a Yielding SMC is preempted, it's possible that Non-secure world is resumed afterwards. In this case, Non-secure execution would find itself in a state where the SMC has returned. However, the dispatcher might not get an opportunity to populate the corrected return code for having been preempted, and therefore the caller of the Yielding SMC cannot reliably determine whether the SMC had successfully completed or had been preempted. To solve this, this patch introduces a new parameter to the ehf_allow_ns_preemption() API. An SPD, through this parameter, would provide the expected error code when a Yielding SMC is preempted. EHF can then populate the specified value in x0 of the Non-secure context so that the caller of the Yielding SMC correctly identifies the SMC return as a preemption. Documentation updates to follow. Change-Id: Ia9c3f8f03f9d72d81aa235eaae2ee0374b972e1e Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-02-27Add comments about mismatched TCR_ELx and xlat tablesAntonio Nino Diaz
When the MMU is enabled and the translation tables are mapped, data read/writes to the translation tables are made using the attributes specified in the translation tables themselves. However, the MMU performs table walks with the attributes specified in TCR_ELx. They are completely independent, so special care has to be taken to make sure that they are the same. This has to be done manually because it is not practical to have a test in the code. Such a test would need to know the virtual memory region that contains the translation tables and check that for all of the tables the attributes match the ones in TCR_ELx. As the tables may not even be mapped at all, this isn't a test that can be made generic. The flags used by enable_mmu_xxx() have been moved to the same header where the functions are. Also, some comments in the linker scripts related to the translation tables have been fixed. Change-Id: I1754768bffdae75f53561b1c4a5baf043b45a304 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-02-26Introduce the new BL handover interfaceSoby Mathew
This patch introduces a new BL handover interface. It essentially allows passing 4 arguments between the different BL stages. Effort has been made so as to be compatible with the previous handover interface. The previous blx_early_platform_setup() platform API is now deprecated and the new blx_early_platform_setup2() variant is introduced. The weak compatiblity implementation for the new API is done in the `plat_bl_common.c` file. Some of the new arguments in the new API will be reserved for generic code use when dynamic configuration support is implemented. Otherwise the other registers are available for platform use. Change-Id: Ifddfe2ea8e32497fe1beb565cac155ad9d50d404 Signed-off-by: Soby Mathew <soby.mathew@arm.com>
2018-02-20Merge pull request #1270 from antonio-nino-diaz-arm/an/smc-unknowndavidcunado-arm
Redefine SMC_UNK as -1 instead of 0xFFFFFFFF
2018-02-15Redefine SMC_UNK as -1 instead of 0xFFFFFFFFAntonio Nino Diaz
According to the SMC Calling Convention (ARM DEN0028B): The Unknown SMC Function Identifier is a sign-extended value of (-1) that is returned in R0, W0 or X0 register. The value wasn't sign-extended because it was defined as a 32-bit unsigned value (0xFFFFFFFF). SMC_PREEMPT has been redefined as -2 for the same reason. NOTE: This might be a compatibility break for some AArch64 platforms that don't follow the previous version of the SMCCC (ARM DEN0028A) correctly. That document specifies that only the bottom 32 bits of the returned value must be checked. If a platform relies on the top 32 bits of the result being 0 (so that SMC_UNK is 0x00000000FFFFFFFF), it will have to fix its code to comply with the SMCCC. Change-Id: I7f7b109f6b30c114fe570aa0ead3c335383cb54d Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2018-02-12EHF: Fix priority checkJeenu Viswambharan
When deactivating, it's not an error if the priority being deactivating is equal to the active priority. Fix this. Change-Id: I66f0e9e775ac9aba8a7cc48cd3ecd3b358be63c0 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2018-01-29Implement support for SMCCC v1.1Dimitris Papastamos
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>
2018-01-29runtime_exceptions: Save x4-x29 unconditionallyDimitris Papastamos
In preparation for SMCCC v1.1 support, save x4 to x29 unconditionally. Previously we expected callers coming from AArch64 mode to preserve x8-x17. This is no longer the case with SMCCC v1.1 as AArch64 callers only need to save x0-x3. Change-Id: Ie62d620776533969ff4a02c635422f1b9208be9c Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2018-01-24Merge pull request #1193 from jwerner-chromium/JW_corebootdavidcunado-arm
New console API and coreboot support [v4]
2018-01-12Merge pull request #1197 from dp-arm/dp/amudavidcunado-arm
AMUv1 support
2018-01-11AMU: Add configuration helpers for aarch64Dimitris Papastamos
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>
2018-01-11Workaround for CVE-2017-5715 on Cortex A73 and A75Dimitris Papastamos
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>
2018-01-11Workaround for CVE-2017-5715 on Cortex A57 and A72Dimitris Papastamos
Invalidate the Branch Target Buffer (BTB) on entry to EL3 by disabling and enabling the MMU. To achieve this without performing any branch instruction, a per-cpu vbar is installed which executes the workaround and then branches off to the corresponding vector entry in the main vector table. A side effect of this change is that the main vbar is configured before any reset handling. This is to allow the per-cpu reset function to override the vbar setting. This workaround is enabled by default on the affected CPUs. Change-Id: I97788d38463a5840a410e3cea85ed297a1678265 Signed-off-by: Dimitris Papastamos <dimitris.papastamos@arm.com>
2017-12-12utils_def: Add REGSZ and make BIT() assembly-compatibleJulius Werner
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>
2017-12-11Merge pull request #1178 from davidcunado-arm/dc/enable_svedavidcunado-arm
Enable SVE for Non-secure world
2017-11-30Enable SVE for Non-secure worldDavid Cunado
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>
2017-11-29Replace magic numbers in linkerscripts by PAGE_SIZEAntonio Nino Diaz
When defining different sections in linker scripts it is needed to align them to multiples of the page size. In most linker scripts this is done by aligning to the hardcoded value 4096 instead of PAGE_SIZE. This may be confusing when taking a look at all the codebase, as 4096 is used in some parts that aren't meant to be a multiple of the page size. Change-Id: I36c6f461c7782437a58d13d37ec8b822a1663ec1 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
2017-11-29AMU: Implement support for aarch64Dimitris Papastamos
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>
2017-11-20Refactor Statistical Profiling Extensions implementationDimitris Papastamos
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>
2017-11-15Move FPEXC32_EL2 to FP ContextDavid Cunado
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>
2017-11-13BL31: Add SDEI dispatcherJeenu Viswambharan
The implementation currently supports only interrupt-based SDEI events, and supports all interfaces as defined by SDEI specification version 1.0 [1]. Introduce the build option SDEI_SUPPORT to include SDEI dispatcher in BL31. Update user guide and porting guide. SDEI documentation to follow. [1] http://infocenter.arm.com/help/topic/com.arm.doc.den0054a/ARM_DEN0054A_Software_Delegated_Exception_Interface.pdf Change-Id: I758b733084e4ea3b27ac77d0259705565842241a Co-authored-by: Yousuf A <yousuf.sait@arm.com> Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-11-13BL31: Program Priority Mask for SMC handlingJeenu Viswambharan
On GICv3 systems, as a side effect of adding provision to handle EL3 interrupts (unconditionally routing FIQs to EL3), pending Non-secure interrupts (signalled as FIQs) may preempt execution in lower Secure ELs [1]. This will inadvertently disrupt the semantics of Fast SMC (previously called Atomic SMC) calls. To retain semantics of Fast SMCs, the GIC PMR must be programmed to prevent Non-secure interrupts from preempting Secure execution. To that effect, two new functions in the Exception Handling Framework subscribe to events introduced in an earlier commit: - Upon 'cm_exited_normal_world', the Non-secure PMR is stashed, and the PMR is programmed to the highest Non-secure interrupt priority. - Upon 'cm_entering_normal_world', the previously stashed Non-secure PMR is restored. The above sequence however prevents Yielding SMCs from being preempted by Non-secure interrupts as intended. To facilitate this, the public API exc_allow_ns_preemption() is introduced that programs the PMR to the original Non-secure PMR value. Another API exc_is_ns_preemption_allowed() is also introduced to check if exc_allow_ns_preemption() had been called previously. API documentation to follow. [1] On GICv2 systems, this isn't a problem as, unlike GICv3, pending NS IRQs during Secure execution are signalled as IRQs, which aren't routed to EL3. Change-Id: Ief96b162b0067179b1012332cd991ee1b3051dd0 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
2017-11-13BL31: Introduce Exception Handling FrameworkJeenu Viswambharan
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>
2017-11-08SPM: Introduce Secure Partition ManagerAntonio Nino Diaz
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>
2017-10-23BL31: Introduce Publish and Subscribe frameworkJeenu Viswambharan
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>
2017-08-21Fix x30 reporting for unhandled exceptionsJulius Werner
Some error paths that lead to a crash dump will overwrite the value in the x30 register by calling functions with the no_ret macro, which resolves to a BL instruction. This is not very useful and not what the reader would expect, since a crash dump should usually show all registers in the state they were in when the exception happened. This patch replaces the offending function calls with a B instruction to preserve the value in x30. Change-Id: I2a3636f2943f79bab0cd911f89d070012e697c2a Signed-off-by: Julius Werner <jwerner@chromium.org>
2017-07-12Fix order of #includesIsla Mitchell
This fix modifies the order of system includes to meet the ARM TF coding standard. There are some exceptions in order to retain header groupings, minimise changes to imported headers, and where there are headers within the #if and #ifndef statements. Change-Id: I65085a142ba6a83792b26efb47df1329153f1624 Signed-off-by: Isla Mitchell <isla.mitchell@arm.com>