Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:7 as permitted sender) client-ip=2620:137:e000::3:7;
Date:   Wed, 22 Nov 2023 07:54:11 -0800
From:   Breno Leitao <leitao@debian.org>
To:     Andrew Cooper <andrew.cooper3@citrix.com>
Cc:     jpoimboe@kernel.org, mingo@redhat.com, tglx@linutronix.de,
        bp@alien8.de, 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>,
        Jason Baron <jbaron@akamai.com>,
        Steven Rostedt <rostedt@goodmis.org>,
        Ard Biesheuvel <ardb@kernel.org>,
        Masahiro Yamada <masahiroy@kernel.org>,
        Nathan Chancellor <nathan@kernel.org>,
        Nick Desaulniers <ndesaulniers@google.com>,
        Nicolas Schier <nicolas@fjasle.eu>, leit@meta.com,
        linux-kernel@vger.kernel.org, Ingo Molnar <mingo@kernel.org>,
        Lukas Bulwahn <lukas.bulwahn@gmail.com>,
        Sven Joachim <svenjoac@gmx.de>, Ian Kent <raven@themaw.net>,
        Yu-cheng Yu <yu-cheng.yu@intel.com>,
        Kees Cook <keescook@chromium.org>,
        Rick Edgecombe <rick.p.edgecombe@intel.com>,
        Kim Phillips <kim.phillips@amd.com>,
        Juergen Gross <jgross@suse.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        Randy Dunlap <rdunlap@infradead.org>,
        Jinghao Jia <jinghao@linux.ibm.com>,
        Vincent Whitchurch <vincent.whitchurch@axis.com>,
        Arnaldo Carvalho de Melo <acme@redhat.com>
Subject: Re: [PATCH v6 10/13] x86/bugs: Rename RETHUNK to MITIGATION_RETHUNK
Message-ID: <ZV4kI2mu6fBVcZn9@gmail.com>
References: <20231121160740.1249350-1-leitao@debian.org>
 <20231121160740.1249350-11-leitao@debian.org>
 <da12ea3e-8fef-49d4-aea1-40a46a5ae056@citrix.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <da12ea3e-8fef-49d4-aea1-40a46a5ae056@citrix.com>
Precedence: bulk

Hello Andrew,

On Tue, Nov 21, 2023 at 09:39:47PM +0000, Andrew Cooper wrote:
> On 21/11/2023 4:07 pm, Breno Leitao wrote:
> > CPU mitigations config entries are inconsistent, and names are hard to
> > related. There are concrete benefits for both users and developers of
> > having all the mitigation config options living in the same config
> > namespace.
> >
> > The mitigation options should have consistency and start with
> > MITIGATION.
> >
> > Rename the Kconfig entry from RETHUNK to MITIGATION_RETHUNK.
> >
> > Suggested-by: Josh Poimboeuf <jpoimboe@kernel.org>
> > Signed-off-by: Breno Leitao <leitao@debian.org>
> 
> (I'm CC'd on only this single patch so I can't see what's going on, but)
> 
> Really?? Rethunk[sic] isn't a mitigation.? It's just a compiler
> transformation for return instructions upon which various mitigations
> depend.

The MITIGATION namespace is not only for mitigation, but, for "features"
that are available with the only purpose of mitigating speculative
hardware vulnerability. The original suggested namespace was "MITIGATE",
and then it would make no sense for RETHUNK, since, we are not
mitigating RETHUNK per se. Please check the discussion here:

 https://lore.kernel.org/all/20231011044252.42bplzjsam3qsasz@treble/

That said, the way the x86 Kconfig is organized today, CONFIG_RETHUNK is
very focused in solving a mitigations problem, thus, the MITIGATION_
namespace has been added to it.

For instance, CONFIG_RETHUNK is inside the SPECULATION_MITIGATIONS,
thus, it is only enabled if SPECULATION_MITIGATIONS is set.

  menuconfig SPECULATION_MITIGATIONS
  bool "Mitigations for speculative execution vulnerabilities"

	config RETHUNK
		bool "Enable return-thunks"
		depends on MITIGATION_RETPOLINE && CC_HAS_RETURN_THUNK
		help
		  Compile the kernel with the return-thunks compiler option to guard
		  against kernel-to-user data leaks by avoiding return speculation.
		  Requires a compiler with -mfunction-return=thunk-extern
		  support for full protection. The kernel may run slower.

  endif

Thanks for the feedback.