- 23 Jul, 2021 1 commit
-
-
Daniel Boulby authored
The SDEI specification now says that during an SDEI event handler dispatch the SPSR should be set according to the TakeException() pseudocode function defined in the Arm Architecture Reference Manual. This patch sets the SPSR according to the function given in ARM DDI 0487F.c page J1-7635 Change-Id: Id2f8f2464fd69c701d81626162827e5c4449b658 Signed-off-by: Daniel Boulby <daniel.boulby@arm.com>
-
- 08 Feb, 2019 1 commit
-
-
Antonio Nino Diaz authored
Instead of having a custom implementation of setjmp() and longjmp() it is better to follow the C standard. The comments in setjmp.h are no longer needed as there are no deviations from the expected one, so they have been removed. All SDEI code that relied on them has been fixed to use the new function prototypes and structs. Change-Id: I6cd2e21cb5a5bcf81ba12283f2e4c067bd5172ca Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 04 Jan, 2019 1 commit
-
-
Antonio Nino Diaz authored
Enforce full include path for includes. Deprecate old paths. The following folders inside include/lib have been left unchanged: - include/lib/cpus/${ARCH} - include/lib/el3_runtime/${ARCH} The reason for this change is that having a global namespace for includes isn't a good idea. It defeats one of the advantages of having folders and it introduces problems that are sometimes subtle (because you may not know the header you are actually including if there are two of them). For example, this patch had to be created because two headers were called the same way: e0ea0928 ("Fix gpio includes of mt8173 platform to avoid collision."). More recently, this patch has had similar problems: 46f9b2c3 ("drivers: add tzc380 support"). This problem was introduced in commit 4ecca339 ("Move include and source files to logical locations"). At that time, there weren't too many headers so it wasn't a real issue. However, time has shown that this creates problems. Platforms that want to preserve the way they include headers may add the removed paths to PLAT_INCLUDES, but this is discouraged. Change-Id: I39dc53ed98f9e297a5966e723d1936d6ccf2fc8f Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 26 Nov, 2018 1 commit
-
-
Jeenu Viswambharan authored
Secure world execution nearly always expect a controlled exit to Non-secure world. SDEI interrupts, although targets EL3, occur on behalf of Non-secure world, and may have higher priority than Secure world interrupts. Therefore they might preempt Secure execution, and yield execution to Non-secure SDEI handler. Upon completion of SDEI event handling (regardless of whether it's COPLETE or COMPLETE_AND_RESUME), we must resume Secure execution if it was preempted. Change-Id: I6edd991032588588427ba2fe6c3d7668f7080e3d Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 20 Aug, 2018 2 commits
-
-
Jeenu Viswambharan authored
The event lock for a shared event was being unlocked twice, and the locking sequence for event complete was misplaced. This patch fixes both issues. Change-Id: Ie2fb15c6ec240af132d7d438946ca160bd5c63dc Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
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>
-
- 22 Jun, 2018 2 commits
-
-
Jeenu Viswambharan authored
The function end_sdei_explicit_dispatch() was intended to be end_sdei_synchronous_dispatch() which does the opposite of begin_sdei_synchronous_dispatch(). This patch fixes that. No functional changes. Change-Id: I141bd91eb342ecf4ddfd05b49513eee4549e7a56 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
The Commit cdb6ac94 introduced a bug because of which the SDEI dispatcher wrongly panic when an SDEI event dispatched earlier as a result of interrupt. This patch fixes the check for a bound interrupt. Change-Id: If55c8f0422ff781731248bbbc9c1b59fa0d3c4b0 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 21 Jun, 2018 3 commits
-
-
Jeenu Viswambharan authored
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>
-
Jeenu Viswambharan authored
Currently, the dispatcher reads from SCR_EL3 register directly to determine the EL of SDEI client. This is with the assumption that SCR_EL3 is not modified throughout. However, with RAS work flows, it's possible that SCR_EL3 register contains values corresponding to Secure world, and therefore EL determination can go wrong. To mitigate this, always read the register from the saved Non-secure context. Change-Id: Ic85e4021deb18eb58757f676f9a001174998543a Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
The current macros only allow to define dynamic and statically-bound SDEI events. However, there ought be a mechanism to define SDEI events that are explicitly dispatched; i.e., events that are dispatched as a result of a previous secure interrupt or other exception This patch introduces SDEI_EXPLICIT_EVENT() macro to define an explicit event. They must be placed under private mappings. Only the priority flags are allowed to be additionally specified. Documentation updated. Change-Id: I2e12f5571381195d6234c9dfbd5904608ad41db3 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>
-
- 27 Feb, 2018 1 commit
-
-
Jeenu Viswambharan authored
Currently, when the client attempts to do SDEI_EVENT_COMPLETE or SDEI_EVENT_COMPLETE_AND_RESUME, the dispatcher pops off the outstanding dispatch context for sanity check. There are however other checks following this, which could potentially return failure. If that happens, by popping the context, the dispatcher has inadvertently discarded a valid context. This patch fixes this bug by inspecting (not actually popping) the outstanding context. The context is popped only after all error checks are completed. Change-Id: Ie199f6442f871a8177a8247a0c646543bad76d21 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 20 Nov, 2017 1 commit
-
-
Jeenu Viswambharan authored
Change-Id: Ic381ab5d03ec68c7f6e8d357ac2e2cbf0cc6b2e8 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 13 Nov, 2017 2 commits
-
-
Jeenu Viswambharan authored
This allows for other EL3 components to schedule an SDEI event dispatch to Normal world upon the next ERET. The API usage constrains are set out in the SDEI dispatcher documentation. Documentation to follow. Change-Id: Id534bae0fd85afc94523490098c81f85c4e8f019 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
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>
-