On 8/6/2026 9:15 AM, Sohil Mehta wrote: > With LASS enabled, a user-mode access to a kernel address raises a #GP > instead of the #PF that SMAP/SMEP would produce. Nothing in the x86 > selftests specifically tests for a LASS violation. The vsyscall selftest > exercises this flow but doesn't verify the resulting #GP. > > Add a test that reads, writes and executes at a canonical kernel address > and verifies each one faults with a #GP and a null error code. For the > instruction fetch, also verify the fault is reported at the target, > since LASS does not check the target of a branch. > > Skip the test unless /proc/cpuinfo reports the lass flag. The CPUID bit > alone does not say whether the kernel enabled LASS. > > Assisted-by: Claude:claude-opus-5 > Signed-off-by: Sohil Mehta <[email protected]>
Reviewed-by: Binbin Wu <[email protected]> [...] > +int main(void) > +{ > + ksft_print_header(); > + > + if (!is_lass_active()) > + ksft_exit_skip("LASS is not enabled\n"); > + > + ksft_set_plan(TOTAL_TESTS); > + > + sethandler(SIGSEGV, fault_handler, 0); > + /* Only to report a #SS; LASS shouldn't cause one here. */ > + sethandler(SIGBUS, fault_handler, 0); So the purpose is that if there is an unexpected #SS, fails the test instead of killing it, right? > + > + ksft_print_msg("Accessing the kernel address 0x%lx from userspace\n", > + (unsigned long)KERNEL_ADDR); > + test_kernel_read(); > + test_kernel_write(); > + test_kernel_fetch(); > + > + clearhandler(SIGBUS); > + clearhandler(SIGSEGV); > + > + ksft_finished(); > +}
