virt/hyperv/coco.rst

25 * AMD processor with SEV-SNP. Hyper-V does not run guest VMs with AMD SME,
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
44   host provides some operations needed to run as a CoCo VM. The guest operating
49 points on a spectrum spanning the degree of guest enlightenment needed to run
53 guest OS with no knowledge of memory encryption or other aspects of CoCo VMs
56 aspects of CoCo VMs are handled by the Hyper-V paravisor while the guest OS
59 paravisor, and there is no standardized mechanism for a guest OS to query the
61 the paravisor provides is hard-coded in the guest OS.
64 a limited paravisor to provide services to the guest such as a virtual TPM.
67 guest enlightenments required" end of the spectrum.
71 In the CoCo VM threat model, the paravisor is in the guest security domain
72 and must be trusted by the guest OS. By implication, the hypervisor/VMM must
74 protects against a potentially malicious guest.
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
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
90   L1 VM, and the guest OS runs in a nested L2 VM.
103 * Initial guest memory setup. When a new VM is created in paravisor mode, the
104   paravisor runs first and sets up the guest physical memory as encrypted. The
105   guest Linux does normal memory initialization, except for explicitly marking
110 * #VC/#VE exception handling. In paravisor mode, Hyper-V configures the guest
112   respectively, and not the guest Linux. Consequently, these exception handlers
113   do not run in the guest Linux and are not a required enlightenment for a
114   Linux guest in paravisor mode.
117   guest indicating that the VM is operating with the respective hardware
119   the paravisor filters out these flags and the guest Linux does not see them.
132   happens in the paravisor in the guest context (instead of the hypervisor/VMM
139 * Encrypt/decrypt memory transitions. In a CoCo VM, transitioning guest
149   could inject interrupts into the guest OS at times that violate x86/x64
150   architectural rules. For full protection, the guest OS should include
153   interrupt injection into the guest OS, and ensures that the guest OS only
156   masking these complexities from the guest OS.
160 When in fully-enlightened mode, hypercalls made by the Linux guest are routed
164 hypercalls made by the Linux guest must always be routed directly to the
168 Guest communication with Hyper-V
172 shared between the Linux guest and the host. This shared memory must be
174 includes a compromised and potentially malicious host, the guest must guard
190 When the guest writes data to memory that is shared with the host, it must
195 Similarly, when the guest reads memory that is shared with the host, it must
197 the guest to expose unintended data. Doing such validation can be tricky
199 validation is performed. For messages passed from the host to the guest in a
229 encryption prevents Hyper-V from reading the guest instruction stream to
251 the guest kernel, and in such a case, the load_unaligned_zeropad() fixup code