Lines Matching full:secure
1 Secure Partition Manager
42 | SP | Secure Partition |
44 | SPD | Secure Payload Dispatcher |
46 | SPM | Secure Partition Manager |
54 | SWd | Secure World |
66 Two implementations of a Secure Partition Manager co-exist in the TF-A codebase:
76 - describes the FF-A implementation where the Secure Partition Manager
81 used as a reference code base for an S-EL2 secure firmware on
82 platforms implementing the FEAT_SEL2 (formerly Armv8.4 Secure EL2)
90 - The term SPMC refers to the S-EL2 component managing secure partitions in
91 the secure world when the FEAT_SEL2 architecture extension is implemented.
92 - Alternatively, SPMC can refer to an S-EL1 component, itself being a secure
96 - The term SP refers to a secure world "Virtual Machine" managed by an SPMC.
120 and SPMC, one or multiple secure partitions, with an optional
134 enable another Secure Payload Dispatcher when this option is chosen.
145 (see `Describing secure partitions`_). It
147 secure partitions are to be loaded on behalf of the SPMC.
172 the Hafnium binary path (built for the secure world) or the path to a TEE
209 Same as above with enabling secure boot in addition:
280 Loading Hafnium and secure partitions in the secure world
283 TF-A BL2 is the bootlader for the SPMC and SPs in the secure world.
301 Secure Partition packages
304 Secure partitions are bundled as independent package files consisting
323 Secure Payload BL32 (Trusted OS): offset=0x1BCD1, size=0x15270, cmdline="--tos-fw"
333 .. uml:: ../resources/diagrams/plantuml/fip-secure-partitions.puml
335 Describing secure partitions
371 SP that co-resides with the SPMC and executes at S-EL1 or Secure Supervisor
400 Other nodes in the manifest are consumed by Hafnium in the secure world.
441 Secure boot
445 SPMC manifest, secure partitions and verifies them for authenticity and integrity.
455 Also refer to `Describing secure partitions`_ and `TF-A build options`_ sections.
457 Hafnium in the secure world
463 Build platform for the secure world
467 the secure world. Such portions are isolated in architecture specific files
470 Secure partitions CPU scheduling
474 secure partitions. For this a VM (Hypervisor or OS kernel), or SP invokes one of:
517 provides a memory security attribute hinting to map either to the secure or
518 non-secure EL1&0 Stage-2 table if it exists.
526 Provided that the whole secure partition package image (see
527 `Secure Partition packages`_) is mapped to the SP secure EL1&0 Stage-2
551 at secure physical FF-A instance).
553 The SPMC then creates secure partitions based on SP packages and manifests. Each
554 secure partition is launched in sequence (`SP Boot order`_) on their "primary"
564 - In the case of a MP SP, it invokes the FFA_SECONDARY_EP_REGISTER at secure
582 In a linux based system, once secure and normal worlds are booted but prior to
588 - Other SPs have their first execution context initialized as a result of secure
642 - Schedule Receiver Interrupt: Non-secure physical interrupt to be handled by
644 the SPMC (as suggested by the spec) configures a secure SGI, as non-secure, and
705 FF-A features supported by the SPMC may be discovered by secure partitions at
708 The SPMC calling FFA_FEATURES at secure physical FF-A instance always get
717 When invoked from a secure partition FFA_RXTX_MAP maps the provided send and
719 regime as secure buffers in the MMU descriptors.
726 caller, either it being the Hypervisor or OS kernel, as well as a secure
740 The FF-A id space is split into a non-secure space and secure space:
756 use a secure FF-A ID as origin world by spoofing:
758 - A VM-to-SP direct request/response shall set the origin world to be non-secure
759 (FF-A ID bit 15 clear) and destination world to be secure (FF-A ID bit 15
777 - or initiated by an SP and thus origin endpoint ID must be a "secure world ID".
783 This is a mandatory interface for secure partitions consisting in direct request
796 The secure partitions notifications bitmap are statically allocated by the SPMC.
797 Hence, this interface is not to be issued by secure partitions.
846 The call emitted at NS and secure physical FF-A instances returns the SPM ID
849 Secure partitions call this interface at the virtual instance, to which the SPMC
858 When the SPMC boots, all secure partitions are initialized on their primary
861 The interface FFA_SECONDARY_EP_REGISTER is to be used by a secure partitions
881 With secure virtualization enabled, two IPA spaces are output from the secure
882 EL1&0 Stage-1 translation (secure and non-secure). The EL1&0 Stage-2 translation
885 - A single secure IPA space when the SP EL1&0 Stage-1 MMU is disabled.
886 - Two IPA spaces (secure and non-secure) when the SP EL1&0 Stage-1 MMU is
894 - Stage-2 translation table walks for the NS IPA space are to the secure PA space.
896 Secure and non-secure IPA regions use the same set of Stage-2 page tables within
905 The SPMC owns the GIC configuration. Secure and non-secure interrupts are
910 Non-secure interrupt handling
913 The following illustrate the scenarios of non secure physical interrupts trapped
924 Secure interrupt handling
927 This section documents the support implemented for secure interrupt handling in
936 - Secure interrupts are configured as G1S or G0 interrupts.
937 - All physical interrupts are routed to SPMC when running a secure partition
940 A physical secure interrupt could preempt normal world execution. Moreover, when
941 the execution is in secure world, it is highly likely that the target of a
942 secure interrupt is not the currently running execution context of an SP. It
943 could be targeted to another FF-A component. Consequently, secure interrupt
946 how to signal start and completion of secure interrupt handling as discussed in
949 Secure interrupt signaling mechanisms
956 to S-EL1 SPs. When normal world execution is preempted by a secure interrupt,
981 Secure interrupt completion mechanisms
984 A SP signals secure interrupt handling completion to the SPMC through the
994 If normal world execution was preempted by secure interrupt, SPMC uses
995 FFA_NORMAL_WORLD_RESUME ABI to indicate completion of secure interrupt handling
997 context was preempted by a secure interrupt to be handled by execution context
1002 interrupt. In order to simplify the design, the current version of secure
1022 - NS-Int: A Non-secure physical interrupt. It requires a switch to the Normal
1024 - Other S-Int: A secure physical interrupt targeted to an SP different from
1026 - Self S-Int: A secure physical interrupt targeted to the SP that is currently
1029 The following figure describes interrupt handling flow when secure interrupt
1032 .. image:: ../resources/diagrams/ffa-secure-interrupt-handling-nwd.png
1036 - 1) Secure interrupt triggers while normal world is running.
1038 - 3) SPMD signals secure interrupt to SPMC at S-EL2 using FFA_INTERRUPT ABI.
1048 - 9) SP performs secure interrupt completion through FFA_MSG_WAIT ABI.
1052 The following figure describes interrupt handling flow when secure interrupt
1053 triggers while in secure world:
1055 .. image:: ../resources/diagrams/ffa-secure-interrupt-handling-swd.png
1059 - 1) Secure interrupt triggers while SP2 is running and SP1 is blocked.
1061 - 3) SPMC finds the target vCPU of secure partition responsible for handling
1062 this secure interrupt. In this scenario, it is SP1.
1067 - 6) SP1 services the secure interrupt and invokes the de-activation HVC call.
1070 - 8) Assuming SP1 is in BLOCKED state, SP1 performs secure interrupt completion
1078 In platforms with or without secure virtualization:
1084 - While coordinating PM events, the PSCI library calls backs into the Secure
1087 When using the SPMD as a Secure Payload Dispatcher:
1126 support for SMMUv3 driver in both normal and secure world. A brief introduction
1144 - SMMUv3 offers non-secure stream support with secure stream support being
1146 instance for secure and non-secure stream support.
1150 extensions. Consequently, SPM depends on Secure EL2 support in SMMUv3.2
1151 for providing Secure Stage2 translation support to upstream peripheral
1165 registers have independent secure and non-secure versions to configure the
1166 behaviour of SMMUv3 for translation of secure and non-secure streams
1202 The primary design goal for the Hafnium SMMU driver is to support secure
1215 FEAT_VHE (mandatory with ARMv8.1 in non-secure state, and in secure world
1232 a S-EL0 partition to accept a direct message from secure world and normal world,
1251 [2] :ref:`Secure Partition Manager using MM interface<Secure Partition Manager (MM)>`