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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <91ACE1D6-851A-413E-9F1F-F015A36FE49C@zytor.com>
Date: Wed, 25 Jun 2025 11:51:28 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Sohil Mehta <sohil.mehta@...el.com>,
        "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,
        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 June 20, 2025 11:14:56 AM PDT, Sohil Mehta <sohil.mehta@...el.com> wrote:
>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);
>> +}
>> +

"Regardless" is correct. LASS only considers which hemisphere the virtual address is located in, because it is explicitly designed to prevent walking the page tables in the "wrong" hemisphere and therefore speculative accesses that happen to form pointers into user space addresses will not cause TLB or cache fills that might be possible to probe.

The obvious exception is when the kernel is intentionally performing accesses on behalf of user space, which is exactly what SMAP tells the hardware already.