Re: [PATCH 3/5] x86/vsyscall: Add vsyscall emulation for #GP
From: H. Peter Anvin
Date: Thu Mar 05 2026 - 01:33:41 EST
On March 4, 2026 4:10:22 PM PST, Sohil Mehta <sohil.mehta@xxxxxxxxx> wrote:
>On 3/3/2026 2:35 PM, H. Peter Anvin wrote:
>
>> Suggest making an introductory paragraph here with the background information,
>> instead of mixing it into the rest of the text in a somewhat incoherent manner:
>>
>
>I rewrote the whole thing based on your and Dave's input. I added
>sections because it was getting a bit wordy.
>
>x86/vsyscall: Restore vsyscall=xonly mode under LASS
>
>Background
>----------
>The vsyscall page is located in the high/kernel part of the address
>space. Prior to LASS, a vsyscall page access from userspace would always
>generate a #PF. The kernel emulates the accesses in the #PF handler and
>returns the appropriate values to userspace.
>
>Vsyscall emulation has two modes of operation, specified by the
>vsyscall={xonly, emulate} kernel command line option. The vsyscall page
>is marked as execute-only in XONLY mode or read-execute in EMULATE mode.
>XONLY mode is the default and the only one expected to be commonly used.
>The EMULATE mode has been deprecated since 2022 and is considered
>insecure.
>
>With LASS, a vsyscall page access triggers a #GP instead of a #PF.
>Currently, LASS is only enabled when all vsyscall modes are disabled.
>
>LASS with XONLY mode
>--------------------
>Now add support for LASS specifically with XONLY vsyscall emulation. For
>XONLY mode, all that is needed is the faulting RIP, which is trivially
>available regardless of the type of fault. Reuse the #PF emulation code
>during the #GP when the fault address points to the vsyscall page.
>
>As multiple fault handlers will now be using the emulation code, add a
>sanity check to ensure that the fault truly happened in 64-bit user
>mode.
>
>LASS with EMULATE mode
>----------------------
>Supporting vsyscall=emulate with LASS is much harder because the #GP
>doesn't provide enough error information (such as PFEC and CR2 as in
>case of a #PF). So, complex instruction decoding would be required to
>emulate this mode in the #GP handler.
>
>This isn't worth the effort as remaining users of EMULATE mode can be
>reasonably assumed to be niche users, who are already trading off
>security for compatibility. LASS and vsyscall=emulate will be kept
>mutually exclusive for simplicity.
Other than David's comment this looks great to me too.