Re: [PATCH v3] x86/bugs: Add a separate config for each mitigation

[Pawan Gupta]

On Thu, Sep 28, 2023 at 06:40:18AM -0700, Dave Hansen wrote:
> On 9/28/23 05:45, Breno Leitao wrote:
> > 1) Create one Kconfig entry per mitigation, so, the user can pick and
> > choose what to enable and disable. (Version 3 of this patch. May need a
> > re-spin due to the new mitigations being added.)
> 
> This means, what, roughly 18 today?
> 
> #define X86_BUG_CPU_MELTDOWN		X86_BUG(14)
> ...
> #define X86_BUG_GDS                     X86_BUG(30)
> 
> Plus two bonus ones:
> 
> #define X86_BUG_SRSO                    X86_BUG(1*32 + 0)
> #define X86_BUG_DIV0                    X86_BUG(1*32 + 1)
> 
> ... and we've slowed down the rate at which we're adding these, but
> we're still seeing a couple a year.
> 
> Perhaps Pawan and the others actually _doing_ the patches for these can
> speak up, but I don't think adding a Kconfig option will be too much
> additional work for each new X86_BUG.

It is trivial, but seems unnecessary IMO.

> I still think it's highly unlikely that someone will come through and
> pick and choose among a few dozen vulnerabilities.

Second that.

If we do want to provide more control, personally I would like:

 - Global control for all mitigations
	- Enable only cheap mitigations

This could enable mitigations as long as it doesn't hurt the performance
too badly. The challenge being whether a mitigation is cheap or costly
is subjective and highly depends on workloads. Without a standard way of
categorizing a mitigation it will be hard to reach a consensus. OTOH,
there are mitigations that are relatively cheaper e.g. Enhanced IBRS.

Other way to categorize could be:

 - Global control for all mitigations
	- Guest only mitigations (host userspace is trusted)

This control can disable all mitigation for userspace, but will continue
to mitigate host against a rouge guests. This could be quite a lot of
work.