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: <B3004060-F512-460B-BEEC-C6F335ED6456@linux.dev>
Date: Tue, 14 Oct 2025 13:16:55 +0200
From: Thorsten Blum <thorsten.blum@...ux.dev>
To: Sean Christopherson <seanjc@...gle.com>
Cc: Paolo Bonzini <pbonzini@...hat.com>,
 Thomas Gleixner <tglx@...utronix.de>,
 Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>,
 Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org,
 "H. Peter Anvin" <hpa@...or.com>,
 "Kirill A. Shutemov" <kas@...nel.org>,
 Rick Edgecombe <rick.p.edgecombe@...el.com>,
 kvm@...r.kernel.org,
 linux-kernel@...r.kernel.org,
 linux-coco@...ts.linux.dev
Subject: Re: [PATCH] KVM: TDX: Replace kmalloc + copy_from_user with
 memdup_user in tdx_td_init

On 14. Oct 2025, at 00:15, Sean Christopherson wrote:
> On Tue, Sep 16, 2025, Thorsten Blum wrote:
>> Use get_user() to retrieve the number of entries instead of allocating
>> memory for 'init_vm' with the maximum size, copying 'cmd->data' to it,
>> only to then read the actual entry count 'cpuid.nent' from the copy.
>> 
>> Return -E2BIG early if 'nr_user_entries' exceeds KVM_MAX_CPUID_ENTRIES.
> 
> I think I'll drop this line from the changelog.  At first glance I thought you
> were calling out a change in behavior, and my hackles went up.  :-)
> 
>> Use memdup_user() to allocate just enough memory to fit all entries and
>> to copy 'cmd->data' from userspace. Use struct_size() instead of
>> manually calculating the number of bytes to allocate and copy.
>> 
>> No functional changes intended.
>> 
>> Signed-off-by: Thorsten Blum <thorsten.blum@...ux.dev>
>> ---
>> [...]
> 
> Any objection to calling this user_data instead of user_init_vm?  I keep reading
> user_init_vm as a flag or command, e.g. "user initialized VM" or something, not
> as a pointer to user data.

No objection.

> No need for a v2, I'll fixup to whatever we settle on (assuming no one jumps in
> with a crazy idea).

Ok thanks!


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ