RE: [RFC PATCH 00/56] Dynamic mitigations

Kaplan, David
2025-10-24T13:41:44Z

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Pawan Gupta <pawan.kumar.gupta@linux.intel.com>
> Sent: Friday, October 24, 2025 12:01 AM
> To: Kaplan, David <David.Kaplan@amd.com>
> Cc: Thomas Gleixner <tglx@linutronix.de>; Borislav Petkov <bp@alien8.de>; Peter
> Zijlstra <peterz@infradead.org>; Josh Poimboeuf <jpoimboe@kernel.org>; Ingo
> Molnar <mingo@redhat.com>; Dave Hansen <dave.hansen@linux.intel.com>;
> x86@kernel.org; H . Peter Anvin <hpa@zytor.com>; Alexander Graf
> <graf@amazon.com>; Boris Ostrovsky <boris.ostrovsky@oracle.com>; linux-
> kernel@vger.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