| 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: <CAEvNRgGz2gRu2i+OSxasuyZudqsRGXijbDES8uXVe_hH6QCK4g@mail.gmail.com>
Date: Thu, 15 Jan 2026 11:39:47 -0800
From: Ackerley Tng <ackerleytng@...gle.com>
To: "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
"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?
> + 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