Re: [PATCH v2 0/5] x86: Enable LASS support with vsyscall=xonly mode

[Maciej Wieczor-Retman]

Hi! Tested the patchset on a Sierra Forest system using mostly the selftest and
checking out the feature status. Verified all combinations of config options and
cmdline arguments behave as expected.

Tested-by: Maciej Wieczor-Retman <maciej.wieczor-retman@xxxxxxxxx>

Kind regards
Maciej Wieczór-Retman

On 2026-03-05 at 13:40:21 -0800, Sohil Mehta wrote:
>Linear Address Space Separation (LASS) is currently disabled [1] when
>support for vsyscall emulation is configured. This series extends LASS
>support specifically to the default XONLY mode (vsyscall=xonly).
>
>Changes in v2
>-------------
>- Pick up review tags from Dave.
>- Improve commit messages based on feedback from Dave and Peter.
>- Minor change in patch 4 to avoid unnecessary clearing of CR4.LASS.
>
>v1: https://lore.kernel.org/lkml/20260219233600.154313-1-sohil.mehta@xxxxxxxxx/
>
>Patches
>-------
>These patches were originally part of the v10 LASS series [2] before
>being split out into a smaller series to make it easier to review and
>merge. The overall approach to enable vsyscall support was okayed by
>Andy Lutomirski [3].
>
>The patches are based on the tip x86/cpu branch which has the recently
>merged LASS-EFI series [4].
>
>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.
>
>Please find more details in the individual commit messages.
>
>Links
>-----
>[1]: https://lore.kernel.org/lkml/20251118182911.2983253-1-sohil.mehta@xxxxxxxxx/
>[2]: https://lore.kernel.org/lkml/20251007065119.148605-1-sohil.mehta@xxxxxxxxx/
>[3]: https://lore.kernel.org/lkml/f4ae0030-9bc2-4675-ae43-e477cd894750@xxxxxxxxxxxxxxxx/
>[4]: https://lore.kernel.org/lkml/20260120234730.2215498-1-sohil.mehta@xxxxxxxxx/
>
>Sohil Mehta (5):
>  x86/vsyscall: Reorganize the page fault emulation code
>  x86/traps: Consolidate user fixups in the #GP handler
>  x86/vsyscall: Restore vsyscall=xonly mode under LASS
>  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         | 89 +++++++++++--------
> 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, 77 insertions(+), 61 deletions(-)
>
>
>base-commit: 68400c1aaf02636a97c45ba198110b66feb270a9
>-- 
>2.43.0
>