Re: [PATCH v4 7/7] selftests/x86: Add a userspace test for LASS enforcement

[Binbin Wu]

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 <sohil.mehta@xxxxxxxxx>

Reviewed-by: Binbin Wu <binbin.wu@xxxxxxxxxxxxxxx>

[...]

> +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();
> +}