Message-ID:
 <LV3PR12MB9265295E1470ED9C5BE9EF9094FAA@LV3PR12MB9265.namprd12.prod.outlook.com>
Date: Wed, 29 Oct 2025 16:26:58 +0000
From: "Kaplan, David" <David.Kaplan@....com>
To: Nikolay Borisov <nik.borisov@...e.com>, Juergen Gross <jgross@...e.com>,
	Thomas Gleixner <tglx@...utronix.de>, Borislav Petkov <bp@...en8.de>, Peter
 Zijlstra <peterz@...radead.org>, Josh Poimboeuf <jpoimboe@...nel.org>, Pawan
 Gupta <pawan.kumar.gupta@...ux.intel.com>, Ingo Molnar <mingo@...hat.com>,
	Dave Hansen <dave.hansen@...ux.intel.com>, "x86@...nel.org" <x86@...nel.org>,
	"H . Peter Anvin" <hpa@...or.com>
CC: Alexander Graf <graf@...zon.com>, Boris Ostrovsky
	<boris.ostrovsky@...cle.com>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [RFC PATCH 34/56] x86/alternative: Save old bytes for
 alternatives

[AMD Official Use Only - AMD Internal Distribution Only]

> -----Original Message-----
> From: Nikolay Borisov <nik.borisov@...e.com>
> Sent: Wednesday, October 29, 2025 4:37 AM
> To: Kaplan, David <David.Kaplan@....com>; Juergen Gross
> <jgross@...e.com>; Thomas Gleixner <tglx@...utronix.de>; Borislav Petkov
> <bp@...en8.de>; Peter Zijlstra <peterz@...radead.org>; Josh Poimboeuf
> <jpoimboe@...nel.org>; Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>;
> Ingo Molnar <mingo@...hat.com>; Dave Hansen <dave.hansen@...ux.intel.com>;
> x86@...nel.org; H . Peter Anvin <hpa@...or.com>
> Cc: Alexander Graf <graf@...zon.com>; Boris Ostrovsky
> <boris.ostrovsky@...cle.com>; linux-kernel@...r.kernel.org
> Subject: Re: [RFC PATCH 34/56] x86/alternative: Save old bytes for alternatives
>
> Caution: This message originated from an External Source. Use proper caution
> when opening attachments, clicking links, or responding.
>
>
> On 10/27/25 16:19, Kaplan, David wrote:
> > [AMD Official Use Only - AMD Internal Distribution Only]
> >
> >> -----Original Message-----
> >> From: Nikolay Borisov <nik.borisov@...e.com>
> >> Sent: Monday, October 27, 2025 6:35 AM
> >> To: Kaplan, David <David.Kaplan@....com>; Juergen Gross
> <jgross@...e.com>;
> >> Thomas Gleixner <tglx@...utronix.de>; Borislav Petkov <bp@...en8.de>; Peter
> >> Zijlstra <peterz@...radead.org>; Josh Poimboeuf <jpoimboe@...nel.org>;
> Pawan
> >> Gupta <pawan.kumar.gupta@...ux.intel.com>; Ingo Molnar
> <mingo@...hat.com>;
> >> Dave Hansen <dave.hansen@...ux.intel.com>; x86@...nel.org; H . Peter Anvin
> >> <hpa@...or.com>
> >> Cc: Alexander Graf <graf@...zon.com>; Boris Ostrovsky
> >> <boris.ostrovsky@...cle.com>; linux-kernel@...r.kernel.org
> >> Subject: Re: [RFC PATCH 34/56] x86/alternative: Save old bytes for alternatives
> >>
> >> Caution: This message originated from an External Source. Use proper caution
> >> when opening attachments, clicking links, or responding.
> >>
> >>
> >> On 10/15/25 16:45, Kaplan, David wrote:
> >>> [AMD Official Use Only - AMD Internal Distribution Only]
> >>>
> >>>> -----Original Message-----
> >>>> From: Juergen Gross <jgross@...e.com>
> >>>> Sent: Wednesday, October 15, 2025 5:38 AM
> >>>> To: Kaplan, David <David.Kaplan@....com>; Thomas Gleixner
> >>>> <tglx@...utronix.de>; Borislav Petkov <bp@...en8.de>; Peter Zijlstra
> >>>> <peterz@...radead.org>; Josh Poimboeuf <jpoimboe@...nel.org>; Pawan
> >> Gupta
> >>>> <pawan.kumar.gupta@...ux.intel.com>; Ingo Molnar <mingo@...hat.com>;
> >> Dave
> >>>> Hansen <dave.hansen@...ux.intel.com>; x86@...nel.org; H . Peter Anvin
> >>>> <hpa@...or.com>
> >>>> Cc: Alexander Graf <graf@...zon.com>; Boris Ostrovsky
> >>>> <boris.ostrovsky@...cle.com>; linux-kernel@...r.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@....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.
> >
> > I see.  Just to understand, the issue is more with the numerous small allocations
> right? (that is the kmalloc at each alt_site)  And less about the single large allocation
> of the array?
>
> Yep, do you have some statistics how many allocs have to be done?
>

On a typical kernel, I'm seeing 6427 kmallocs() from this with a total size of ~36kb.

If that is too many, another option could be to go through and figure out the total size needed and then do one big allocation.

--David Kaplan

Powered by blists - more mailing lists