Lines Matching +full:shared +full:- +full:memory
1 .. SPDX-License-Identifier: GPL-2.0
5 Hyper-V can create and run Linux guests that are Confidential Computing
7 the confidentiality and integrity of data in the VM's memory, even in the
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
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
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
53 guest OS with no knowledge of memory encryption or other aspects of CoCo VMs
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.
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
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
86 of memory encryption when a paravisor is used.
88 * With Intel TDX processor, in fully-enlightened mode the guest OS runs in an
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
99 -----------------
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
106 appropriate ranges as decrypted (shared). In paravisor mode, Linux does not
107 perform the early boot memory setup steps that are particularly tricky with
108 AMD SEV-SNP in fully-enlightened mode.
110 * #VC/#VE exception handling. In paravisor mode, Hyper-V configures the guest
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
128 boot memory setup.
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
139 * Encrypt/decrypt memory transitions. In a CoCo VM, transitioning guest
140 memory between encrypted and decrypted requires coordinating with the
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
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,
168 Guest communication with Hyper-V
169 --------------------------------
170 Separate from the generic Linux kernel handling of memory encryption in Linux
171 CoCo VMs, Hyper-V has VMBus and VMBus devices that communicate using memory
172 shared between the Linux guest and the host. This shared memory must be
175 against leaking any unintended data to the host through this shared 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)
190 When the guest writes data to memory that is shared with the host, it must
192 be initialized to zeros before copying into the shared memory so that random
195 Similarly, when the guest reads memory that is shared with the host, it must
198 because the host can modify the shared memory areas even while or after
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:
215 memory is done implicitly. netvsc has two modes for data transfers. The first
220 equivalent of bounce buffering between encrypted and decrypted memory is
222 DMA APIs, and is bounce buffered through swiotlb memory implicitly like in
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 ------------------------
237 When transitioning memory between encrypted and decrypted, the caller of
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
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-