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

[Nikolay Borisov]

On 10/15/25 16:45, Kaplan, David wrote:
> [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.

It's not just about memory usage per-se but also memory pressure from 
allocation and the resulting fragmentation, though I'd think that 
majority of the allocation will fit into kmalloc-32 bucket, still having 
them as part of the kernel image eliminates the additional allocs.
> Thanks
> --David Kaplan