Re: [PATCH 3/5] x86/vsyscall: Add vsyscall emulation for #GP

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

On 3/3/2026 7:51 AM, Dave Hansen wrote:
> On 2/19/26 15:35, Sohil Mehta wrote:
>> With LASS, these accesses are intercepted before the paging structures
>> are traversed triggering a #GP instead of a #PF. The #GP doesn't provide
>> much information in terms of the error code.
> 
> It's the error code and the address from CR2, right?
> 

Yes.

> I _think_ this is trying to make the point that "emulate" mode is hard
> with LASS. It's hard because it needs to be able to tell the difference
> between a read of the vsyscall page and an instruction fetch from the
> vsyscall page.
> 
> But, the "xonly" mode is far easier because reads are simply disallowed.
> Any time userspace has an RIP pointing to the vsyscall page (with LASS
> enabled), it's assumed to be a vsyscall. Any normal memory reads of the
> vsyscall page get normal #GP handling.
> 
> Is that right?

That is correct.

> 
> BTW, reading it back now, I think the subject is really unfortunate. It
> would be quite easy to read it and infer that this "adds
> vsyscall=emulate for #GP".
> 
> It should probably be:
> 
> 	x86/vsyscall: Restore vsyscall=xonly mode under LASS
> 

Yeah, I realize now that the "vsyscall emulation" support and EMULATE
mode of the support can easily cause confusion. Will use your proposed
title.

> Maybe this structure would help, based around explaining the three
> vsyscall= modes:
> 

Sure, combining things from the cover letter and what you suggested
here. How about?


"The vsyscall page is located in the high/kernel part of the address
space. LASS prevents access to this page from userspace. The current
kernel only enables LASS when all vsyscall modes are disabled.

Now add support for LASS when vsyscall=xonly (default) is configured.
With LASS, vsyscall page accesses trigger a #GP instead of a #PF. In
XONLY (execute-only) mode, directly reading the vsyscall page is
disallowed. So, the faulting RIP can be easily used to determine if the
#GP was triggered due to a vsyscall access.

Reuse the #PF emulation code during a #GP and emulate the vsyscall
access in XONLY mode. As multiple fault handlers are now using the
emulation code, add a sanity check to ensure that the fault truly
happened in 64-bit user mode.

In contrast, when vsyscall=emulate (deprecated) is configured, it maps
the vsyscall page as readable. Supporting EMULATE mode with LASS is much
harder because the #GP doesn't provide enough error information (such as
PFEC and CR2 in case of #PF). So, complex instruction decoding would be
required in the #GP handler which isn't worth the effort. LASS and
vsyscall=emulate will be kept mutually exclusive for simplicity."