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

[Sohil Mehta <sohil.mehta@intel.com>]

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.