linux-kernel - Re: [PATCHv6 01/16] x86/cpu: Enumerate the LASS feature bits

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: <248e272c-79ec-4c11-a3a8-dff1de2147c0@intel.com>
Date: Fri, 20 Jun 2025 11:14:56 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>, Dave Hansen
	<dave.hansen@...ux.intel.com>
CC: Jonathan Corbet <corbet@....net>, Ingo Molnar <mingo@...nel.org>, "Pawan
 Gupta" <pawan.kumar.gupta@...ux.intel.com>, Daniel Sneddon
	<daniel.sneddon@...ux.intel.com>, Kai Huang <kai.huang@...el.com>, "Sandipan
 Das" <sandipan.das@....com>, Breno Leitao <leitao@...ian.org>, Rick Edgecombe
	<rick.p.edgecombe@...el.com>, Alexei Starovoitov <ast@...nel.org>, Hou Tao
	<houtao1@...wei.com>, Juergen Gross <jgross@...e.com>, Vegard Nossum
	<vegard.nossum@...cle.com>, Kees Cook <kees@...nel.org>, Eric Biggers
	<ebiggers@...gle.com>, Jason Gunthorpe <jgg@...pe.ca>, "Masami Hiramatsu
 (Google)" <mhiramat@...nel.org>, Andrew Morton <akpm@...ux-foundation.org>,
	Luis Chamberlain <mcgrof@...nel.org>, Yuntao Wang <ytcoode@...il.com>,
	"Rasmus Villemoes" <linux@...musvillemoes.dk>, Christophe Leroy
	<christophe.leroy@...roup.eu>, Tejun Heo <tj@...nel.org>, Changbin Du
	<changbin.du@...wei.com>, Huang Shijie <shijie@...amperecomputing.com>,
	"Geert Uytterhoeven" <geert+renesas@...der.be>, Namhyung Kim
	<namhyung@...nel.org>, Arnaldo Carvalho de Melo <acme@...hat.com>,
	<linux-doc@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<linux-efi@...r.kernel.org>, <linux-mm@...ck.org>, Yian Chen
	<yian.chen@...el.com>, Andy Lutomirski <luto@...nel.org>, Thomas Gleixner
	<tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov
	<bp@...en8.de>, <x86@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, Peter
 Zijlstra <peterz@...radead.org>, "Ard Biesheuvel" <ardb@...nel.org>, "Paul E.
 McKenney" <paulmck@...nel.org>, "Josh Poimboeuf" <jpoimboe@...nel.org>,
	Xiongwei Song <xiongwei.song@...driver.com>, Xin Li <xin3.li@...el.com>,
	"Mike Rapoport (IBM)" <rppt@...nel.org>, "Brijesh Singh"
	<brijesh.singh@....com>, Michael Roth <michael.roth@....com>, Tony Luck
	<tony.luck@...el.com>, Alexey Kardashevskiy <aik@....com>, Alexander Shishkin
	<alexander.shishkin@...ux.intel.com>
Subject: Re: [PATCHv6 01/16] x86/cpu: Enumerate the LASS feature bits

On 6/20/2025 6:53 AM, Kirill A. Shutemov wrote:
>  
> +/*
> + * The CLAC/STAC instructions toggle enforcement of X86_FEATURE_SMAP.
> + *
> + * X86_FEATURE_LASS requires flipping the AC flag when accessing the lower half
> + * of the virtual address space, regardless of the _PAGE_BIT_USER bit in the
> + * page tables. lass_clac/stac() should be used for these cases.
> + *

Is this supposed to be "regardless" or only when the _PAGE_BIT_USER bit
it set? The way the sentence is worded it would seem that the kernel
could always use lass_clac()/stac() since the value in _PAGE_BIT_USER
doesn't matter.

Please correct me if I am wrong, but here is my understanding:

X86_FEATURE_SMAP and X86_FEATURE_LASS both complain when the kernel
tries to access the lower half of the virtual addresses.

SMAP flags an issue if _PAGE_BIT_USER is not set. LASS would #GP in both
cases with or without the _PAGE_BIT_USER being set.

However, in terms of usage, we want to use LASS specific stac()/clac()
only when _PAGE_BIT_USER is set. Since this won't be flagged by SMAP.

@Dave Hansen, you had suggested separating out the SMAP/LASS AC toggle
functions. But, the difference in usage between both of them seems very
subtle. Could this be easily misused?

For example, there is no failure that would happen if someone
incorrectly uses the SMAP specific clac()/stac() calls instead of the
LASS ones.

> + * Note: a barrier is implicit in alternative().
> + */
> +
>  static __always_inline void clac(void)
>  {
> -	/* Note: a barrier is implicit in alternative() */
>  	alternative("", "clac", X86_FEATURE_SMAP);
>  }
>  
>  static __always_inline void stac(void)
>  {
> -	/* Note: a barrier is implicit in alternative() */
>  	alternative("", "stac", X86_FEATURE_SMAP);
>  }
>  
> +static __always_inline void lass_clac(void)
> +{
> +	alternative("", "clac", X86_FEATURE_LASS);
> +}
> +
> +static __always_inline void lass_stac(void)
> +{
> +	alternative("", "stac", X86_FEATURE_LASS);
> +}
> +