linux-kernel - Re: [PATCH v11 9/9] x86/cpu: Enable LASS by default during CPU initialization

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: <255724be-a6d8-4aa6-94f9-1e6ffba3a3cc@zytor.com>
Date: Fri, 7 Nov 2025 00:01:28 -0800
From: "H. Peter Anvin" <hpa@...or.com>
To: Dave Hansen <dave.hansen@...el.com>, Sohil Mehta <sohil.mehta@...el.com>,
        x86@...nel.org, Dave Hansen <dave.hansen@...ux.intel.com>,
        Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
        Borislav Petkov <bp@...en8.de>
Cc: Jonathan Corbet <corbet@....net>, Andy Lutomirski <luto@...nel.org>,
        Josh Poimboeuf <jpoimboe@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ard Biesheuvel <ardb@...nel.org>,
        "Kirill A . Shutemov" <kas@...nel.org>, Xin Li <xin@...or.com>,
        David Woodhouse <dwmw@...zon.co.uk>,
        Sean Christopherson <seanjc@...gle.com>,
        Rick Edgecombe <rick.p.edgecombe@...el.com>,
        Vegard Nossum <vegard.nossum@...cle.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>, Kees Cook <kees@...nel.org>,
        Tony Luck <tony.luck@...el.com>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-efi@...r.kernel.org
Subject: Re: [PATCH v11 9/9] x86/cpu: Enable LASS by default during CPU
 initialization

On 2025-10-30 09:27, Dave Hansen wrote:
> On 10/30/25 01:40, H. Peter Anvin wrote:
>> Legacy vsyscalls have been obsolete for how long now?
> 
> I asked Sohil to start throwing out all the non-essential bits from this
> series. My thought was that we could get mainline so that LASS itself
> could be enabled, even if it was in a somewhat weird config that a
> distro would probably never do.
> 
> After that is merged, we can circle back and decide what to do with the
> remaining bits like CR pinning and vsyscall emulation. I don't think any
> of those bits will change the basic desire to have LASS support in the
> kernel.
> 
> Does that sound like a sane approach to everyone?

XONLY vsyscall emulation should be trivial, though (just look for the magic
RIP values, just like the page fault code does now, too.) The FULL emulation
mode is completely irrelevant these days, so I don't think it matters at all.

EFI handling is similarly straightforward: just disable CR4.LASS right before
calling EFI, and enable it on return. As long as we are *already* in the
efi_mm context, it is perfectly safe to disable CR4.LASS, because there *is no
user memory mapped at that point*.

These two things should only be a few lines of code each, and I don't see any
reason to further elaborate them at this time (to handle FULL emulation, or to
take a LASS trap inside EFI to write a shame-the-vendor message; if we wanted
to do that, it would be better to make that independent of LASS and empty out
efi_mm entirely.

Am I missing something?

	-hpa