| 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: <2457cb3b-5dde-4ca1-b75d-174b5daee28a@arm.com>
Date: Wed, 22 Oct 2025 16:21:34 +0100
From: Steven Price <steven.price@....com>
To: Ackerley Tng <ackerleytng@...gle.com>, cgroups@...r.kernel.org,
kvm@...r.kernel.org, linux-doc@...r.kernel.org,
linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
linux-kselftest@...r.kernel.org, linux-mm@...ck.org,
linux-trace-kernel@...r.kernel.org, x86@...nel.org
Cc: akpm@...ux-foundation.org, binbin.wu@...ux.intel.com, bp@...en8.de,
brauner@...nel.org, chao.p.peng@...el.com, chenhuacai@...nel.org,
corbet@....net, dave.hansen@...el.com, dave.hansen@...ux.intel.com,
david@...hat.com, dmatlack@...gle.com, erdemaktas@...gle.com,
fan.du@...el.com, fvdl@...gle.com, haibo1.xu@...el.com, hannes@...xchg.org,
hch@...radead.org, hpa@...or.com, hughd@...gle.com, ira.weiny@...el.com,
isaku.yamahata@...el.com, jack@...e.cz, james.morse@....com,
jarkko@...nel.org, jgg@...pe.ca, jgowans@...zon.com, jhubbard@...dia.com,
jroedel@...e.de, jthoughton@...gle.com, jun.miao@...el.com,
kai.huang@...el.com, keirf@...gle.com, kent.overstreet@...ux.dev,
liam.merwick@...cle.com, maciej.wieczor-retman@...el.com,
mail@...iej.szmigiero.name, maobibo@...ngson.cn,
mathieu.desnoyers@...icios.com, maz@...nel.org, mhiramat@...nel.org,
mhocko@...nel.org, mic@...ikod.net, michael.roth@....com, mingo@...hat.com,
mlevitsk@...hat.com, mpe@...erman.id.au, muchun.song@...ux.dev,
nikunj@....com, nsaenz@...zon.es, oliver.upton@...ux.dev,
palmer@...belt.com, pankaj.gupta@....com, paul.walmsley@...ive.com,
pbonzini@...hat.com, peterx@...hat.com, pgonda@...gle.com, prsampat@....com,
pvorel@...e.cz, qperret@...gle.com, richard.weiyang@...il.com,
rick.p.edgecombe@...el.com, rientjes@...gle.com, rostedt@...dmis.org,
roypat@...zon.co.uk, rppt@...nel.org, seanjc@...gle.com,
shakeel.butt@...ux.dev, shuah@...nel.org, steven.sistare@...cle.com,
suzuki.poulose@....com, tabba@...gle.com, tglx@...utronix.de,
thomas.lendacky@....com, vannapurve@...gle.com, vbabka@...e.cz,
viro@...iv.linux.org.uk, vkuznets@...hat.com, wei.w.wang@...el.com,
will@...nel.org, willy@...radead.org, wyihan@...gle.com,
xiaoyao.li@...el.com, yan.y.zhao@...el.com, yilun.xu@...el.com,
yuzenghui@...wei.com, zhiquan1.li@...el.com
Subject: Re: [RFC PATCH v1 07/37] KVM: Introduce KVM_SET_MEMORY_ATTRIBUTES2
On 17/10/2025 21:11, Ackerley Tng wrote:
> Introduce a "version 2" of KVM_SET_MEMORY_ATTRIBUTES to support returning
> information back to userspace.
>
> This new ioctl and structure will, in a later patch, be shared as a
> guest_memfd ioctl, where the padding in the new kvm_memory_attributes2
> structure will be for writing the response from the guest_memfd ioctl to
> userspace.
>
> A new ioctl is necessary for these reasons:
>
> 1. KVM_SET_MEMORY_ATTRIBUTES is currently a write-only ioctl and does not
> allow userspace to read fields. There's nothing in code (yet?) that
> validates this, but using _IOWR for consistency would be prudent.
>
> 2. KVM_SET_MEMORY_ATTRIBUTES, when used as a guest_memfd ioctl, will need
> an additional field to provide userspace with more error details.
>
> Alternatively, a completely new ioctl could be defined, unrelated to
> KVM_SET_MEMORY_ATTRIBUTES, but using the same ioctl number and struct for
> the vm and guest_memfd ioctls streamlines the interface for userspace. In
> addition, any memory attributes, implemented on the vm or guest_memfd
> ioctl, can be easily shared with the other.
>
> Suggested-by: Sean Christopherson <seanjc@...gle.com>
> Signed-off-by: Ackerley Tng <ackerleytng@...gle.com>
> ---
> Documentation/virt/kvm/api.rst | 32 +++++++++++++++++++++++++++++++
> include/uapi/linux/kvm.h | 12 ++++++++++++
> virt/kvm/kvm_main.c | 35 +++++++++++++++++++++++++++++++---
> 3 files changed, 76 insertions(+), 3 deletions(-)
>
[...]
> diff --git a/include/uapi/linux/kvm.h b/include/uapi/linux/kvm.h
> index 52f6000ab0208..c300e38c7c9cd 100644
> --- a/include/uapi/linux/kvm.h
> +++ b/include/uapi/linux/kvm.h
[...]
> @@ -5366,15 +5375,35 @@ static long kvm_vm_ioctl(struct file *filp,
> }
> #endif /* CONFIG_HAVE_KVM_IRQ_ROUTING */
> #ifdef CONFIG_KVM_VM_MEMORY_ATTRIBUTES
> + case KVM_SET_MEMORY_ATTRIBUTES2:
> case KVM_SET_MEMORY_ATTRIBUTES: {
> - struct kvm_memory_attributes attrs;
> + struct kvm_memory_attributes2 attrs;
> + unsigned long size;
> +
> + if (ioctl == KVM_SET_MEMORY_ATTRIBUTES) {
> + /*
> + * Fields beyond struct kvm_userspace_memory_region shouldn't be
> + * accessed, but avoid leaking kernel memory in case of a bug.
> + */
> + memset(&mem, 0, sizeof(mem));
s/mem/attrs/g
> + size = sizeof(struct kvm_set_memory_attributes);
> + } else {
> + size = sizeof(struct kvm_set_memory_attributes2);
s/kvm_set_memory_attributes/kvm_memory_attributes/ (on both sizeof lines
above and in the SANITY_CHECK_MEMORY_ATTRIBUTES_FIELD macro).
> + }
> +
> + /* Ensure the common parts of the two structs are identical. */
> + SANITY_CHECK_MEMORY_ATTRIBUTES_FIELD(slot);
> + SANITY_CHECK_MEMORY_ATTRIBUTES_FIELD(flags);
> + SANITY_CHECK_MEMORY_ATTRIBUTES_FIELD(guest_phys_addr);
> + SANITY_CHECK_MEMORY_ATTRIBUTES_FIELD(memory_size);
> + SANITY_CHECK_MEMORY_ATTRIBUTES_FIELD(userspace_addr);
The fields are:
* address
* size
* attributes
* flags
The list you've got appears to match struct kvm_userspace_memory_region
- copy/paste error?
Thanks,
Steve
>
> r = -ENOTTY;
> if (!vm_memory_attributes)
> goto out;
>
> r = -EFAULT;
> - if (copy_from_user(&attrs, argp, sizeof(attrs)))
> + if (copy_from_user(&attrs, argp, size))
> goto out;
>
> r = kvm_vm_ioctl_set_mem_attributes(kvm, &attrs);
Powered by blists - more mailing lists