On Thu, 2024-10-31 at 09:50 +0000, David Hildenbrand wrote: > On 30.10.24 14:49, Patrick Roy wrote: >> Unmapping virtual machine guest memory from the host kernel's direct map >> is a successful mitigation against Spectre-style transient execution >> issues: If the kernel page tables do not contain entries pointing to >> guest memory, then any attempted speculative read through the direct map >> will necessarily be blocked by the MMU before any observable >> microarchitectural side-effects happen. This means that Spectre-gadgets >> and similar cannot be used to target virtual machine memory. Roughly 60% >> of speculative execution issues fall into this category [1, Table 1]. >> >> This patch series extends guest_memfd with the ability to remove its >> memory from the host kernel's direct map, to be able to attain the above >> protection for KVM guests running inside guest_memfd. >> >> === Changes to v2 === >> >> - Handle direct map removal for physically contiguous pages in arch code >> (Mike R.) >> - Track the direct map state in guest_memfd itself instead of at the >> folio level, to prepare for huge pages support (Sean C.) >> - Allow configuring direct map state of not-yet faulted in memory >> (Vishal A.) >> - Pay attention to alignment in ftrace structs (Steven R.) >> >> Most significantly, I've reduced the patch series to focus only on >> direct map removal for guest_memfd for now, leaving the whole "how to do >> non-CoCo VMs in guest_memfd" for later. If this separation is >> acceptable, then I think I can drop the RFC tag in the next revision >> (I've mainly kept it here because I'm not entirely sure what to do with >> patches 3 and 4). > > Hi, > > keeping upcoming "shared and private memory in guest_memfd" in mind, I > assume the focus would be to only remove the direct map for private memory? > > So in the current upstream state, you would only be removing the direct > map for private memory, currently translating to "encrypted"/"protected" > memory that is inaccessible either way already. > > Correct? Yea, with the upcomming "shared and private" stuff, I would expect the the shared<->private conversions would call the routines from patch 3 to restore direct map entries on private->shared, and zap them on shared->private. But as you said, the current upstream state has no notion of "shared" memory in guest_memfd, so everything is private and thus everything is direct map removed (although it is indeed already inaccessible anyway for TDX and friends. That's what makes this patch series a bit awkward :( ) > -- > Cheers, > > David / dhildenb > Best, Patrick
