Djam/arm-trusted-firmware
1
0
Fork 0
mirror of https://github.com/ARM-software/arm-trusted-firmware.git synced 2025-04-08 05:43:53 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions

docs(sdei): provide security guidelines when using SDEI

Browse source 
Signed-off-by: Manish Pandey <manish.pandey2@arm.com>
Signed-off-by: Jayanth Dodderi Chidanand <jayanthdodderi.chidanand@arm.com>
Change-Id: Ic27bdc88186f6805adee2f452503856e213a4710
This commit is contained in:
Manish Pandey 2024-01-11 16:06:29 +00:00
parent 514d022fda
commit 3e95bea5ec
1 changed files with 45 additions and 1 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

46
docs/components/sdei.rst
View file

@ -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