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

[Kaplan, David]

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Juergen Gross <jgross@xxxxxxxx>
> Sent: Wednesday, October 15, 2025 5:38 AM
> To: Kaplan, David <David.Kaplan@xxxxxxx>; Thomas Gleixner
> <tglx@xxxxxxxxxxxxx>; Borislav Petkov <bp@xxxxxxxxx>; Peter Zijlstra
> <peterz@xxxxxxxxxxxxx>; Josh Poimboeuf <jpoimboe@xxxxxxxxxx>; Pawan Gupta
> <pawan.kumar.gupta@xxxxxxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; Dave
> Hansen <dave.hansen@xxxxxxxxxxxxxxx>; x86@xxxxxxxxxx; H . Peter Anvin
> <hpa@xxxxxxxxx>
> Cc: Alexander Graf <graf@xxxxxxxxxx>; Boris Ostrovsky
> <boris.ostrovsky@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx
> 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@xxxxxxx>
>
> 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