linux-kernel - Re: [PATCH v10 01/15] 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] [day] [month] [year] [list]

Message-ID: <6da9ae07-622e-428b-b1de-df4ead7a7761@zytor.com>
Date: Wed, 15 Oct 2025 20:10:27 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Sohil Mehta <sohil.mehta@...el.com>, Dave Hansen <dave.hansen@...el.com>,
        "Edgecombe, Rick P" <rick.p.edgecombe@...el.com>,
        "dave.hansen@...ux.intel.com" <dave.hansen@...ux.intel.com>
Cc: "corbet@....net" <corbet@....net>, "ardb@...nel.org" <ardb@...nel.org>,
        "david.laight.linux@...il.com" <david.laight.linux@...il.com>,
        "luto@...nel.org" <luto@...nel.org>,
        "jpoimboe@...nel.org" <jpoimboe@...nel.org>,
        "andrew.cooper3@...rix.com" <andrew.cooper3@...rix.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        "alexander.shishkin@...ux.intel.com" <alexander.shishkin@...ux.intel.com>,
        "kas@...nel.org" <kas@...nel.org>,
        "seanjc@...gle.com" <seanjc@...gle.com>,
        "rdunlap@...radead.org" <rdunlap@...radead.org>,
        "dwmw@...zon.co.uk" <dwmw@...zon.co.uk>,
        "vegard.nossum@...cle.com" <vegard.nossum@...cle.com>,
        "xin@...or.com" <xin@...or.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
        "kees@...nel.org" <kees@...nel.org>,
        "peterz@...radead.org" <peterz@...radead.org>,
        "linux-efi@...r.kernel.org" <linux-efi@...r.kernel.org>,
        "geert@...ux-m68k.org" <geert@...ux-m68k.org>,
        "tglx@...utronix.de" <tglx@...utronix.de>,
        "mingo@...hat.com" <mingo@...hat.com>, "bp@...en8.de" <bp@...en8.de>,
        "x86@...nel.org" <x86@...nel.org>
Subject: Re: [PATCH v10 01/15] x86/cpu: Enumerate the LASS feature bits

On 2025-10-07 13:20, Sohil Mehta wrote:
> 
> The spec says,
> "A supervisor-mode data access causes a LASS violation if it would
> access a linear address of which bit 63 is 0, supervisor-mode access
> protection is enabled (by setting CR4.SMAP), and either RFLAGS.AC = 0 or
> the access is an implicit supervisor-mode access."
> 
> One could argue that the LASS hardware enforcement of the kernel data
> accesses *depends* on SMAP being enabled.
> 
>> Actually, it might be worth breaking this dependency hunk out into its
>> own patch, just so there's a nice clean place to discuss this.
> 
> Sure, we can talk about the above wording in the spec, as well as the
> STAC/CLAC dependency in a separate patch.
> 
> I included some information in the cover letter to explain that:
> 
> When there are valid reasons for the kernel to access memory in the user
> half, it can temporarily suspend LASS enforcement by toggling the
> RFLAGS.AC bit. Most of these cases are already covered today through the
> stac()/clac() pairs, which avoid SMAP violations. However, there are
> kernel usages, such as text poking, that access mappings (!_PAGE_USER)
> in the lower half of the address space. LASS-specific AC bit toggling is
> added for these cases.

Just to be clear: there is no reason to spend any time whatsoever on
supporting LASS without SMAP, because no such hardware is ever expected to
exist. The CPU feature dependencies are not all necessarily architectural, but
also Linux implementation choices -- Linux is in no way somehow required to be
optimized for every combination of features, and a lot of the time it makes
perfect sense to say "you don't have X, so I won't use Y either."

	-hpa