linux-kernel - Re: [PATCH v5 1/2] KVM: guest_memfd: add generic population via write

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAGtprH8QjeuR90QJ7byxoAPfb30kmUEDhRhzqNZqSpR8y_+z9g@mail.gmail.com>
Date: Fri, 12 Sep 2025 17:18:06 -0700
From: Vishal Annapurve <vannapurve@...gle.com>
To: David Hildenbrand <david@...hat.com>
Cc: kalyazin@...zon.com, James Houghton <jthoughton@...gle.com>, 
	"Kalyazin, Nikita" <kalyazin@...zon.co.uk>, "pbonzini@...hat.com" <pbonzini@...hat.com>, 
	"shuah@...nel.org" <shuah@...nel.org>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>, 
	"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>, 
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "michael.day@....com" <michael.day@....com>, 
	"Roy, Patrick" <roypat@...zon.co.uk>, "Thomson, Jack" <jackabt@...zon.co.uk>, 
	"Manwaring, Derek" <derekmn@...zon.com>, "Cali, Marco" <xmarcalx@...zon.co.uk>
Subject: Re: [PATCH v5 1/2] KVM: guest_memfd: add generic population via write

On Fri, Sep 12, 2025 at 8:39 AM David Hildenbrand <david@...hat.com> wrote:
>
> >>>> What's meant to happen if we do use this for CoCo VMs? I would expect
> >>>> write() to fail, but I don't see why it would (seems like we need/want
> >>>> a check that we aren't write()ing to private memory).
> >>>
> >>> I am not so sure that write() should fail even in CoCo VMs if we access
> >>> not-yet-prepared pages.  My understanding was that the CoCoisation of
> >>> the memory occurs during "preparation".  But I may be wrong here.
> >>
> >> But how do you handle that a page is actually inaccessible and should
> >> not be touched?
> >>
> >> IOW, with CXL you could crash the host.
> >>
> >> There is likely some state check missing, or it should be restricted to
> >> VM types.
> >
> > Sorry, I'm missing the link between VM types and CXL.  How are they related?
>
> I think what you explain below clarifies it.
>
> >
> > My thinking was it is a regular (accessible) page until it is "prepared"
> > by the CoCo hardware, which is currently tracked by the up-to-date flag,
> > so it is safe to assume that until it is "prepared", it is accessible
> > because it was allocated by filemap_grab_folio() ->
> > filemap_alloc_folio() and hasn't been taken over by the CoCo hardware.
> > What scenario can you see where it doesn't apply as of now?
>
> Thanks for clarifying, see below.
>
> >
> > I am aware of an attempt to remove preparation tracking from
> > guest_memfd, but it is still at an RFC stage AFAIK [1].
> >
> >>
> >> Do we know how this would interact with the direct-map removal?
> >
> > I'm using folio_test_uptodate() to determine if the page has been
> > removed from the direct map as kvm_gmem_mark_prepared() is what
> > currently removes the page from the direct map and marks it as
> > up-to-date.  [2] is a Firecracker feature branch where the two work in
> > combination.
>
> Ah, okay. Yes, I recalled [1] that we wanted to change these semantics
> to be "uptodate: was zeroed", and that preparation handling would be
> essentially handled by the arch backend.

Yes, I think we should not be overloading uptodate flag to be an
indicator of what is private for CoCo guests. Uptodate flag should
just mean zeroed/fresh folio. It's possible that future allocator
backing for huge pages already provides uptodate folios.

If there is no current use case for read/write for CoCo VMs, I think
it makes sense to disable it for now by checking the VM type before
adding further overloading of uptodate flags.

>
> --
> Cheers
>
> David / dhildenb
>
>