On Fri, Feb 09, 2024, Steven Price wrote: > >> One option that I've considered is to implement a seperate CCA ioctl to > >> notify KVM whether the memory should be mapped protected. > > > > That's what KVM_SET_MEMORY_ATTRIBUTES+KVM_MEMORY_ATTRIBUTE_PRIVATE is for, no? > > Sorry, I really didn't explain that well. Yes effectively this is the > attribute flag, but there's corner cases for destruction of the VM. My > thought was that if the VMM wanted to tear down part of the protected > range (without making it shared) then a separate ioctl would be needed > to notify KVM of the unmap. No new uAPI should be needed, because the only scenario time a benign VMM should do this is if the guest also knows the memory is being removed, in which case PUNCH_HOLE will suffice. > >> This 'solves' the problem nicely except for the case where the VMM > >> deliberately punches holes in memory which the guest is using. > > > > I don't see what problem there is to solve in this case. PUNCH_HOLE is destructive, > > so don't do that. > > A well behaving VMM wouldn't PUNCH_HOLE when the guest is using it, but > my concern here is a VMM which is trying to break the host. In this case > either the PUNCH_HOLE needs to fail, or we actually need to recover the > memory from the guest (effectively killing the guest in the process). The latter. IIRC, we talked about this exact case somewhere in the hour-long rambling discussion on guest_memfd at PUCK[1]. And we've definitely discussed this multiple times on-list, though I don't know that there is a single thread that captures the entire plan. The TL;DR is that gmem will invoke an arch hook for every "struct kvm_gmem" instance that's attached to a given guest_memfd inode when a page is being fully removed, i.e. when a page is being freed back to the normal memory pool. Something like this proposed SNP patch[2]. Mike, do have WIP patches you can share? [1] https://drive.google.com/corp/drive/folders/116YTH1h9yBZmjqeJc03cV4_AhSe-VBkc?resourcekey=0-sOGeFEUi60-znJJmZBsTHQ [2] https://lore.kernel.org/all/20231230172351.574091-30-michael.roth@xxxxxxx
