Re: [PATCH v12 10/18] KVM: x86/mmu: Handle guest page faults for guest_memfd with shared memory

[David Hildenbrand <david@redhat.com>]

>>> I support this approach.
>>
>> Agreed. Let's get this in with the changes requested by Sean applied.
>>
>> How to use GUEST_MEMFD_FLAG_MMAP in combination with a CoCo VM with
>> legacy mem attributes (-> all memory in guest_memfd private) could be
>> added later on top, once really required.
>>
>> As discussed, CoCo VMs that want to support GUEST_MEMFD_FLAG_MMAP will
>> have to disable legacy mem attributes using a new capability in stage-2.
>>
> 
> I rewatched the guest_memfd meeting on 2025-06-12.  We do want to
> support the use case where userspace wants to have mmap (e.g. to set
> mempolicy) but does not want to allow faulting into the host.
> 
> On 2025-06-12, the conclusion was that the problem will be solved once
> guest_memfd supports shareability, and that's because userspace can set
> shareability to GUEST, so the memory can't be faulted into the host.
> 
> On 2025-06-26, Sean said we want to let userspace have an extra layer of
> protection so that memory cannot be faulted in to the host, ever. IOW,
> we want to let userspace say that even if there is a stray
> private-to-shared conversion, *don't* allow faulting memory into the
> host.
> 
> The difference is the "extra layer of protection", which should remain
> in effect even if there are (stray/unexpected) private-to-shared
> conversions to guest_memfd or to KVM. Here's a direct link to the point
> in the video where Sean brought this up [1]. I'm really hoping I didn't
> misinterpret this!
> 
> Let me look ahead a little, since this involves use cases already
> brought up though I'm not sure how real they are. I just want to make
> sure that in a few patch series' time, we don't end up needing userspace
> to use a complex bunch of CAPs and FLAGs.
> 
> In this series (mmap support, V12, patch 10/18) [2], to allow
> KVM_X86_DEFAULT_VMs to use guest_memfd, I added a `fault_from_gmem()`
> helper, which is defined as follows (before the renaming Sean requested):
> 
> +static inline bool fault_from_gmem(struct kvm_page_fault *fault)
> +{
> +	return fault->is_private || kvm_gmem_memslot_supports_shared(fault->slot);
> +}
> 
> The above is changeable, of course :). The intention is that if the
> fault is private, fault from guest_memfd. If GUEST_MEMFD_FLAG_MMAP is
> set (KVM_MEMSLOT_GMEM_ONLY will be set on the memslot), fault from
> guest_memfd.
> 
> If we defer handling GUEST_MEMFD_FLAG_MMAP in combination with a CoCo VM
> with legacy mem attributes to the future, this helper will probably
> become
> 
> -static inline bool fault_from_gmem(struct kvm_page_fault *fault)
> +static inline bool fault_from_gmem(struct kvm *kvm, struct kvm_page_fault *fault)
> +{
> -	return fault->is_private || kvm_gmem_memslot_supports_shared(fault->slot);
> +	return fault->is_private || (kvm_gmem_memslot_supports_shared(fault->slot) &&
> +	                             !kvm_arch_disable_legacy_private_tracking(kvm));
> +}
> 
> And on memslot binding we check
> 
> if kvm_arch_disable_legacy_private_tracking(kvm) and not GUEST_MEMFD_FLAG_MMAP
> 	return -EINVAL;
> 
> 1. Is that what yall meant?

My understanding:

CoCo VMs will initially (stage-1) only support !GUEST_MEMFD_FLAG_MMAP.

With stage-2, CoCo VMs will support GUEST_MEMFD_FLAG_MMAP only with 
kvm_arch_disable_legacy_private_tracking().

Non-CoCo VMs will only support GUEST_MEMFD_FLAG_MMAP. (no concept of 
private)

> 
> 2. Does this kind of not satisfy the "extra layer of protection"
>     requirement (if it is a requirement)?
> 
>     A legacy CoCo VM using guest_memfd only for private memory (shared
>     memory from say, shmem) and needing to set mempolicy would
>     
>     * Set GUEST_MEMFD_FLAG_MMAP
>     * Leave KVM_CAP_DISABLE_LEGACY_PRIVATE_TRACKING defaulted to false
>     
>     but still be able to send conversion ioctls directly to guest_memfd,
>     and then be able to fault guest_memfd memory into the host.

In that configuration, I would expect that all memory in guest_memfd is 
private and remains private.

guest_memfd without memory attributes cannot support in-place conversion.

How to achieve that might be interesting: the capability will affect 
guest_memfd behavior?

> 
> 3. Now for a use case I've heard of (feel free to tell me this will
>     never be supported or "we'll deal with it if it comes"): On a
>     non-CoCo VM, we want to use guest_memfd but not use mmap (and the
>     initial VM image will be written using write() syscall or something
>     else).
> 
>     * Set GUEST_MEMFD_FLAG_MMAP to false
>     * Leave KVM_CAP_DISABLE_LEGACY_PRIVATE_TRACKING defaulted to false
>       (it's a non-CoCo VM, weird to do anything to do with private
>       tracking)
> 
>     And now we're stuck because fault_from_gmem() will return false all
>     the time and we can't use memory from guest_memfd.

I think I discussed that with Sean: we would have GUEST_MEMFD_FLAG_WRITE 
that will imply everything that GUEST_MEMFD_FLAG_MMAP would imply, 
except the actual mmap() support.

-- 
Cheers,

David / dhildenb