From 26ea390891154aaa3c0236f3c206342cc5d3fdc0 Mon Sep 17 00:00:00 2001 From: Jeenu Viswambharan Date: Wed, 10 Jan 2018 15:00:20 +0000 Subject: Deprecate one EL3 interrupt routing model with EL3 exception handling When ARM Trusted Firmware is built with EL3_EXCEPTION_HANDLING=1, EL3 interrupts (INTR_TYPE_EL3) will always preempt both Non-secure and secure execution. The interrupt management framework currently treats EL3 interrupt routing as valid. For the above reason, this patch makes them invalid when EL3_EXCEPTION_HANDLING is in effect. Change-Id: I95bca8f5dc8df8eb0ff6f305cfba098611522a39 Signed-off-by: Jeenu Viswambharan --- docs/interrupt-framework-design.rst | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'docs') diff --git a/docs/interrupt-framework-design.rst b/docs/interrupt-framework-design.rst index 940bc24f..d5654870 100644 --- a/docs/interrupt-framework-design.rst +++ b/docs/interrupt-framework-design.rst @@ -151,6 +151,10 @@ EL3 interrupts in Secure-EL1/Secure-EL0 is in control of how its execution is preempted by EL3 interrupt and can handover the interrupt to EL3 for handling. + However, when ``EL3_EXCEPTION_HANDLING`` is ``1``, this routing model is + invalid as EL3 interrupts are unconditionally routed to EL3, and EL3 + interrupts will always preempt Secure EL1/EL0 execution. + #. **CSS=0, TEL3=1**. Interrupt is routed to EL3 when execution is in Secure-EL1/Secure-EL0. This is a valid routing model as secure software in EL3 can handle the interrupt. -- cgit v1.2.3 From 6027796fff15f0d9c9dbd9aabe2bcc3daeebbd14 Mon Sep 17 00:00:00 2001 From: Jeenu Viswambharan Date: Thu, 11 Jan 2018 14:30:22 +0000 Subject: TSPD: Require NS preemption along with EL3 exception handling At present, the build option TSP_NS_INTR_ASYNC_PREEMPT controls how Non-secure interrupt affects TSPs execution. When TSP is executing: 1. When TSP_NS_INTR_ASYNC_PREEMPT=0, Non-secure interrupts are received at the TSP's exception vector, and TSP voluntarily preempts itself. 2. When TSP_NS_INTR_ASYNC_PREEMPT=1, Non-secure interrupts causes a trap to EL3, which preempts TSP execution. When EL3 exception handling is in place (i.e., EL3_EXCEPTION_HANDLING=1), FIQs are always trapped to EL3. On a system with GICv3, pending NS interrupts while TSP is executing will be signalled as FIQ (which traps to EL3). This situation necessitates the same treatment applied to case (2) above. Therefore, when EL3 exception handling is in place, additionally require that TSP_NS_INTR_ASYNC_PREEMPT is set to one 1. Strictly speaking, this is not required on a system with GICv2, but the same model is uniformly followed regardless, for simplicity. Relevant documentation updated. Change-Id: I928a8ed081fb0ac96e8b1dfe9375c98384da1ccd Signed-off-by: Jeenu Viswambharan --- docs/interrupt-framework-design.rst | 12 ++++++++---- docs/user-guide.rst | 5 ++++- 2 files changed, 12 insertions(+), 5 deletions(-) (limited to 'docs') diff --git a/docs/interrupt-framework-design.rst b/docs/interrupt-framework-design.rst index d5654870..f65e0559 100644 --- a/docs/interrupt-framework-design.rst +++ b/docs/interrupt-framework-design.rst @@ -419,6 +419,9 @@ runtime. Test secure payload dispatcher behavior ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +**Note:** where this document discusses ``TSP_NS_INTR_ASYNC_PREEMPT`` as being +``1``, the same results also apply when ``EL3_EXCEPTION_HANDLING`` is ``1``. + The TSPD only handles Secure-EL1 interrupts and is provided with the following routing model at build time. @@ -813,9 +816,10 @@ Test secure payload dispatcher non-secure interrupt handling The TSP in Secure-EL1 can be preempted by a non-secure interrupt during ``yielding`` SMC processing or by a higher priority EL3 interrupt during -Secure-EL1 interrupt processing. Currently only non-secure interrupts can -cause preemption of TSP since there are no EL3 interrupts in the -system. +Secure-EL1 interrupt processing. When ``EL3_EXCEPTION_HANDLING`` is ``0``, only +non-secure interrupts can cause preemption of TSP since there are no EL3 +interrupts in the system. With ``EL3_EXCEPTION_HANDLING=1`` however, any EL3 +interrupt may preempt Secure execution. It should be noted that while TSP is preempted, the TSPD only allows entry into the TSP either for Secure-EL1 interrupt handling or for resuming the preempted @@ -998,7 +1002,7 @@ TSP by returning ``SMC_UNK`` error. -------------- -*Copyright (c) 2014-2015, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2014-2018, ARM Limited and Contributors. All rights reserved.* .. _Porting Guide: ./porting-guide.rst .. _SMC calling convention: http://infocenter.arm.com/help/topic/com.arm.doc.den0028a/index.html diff --git a/docs/user-guide.rst b/docs/user-guide.rst index ed5ba184..8cf15b8e 100644 --- a/docs/user-guide.rst +++ b/docs/user-guide.rst @@ -617,6 +617,9 @@ Common build options interrupts to TSP allowing it to save its context and hand over synchronously to EL3 via an SMC. + Note: when ``EL3_EXCEPTION_HANDLING`` is ``1``, ``TSP_NS_INTR_ASYNC_PREEMPT`` + must also be set to ``1``. + - ``USE_COHERENT_MEM``: This flag determines whether to include the coherent memory region in the BL memory map or not (see "Use of Coherent memory in Trusted Firmware" section in `Firmware Design`_). It can take the value 1 @@ -1867,7 +1870,7 @@ wakeup interrupt from RTC. -------------- -*Copyright (c) 2013-2017, ARM Limited and Contributors. All rights reserved.* +*Copyright (c) 2013-2018, ARM Limited and Contributors. All rights reserved.* .. _Linaro: `Linaro Release Notes`_ .. _Linaro Release: `Linaro Release Notes`_ -- cgit v1.2.3 From fb750ee16112c7672ef605af35e174375c55fabc Mon Sep 17 00:00:00 2001 From: Jeenu Viswambharan Date: Wed, 10 Jan 2018 14:56:03 +0000 Subject: interrupt-framework-design.rst: Cosmetic changes Change-Id: Id2e2800af59ca35fc0c4cfdddd9f5c5afd56a4db Signed-off-by: Jeenu Viswambharan --- docs/interrupt-framework-design.rst | 21 +++++++++------------ 1 file changed, 9 insertions(+), 12 deletions(-) (limited to 'docs') diff --git a/docs/interrupt-framework-design.rst b/docs/interrupt-framework-design.rst index f65e0559..0eb7f54f 100644 --- a/docs/interrupt-framework-design.rst +++ b/docs/interrupt-framework-design.rst @@ -135,7 +135,7 @@ Non-secure interrupts former's state is correctly saved by the latter. #. **CSS=1, TEL3=0**. Interrupt is routed to FEL when execution is in - non-secure state. This is an valid routing model as a non-secure interrupt + non-secure state. This is a valid routing model as a non-secure interrupt is handled by non-secure software. #. **CSS=1, TEL3=1**. Interrupt is routed to EL3 when execution is in @@ -216,17 +216,14 @@ The framework makes the following assumptions to simplify its implementation. #. Interrupt exceptions (``PSTATE.I`` and ``F`` bits) are masked during execution in EL3. -#. .. rubric:: Interrupt management - :name: interrupt-management +#. Interrupt management: the following sections describe how interrupts are + managed by the interrupt handling framework. This entails: - The following sections describe how interrupts are managed by the interrupt - handling framework. This entails: + #. Providing an interface to allow registration of a handler and + specification of the routing model for a type of interrupt. -#. Providing an interface to allow registration of a handler and specification - of the routing model for a type of interrupt. - -#. Implementing support to hand control of an interrupt type to its registered - handler when the interrupt is generated. + #. Implementing support to hand control of an interrupt type to its + registered handler when the interrupt is generated. Both aspects of interrupt management involve various components in the secure software stack spanning from EL3 to Secure-EL1. These components are described @@ -685,14 +682,14 @@ the handler function for that type of interrupt. The SPD service is responsible for the following: #. Validating the interrupt. This involves ensuring that the interrupt was - generating according to the interrupt routing model specified by the SPD + generated according to the interrupt routing model specified by the SPD service during registration. It should use the security state of the exception level (passed in the ``flags`` parameter of the handler) where the interrupt was taken from to determine this. If the interrupt is not recognised then the handler should treat it as an irrecoverable error condition. - A SPD service can register a handler for Secure-EL1 and/or Non-secure + An SPD service can register a handler for Secure-EL1 and/or Non-secure interrupts. A non-secure interrupt should never be routed to EL3 from from non-secure state. Also if a routing model is chosen where Secure-EL1 interrupts are routed to S-EL1 when execution is in Secure state, then a -- cgit v1.2.3