| 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
| ||
|
Message-ID: <04173297-518d-460a-be9f-502d32cbe509@amazon.com>
Date: Fri, 16 Jan 2026 15:00:53 +0000
From: Nikita Kalyazin <kalyazin@...zon.com>
To: Ackerley Tng <ackerleytng@...gle.com>, "Kalyazin, Nikita"
<kalyazin@...zon.co.uk>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "kvmarm@...ts.linux.dev"
<kvmarm@...ts.linux.dev>, "linux-fsdevel@...r.kernel.org"
<linux-fsdevel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>,
"linux-kselftest@...r.kernel.org" <linux-kselftest@...r.kernel.org>,
"kernel@...0n.name" <kernel@...0n.name>, "linux-riscv@...ts.infradead.org"
<linux-riscv@...ts.infradead.org>, "linux-s390@...r.kernel.org"
<linux-s390@...r.kernel.org>, "loongarch@...ts.linux.dev"
<loongarch@...ts.linux.dev>
CC: "pbonzini@...hat.com" <pbonzini@...hat.com>, "corbet@....net"
<corbet@....net>, "maz@...nel.org" <maz@...nel.org>, "oupton@...nel.org"
<oupton@...nel.org>, "joey.gouly@....com" <joey.gouly@....com>,
"suzuki.poulose@....com" <suzuki.poulose@....com>, "yuzenghui@...wei.com"
<yuzenghui@...wei.com>, "catalin.marinas@....com" <catalin.marinas@....com>,
"will@...nel.org" <will@...nel.org>, "seanjc@...gle.com" <seanjc@...gle.com>,
"tglx@...utronix.de" <tglx@...utronix.de>, "mingo@...hat.com"
<mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
"dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>, "x86@...nel.org"
<x86@...nel.org>, "hpa@...or.com" <hpa@...or.com>, "luto@...nel.org"
<luto@...nel.org>, "peterz@...radead.org" <peterz@...radead.org>,
"willy@...radead.org" <willy@...radead.org>, "akpm@...ux-foundation.org"
<akpm@...ux-foundation.org>, "david@...nel.org" <david@...nel.org>,
"lorenzo.stoakes@...cle.com" <lorenzo.stoakes@...cle.com>,
"Liam.Howlett@...cle.com" <Liam.Howlett@...cle.com>, "vbabka@...e.cz"
<vbabka@...e.cz>, "rppt@...nel.org" <rppt@...nel.org>, "surenb@...gle.com"
<surenb@...gle.com>, "mhocko@...e.com" <mhocko@...e.com>, "ast@...nel.org"
<ast@...nel.org>, "daniel@...earbox.net" <daniel@...earbox.net>,
"andrii@...nel.org" <andrii@...nel.org>, "martin.lau@...ux.dev"
<martin.lau@...ux.dev>, "eddyz87@...il.com" <eddyz87@...il.com>,
"song@...nel.org" <song@...nel.org>, "yonghong.song@...ux.dev"
<yonghong.song@...ux.dev>, "john.fastabend@...il.com"
<john.fastabend@...il.com>, "kpsingh@...nel.org" <kpsingh@...nel.org>,
"sdf@...ichev.me" <sdf@...ichev.me>, "haoluo@...gle.com" <haoluo@...gle.com>,
"jolsa@...nel.org" <jolsa@...nel.org>, "jgg@...pe.ca" <jgg@...pe.ca>,
"jhubbard@...dia.com" <jhubbard@...dia.com>, "peterx@...hat.com"
<peterx@...hat.com>, "jannh@...gle.com" <jannh@...gle.com>,
"pfalcato@...e.de" <pfalcato@...e.de>, "shuah@...nel.org" <shuah@...nel.org>,
"riel@...riel.com" <riel@...riel.com>, "ryan.roberts@....com"
<ryan.roberts@....com>, "jgross@...e.com" <jgross@...e.com>,
"yu-cheng.yu@...el.com" <yu-cheng.yu@...el.com>, "kas@...nel.org"
<kas@...nel.org>, "coxu@...hat.com" <coxu@...hat.com>,
"kevin.brodsky@....com" <kevin.brodsky@....com>, "maobibo@...ngson.cn"
<maobibo@...ngson.cn>, "prsampat@....com" <prsampat@....com>,
"mlevitsk@...hat.com" <mlevitsk@...hat.com>, "jmattson@...gle.com"
<jmattson@...gle.com>, "jthoughton@...gle.com" <jthoughton@...gle.com>,
"agordeev@...ux.ibm.com" <agordeev@...ux.ibm.com>, "alex@...ti.fr"
<alex@...ti.fr>, "aou@...s.berkeley.edu" <aou@...s.berkeley.edu>,
"borntraeger@...ux.ibm.com" <borntraeger@...ux.ibm.com>,
"chenhuacai@...nel.org" <chenhuacai@...nel.org>, "dev.jain@....com"
<dev.jain@....com>, "gor@...ux.ibm.com" <gor@...ux.ibm.com>,
"hca@...ux.ibm.com" <hca@...ux.ibm.com>, "Jonathan.Cameron@...wei.com"
<Jonathan.Cameron@...wei.com>, "palmer@...belt.com" <palmer@...belt.com>,
"pjw@...nel.org" <pjw@...nel.org>, "shijie@...amperecomputing.com"
<shijie@...amperecomputing.com>, "svens@...ux.ibm.com" <svens@...ux.ibm.com>,
"thuth@...hat.com" <thuth@...hat.com>, "wyihan@...gle.com"
<wyihan@...gle.com>, "yang@...amperecomputing.com"
<yang@...amperecomputing.com>, "vannapurve@...gle.com"
<vannapurve@...gle.com>, "jackmanb@...gle.com" <jackmanb@...gle.com>,
"aneesh.kumar@...nel.org" <aneesh.kumar@...nel.org>, "patrick.roy@...ux.dev"
<patrick.roy@...ux.dev>, "Thomson, Jack" <jackabt@...zon.co.uk>, "Itazuri,
Takahiro" <itazur@...zon.co.uk>, "Manwaring, Derek" <derekmn@...zon.com>,
"Cali, Marco" <xmarcalx@...zon.co.uk>
Subject: Re: [PATCH v9 09/13] KVM: selftests: set KVM_MEM_GUEST_MEMFD in
vm_mem_add() if guest_memfd != -1
On 15/01/2026 19:39, Ackerley Tng wrote:
> "Kalyazin, Nikita" <kalyazin@...zon.co.uk> writes:
>
>> From: Patrick Roy <patrick.roy@...ux.dev>
>>
>> Have vm_mem_add() always set KVM_MEM_GUEST_MEMFD in the memslot flags if
>> a guest_memfd is passed in as an argument. This eliminates the
>> possibility where a guest_memfd instance is passed to vm_mem_add(), but
>> it ends up being ignored because the flags argument does not specify
>> KVM_MEM_GUEST_MEMFD at the same time.
>>
>> This makes it easy to support more scenarios in which no vm_mem_add() is
>> not passed a guest_memfd instance, but is expected to allocate one.
>> Currently, this only happens if guest_memfd == -1 but flags &
>> KVM_MEM_GUEST_MEMFD != 0, but later vm_mem_add() will gain support for
>> loading the test code itself into guest_memfd (via
>> GUEST_MEMFD_FLAG_MMAP) if requested via a special
>> vm_mem_backing_src_type, at which point having to make sure the src_type
>> and flags are in-sync becomes cumbersome.
>>
>> Signed-off-by: Patrick Roy <patrick.roy@...ux.dev>
>> Signed-off-by: Nikita Kalyazin <kalyazin@...zon.com>
>> ---
>> tools/testing/selftests/kvm/lib/kvm_util.c | 24 +++++++++++++---------
>> 1 file changed, 14 insertions(+), 10 deletions(-)
>>
>> diff --git a/tools/testing/selftests/kvm/lib/kvm_util.c b/tools/testing/selftests/kvm/lib/kvm_util.c
>> index 8279b6ced8d2..56ddbca91850 100644
>> --- a/tools/testing/selftests/kvm/lib/kvm_util.c
>> +++ b/tools/testing/selftests/kvm/lib/kvm_util.c
>> @@ -1057,21 +1057,25 @@ void vm_mem_add(struct kvm_vm *vm, enum vm_mem_backing_src_type src_type,
>>
>> region->backing_src_type = src_type;
>>
>> - if (flags & KVM_MEM_GUEST_MEMFD) {
>> - if (guest_memfd < 0) {
>> + if (guest_memfd < 0) {
>> + if (flags & KVM_MEM_GUEST_MEMFD) {
>> uint32_t guest_memfd_flags = 0;
>> TEST_ASSERT(!guest_memfd_offset,
>> "Offset must be zero when creating new guest_memfd");
>> guest_memfd = vm_create_guest_memfd(vm, mem_size, guest_memfd_flags);
>> - } else {
>> - /*
>> - * Install a unique fd for each memslot so that the fd
>> - * can be closed when the region is deleted without
>> - * needing to track if the fd is owned by the framework
>> - * or by the caller.
>> - */
>> - guest_memfd = kvm_dup(guest_memfd);
>> }
>> + } else {
>> + /*
>> + * Install a unique fd for each memslot so that the fd
>> + * can be closed when the region is deleted without
>> + * needing to track if the fd is owned by the framework
>> + * or by the caller.
>> + */
>> + guest_memfd = kvm_dup(guest_memfd);
>> + }
>> +
>> + if (guest_memfd > 0) {
>
> Might 0 turn out to be a valid return from dup() for a guest_memfd?
Yes, you're right, it isn't impossible. Thanks!
>
>> + flags |= KVM_MEM_GUEST_MEMFD;
>>
>> region->region.guest_memfd = guest_memfd;
>> region->region.guest_memfd_offset = guest_memfd_offset;
>
> Refactoring vm_mem_add() (/* FIXME: This thing needs to be ripped apart
> and rewritten. */) should probably be a separate patch series, but I'd
> like to take this opportunity to ask: Sean, what do you have in mind for
> the rewritten version?
>
> Would it be something like struct vm_shape, where there are default
> mem_shapes, and the shapes get validated and then passed to
> vm_mem_add()?
>
>> --
>> 2.50.1
Powered by blists - more mailing lists