Re: [RFC PATCH 00/56] Dynamic mitigations

[Boris Ostrovsky]

On 10/14/25 2:06 PM, Kaplan, David wrote:
> [AMD Official Use Only - AMD Internal Distribution Only]
>
> > -----Original Message-----
> > From: Josh Poimboeuf <jpoimboe@xxxxxxxxxx>
> > Sent: Tuesday, October 14, 2025 11:29 AM
> > To: Kaplan, David <David.Kaplan@xxxxxxx>
> > Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>; Borislav Petkov <bp@xxxxxxxxx>; Peter
> > Zijlstra <peterz@xxxxxxxxxxxxx>; Pawan Gupta
> > <pawan.kumar.gupta@xxxxxxxxxxxxxxx>; Ingo Molnar <mingo@xxxxxxxxxx>; Dave
> > Hansen <dave.hansen@xxxxxxxxxxxxxxx>; x86@xxxxxxxxxx; H . Peter Anvin
> > <hpa@xxxxxxxxx>; Alexander Graf <graf@xxxxxxxxxx>; Boris Ostrovsky
> > <boris.ostrovsky@xxxxxxxxxx>; linux-kernel@xxxxxxxxxxxxxxx
> > Subject: Re: [RFC PATCH 00/56] Dynamic mitigations


> > I'm not really a fan of this.  It adds complexity to some areas that are
> > already struggling with too much complexity.
> >
> > IMO this would need some REALLY strong justification, more than just
> > "hey, this makes things more convenient."
> >
> > The mitigations should be a "set it and forget it" thing.  I don't see
> > anything here which justifies the considerable maintenance burden this
> > would add for all existing and future mitigations.
>
> The problem is there are environments like the one outlined where you can't just 'set it and forget it' because the kernel needs it set at boot-time, but in these environments you don't know how to configure the system until much later in boot.  So you end up running with the default settings all the time, even if you don't need them.  And the default settings can have significant performance impacts in many cases.
>
> The cloud guys on this thread may be able to offer some additional color here since I believe that's where you're most likely to have this situation.


We've had quite a few cases where initially selected mitigation would 
turn out to be wrong --- either because we discovered that performance 
characteristics were not what we expected or that mitigation had some 
issues (i.e. bugs). Once could argue that this could be true of any code 
but this area has been particularly troublesome.

There are ways to get around this such as live migration or 
ksplice/kpatch but these are not always possible or practical.


-boris