Lines Matching +full:mode +full:- +full:normal
1 .. SPDX-License-Identifier: GPL-2.0
5 Hyper-V can create and run Linux guests that are Confidential Computing
9 CoCo VMs on Hyper-V share the generic CoCo VM threat model and security
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
14 A Linux CoCo VM on Hyper-V requires the cooperation and interaction of the
19 * The hardware runs a version of Windows/Hyper-V with support for CoCo VMs
25 * AMD processor with SEV-SNP. Hyper-V does not run guest VMs with AMD SME,
26 SEV, or SEV-ES encryption, and such encryption is not sufficient for a CoCo
27 VM on Hyper-V.
31 To create a CoCo VM, the "Isolated VM" attribute must be specified to Hyper-V
32 when the VM is created. A VM cannot be changed from a CoCo VM to a normal VM,
36 -----------------
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
46 fully-enlightened case.
48 Conceptually, fully-enlightened mode and paravisor mode may be treated as
50 as a CoCo VM. Fully-enlightened mode is one end of the spectrum. A full
51 implementation of paravisor mode is the other end of the spectrum, where all
52 aspects of running as a CoCo VM are handled by the paravisor, and a normal
54 can run successfully. However, the Hyper-V implementation of paravisor mode
56 aspects of CoCo VMs are handled by the Hyper-V paravisor while the guest OS
61 the paravisor provides is hard-coded in the guest OS.
63 Paravisor mode has similarities to the `Coconut project`_, which aims to provide
65 However, the Hyper-V paravisor generally handles more aspects of CoCo VMs
69 .. _Coconut project: https://github.com/coconut-svsm/svsm
76 The hardware architectural approach to fully-enlightened vs. paravisor mode
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
84 paravisor mode the guest OS operates in "virtual Top Of Memory" (vTOM) mode
85 as defined by the SEV-SNP architecture. This mode simplifies guest management
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
92 Hyper-V exposes a synthetic MSR to guests that describes the CoCo mode. This
93 MSR indicates if the underlying processor uses AMD SEV-SNP or Intel TDX, and
96 either mode.
99 -----------------
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
105 guest Linux does normal memory initialization, except for explicitly marking
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
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,
122 abstracting the differences between SEV-SNP and TDX. But the
123 cc_platform_has() abstraction also allows the Hyper-V paravisor configuration
125 flags are not set. The exception is early boot memory setup on SEV-SNP, which
126 tests the CPUID SEV-SNP flag. But not having the flag in Hyper-V paravisor
127 mode VM achieves the desired effect or not running SEV-SNP specific early
130 * Device emulation. In paravisor mode, the Hyper-V paravisor provides
131 emulation of devices such as the IO-APIC and TPM. Because the emulation
134 of the decrypted references that would be used in a fully-enlightened CoCo
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
155 management features provided by the CoCo-capable physical processor, thereby
158 Hyper-V Hypercalls
159 ------------------
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
168 Guest communication with Hyper-V
169 --------------------------------
171 CoCo VMs, Hyper-V has VMBus and VMBus devices that communicate using memory
177 These Hyper-V and VMBus memory pages are marked as decrypted:
184 * Per-cpu hypercall input and output pages (unless running with a paravisor)
206 validate messages received over VMBus, instead of assuming that Hyper-V is
212 Two VMBus devices depend on the Hyper-V host to do DMA data transfers:
213 storvsc for disk I/O and netvsc for network I/O. storvsc uses the normal
216 mode goes through send and receive buffer space that is explicitly allocated
221 already part of the data path. The second mode uses the normal Linux kernel
227 by the Linux PCI subsystem. On Hyper-V, these functions directly access MMIO
228 space, and the access traps to Hyper-V for emulation. But in CoCo VMs, memory
229 encryption prevents Hyper-V from reading the guest instruction stream to
236 ------------------------
241 the Hyper-V host. The memory is in an inconsistent state until all steps are
248 handler to fixup this case. But a CoCo VM running on Hyper-V may be
254 To avoid this problem, the Hyper-V specific functions for notifying the
257 normal page fault is generated instead of #VC or #VE, and the page-fault-