SDEI: Make dispatches synchronous
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>
diff --git a/docs/sdei.rst b/docs/sdei.rst
index ed6a85a..531145f 100644
--- a/docs/sdei.rst
+++ b/docs/sdei.rst
@@ -233,14 +233,10 @@
::
- int sdei_dispatch_event(int ev_num, unsigned int preempted_sec_state);
+ int sdei_dispatch_event(int ev_num);
-- The parameter ``ev_num`` is the event number to dispatch;
-
-- The parameter ``preempted_sec_state`` indicates the context that was
- preempted. This must be either ``SECURE`` or ``NON_SECURE``.
-
-The API returns ``0`` on success, or ``-1`` on failure.
+The parameter ``ev_num`` is the event number to dispatch. The API returns ``0``
+on success, or ``-1`` on failure.
The following figure depicts a scenario involving explicit dispatch of SDEI
event. A commentary is provided below:
@@ -253,22 +249,18 @@
bound or dynamic events can't be explicitly dispatched (see the section below).
At a later point in time, a critical event [#critical-event]_ is trapped into
-EL3 [7]. EL3 performs a first-level triage of the event, and decides to dispatch
-to a Secure Partition [#secpart]_ for further handling [8]. The dispatch
-completes, but intends to involve Non-secure world in further handling, and
-therefore decides to explicitly dispatch an event [10] (which the client had
-already registered for [1]). The rest of the sequence is similar to that in the
-`general SDEI dispatch`_: the requested event is dispatched to the client
-(assuming all the conditions are met), and when the handler completes, the
-preempted execution resumes.
+EL3 [7]. EL3 performs a first-level triage of the event, and a RAS component
+assumes further handling [8]. The dispatch completes, but intends to involve
+Non-secure world in further handling, and therefore decides to explicitly
+dispatch an event [10] (which the client had already registered for [1]). The
+rest of the sequence is similar to that in the `general SDEI dispatch`_: the
+requested event is dispatched to the client (assuming all the conditions are
+met), and when the handler completes, the preempted execution resumes.
.. [#critical-event] Examples of critical event are *SError*, *Synchronous
External Abort*, *Fault Handling interrupt*, or *Error
Recovery interrupt* from one of RAS nodes in the system.
-.. [#secpart] Dispatching to Secure Partition involves *Secure Partition
- Manager*, which isn't depicted in the sequence.
-
Conditions for event dispatch
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -302,28 +294,22 @@
Further, the caller should be aware of the following assumptions made by the
dispatcher:
-- The caller of the API is a component running in EL3; for example, the *Secure
- Partition Manager*.
+- The caller of the API is a component running in EL3; for example, a RAS
+ driver.
- The requested dispatch will be permitted by the Exception Handling Framework.
I.e. the caller must make sure that the requested dispatch has sufficient
priority so as not to cause priority level inversion within Exception
Handling Framework.
-- At the time of the call, the active context is Secure, and it has been saved.
+- The caller must be prepared for the SDEI dispatcher to restore the Non-secure
+ context, and mark that the active context.
-- Upon returning success, the Non-secure context will be restored and setup for
- the event dispatch, and it will be the active context. The Non-secure context
- should not be modified further by the caller.
-
-- The API returning success only means that the dispatch is scheduled at the
- next ``ERET``, and not immediately performed. Also, the caller must be
- prepared for this API to return failure and handle accordingly.
+- The call will block until the SDEI client completes the event (i.e. when the
+ client calls either ``SDEI_EVENT_COMPLETE`` or ``SDEI_COMPLETE_AND_RESUME``).
-- Upon completing the event (i.e. when the client calls either
- ``SDEI_EVENT_COMPLETE`` or ``SDEI_COMPLETE_AND_RESUME``), the preempted
- context is resumed (as indicated by the ``preempted_sec_state`` parameter of
- the API).
+- The caller must be prepared for this API to return failure and handle
+ accordingly.
Porting requirements
--------------------