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: <d1b5698e-94ab-45a2-a472-4488895d55bb@intel.com>
Date: Thu, 30 Oct 2025 09:44:02 -0700
From: Sohil Mehta <sohil.mehta@...el.com>
To: Andy Lutomirski <luto@...nel.org>, "H. Peter Anvin" <hpa@...or.com>, "the
 arch/x86 maintainers" <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>, Josh Poimboeuf <jpoimboe@...nel.org>,
	"Peter Zijlstra (Intel)" <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 P 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 Mailing List" <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 10/30/2025 8:45 AM, Andy Lutomirski wrote:
> On Thu, Oct 30, 2025, at 1:40 AM, H. Peter Anvin wrote:
>> Legacy vsyscalls have been obsolete for how long now?
> 
> A looooong time.
> 
> I would suggest defaulting LASS to on and *maybe* decoding just enough to log, once per boot, that a legacy vsyscall may have been attempted. It’s too bad that #GP doesn’t report the faulting address.
> 

Unfortunately, CONFIG_X86_VSYSCALL_EMULATION defaults to y. Also, the
default Vsyscall mode is XONLY. So even if vsyscalls are deprecated,
there is a non-zero possibility someone would complain about it.

My primary goal here is to get the base LASS series merged (soonish)
with the simplest possible option.

I am planning to follow-up immediately with a vsyscall specific series
that relaxes *most* restrictions.

IIUC, supporting XONLY mode with LASS probably does not need complicated
decoding because the vsyscall address is available in the faulting RIP.

The spec says:
"LASS for instruction fetches applies when the linear address in RIP is
used to load an instruction from memory. Unlike canonicality checking
(see Section 4.5.2), LASS does not apply to branch instructions that
load RIP. A branch instruction can load RIP with an address that would
violate LASS. Only when the address is used to fetch an instruction will
a LASS violation occur, generating a #GP. (The return instruction
pointer of the #GP handler is the address that incurred the LASS
violation.)"

I attempted to do that in the last revision here:
https://lore.kernel.org/lkml/20251007065119.148605-9-sohil.mehta@intel.com/
https://lore.kernel.org/lkml/20251007065119.148605-11-sohil.mehta@intel.com/

On the other hand, supporting EMULATE mode during a #GP is a bit tricky,
which isn't worth the effort.