RE: [RFC PATCH 34/56] x86/alternative: Save old bytes for alternatives

Kaplan, David
2025-10-15T13:45:46Z

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Juergen Gross <jgross@suse.com>
> Sent: Wednesday, October 15, 2025 5:38 AM
> To: Kaplan, David <David.Kaplan@amd.com>; Thomas Gleixner
> <tglx@linutronix.de>; Borislav Petkov <bp@alien8.de>; Peter Zijlstra
> <peterz@infradead.org>; Josh Poimboeuf <jpoimboe@kernel.org>; Pawan Gupta
> <pawan.kumar.gupta@linux.intel.com>; Ingo Molnar <mingo@redhat.com>; Dave
> Hansen <dave.hansen@linux.intel.com>; x86@kernel.org; H . Peter Anvin
> <hpa@zytor.com>
> Cc: Alexander Graf <graf@amazon.com>; Boris Ostrovsky
> <boris.ostrovsky@oracle.com>; linux-kernel@vger.kernel.org
> Subject: Re: [RFC PATCH 34/56] x86/alternative: Save old bytes for alternatives
>
> On 13.10.25 16:34, David Kaplan wrote:
> > Save the existing instruction bytes at each alternative site when patching.
> > This is only done the first time, and these will be used later to help
> > restore the code back to its original form.
> >
> > Signed-off-by: David Kaplan <david.kaplan@amd.com>
>
> Instead of saving the original instructions at runtime, why don't you
> expand struct alt_instr to have an additional offset to a saved copy
> of the original instruction, located in .altinstr_replacement?
>
> The new field should be guarded with #ifdef CONFIG_DYNAMIC_MITIGATIONS,
> of course, like the added handling in the ALTERNATIVE() macros.
>

That's an interesting idea, I think that could work. That would make the kernel image on disk (slightly) larger though, as the original bytes will essentially be duplicated (at the original location and in .altinstr_replacement). I'm not sure which is the better trade-off (kernel image bytes on disk vs runtime memory usage). Although I think we're talking about a relatively small amount of memory regardless. Most of the runtime overhead of dynamic mitigations comes from remembering the call sites/returns.

Thanks
--David Kaplan