Lines Matching refs:secure
8 #. It should be possible to route interrupts meant to be handled by secure
9 software (Secure interrupts) to EL3, when execution is in non-secure state
13 that secure interrupts are under the control of the secure software with
15 intervention from non-secure software.
18 non-secure software (Non-secure interrupts) to the last executed exception
19 level in the normal world when the execution is in secure world at
22 approach should be governed by the secure software. This requirement
23 ensures that non-secure software is able to execute in tandem with the
24 secure software without overriding it.
39 #. Non-secure interrupt. This type of interrupt can be routed to EL3,
40 Secure-EL1, Non-secure EL1 or EL2 depending upon the security state of the
41 current execution context. It is always handled in either Non-secure EL1
85 for GIC version 3.0 (Arm GICv3) and only the Secure-EL1 and Non-secure interrupt
90 #. **CSS**. Current Security State. ``0`` when secure and ``1`` when non-secure
99 secure state. This is a valid routing model as secure software is in
100 control of handling secure interrupts.
102 #. **CSS=0, TEL3=1**. Interrupt is routed to EL3 when execution is in secure
103 state. This is a valid routing model as secure software in EL3 can
107 non-secure state. This is an invalid routing model as a secure interrupt
108 is not visible to the secure software which violates the motivation behind
112 non-secure state. This is a valid routing model as secure software in EL3
115 Non-secure interrupts
119 secure state. This allows the secure software to trap non-secure
121 non-secure software through EL3. This is a valid routing model as secure
122 software is in control of how its execution is preempted by non-secure
125 #. **CSS=0, TEL3=1**. Interrupt is routed to EL3 when execution is in secure
126 state. This is a valid routing model as secure software in EL3 can save
128 interrupt to non-secure software. This model requires additional
133 non-secure state. This is a valid routing model as a non-secure interrupt
134 is handled by non-secure software.
137 non-secure state. This is an invalid routing model as there is no valid
139 non-secure software for handling.
147 Secure-EL1/Secure-EL0. This is a valid routing model as secure software
157 Secure-EL1/Secure-EL0. This is a valid routing model as secure software
161 non-secure state. This is an invalid routing model as a secure interrupt
162 is not visible to the secure software which violates the motivation behind
166 non-secure state. This is a valid routing model as secure software in EL3
182 FIQ signal while Non-secure interrupts are signaled through the IRQ signal.
196 Secure-EL0, both the EL3 and the non secure interrupt types map to the FIQ
207 #. Although the framework has support for 2 types of secure interrupts (EL3
210 Group 0 interrupts. In Arm GICv2, all secure interrupts are assumed to be
226 Both aspects of interrupt management involve various components in the secure
240 bits[1:0]. Bit[0] stores the routing model when execution is in the secure
241 state. Bit[1] stores the routing model when execution is in the non-secure
253 controller to distinguish between secure and non-secure interrupts. The platform
254 is expected to be aware of the secure devices present in the system and their
256 enable the secure interrupts, ensure that their priority is always higher than
257 the non-secure interrupts and target them to the primary CPU. It should also
263 interrupts and the IRQ signal is used to generate non-secure interrupts in either
277 responsible for switching execution between secure and non-secure states.
290 SPD service to manage communication with non-secure software. TF-A
291 implements an example secure payload called Test Secure Payload (TSP)
326 that it was in the non-secure state. A value of ``0`` indicates that it was
327 in the secure state. This bit can be used by the handler to ensure that
336 Once the handler routine completes, execution will return to either the secure
337 or non-secure state. The handler routine must return a pointer to
350 this API to register a handler for Secure-EL1 and optionally for non-secure
403 for ferrying interrupts between secure and non-secure software depending upon
418 Test secure payload dispatcher behavior
428 - Secure-EL1 interrupts are routed to EL3 when execution is in non-secure
429 state and are routed to the FEL when execution is in the secure state
433 model is used for non-secure interrupts. They are routed to the FEL in
435 Non-secure interrupts.
438 non secure interrupts are routed to EL3 when execution is in secure state
439 i.e **CSS=0, TEL3=1** for non-secure interrupts. This effectively preempts
440 Secure-EL1. The default routing model is used for non secure interrupts in
441 non-secure state. i.e **CSS=1, TEL3=0**.
475 implements a handler function for non-secure interrupts. This function is
503 handling interrupts. This mode applies to both Secure-EL1 and non-secure
508 non-secure state. Any non-secure interrupts will be handled as described
525 is used to generate non-secure interrupts in either security state.
527 Secure payload IHF design w.r.t secure-EL1 interrupts
544 non-secure state. They should be handled through the synchronous interrupt
548 is in secure state. They will not be visible to the SP. The ``PSTATE.F`` bit
554 Secure payload IHF design w.r.t non-secure interrupts
557 #. **CSS=0, TEL3=0**. If ``PSTATE.I=0``, non-secure interrupts will be
560 non-secure state where the interrupt should be handled e.g the SP could
563 non-secure interrupt. If this function identifier is not known to the SPD
567 If ``PSTATE.I=1`` then the non-secure interrupt will pend until execution
568 resumes in the non-secure state.
570 #. **CSS=0, TEL3=1**. Non-secure interrupts are routed to EL3. They will not
572 have not effect. The SPD service should register a non-secure interrupt
574 the non-secure state where the interrupt will be handled. The Secure-EL1
577 #. **CSS=1, TEL3=0**. Non-secure interrupts are handled in the FEL in
578 non-secure state (EL1/EL2) and are not visible to the SP. This routing
586 Test secure payload behavior
589 The routing model for Secure-EL1 and non-secure interrupts chosen by the TSP is
596 interrupts taken in non-secure state and routed through the TSPD service
646 at the FIQ vector. Non-secure interrupts will be signaled at the IRQ
701 An SPD service can register a handler for Secure-EL1 and/or Non-secure
702 interrupts. A non-secure interrupt should never be routed to EL3 from
703 from non-secure state. Also if a routing model is chosen where Secure-EL1
705 S-EL1 interrupt should never be routed to EL3 from secure state. The handler
709 routing model and interrupt type. For non secure and S-EL1 interrupt,
713 require a context switch from secure to non-secure or vice-versa:
715 #. A Secure-EL1 interrupt taken from the non-secure state should be
718 #. A non-secure interrupt taken from the secure state should be routed
719 to the last known non-secure exception level.
727 If the target state is secure then execution should be handed to the SP as
732 service should be able to handle this preemption or manage secure interrupt
739 The routing model allows non-secure interrupts to interrupt Secure-EL1 when in
740 secure state if it has been configured to do so. The SPD service and the SP
742 exception level in the non-secure state. The former should save the SP context,
743 restore the non-secure context and arrange for entry into the non-secure state
751 should handle this secure monitor call so that execution resumes in the
755 Test secure payload dispatcher Secure-EL1 interrupt handling
759 from the non-secure state. During execution in S-EL1, the TSPD expects that the
762 originating from the non-secure state. It takes the following actions upon being
766 that the secure interrupt originated from the non-secure state. It asserts
769 #. It saves the system register context for the non-secure state by calling
773 ``SPSR_EL3.DAIF`` bits in the secure CPU context. It sets ``x0`` to
775 secure interrupt during ``yielding`` SMC processing, save the registers that
778 save any other secure context since the TSP is expected to preserve it
779 (see section `Test secure payload dispatcher behavior`_).
781 #. It restores the system register context for the secure state by calling
784 #. It ensures that the secure CPU context is used to program the next
789 register for the non-secure state. This information is used by the SP for
793 when a Secure-EL1 interrupt is generated when execution is in the non-secure
804 #. It ensures that the call originated from the secure state otherwise
805 execution returns to the non-secure state with ``SMC_UNK`` in ``x0``.
808 the secure CPU context (see step 3 above) in case the TSP had been preempted
809 by a non secure interrupt earlier.
811 #. It restores the system register context for the non-secure state by
814 #. It ensures that the non-secure CPU context is used to program the next
817 #. ``tspd_smc_handler()`` returns a reference to the non-secure ``cpu_context``
820 Test secure payload dispatcher non-secure interrupt handling
823 The TSP in Secure-EL1 can be preempted by a non-secure interrupt during
826 non-secure interrupts can cause preemption of TSP since there are no EL3
835 The non-secure interrupt triggered in Secure-EL1 during ``yielding`` SMC
837 option ``TSP_NS_INTR_ASYNC_PREEMPT`` (see Section `Test secure payload
839 routing model for the non-secure interrupt to be routed to EL3 from secure state
841 non-secure interrupt handler. The ``tspd_ns_interrupt_handler()`` on being
842 invoked ensures that the interrupt originated from the secure state and disables
843 routing of non-secure interrupts from secure state to EL3. This is to prevent
844 further preemption (by a non-secure interrupt) when TSP is reentered for
850 routing model for non-secure interrupt in secure state is in effect
852 exceptions are unmasked i.e. ``PSTATE.I=0``, and a non-secure interrupt will
857 secure state otherwise execution returns to the non-secure state with
864 #. It saves the system register context for the secure state by calling
867 #. It restores the system register context for the non-secure state by
870 #. It ensures that the non-secure CPU context is used to program the next
873 #. ``SMC_PREEMPTED`` is set in x0 and return to non secure state after
874 restoring non secure context.
882 #. It ensures that the call originated from the non secure state. An
886 then saves the system register context for the non-secure state by calling
889 #. Restores the secure context by calling
892 #. It ensures that the secure CPU context is used to program the next
895 #. ``tspd_smc_handler()`` returns a reference to the secure ``cpu_context`` as the
898 The figure below describes how the TSP/TSPD handle a non-secure interrupt when
923 non-secure and Secure-EL1 interrupts at the IRQ and FIQ vectors in its exception
925 when a non-secure interrupt is generated, the SP should coordinate with the SPD
926 service to pass control back to the non-secure state in the last known exception
927 level. This will allow the non-secure interrupt to be handled in the non-secure
930 Test secure payload behavior
935 handover agreement described in Section `Test secure payload dispatcher
940 #. Checks whether the interrupt is the secure physical timer interrupt. It
942 interrupt number. If it is not the secure physical timer interrupt, then
947 #. Handles the secure timer interrupt interrupt by acknowledging it using the
949 ``tsp_generic_timer_handler()`` to reprogram the secure physical generic
961 #. Non-secure interrupts are handled by calling the ``tsp_common_int_handler()``
966 identifier from the non-secure state (see section `Test secure payload
967 dispatcher non-secure interrupt handling`_).
975 A ``yielding`` SMC call to Secure payload can be preempted by a non-secure
976 interrupt and the execution can return to the non-secure world for handling
979 must return back to the secure payload to resume the preempted SMC call.
989 secure software sequence for issuing a ``yielding`` SMC would look like this,
990 assuming ``P.STATE.I=0`` in the non secure state :
996 /* The pending non-secure interrupt is handled by the interrupt handler
1003 function invokes a SMC call with the required arguments. The pending non-secure
1005 exception vector handles the non-secure interrupt and returns. The return value