- 13 Jul, 2018 1 commit
-
-
Sandrine Bailleux authored
Fix mismatches between the format specifier and the corresponding variable type. Change-Id: Ib9004bd9baa9ba24a50000bea4f2418e1bf7e743 Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
-
- 22 Jun, 2018 3 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
commit 2ccfcb2e ("SDEI: Determine client EL from NS context's SCR_EL3") intended to read from SCR_EL3, but wrongly read from SPSR_EL3 instead. This patch fixes that. Change-Id: I8ffea39cc98ef59cb8e7a4c6ef4cb12011c58536 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>
-
- 26 Mar, 2018 1 commit
-
-
Jonathan Wright authored
Ensure (where possible) that switch statements in services comply with MISRA rules 16.1 - 16.7. Change-Id: I47bf6ed4a026201e6fe125ce51842482e99e8bb0 Signed-off-by: Jonathan Wright <jonathan.wright@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>
-
- 14 Feb, 2018 1 commit
-
-
Antonio Nino Diaz authored
This fixes all defects according to MISRA Rule 3.1: "The character sequences /* and // shall not be used within a comment". This affects all URLs in comments, so they have been removed: - The link in `sdei_state.c` can also be found in the documentation file `docs/sdei.rst`. - The bug that the file `io_fip.c` talks about doesn't affect the currently supported version of GCC, so it doesn't make sense to keep the comment. Note that the version of GCC officially supported is the one that comes with Linaro Release 17.10, which is GCC 6.2. - The link in `tzc400.c` was broken, and it didn't correctly direct to the Technical Reference Manual it should. The link has been replaced by the title of the document, which is more convenient when looking for the document. Change-Id: I89f60c25f635fd4c008a5d3a14028f814c147bbe Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
-
- 06 Dec, 2017 1 commit
-
-
Jeenu Viswambharan authored
At present, both SDEI_PRIVATE_RESET and SDEI_SHARED_RESET returns SDEI_PENDING if they fail to unregister an event. The SDEI specification however requires that the APIs return SDEI_EDENY in these cases. This patch fixes the return codes for the reset APIs. Change-Id: Ic14484c91fa8396910387196c256d1ff13d03afd Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 20 Nov, 2017 2 commits
-
-
Jeenu Viswambharan authored
The SDEI specification requires that binding a client interrupt dispatches SDEI Normal priority event. This means that dynamic events can't have Critical priority. Add asserts for this. Change-Id: I0bdd9e0e642fb2b61810cb9f4cbfbd35bba521d1 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
Jeenu Viswambharan authored
Change-Id: Ic381ab5d03ec68c7f6e8d357ac2e2cbf0cc6b2e8 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
- 13 Nov, 2017 3 commits
-
-
Jeenu Viswambharan authored
Change-Id: Iee617a3528225349b6eede2f8abb26da96640678 Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
-
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>
-