linux-kernel - Re: [PATCH v4 02/11] x86/startup_64: Replace pointer fixups with RIP-relative references

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240219100124.GCZdMm9IAWoMcfEKhF@fat_crate.local>
Date: Mon, 19 Feb 2024 11:01:24 +0100
From: Borislav Petkov <bp@...en8.de>
To: Ard Biesheuvel <ardb@...nel.org>
Cc: Ard Biesheuvel <ardb+git@...gle.com>, linux-kernel@...r.kernel.org,
	Kevin Loughlin <kevinloughlin@...gle.com>,
	Tom Lendacky <thomas.lendacky@....com>,
	Dionna Glaze <dionnaglaze@...gle.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Andy Lutomirski <luto@...nel.org>, Arnd Bergmann <arnd@...db.de>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <ndesaulniers@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>,
	Kees Cook <keescook@...omium.org>, Brian Gerst <brgerst@...il.com>,
	linux-arch@...r.kernel.org, llvm@...ts.linux.dev
Subject: Re: [PATCH v4 02/11] x86/startup_64: Replace pointer fixups with
 RIP-relative references

On Sat, Feb 17, 2024 at 02:58:29PM +0100, Ard Biesheuvel wrote:
> More testing is always good, but I am not particularly nervous about
> these changes.

Perhaps but there's a big difference between testing everything as much
as one can and *then* queueing it - vs testing a bit, not being really
nervous about the changes and then someone reporting a snafu when the
patches are already in Linus' tree.

Means dropping everything and getting on that. And then imagine a couple
more breakages happening in parallel and needing urgent attention.

Not something you wanna deal with. Speaking from my experience, at
least.

> I could split this up into 3+ patches so we could bisect any resulting
> issues more effectively.

Yeah, splitting changes into separate bits - ala, one logical change per
patch - is always a good idea.

In this particular case, I don't mind splitting them even more so that
it is perfectly clear what happens and looking at those changes doesn't
make people have to go look at the source to figure out what the change
actually looks like applied, in order to fully grok it.

Thx.

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette