linux-kernel - Re: [PATCH v2 09/12] x86/msr: Use the alternatives mechanism for WRMSR

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: <20251001105058.GP3419281@noisy.programming.kicks-ass.net>
Date: Wed, 1 Oct 2025 12:50:58 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Juergen Gross <jgross@...e.com>
Cc: linux-kernel@...r.kernel.org, x86@...nel.org, llvm@...ts.linux.dev,
	xin@...or.com, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	Nathan Chancellor <nathan@...nel.org>,
	Nick Desaulniers <nick.desaulniers+lkml@...il.com>,
	Bill Wendling <morbo@...gle.com>,
	Justin Stitt <justinstitt@...gle.com>
Subject: Re: [PATCH v2 09/12] x86/msr: Use the alternatives mechanism for
 WRMSR

On Wed, Oct 01, 2025 at 10:49:31AM +0200, Juergen Gross wrote:

> Thinking more about that I believe there are additional problems:
> 
> Having overlapping alternatives not starting at the same address will result
> in problems with length padding of the outer alternative in case the inner
> one starting later is extending past the end of the outer one. This might be
> possible to handle, but it will be tedious.

Yes, this must not happen.

> Using your idea with pv_ops could result in the inner alternative not being
> at the start of the outer alternative AND being not the initial code. This
> would result in patching in the .altinstructions area instead of the normal
> .text site, resulting in possible loss of a patching action if the patched
> area would have been used as a replacement before.

Not quite, the nested alternative was in the orig_insn part. So it would
result in patching the orig text twice, once from the inner (which comes
first in the patch list) and then once again from the outer (which comes
later).

> So in my opinion allowing alternatives to nest without all inner levels
> starting at the same location as the outermost level would be a receipt for
> failure.

Certainly tricky, no argument there.

> I think I'll write another patch to BUG() in case such a situation is being
> detected.

Fair enough; we should not currently have any such cases. And going by
my attempt to make it work, its going to be really tricky in any case.

But please put on a comment on why, which explains the constraints.