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: <8e55ba3a-e7ae-422a-9c79-11aa0e17eae9@redhat.com>
Date: Fri, 12 Sep 2025 15:36:21 +0200
From: David Hildenbrand <david@...hat.com>
To: kalyazin@...zon.com, James Houghton <jthoughton@...gle.com>,
 "Kalyazin, Nikita" <kalyazin@...zon.co.uk>
Cc: "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 11.09.25 12:15, Nikita Kalyazin wrote:
> 
> 
> On 10/09/2025 22:23, James Houghton wrote:
>> On Tue, Sep 2, 2025 at 4:20 AM Kalyazin, Nikita <kalyazin@...zon.co.uk> wrote:
>>>
>>> From: Nikita Kalyazin <kalyazin@...zon.com>
>>
>> Hi Nikita,
> 
> Hi James,
> 
> Thanks for the review!
> 
> 
>>>
>>> write syscall populates guest_memfd with user-supplied data in a generic
>>> way, ie no vendor-specific preparation is performed.  This is supposed
>>> to be used in non-CoCo setups where guest memory is not
>>> hardware-encrypted.
>>
>> 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.

Do we know how this would interact with the direct-map removal?

-- 
Cheers

David / dhildenb