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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZS0Lfy8LUdRG3ca0@gmail.com>
Date:   Mon, 16 Oct 2023 12:07:59 +0200
From:   Ingo Molnar <mingo@...nel.org>
To:     Borislav Petkov <bp@...en8.de>
Cc:     Josh Poimboeuf <jpoimboe@...nel.org>,
        Breno Leitao <leitao@...ian.org>, tglx@...utronix.de,
        Ingo Molnar <mingo@...hat.com>,
        Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org,
        "H. Peter Anvin" <hpa@...or.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Pawan Gupta <pawan.kumar.gupta@...ux.intel.com>, leit@...a.com,
        "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
        <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH v4] x86/bugs: Add a separate config for each mitigation


* Borislav Petkov <bp@...en8.de> 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