linux-kernel - Re: [PATCH v3 2/9] x86/entry/vdso: refactor the vdso build

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: <CAMzpN2gC1NWFu5XG49cCrktTUZbDBbng71RjpALMxzSOmPrQPg@mail.gmail.com>
Date: Thu, 13 Nov 2025 17:41:50 -0500
From: Brian Gerst <brgerst@...il.com>
To: "H. Peter Anvin" <hpa@...or.com>
Cc: "Jason A. Donenfeld" <Jason@...c4.com>, "Peter Zijlstra (Intel)" <peterz@...radead.org>, "Theodore Ts'o" <tytso@....edu>, 
	Thomas Weißschuh <thomas.weissschuh@...utronix.de>, 
	Xin Li <xin@...or.com>, Andrew Cooper <andrew.cooper3@...rix.com>, 
	Andy Lutomirski <luto@...nel.org>, Ard Biesheuvel <ardb@...nel.org>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>, 
	James Morse <james.morse@....com>, Jarkko Sakkinen <jarkko@...nel.org>, 
	Josh Poimboeuf <jpoimboe@...nel.org>, Kees Cook <kees@...nel.org>, Nam Cao <namcao@...utronix.de>, 
	Oleg Nesterov <oleg@...hat.com>, Perry Yuan <perry.yuan@....com>, 
	Thomas Gleixner <tglx@...utronix.de>, Thomas Huth <thuth@...hat.com>, Uros Bizjak <ubizjak@...il.com>, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, linux-sgx@...r.kernel.org, 
	x86@...nel.org
Subject: Re: [PATCH v3 2/9] x86/entry/vdso: refactor the vdso build

On Thu, Nov 13, 2025 at 4:12 PM H. Peter Anvin <hpa@...or.com> wrote:
>
> On 2025-11-13 10:38, Brian Gerst wrote:
> >
> > Some of these changes (like moving vdso2c) can be split out into
> > smaller patches.
> >
>
> Sure, but is it worth the extra work?
>
>         -hpa
>

The vdso2c move would be a clean patch on its own.  The rest would
probably need too many intermediate steps to be worth the effort, but
it does make it harder to compare the new and old code.  Not a
dealbreaker though.