Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
Sender: Ingo Molnar <mingo.kernel.org@gmail.com>
Date:   Mon, 16 Oct 2023 12:07:59 +0200
From:   Ingo Molnar <mingo@kernel.org>
To:     Borislav Petkov <bp@alien8.de>
Cc:     Josh Poimboeuf <jpoimboe@kernel.org>,
        Breno Leitao <leitao@debian.org>, tglx@linutronix.de,
        Ingo Molnar <mingo@redhat.com>,
        Dave Hansen <dave.hansen@linux.intel.com>, x86@kernel.org,
        "H. Peter Anvin" <hpa@zytor.com>,
        Peter Zijlstra <peterz@infradead.org>,
        Pawan Gupta <pawan.kumar.gupta@linux.intel.com>, leit@meta.com,
        "open list:X86 ARCHITECTURE (32-BIT AND 64-BIT)" 
        <linux-kernel@vger.kernel.org>,
        Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH v4] x86/bugs: Add a separate config for each mitigation
Message-ID: <ZS0Lfy8LUdRG3ca0@gmail.com>
References: <20231010103028.4192223-1-leitao@debian.org>
 <20231011044252.42bplzjsam3qsasz@treble>
 <20231011190317.GDZSbxdd5TuCIp5+JN@fat_crate.local>
 <20231011220325.5uje4xnfxuccumm7@treble>
 <20231012072920.GAZSegUJkwHbcernQo@fat_crate.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20231012072920.GAZSegUJkwHbcernQo@fat_crate.local>
Precedence: bulk


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