mirror of
https://github.com/ARM-software/arm-trusted-firmware.git
synced 2025-04-15 17:14:21 +00:00
Merge "docs(sdei): provide security guidelines when using SDEI" into integration
This commit is contained in:
commit
b11d8b824b
1 changed files with 45 additions and 1 deletions
|
@ -354,7 +354,51 @@ implemented in assembly, following a similar pattern as below:
|
||||||
|
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
*Copyright (c) 2017-2019, Arm Limited and Contributors. All rights reserved.*
|
Security Considerations
|
||||||
|
-----------------------
|
||||||
|
|
||||||
|
SDEI introduces concept of providing software based non-maskable interrupts to
|
||||||
|
Hypervisor/OS. In doing so, it modifies the priority scheme defined by Interrupt
|
||||||
|
controllers and relies on Non-Secure clients, Hypervisor or OS, to create/manage
|
||||||
|
high priority events.
|
||||||
|
|
||||||
|
Considering a Non-secure client is involved in SDEI state management, there exists
|
||||||
|
some security considerations which needs to be taken care of in both client and EL3
|
||||||
|
when using SDEI. Few of them are mentioned below.
|
||||||
|
|
||||||
|
Bound events
|
||||||
|
~~~~~~~~~~~~
|
||||||
|
|
||||||
|
A bound event is an SDEI event that corresponds to a client interrupt.
|
||||||
|
The binding of event is done using ``SDEI_INTERRUPT_BIND`` SMC call to associate
|
||||||
|
an SDEI event with a client interrupt. There is a possibility that a rogue
|
||||||
|
client can request an invalid interrupt to be bound. This may potentially
|
||||||
|
cause out-of-bound memory read.
|
||||||
|
|
||||||
|
Even though TF-A implementation has checks to ensure that interrupt ID passed
|
||||||
|
by client is architecturally valid, Non-secure client should also ensure the
|
||||||
|
validity of interrupts.
|
||||||
|
|
||||||
|
Recurring events
|
||||||
|
~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
For a given event source, if the events are generated continuously, then NS client
|
||||||
|
may be unusable. To mitigate against this, the Non-secure client must have
|
||||||
|
mechanism in place to remove such interrupt source from the system.
|
||||||
|
|
||||||
|
One of the examples is a memory region which continuously generates RAS errors.
|
||||||
|
This may result in unusable Non-secure client.
|
||||||
|
|
||||||
|
Dispatched events
|
||||||
|
~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
For a dispatched event, it is the client's responsibility to ensure that the
|
||||||
|
handling finishes in finite time and notify the dispatcher through
|
||||||
|
``SDEI_EVENT_COMPLETE`` or ``SDEI_EVENT_COMPLETE_AND_RESUME``. If the client
|
||||||
|
fails to complete the event handling, it might result in ``UNPREDICTABLE`` behavior
|
||||||
|
in the client and potentially end up in unusable PE.
|
||||||
|
|
||||||
|
*Copyright (c) 2017-2024, Arm Limited and Contributors. All rights reserved.*
|
||||||
|
|
||||||
.. rubric:: Footnotes
|
.. rubric:: Footnotes
|
||||||
|
|
||||||
|
|
Loading…
Add table
Reference in a new issue