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

[Nikolay Borisov <nik.borisov@suse.com>]

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

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