linux-kernel - RE: [RFC PATCH 00/56] Dynamic mitigations

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:
 <LV3PR12MB9265BDF285491D93196A17D094F1A@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Fri, 24 Oct 2025 13:41:40 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
CC: Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>,
	Peter Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>,
	Ingo Molnar <mingo@...hat.com>, Dave Hansen <dave.hansen@...ux.intel.com>,
	"x86@...nel.org" <x86@...nel.org>, "H . Peter Anvin" <hpa@...or.com>,
	Alexander Graf <graf@...zon.com>, Boris Ostrovsky
	<boris.ostrovsky@...cle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 00/56] Dynamic mitigations

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>
> Sent: Friday, October 24, 2025 12:01 AM
> To: Kaplan, David <David.Kaplan@....com>
> Cc: Thomas Gleixner <tglx@...utronix.de>; Borislav Petkov <bp@...en8.de>; Peter
> Zijlstra <peterz@...radead.org>; Josh Poimboeuf <jpoimboe@...nel.org>; Ingo
> Molnar <mingo@...hat.com>; Dave Hansen <dave.hansen@...ux.intel.com>;
> x86@...nel.org; H . Peter Anvin <hpa@...or.com>; Alexander Graf
> <graf@...zon.com>; Boris Ostrovsky <boris.ostrovsky@...cle.com>; linux-
> kernel@...r.kernel.org
> Subject: Re: [RFC PATCH 00/56] Dynamic mitigations
>
> Although it adds some complexity, this adds a very useful feature. Thanks
> for doing this series.
>
> Just curious, for patching indirect branches, was replacing alternatives
> with static_calls considered? I haven't looked at the feasibility, but
> static_calls seems to be more suited for post-boot patching.

Something like that may be doable for indirect branches, but I think I dismissed that general direction because I didn't see how it could work for alternatives in general.  Runtime patching is quite complex, especially with the instruction emulation that happens within the int3 handler.  While that can work for branches, I didn't think that could work as a general solution.  Given how rare mitigation re-patching was expected to be, making everything quiesce seemed safer and significantly less complex.

>
> Thinking out loud, patching in something similar to suspend-to-RAM flow may
> reduce some corner cases. Barring the BSP, the APs gets reinitialized in
> that case.

Right now, the BSP handles most of the patching.  The AP's spin during the patching and then when it's complete, they update their local MSR values for the speculation related MSRs (similar to on AP startup I think).  But that should be all they need to do I think.

Thanks
--David Kaplan