Lines Matching full: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
11 the interrupt to either software in EL3 or Secure-EL1 depending upon the
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
21 knowledge of software executing in Secure-EL1/Secure-EL0. The choice of
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.
35 #. Secure EL1 interrupt. This type of interrupt can be routed to EL3 or
36 Secure-EL1 depending upon the security state of the current execution
37 context. It is always handled in Secure-EL1.
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
44 #. EL3 interrupt. This type of interrupt can be routed to EL3 or Secure-EL1
62 in the Secure Configuration Register at EL3 (``SCR_EL3.FIQ`` and ``SCR_EL3.IRQ``
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
95 Secure-EL1 interrupts
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
104 handover the interrupt to Secure-EL1 for handling.
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
113 can handover the interrupt to Secure-EL1 for handling.
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
127 the state of software in Secure-EL1/Secure-EL0 before handing the
128 interrupt to non-secure software. This model requires additional
129 coordination between Secure-EL1 and EL3 software to ensure that the
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
148 in Secure-EL1/Secure-EL0 is in control of how its execution is preempted
153 interrupts will always preempt Secure EL1/EL0 execution. See :ref:`exception
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
181 Arm GICv2 interrupt controller, Secure-EL1 interrupts are signaled through the
182 FIQ signal while Non-secure interrupts are signaled through the IRQ signal.
195 For example, in Arm GICv3, when the execution context is Secure-EL1/
196 Secure-EL0, both the EL3 and the non secure interrupt types map to the FIQ
199 route the FIQ signal to EL3 when executing in Secure-EL1/Secure-EL0, thereby
207 #. Although the framework has support for 2 types of secure interrupts (EL3
208 and Secure-EL1 interrupt), only interrupt controller architectures
210 Group 0 interrupts. In Arm GICv2, all secure interrupts are assumed to be
211 handled in Secure-EL1. They can be delivered to Secure-EL1 via EL3 but they
226 Both aspects of interrupt management involve various components in the secure
227 software stack spanning from EL3 to Secure-EL1. These components are described
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
262 is considered and it is assumed that the FIQ signal is used to generate Secure-EL1
263 interrupts and the IRQ signal is used to generate non-secure interrupts in either
270 following components of software running in EL3 and Secure-EL1. Each component is
275 #. Secure Payload Dispatcher (SPD) service. This service interfaces with the
276 Secure Payload (SP) software which runs in Secure-EL1/Secure-EL0 and is
277 responsible for switching execution between secure and non-secure states.
278 A switch is triggered by a Secure Monitor Call and it uses the APIs
282 the SPD service. TF-A implements an example Test Secure Payload Dispatcher
288 #. Secure Payload (SP). On a production system, the Secure Payload corresponds
289 to a Secure OS which runs in Secure-EL1/Secure-EL0. It interfaces with the
290 SPD service to manage communication with non-secure software. TF-A
291 implements an example secure payload called Test Secure Payload (TSP)
292 which runs only in Secure-EL1.
294 A Secure payload implementation could be common to some ports of TF-A,
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
349 particular type of interrupt. A Secure Payload Dispatcher service should use
350 this API to register a handler for Secure-EL1 and optionally for non-secure
398 Secure payload dispatcher
402 routing model supported by itself and the Secure Payload. It is also responsible
403 for ferrying interrupts between secure and non-secure software depending upon
413 The SPD should determine the mechanism to pass control to the Secure Payload
418 Test secure payload dispatcher behavior
425 The TSPD only handles Secure-EL1 interrupts and is provided with the following
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
430 i.e **CSS=0, TEL3=0** & **CSS=1, TEL3=1** for Secure-EL1 interrupts
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**.
446 #. It passes control to the Test Secure Payload to perform its
448 ``tsp_vectors`` in the SP which also includes the handler for Secure-EL1
450 this address when it receives a Secure-EL1 interrupt.
455 purpose, SP_EL1/Secure-EL0, LR, VFP and system registers. It can use
458 #. The TSPD implements a handler function for Secure-EL1 interrupts. This
475 implements a handler function for non-secure interrupts. This function is
484 set_interrupt_rm_flag(flags, SECURE);
493 Secure payload
496 A Secure Payload must implement an interrupt handling framework at Secure-EL1
497 (Secure-EL1 IHF) to support its chosen interrupt routing model. Secure payload
501 type is targeted to the FEL, then it will be routed to the Secure-EL1
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
509 in the routing model where **CSS=1 and TEL3=0**. Secure-EL1 interrupts
518 (see `Valid routing models`_) effects the implementation of the Secure-EL1
524 the FIQ signal is used to generate Secure-EL1 interrupts and the IRQ signal
525 is used to generate non-secure interrupts in either security state.
527 Secure payload IHF design w.r.t secure-EL1 interrupts
530 #. **CSS=0, TEL3=0**. If ``PSTATE.F=0``, Secure-EL1 interrupts will be
531 triggered at one of the Secure-EL1 FIQ exception vectors. The Secure-EL1
534 If ``PSTATE.F=1`` then Secure-EL1 interrupts will be handled as per the
536 by exporting a separate entrypoint for Secure-EL1 interrupts to the SPD
544 non-secure state. They should be handled through the synchronous interrupt
547 #. **CSS=0, TEL3=1**. Secure-EL1 interrupts are routed to EL3 when execution
548 is in secure state. They will not be visible to the SP. The ``PSTATE.F`` bit
549 in Secure-EL1/Secure-EL0 will not mask FIQs. The EL3 runtime firmware will
550 call the handler registered by the SPD service for Secure-EL1 interrupts.
551 Secure-EL1 IHF should then handle all Secure-EL1 interrupt through the
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
558 triggered at one of the Secure-EL1 IRQ exception vectors . The Secure-EL1
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
571 be visible to the SP. The ``PSTATE.I`` bit in Secure-EL1/Secure-EL0 will
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
581 A Secure Payload must also ensure that all Secure-EL1 interrupts are correctly
583 firmware. It should configure any additional Secure-EL1 interrupts which the EL3
586 Test secure payload behavior
589 The routing model for Secure-EL1 and non-secure interrupts chosen by the TSP is
590 described in Section `Secure Payload Dispatcher`__. It is known to the TSPD
595 The TSP implements an entrypoint (``tsp_sel1_intr_entry()``) for handling Secure-EL1
596 interrupts taken in non-secure state and routed through the TSPD service
602 exceptions taken at the same (Secure-EL1) exception level. This table is
606 The TSP also programs the Secure Physical Timer in the Arm Generic Timer block
645 #. Determining the type of interrupt. Secure-EL1 interrupts will be signaled
646 at the FIQ vector. Non-secure interrupts will be signaled at the IRQ
683 Secure payload dispatcher
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
704 interrupts are routed to S-EL1 when execution is in Secure state, then a
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
716 routed to the Secure Payload.
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
728 per the synchronous interrupt handling model it implements. A Secure-EL1
731 another higher priority Secure-EL1 interrupt or a EL3 interrupt. The SPD
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
749 When the Secure Payload has finished handling a Secure-EL1 interrupt, it could
751 should handle this secure monitor call so that execution resumes in the
752 exception level and the security state from where the Secure-EL1 interrupt was
755 Test secure payload dispatcher Secure-EL1 interrupt handling
758 The example TSPD service registers a handler for Secure-EL1 interrupts taken
759 from the non-secure state. During execution in S-EL1, the TSPD expects that the
760 Secure-EL1 interrupts are handled in S-EL1 by TSP. Its handler
761 ``tspd_secure_el1_interrupt_handler()`` expects only to be invoked for Secure-EL1
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
777 to re-enter TSP for Secure-EL1 interrupt processing. It does not need to
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
782 ``cm_el1_sysregs_context_restore(SECURE);``.
784 #. It ensures that the secure CPU context is used to program the next
785 exception return from EL3 by calling ``cm_set_next_eret_context(SECURE);``.
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
825 Secure-EL1 interrupt processing. When ``EL3_EXCEPTION_HANDLING`` is ``0``, only
826 non-secure interrupts can cause preemption of TSP since there are no EL3
828 interrupt may preempt Secure execution.
831 the TSP either for Secure-EL1 interrupt handling or for resuming the preempted
833 (See Section `Implication of preempted SMC on Non-Secure Software`_).
835 The non-secure interrupt triggered in Secure-EL1 during ``yielding`` SMC
836 processing can be routed to either EL3 or Secure-EL1 and is controlled by build
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
845 handling Secure-EL1 interrupts that triggered while execution was in the normal
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
853 trigger at Secure-EL1 IRQ exception vector. The TSP saves the general purpose
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
865 ``cm_el1_sysregs_context_save(SECURE)``.
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.
878 (see section `Implication of preempted SMC on Non-Secure Software`_). The TSPD
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
890 ``cm_el1_sysregs_context_restore(SECURE)``
892 #. It ensures that the secure CPU context is used to program the next
893 exception return from EL3 by calling ``cm_set_next_eret_context(SECURE)``.
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
906 Secure payload interrupt handling
911 chosen (as described in section :ref:`Secure Payload <sp-int-registration>`).
913 In the synchronous model, it should begin handling a Secure-EL1 interrupt after
916 should save any Secure-EL1 system register context which is needed for resuming
922 In the asynchronous model, the Secure Payload is responsible for handling
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
933 The TSPD hands control of a Secure-EL1 interrupt to the TSP at the
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
958 #. Secure-EL1 interrupts are handled by calling the ``tsp_common_int_handler()``
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`_).
972 Implication of preempted SMC on Non-Secure Software
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.
986 In the Test Secure Payload implementation, ``TSP_FID_RESUME`` is designated
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