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: <ZV4kI2mu6fBVcZn9@gmail.com>
Date:   Wed, 22 Nov 2023 07:54:11 -0800
From:   Breno Leitao <leitao@...ian.org>
To:     Andrew Cooper <andrew.cooper3@...rix.com>
Cc:     jpoimboe@...nel.org, mingo@...hat.com, tglx@...utronix.de,
        bp@...en8.de, 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>,
        Jason Baron <jbaron@...mai.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        Masahiro Yamada <masahiroy@...nel.org>,
        Nathan Chancellor <nathan@...nel.org>,
        Nick Desaulniers <ndesaulniers@...gle.com>,
        Nicolas Schier <nicolas@...sle.eu>, leit@...a.com,
        linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
        Lukas Bulwahn <lukas.bulwahn@...il.com>,
        Sven Joachim <svenjoac@....de>, Ian Kent <raven@...maw.net>,
        Yu-cheng Yu <yu-cheng.yu@...el.com>,
        Kees Cook <keescook@...omium.org>,
        Rick Edgecombe <rick.p.edgecombe@...el.com>,
        Kim Phillips <kim.phillips@....com>,
        Juergen Gross <jgross@...e.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Jinghao Jia <jinghao@...ux.ibm.com>,
        Vincent Whitchurch <vincent.whitchurch@...s.com>,
        Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [PATCH v6 10/13] x86/bugs: Rename RETHUNK to MITIGATION_RETHUNK

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@...nel.org>
> > Signed-off-by: Breno Leitao <leitao@...ian.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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ