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

[Ingo Molnar]

* Borislav Petkov <bp@xxxxxxxxx> wrote:

> On Wed, Oct 11, 2023 at 03:03:25PM -0700, Josh Poimboeuf wrote:
> > I wouldn't call it senseless churn.  There are concrete benefits -- for
> > both users and developers -- of having all the mitigation config options
> > living in the same config namespace.
> 
> I don't see it. What does the same namespace give you?

Having the current inconsistent Kconfig mess of CPU bug mitigation options 
is called 'technical debt', and it is a liability.

Just look at it in its messiness:

  CONFIG_RETPOLINE=y
  CONFIG_PAGE_TABLE_ISOLATION=y
  CONFIG_CPU_UNRET_ENTRY=y
  CONFIG_CALL_DEPTH_TRACKING=y
  CONFIG_CPU_IBPB_ENTRY=y
  CONFIG_CPU_IBRS_ENTRY=y
  CONFIG_CPU_SRSO=y
  CONFIG_SLS=y

Or current naming is confusing:

 - 'CONFIG_PAGE_TABLE_ISOLATION', which works around a CPU bug at hideous 
    runtime costs switching pagetables at every system call entry and exit, 
    reads like an isolation feature like CONFIG_CPU_ISOLATION=y, which is a 
    useful feature that improves worst-case latencies at essentially no 
    cost ...

 - 'CONFIG_CPU_IBPB_ENTRY=y' reads like a useful system call CPU feature. 
    Nothing in the name tells us that it's a workaround for a CPU bug, with 
    a significant runtime cost.

 -  What is CONFIG_SLS? It's a compiler-driven mitigation feature, with a 
    cost, not a driver for the Space Launch System.

 -  I could go on. Literally *every* mitigation feature Kconfig name we have 
    currently is problematic in one fashion or another: and all of them are 
    whitewashing the fact that they are expensive features to work around 
    CPU bugs...

All this mess was created due to arguably rushed fix-the-next-vulnerability 
time pressures of the last ~2 years, not due to some holy grand design 
decisions we wish to preserve as maintainers...

The first 2-3 mitigation options not being harmonized was understandable, 
because we really didn't know where it would stop. But we are up to ~8 
already.

Unless someone like Linus shuts down this effort with a NAK, this kind of 
harmonization would be welcome IMHO:

  CONFIG_MITIGATION_PAGE_TABLE_ISOLATION
  CONFIG_MITIGATION_RETPOLINE
  CONFIG_MITIGATION_UNRET_ENTRY
  CONFIG_MITIGATION_CALL_DEPTH_TRACKING
  CONFIG_MITIGATION_IBPB_ENTRY
  CONFIG_MITIGATION_IBRS_ENTRY
  CONFIG_MITIGATION_SRSO
  CONFIG_MITIGATION_SLS

Efforts by competent people fixing this technical debt comprehensively are 
welcome in my book, as long as advantages are substantial and the 
inter-tree churn is not prohibitive - which I believe is true in this case, 
and churn effect can be reduced via smart timing of rename-patches in any case.

Thanks,

	Ingo