linux-kernel - Re: [RFC PATCH 0/4] KVM: ioctl for populating guest

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] [day] [month] [year] [list]

Message-ID: <86aef751-c2f8-4b9d-b7fc-ad9059c82858@redhat.com>
Date: Thu, 28 Nov 2024 13:11:04 +0100
From: David Hildenbrand <david@...hat.com>
To: kalyazin@...zon.com, pbonzini@...hat.com, corbet@....net,
 kvm@...r.kernel.org, linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org
Cc: jthoughton@...gle.com, brijesh.singh@....com, michael.roth@....com,
 graf@...zon.de, jgowans@...zon.com, roypat@...zon.co.uk, derekmn@...zon.com,
 nsaenz@...zon.es, xmarcalx@...zon.com,
 Sean Christopherson <seanjc@...gle.com>, linux-mm@...ck.org
Subject: Re: [RFC PATCH 0/4] KVM: ioctl for populating guest_memfd

On 26.11.24 17:04, Nikita Kalyazin wrote:
> 
> 
> On 21/11/2024 16:46, Nikita Kalyazin wrote:
>>
>>
>> On 20/11/2024 18:29, David Hildenbrand wrote:
>>   > Any clue how your new ioctl will interact with the WIP to have shared
>>   > memory as part of guest_memfd? For example, could it be reasonable to
>>   > "populate" the shared memory first (via VMA) and then convert that
>>   > "allocated+filled" memory to private?
>>
>> Patrick and I synced internally on this.  What may actually work for
>> guest_memfd population is the following.
>>
>> Non-CoCo use case:
>>    - fallocate syscall to fill the page cache, no page content
>> initialisation (like it is now)
>>    - pwrite syscall to initialise the content + mark up-to-date (mark
>> prepared), no specific preparation logic is required
>>
>> The pwrite will have "once" semantics until a subsequent
>> fallocate(FALLOC_FL_PUNCH_HOLE), ie the next pwrite call will "see" the
>> page is already prepared and return EIO/ENOSPC or something.
> 
> I prototyped that to see if it was possible (and it was).  Actually the
> write syscall can also do the allocation part, so no prior fallocate
> would be required. 

Right

> The only thing is there is a cap on how much IO can
> be done in a single call (MAX_RW_COUNT) [1], but it doesn't look like a
> significant problem.  Does it sound like an acceptable solution?

Does sound quite clean to me. Of course, one thing to figure out is how 
to enable this only for that special type of VM type, but that should be 
possible to be resolved.

-- 
Cheers,

David / dhildenb