[PATCH 0/5] x86: Enable LASS support with vsyscall emulation

[PATCH 0/5] x86: Enable LASS support with vsyscall emulation

[Sohil Mehta]

Linear Address Space Separation (LASS) is currently disabled [1] when
support for EFI or vsyscall emulation is enabled. This series extends
LASS support to vsyscall-enabled configurations.

Patches
-------
These patches were posted earlier as part of the v10 LASS series [2]
before being split out into a smaller series to make it easier to merge.
The overall approach to enable vsyscall support was okayed by Andy
Lutomirski [3].

This series is based on the LASS-EFI series which enables LASS for EFI
configurations.
https://lore.kernel.org/lkml/20260120234730.2215498-1-sohil.mehta@intel.com/

The motivation for this series is to show the combined picture as well
as seek reviews on either series. The combined patches can also be viewed at:
https://github.com/sohilmeh/linux-dev/tree/lass-vsyscall

Issue
-----
Userspace attempts to access any kernel address generate a #GP when LASS
is enabled. Legacy vsyscall functions are located in the address range
0xffffffffff600000 - 0xffffffffff601000. Prior to LASS, default access
(XONLY) to the vsyscall page would generate a page fault and the access
would be emulated in the kernel. Currently, as the #GP handler lacks any
emulation support, LASS is disabled when config X86_VSYSCALL_EMULATION
is set.

Solution
--------
These patches primarily update the #GP handler to reuse the existing
vsyscall emulation code for #PF. In XONLY mode, the faulting RIP is
readily available and can be used to determine if the #GP was triggered
due to a vsyscall access.

In contrast, the vsyscall EMULATE mode is deprecated and not expected to
be used by anyone. Supporting EMULATE mode with LASS would require
complex instruction decoding in the #GP fault handler, which is not
worth the effort. So, LASS is disabled in the rare case when someone
absolutely needs to enable vsyscall=emulate via the command line.

Links
-----
[1]: https://lore.kernel.org/lkml/20251118182911.2983253-1-sohil.mehta@intel.com/
[2]: https://lore.kernel.org/lkml/20251007065119.148605-1-sohil.mehta@intel.com/
[3]: https://lore.kernel.org/lkml/f4ae0030-9bc2-4675-ae43-e477cd894750@app.fastmail.com/

Sohil Mehta (5):
  x86/vsyscall: Reorganize the page fault emulation code
  x86/traps: Consolidate user fixups in the #GP handler
  x86/vsyscall: Add vsyscall emulation for #GP
  x86/vsyscall: Disable LASS if vsyscall mode is set to EMULATE
  x86/cpu: Remove LASS restriction on vsyscall emulation

 .../admin-guide/kernel-parameters.txt         |  4 +-
 arch/x86/entry/vsyscall/vsyscall_64.c         | 90 +++++++++++--------
 arch/x86/include/asm/vsyscall.h               | 13 ++-
 arch/x86/kernel/cpu/common.c                  | 15 ----
 arch/x86/kernel/traps.c                       | 12 +--
 arch/x86/kernel/umip.c                        |  3 +
 arch/x86/mm/fault.c                           |  2 +-
 7 files changed, 78 insertions(+), 61 deletions(-)

-- 
2.43.0

[PATCH 1/5] x86/vsyscall: Reorganize the page fault emulation code

[Sohil Mehta]

With LASS, vsyscall page accesses will cause a #GP instead of a #PF.
Separate out the core vsyscall emulation code from the #PF specific
handling in preparation for the upcoming #GP emulation.

No functional change intended.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
 arch/x86/entry/vsyscall/vsyscall_64.c | 64 ++++++++++++++-------------
 arch/x86/include/asm/vsyscall.h       |  7 ++-
 arch/x86/mm/fault.c                   |  2 +-
 3 files changed, 37 insertions(+), 36 deletions(-)

diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index 4bd1e271bb22..5c6559c37c5b 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -111,43 +111,13 @@ static bool write_ok_or_segv(unsigned long ptr, size_t size)
 	}
 }
 
-bool emulate_vsyscall(unsigned long error_code,
-		      struct pt_regs *regs, unsigned long address)
+static bool __emulate_vsyscall(struct pt_regs *regs, unsigned long address)
 {
 	unsigned long caller;
 	int vsyscall_nr, syscall_nr, tmp;
 	long ret;
 	unsigned long orig_dx;
 
-	/* Write faults or kernel-privilege faults never get fixed up. */
-	if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER)
-		return false;
-
-	/*
-	 * Assume that faults at regs->ip are because of an
-	 * instruction fetch. Return early and avoid
-	 * emulation for faults during data accesses:
-	 */
-	if (address != regs->ip) {
-		/* Failed vsyscall read */
-		if (vsyscall_mode == EMULATE)
-			return false;
-
-		/*
-		 * User code tried and failed to read the vsyscall page.
-		 */
-		warn_bad_vsyscall(KERN_INFO, regs, "vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround");
-		return false;
-	}
-
-	/*
-	 * X86_PF_INSTR is only set when NX is supported.  When
-	 * available, use it to double-check that the emulation code
-	 * is only being used for instruction fetches:
-	 */
-	if (cpu_feature_enabled(X86_FEATURE_NX))
-		WARN_ON_ONCE(!(error_code & X86_PF_INSTR));
-
 	/*
 	 * No point in checking CS -- the only way to get here is a user mode
 	 * trap to a high address, which means that we're in 64-bit user code.
@@ -280,6 +250,38 @@ bool emulate_vsyscall(unsigned long error_code,
 	return true;
 }
 
+bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs,
+			 unsigned long address)
+{
+	/* Write faults or kernel-privilege faults never get fixed up. */
+	if ((error_code & (X86_PF_WRITE | X86_PF_USER)) != X86_PF_USER)
+		return false;
+
+	/*
+	 * Assume that faults at regs->ip are because of an instruction
+	 * fetch. Return early and avoid emulation for faults during
+	 * data accesses:
+	 */
+	if (address != regs->ip) {
+		 /* User code tried and failed to read the vsyscall page. */
+		if (vsyscall_mode != EMULATE)
+			warn_bad_vsyscall(KERN_INFO, regs,
+					  "vsyscall read attempt denied -- look up the vsyscall kernel parameter if you need a workaround");
+
+		return false;
+	}
+
+	/*
+	 * X86_PF_INSTR is only set when NX is supported.  When
+	 * available, use it to double-check that the emulation code
+	 * is only being used for instruction fetches:
+	 */
+	if (cpu_feature_enabled(X86_FEATURE_NX))
+		WARN_ON_ONCE(!(error_code & X86_PF_INSTR));
+
+	return __emulate_vsyscall(regs, address);
+}
+
 /*
  * A pseudo VMA to allow ptrace access for the vsyscall page.  This only
  * covers the 64bit vsyscall page now. 32bit has a real VMA now and does
diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h
index 472f0263dbc6..f34902364972 100644
--- a/arch/x86/include/asm/vsyscall.h
+++ b/arch/x86/include/asm/vsyscall.h
@@ -14,12 +14,11 @@ extern void set_vsyscall_pgtable_user_bits(pgd_t *root);
  * Called on instruction fetch fault in vsyscall page.
  * Returns true if handled.
  */
-extern bool emulate_vsyscall(unsigned long error_code,
-			     struct pt_regs *regs, unsigned long address);
+bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, unsigned long address);
 #else
 static inline void map_vsyscall(void) {}
-static inline bool emulate_vsyscall(unsigned long error_code,
-				    struct pt_regs *regs, unsigned long address)
+static inline bool emulate_vsyscall_pf(unsigned long error_code,
+				       struct pt_regs *regs, unsigned long address)
 {
 	return false;
 }
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index b83a06739b51..f0e77e084482 100644
--- a/arch/x86/mm/fault.c
+++ b/arch/x86/mm/fault.c
@@ -1314,7 +1314,7 @@ void do_user_addr_fault(struct pt_regs *regs,
 	 * to consider the PF_PK bit.
 	 */
 	if (is_vsyscall_vaddr(address)) {
-		if (emulate_vsyscall(error_code, regs, address))
+		if (emulate_vsyscall_pf(error_code, regs, address))
 			return;
 	}
 #endif
-- 
2.43.0

[PATCH 2/5] x86/traps: Consolidate user fixups in the #GP handler

[Sohil Mehta]

Move the UMIP exception fixup under the common "if (user_mode(regs))"
condition where the rest of user mode fixups reside. Also, move the UMIP
feature check into its fixup function to keep the calling code
consistent and clean.

No functional change intended.

Suggested-by: Dave Hansen <dave.hansen@intel.com>
Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
---
 arch/x86/kernel/traps.c | 8 +++-----
 arch/x86/kernel/umip.c  | 3 +++
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index 5a6a772e0a6c..e21f8ad2f9d7 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -921,11 +921,6 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)
 
 	cond_local_irq_enable(regs);
 
-	if (static_cpu_has(X86_FEATURE_UMIP)) {
-		if (user_mode(regs) && fixup_umip_exception(regs))
-			goto exit;
-	}
-
 	if (v8086_mode(regs)) {
 		local_irq_enable();
 		handle_vm86_fault((struct kernel_vm86_regs *) regs, error_code);
@@ -940,6 +935,9 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)
 		if (fixup_vdso_exception(regs, X86_TRAP_GP, error_code, 0))
 			goto exit;
 
+		if (fixup_umip_exception(regs))
+			goto exit;
+
 		gp_user_force_sig_segv(regs, X86_TRAP_GP, error_code, desc);
 		goto exit;
 	}
diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c
index d432f3824f0c..3ce99cbcf187 100644
--- a/arch/x86/kernel/umip.c
+++ b/arch/x86/kernel/umip.c
@@ -354,6 +354,9 @@ bool fixup_umip_exception(struct pt_regs *regs)
 	void __user *uaddr;
 	struct insn insn;
 
+	if (!cpu_feature_enabled(X86_FEATURE_UMIP))
+		return false;
+
 	if (!regs)
 		return false;
 
-- 
2.43.0

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

[Sohil Mehta]

The legacy vsyscall page is mapped at a fixed address in the kernel
address range 0xffffffffff600000-0xffffffffff601000. Prior to LASS, a
vsyscall page access from userspace would always generate a #PF. The
kernel emulates the execute (XONLY) accesses in the #PF handler and
returns the appropriate values to userspace.

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.

However, as clarified in the SDM, the LASS violation only triggers after
an instruction fetch happens from the vsyscall address. So, the faulting
RIP, which is preserved in the user registers, can be used to determine
if the #GP was triggered due to a vsyscall access in XONLY mode.

Reuse the common emulation code during a #GP and emulate the vsyscall
access in XONLY mode without going through complex instruction decoding.
Note, this doesn't work for EMULATE mode which maps the vsyscall page as
readable.

Add an extra check in the common emulation code to ensure that the fault
really happened in 64-bit user mode. This is primarily a sanity check
with the #GP handler reusing the emulation code.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
 arch/x86/entry/vsyscall/vsyscall_64.c | 22 +++++++++++++++++-----
 arch/x86/include/asm/vsyscall.h       |  6 ++++++
 arch/x86/kernel/traps.c               |  4 ++++
 3 files changed, 27 insertions(+), 5 deletions(-)

diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index 5c6559c37c5b..b34c8763d5e9 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -23,7 +23,7 @@
  * soon be no new userspace code that will ever use a vsyscall.
  *
  * The code in this file emulates vsyscalls when notified of a page
- * fault to a vsyscall address.
+ * fault or a general protection fault to a vsyscall address.
  */
 
 #include <linux/kernel.h>
@@ -118,10 +118,9 @@ static bool __emulate_vsyscall(struct pt_regs *regs, unsigned long address)
 	long ret;
 	unsigned long orig_dx;
 
-	/*
-	 * No point in checking CS -- the only way to get here is a user mode
-	 * trap to a high address, which means that we're in 64-bit user code.
-	 */
+	/* Confirm that the fault happened in 64-bit user mode */
+	if (!user_64bit_mode(regs))
+		return false;
 
 	if (vsyscall_mode == NONE) {
 		warn_bad_vsyscall(KERN_INFO, regs,
@@ -282,6 +281,19 @@ bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs,
 	return __emulate_vsyscall(regs, address);
 }
 
+bool emulate_vsyscall_gp(struct pt_regs *regs)
+{
+	/* Without LASS, vsyscall accesses are expected to generate a #PF */
+	if (!cpu_feature_enabled(X86_FEATURE_LASS))
+		return false;
+
+	/* Emulate only if the RIP points to the vsyscall address */
+	if (!is_vsyscall_vaddr(regs->ip))
+		return false;
+
+	return __emulate_vsyscall(regs, regs->ip);
+}
+
 /*
  * A pseudo VMA to allow ptrace access for the vsyscall page.  This only
  * covers the 64bit vsyscall page now. 32bit has a real VMA now and does
diff --git a/arch/x86/include/asm/vsyscall.h b/arch/x86/include/asm/vsyscall.h
index f34902364972..538053b1656a 100644
--- a/arch/x86/include/asm/vsyscall.h
+++ b/arch/x86/include/asm/vsyscall.h
@@ -15,6 +15,7 @@ extern void set_vsyscall_pgtable_user_bits(pgd_t *root);
  * Returns true if handled.
  */
 bool emulate_vsyscall_pf(unsigned long error_code, struct pt_regs *regs, unsigned long address);
+bool emulate_vsyscall_gp(struct pt_regs *regs);
 #else
 static inline void map_vsyscall(void) {}
 static inline bool emulate_vsyscall_pf(unsigned long error_code,
@@ -22,6 +23,11 @@ static inline bool emulate_vsyscall_pf(unsigned long error_code,
 {
 	return false;
 }
+
+static inline bool emulate_vsyscall_gp(struct pt_regs *regs)
+{
+	return false;
+}
 #endif
 
 /*
diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
index e21f8ad2f9d7..a896f9225434 100644
--- a/arch/x86/kernel/traps.c
+++ b/arch/x86/kernel/traps.c
@@ -70,6 +70,7 @@
 #include <asm/tdx.h>
 #include <asm/cfi.h>
 #include <asm/msr.h>
+#include <asm/vsyscall.h>
 
 #ifdef CONFIG_X86_64
 #include <asm/x86_init.h>
@@ -938,6 +939,9 @@ DEFINE_IDTENTRY_ERRORCODE(exc_general_protection)
 		if (fixup_umip_exception(regs))
 			goto exit;
 
+		if (emulate_vsyscall_gp(regs))
+			goto exit;
+
 		gp_user_force_sig_segv(regs, X86_TRAP_GP, error_code, desc);
 		goto exit;
 	}
-- 
2.43.0

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

[Dave Hansen]

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?

> However, as clarified in the SDM, the LASS violation only triggers after
> an instruction fetch happens from the vsyscall address. So, the faulting
> RIP, which is preserved in the user registers, can be used to determine
> if the #GP was triggered due to a vsyscall access in XONLY mode.
> 
> Reuse the common emulation code during a #GP and emulate the vsyscall
> access in XONLY mode without going through complex instruction decoding.
> Note, this doesn't work for EMULATE mode which maps the vsyscall page as
> readable.
> 
> Add an extra check in the common emulation code to ensure that the fault
> really happened in 64-bit user mode. This is primarily a sanity check
> with the #GP handler reusing the emulation code.

This part of the changelog loses me.

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?

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

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

	The vsyscall page is in the high/kernel part of the address
	space. LASS prevents access to this page from userspace. The
	kernel currently forces vsyscall=none mode with LASS.

	Support vsyscall=xonly mode with LASS. <include more content
	here>

	Keep vsyscall=emulate mutually exclusive with LASS. It is hard
	to support because the #GP handler (unlike #PF) doesn't have
	PFEC or CR2 to give information about the fault.

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

[Sohil Mehta]

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."

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

[H. Peter Anvin]

On 2026-03-03 13:20, Sohil Mehta wrote:
> 
> 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.

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:

"vsyscall emulation can be execute-only (XONLY) or read-execute (EMULATE),
specified by the vsyscall= kernel command line option. XONLY mode is the
default. The EMULATE mode has been deprecated since 2022 and is considered
insecure.

This patch adds support for LASS with XONLY vsyscall emulation.

> 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.

How about:

"With LASS, vsyscall page accesses trigger a #GP instead of a #PF. 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 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.

"... as remaining users of EMULATE mode can be reasonably assumed to be niche
users, who are already trading off security for compatibility."

Use "EMULATE mode" consistently here. Captializing it makes it clear that it
is a term and not just a prose word.

> LASS and
> vsyscall=emulate will be kept mutually exclusive for simplicity."

	-hpa

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

[Sohil Mehta]

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.

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

[Dave Hansen]

On 3/4/26 16:10, Sohil Mehta wrote:
> 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.

Is it really "marked as execute only"? We don't have a real execute-only
paging permission on x86, the closest we've got is memory marked with a
pkey that's got the AccessDisable bit set.

I think it's _called_ execute-only because the kernel makes it behave
like execute-only memory when it's handling the page fault. But I dobn't
think it is super accurate to say it is "marked" as execute-only.

The rest of it looks great to me, though.

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

[H. Peter Anvin]

On March 4, 2026 5:45:48 PM PST, Dave Hansen <dave.hansen@intel.com> wrote:
>On 3/4/26 16:10, Sohil Mehta wrote:
>> 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.
>
>Is it really "marked as execute only"? We don't have a real execute-only
>paging permission on x86, the closest we've got is memory marked with a
>pkey that's got the AccessDisable bit set.
>
>I think it's _called_ execute-only because the kernel makes it behave
>like execute-only memory when it's handling the page fault. But I dobn't
>think it is super accurate to say it is "marked" as execute-only.
>
>The rest of it looks great to me, though.

It's not marked as anything; it is in fact not present.

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

[Sohil Mehta]

On 3/4/2026 10:31 PM, H. Peter Anvin wrote:
> On March 4, 2026 5:45:48 PM PST, Dave Hansen <dave.hansen@intel.com> wrote:
>> On 3/4/26 16:10, Sohil Mehta wrote:
>>> 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.
>>
>> Is it really "marked as execute only"? We don't have a real execute-only
>> paging permission on x86, the closest we've got is memory marked with a
>> pkey that's got the AccessDisable bit set.
>>
>> I think it's _called_ execute-only because the kernel makes it behave
>> like execute-only memory when it's handling the page fault. But I dobn't
>> think it is super accurate to say it is "marked" as execute-only.
>>

Sorry about the wording. I should have looked at map_vsyscall() more
carefully. As Peter said the page is not even present in XONLY mode and
in EMULATE mode the PTE is marked as _USR but __NX.

How about using "behaves" instead of marked? Or I could use "emulated"
if you prefer that.

So the above paragraph would be:

Vsyscall emulation has two modes of operation, specified by the
vsyscall={xonly, emulate} kernel command line option. The vsyscall page
behaves as execute-only in XONLY mode and as read-execute in EMULATE mode.

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

[H. Peter Anvin]

On March 4, 2026 4:10:22 PM PST, Sohil Mehta <sohil.mehta@intel.com> 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.

[PATCH 4/5] x86/vsyscall: Disable LASS if vsyscall mode is set to EMULATE

[Sohil Mehta]

The EMULATE mode of vsyscall maps the vsyscall page with a high kernel
address directly into user address space. Reading the vsyscall page in
EMULATE mode would cause LASS to trigger a #GP.

Fixing the LASS violation in EMULATE mode would require complex
instruction decoding because the resulting #GP does not include any
useful error information, and the vsyscall address is not readily
available in the RIP.

The EMULATE mode has been deprecated since 2022 and can only be enabled
using the command line parameter vsyscall=emulate. See commit
bf00745e7791 ("x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE") for
details. At this point, no one is expected to be using this insecure
mode. The rare usages that need it obviously do not care about security.

Disable LASS when EMULATE mode is requested to avoid breaking legacy
user software. Also, update the vsyscall documentation to reflect this.
LASS will only be supported if vsyscall mode is set to XONLY (default)
or NONE.

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
Reviewed-by: Rick Edgecombe <rick.p.edgecombe@intel.com>
---
Eventually, the plan is to get rid of the EMULATE mode altogether. Linus
and AndyL seem to be okay with such a change. However, those changes are
beyond the scope of this series.
---
 Documentation/admin-guide/kernel-parameters.txt | 4 +++-
 arch/x86/entry/vsyscall/vsyscall_64.c           | 6 ++++++
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 9e3ae4071c4b..28aaebd9ca49 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -8283,7 +8283,9 @@ Kernel parameters
 
 			emulate     Vsyscalls turn into traps and are emulated
 			            reasonably safely.  The vsyscall page is
-				    readable.
+				    readable.  This disables the Linear
+				    Address Space Separation (LASS) security
+				    feature and makes the system less secure.
 
 			xonly       [default] Vsyscalls turn into traps and are
 			            emulated reasonably safely.  The vsyscall
diff --git a/arch/x86/entry/vsyscall/vsyscall_64.c b/arch/x86/entry/vsyscall/vsyscall_64.c
index b34c8763d5e9..e0faa4ca0382 100644
--- a/arch/x86/entry/vsyscall/vsyscall_64.c
+++ b/arch/x86/entry/vsyscall/vsyscall_64.c
@@ -62,6 +62,12 @@ static int __init vsyscall_setup(char *str)
 		else
 			return -EINVAL;
 
+		if (cpu_feature_enabled(X86_FEATURE_LASS) && vsyscall_mode == EMULATE) {
+			cr4_clear_bits(X86_CR4_LASS);
+			setup_clear_cpu_cap(X86_FEATURE_LASS);
+			pr_warn_once("x86/cpu: Disabling LASS due to vsyscall=emulate\n");
+		}
+
 		return 0;
 	}
 
-- 
2.43.0

Re: [PATCH 4/5] x86/vsyscall: Disable LASS if vsyscall mode is set to EMULATE

[Dave Hansen]

On 2/19/26 15:35, Sohil Mehta wrote:
> The EMULATE mode of vsyscall maps the vsyscall page with a high kernel
> address directly into user address space. Reading the vsyscall page in
> EMULATE mode would cause LASS to trigger a #GP.
> 
> Fixing the LASS violation in EMULATE mode would require complex
> instruction decoding because the resulting #GP does not include any
> useful error information, and the vsyscall address is not readily
> available in the RIP.
> 
> The EMULATE mode has been deprecated since 2022 and can only be enabled
> using the command line parameter vsyscall=emulate. See commit
> bf00745e7791 ("x86/vsyscall: Remove CONFIG_LEGACY_VSYSCALL_EMULATE") for
> details. At this point, no one is expected to be using this insecure
> mode. The rare usages that need it obviously do not care about security.
> 
> Disable LASS when EMULATE mode is requested to avoid breaking legacy
> user software. Also, update the vsyscall documentation to reflect this.
> LASS will only be supported if vsyscall mode is set to XONLY (default)
> or NONE.

Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>

[PATCH 5/5] x86/cpu: Remove LASS restriction on vsyscall emulation

[Sohil Mehta]

As vsyscall emulation is now supported during #GP, remove the
restriction on LASS when vsyscall emulation is compiled in.

As a result, there is no need for setup_lass() anymore. LASS is enabled
by default through a late_initcall().

Signed-off-by: Sohil Mehta <sohil.mehta@intel.com>
---
 arch/x86/kernel/cpu/common.c | 15 ---------------
 1 file changed, 15 deletions(-)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 3557f0e6b3aa..02472fc763d9 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -406,20 +406,6 @@ static __always_inline void setup_umip(struct cpuinfo_x86 *c)
 	cr4_clear_bits(X86_CR4_UMIP);
 }
 
-static __always_inline void setup_lass(struct cpuinfo_x86 *c)
-{
-	if (!cpu_feature_enabled(X86_FEATURE_LASS))
-		return;
-
-	/*
-	 * Legacy vsyscall page access causes a #GP when LASS is active.
-	 * Disable LASS because the #GP handler doesn't support vsyscall
-	 * emulation.
-	 */
-	if (IS_ENABLED(CONFIG_X86_VSYSCALL_EMULATION))
-		setup_clear_cpu_cap(X86_FEATURE_LASS);
-}
-
 static int enable_lass(unsigned int cpu)
 {
 	cr4_set_bits(X86_CR4_LASS);
@@ -2061,7 +2047,6 @@ static void identify_cpu(struct cpuinfo_x86 *c)
 	setup_smep(c);
 	setup_smap(c);
 	setup_umip(c);
-	setup_lass(c);
 
 	/* Enable FSGSBASE instructions if available. */
 	if (cpu_has(c, X86_FEATURE_FSGSBASE)) {
-- 
2.43.0

Re: [PATCH 5/5] x86/cpu: Remove LASS restriction on vsyscall emulation

[Dave Hansen]

On 2/19/26 15:36, Sohil Mehta wrote:
> As vsyscall emulation is now supported during #GP, remove the
> restriction on LASS when vsyscall emulation is compiled in.
> 
> As a result, there is no need for setup_lass() anymore. LASS is enabled
> by default through a late_initcall().

Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>

Now we just need to get patch 3 settled.

Re: [PATCH 0/5] x86: Enable LASS support with vsyscall emulation

[Dave Hansen]

On 2/19/26 15:35, Sohil Mehta wrote:
> These patches primarily update the #GP handler to reuse the existing
> vsyscall emulation code for #PF. In XONLY mode, the faulting RIP is
> readily available and can be used to determine if the #GP was triggered
> due to a vsyscall access.
> 
> In contrast, the vsyscall EMULATE mode is deprecated and not expected to
> be used by anyone. Supporting EMULATE mode with LASS would require
> complex instruction decoding in the #GP fault handler, which is not
> worth the effort. So, LASS is disabled in the rare case when someone
> absolutely needs to enable vsyscall=emulate via the command line.

So this part is actually pretty nice.

Could we forklift a bit of this into patch 3, please?