Lines Matching full:in
7 the confidentiality and integrity of data in the VM's memory, even in the
10 objectives described in Documentation/security/snp-tdx-threat-model.rst. Note
11 that Hyper-V specific code in Linux refers to CoCo VMs as "isolated VMs" or
37 Hyper-V CoCo VMs can run in two modes. The mode is selected when the VM is
40 * Fully-enlightened mode. In this mode, the guest operating system is
43 * Paravisor mode. In this mode, a paravisor layer between the guest and the
45 system can have fewer CoCo enlightenments than is required in the
55 does not go this far, and is somewhere in the middle of the spectrum. Some
58 standardized enumeration of feature/functions that might be provided in the
61 the paravisor provides is hard-coded in the guest OS.
71 In the CoCo VM threat model, the paravisor is in the guest security domain
79 * With AMD SEV-SNP processors, in fully-enlightened mode the guest OS runs in
80 VMPL 0 and has full control of the guest context. In paravisor mode, the
81 guest OS runs in VMPL 2 and the paravisor runs in VMPL 0. The paravisor
82 running in VMPL 0 has privileges that the guest OS in VMPL 2 does not have.
83 Certain operations require the guest to invoke the paravisor. Furthermore, in
84 paravisor mode the guest OS operates in "virtual Top Of Memory" (vTOM) mode
88 * With Intel TDX processor, in fully-enlightened mode the guest OS runs in an
89 L1 VM. In paravisor mode, TD partitioning is used. The paravisor runs in the
90 L1 VM, and the guest OS runs in a nested L2 VM.
95 kernel image that can boot and run properly on either architecture, and in
100 Running in paravisor mode affects the following areas of generic Linux kernel
103 * Initial guest memory setup. When a new VM is created in paravisor mode, the
106 appropriate ranges as decrypted (shared). In paravisor mode, Linux does not
108 AMD SEV-SNP in fully-enlightened mode.
110 * #VC/#VE exception handling. In paravisor mode, Hyper-V configures the guest
113 do not run in the guest Linux and are not a required enlightenment for a
114 Linux guest in paravisor mode.
116 * CPUID flags. Both AMD SEV-SNP and Intel TDX provide a CPUID flag in the
118 support. While these CPUID flags are visible in fully-enlightened CoCo VMs,
121 eliminated in favor of the cc_platform_has() function, with the goal of
126 tests the CPUID SEV-SNP flag. But not having the flag in Hyper-V paravisor
130 * Device emulation. In paravisor mode, the Hyper-V paravisor provides
132 happens in the paravisor in the guest context (instead of the hypervisor/VMM
134 of the decrypted references that would be used in a fully-enlightened CoCo
139 * Encrypt/decrypt memory transitions. In a CoCo VM, transitioning guest
142 __set_memory_enc_pgtable(). In fully-enlightened mode, the normal SEV-SNP and
143 TDX implementations of these callbacks are used. In paravisor mode, a Hyper-V
148 * Interrupt injection. In fully enlightened mode, a malicious hypervisor
152 by CoCo-capable processors. In paravisor mode, the paravisor mediates
160 When in fully-enlightened mode, hypercalls made by the Linux guest are routed
161 directly to the hypervisor, just as in a non-CoCo VM. But in paravisor mode,
162 normal hypercalls trap to the paravisor first, which may in turn invoke the
163 hypervisor. But the paravisor is idiosyncratic in this regard, and a few
170 Separate from the generic Linux kernel handling of memory encryption in Linux
186 * VMBus ring buffers. The direct mapping is marked decrypted in
187 __vmbus_establish_gpadl(). The secondary mapping created in
199 validation is performed. For messages passed from the host to the guest in a
207 acting cooperatively. Such drivers are marked as "allowed_in_isolated" in the
208 vmbus_devs[] table. Other drivers for VMBus devices that are not needed in a
209 CoCo VM have not been hardened, and they are not allowed to load in a CoCo
222 DMA APIs, and is bounce buffered through swiotlb memory implicitly like in
225 Finally, the VMBus virtual PCI driver needs special handling in a CoCo VM.
228 space, and the access traps to Hyper-V for emulation. But in CoCo VMs, memory
230 emulate the access. So in a CoCo VM, these functions must make a hypercall
239 the memory isn't in use and isn't referenced while the transition is in
241 the Hyper-V host. The memory is in an inconsistent state until all steps are
242 complete. A reference while the state is inconsistent could result in an
247 set_memory_decrypted(), so there's specific code in the #VC or #VE exception
251 the guest kernel, and in such a case, the load_unaligned_zeropad() fixup code
252 in the #VC/#VE handlers doesn't run.
256 is in progress. If load_unaligned_zeropad() causes a stray reference, a