kernel.git/tools/testing/selftests/x86/Makefile, branch linux-rolling-lts

selftests/x86: Add a test to detect infinite SIGTRAP handler loop

2025-06-09T15:52:06Z

When FRED is enabled, if the Trap Flag (TF) is set without an external debugger attached, it can lead to an infinite loop in the SIGTRAP handler. To avoid this, the software event flag in the augmented SS must be cleared, ensuring that no single-step trap remains pending when ERETU completes. This test checks for that specific scenario—verifying whether the kernel correctly prevents an infinite SIGTRAP loop in this edge case when FRED is enabled. The test should _always_ pass with IDT event delivery, thus no need to disable the test even when FRED is not enabled. Signed-off-by: Xin Li (Intel) Signed-off-by: Dave Hansen Tested-by: Sohil Mehta Cc:stable@vger.kernel.org Link: https://lore.kernel.org/all/20250609084054.2083189-3-xin%40zytor.com

selftests/x86/apx: Add APX test

2025-04-16T07:44:14Z

The extended general-purpose registers for APX may contain random data, which is currently assumed by the xstate testing framework. This allows the testing of the new userspace feature using the common test code. Invoke the test entry function from apx.c after enumerating the state component and adding it to the support list Signed-off-by: Chang S. Bae Signed-off-by: Ingo Molnar Reviewed-by: Sohil Mehta Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Oleg Nesterov Link: https://lore.kernel.org/r/20250416021720.12305-6-chang.seok.bae@intel.com

selftests/x86/avx: Add AVX tests

2025-02-26T12:05:30Z

Add xstate testing specifically for those vector register states, validating kernel's context switching and ensuring ABI compliance. Use the established xstate testing framework. Alternatively, this invocation could be placed directly in xstate.c::main(). However, the current test file naming convention, which clearly specifies the tested area, seems reasonable. Adding avx.c considerably aligns with that convention. The test output should be like this for ZMM_Hi256 as an example: $ avx_64 ... [RUN] AVX-512 ZMM_Hi256: check context switches, 10 iterations, 5 threads. [OK] No incorrect case was found. [RUN] AVX-512 ZMM_Hi256: inject xstate via ptrace(). [OK] 'xfeatures' in SW reserved area was correctly written [OK] xstate was correctly updated. [RUN] AVX-512 ZMM_Hi256: load xstate and raise SIGUSR1 [OK] 'magic1' is valid [OK] 'xfeatures' in SW reserved area is valid [OK] 'xfeatures' in XSAVE header is valid [OK] xstate delivery was successful [OK] 'magic2' is valid [RUN] AVX-512 ZMM_Hi256: load new xstate from sighandler and check it after sigreturn [OK] xstate was restored correctly But systems without AVX-512 will look like: ... The kernel does not support feature number: 5 The kernel does not support feature number: 6 The kernel does not support feature number: 7 Signed-off-by: Chang S. Bae Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250226010731.2456-10-chang.seok.bae@intel.com

selftests/x86/xstate: Refactor context switching test

2025-02-26T12:05:29Z

The existing context switching and ptrace tests in amx.c are not specific to dynamic states, making them reusable for general xstate testing. As a first step, move the context switching test to xstate.c. Refactor the test code to allow specifying which xstate component being tested. To decouple the test from dynamic states, remove the permission request code. In fact, The permission request inside the test wrapper was redundant. Additionally, replace fatal_error() with ksft_exit_fail_msg() for consistency in error handling. Expected output: $ amx_64 ... [RUN] AMX Tile data: check context switches, 10 iterations, 5 threads. [OK] No incorrect case was found. Signed-off-by: Chang S. Bae Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/20250226010731.2456-5-chang.seok.bae@intel.com

Documentation/srso: Document a method for checking safe RET operates properly

2024-08-27T07:16:35Z

Add a method to quickly verify whether safe RET operates properly on a given system using perf tool. Also, add a selftest which does the same thing. Signed-off-by: Borislav Petkov (AMD) Link: https://lore.kernel.org/r/20240731160531.28640-1-bp@kernel.org

selftests/x86: avoid -no-pie warnings from clang during compilation

2024-07-11T17:23:55Z

When building with clang, via: make LLVM=1 -C tools/testing/selftests ...clang warns that -no-pie is "unused during compilation". This occurs because clang only wants to see -no-pie during linking. Here, we don't have a separate linking stage, so a compiler warning is unavoidable without (wastefully) restructuring the Makefile. Avoid the warning by simply disabling that warning, for clang builds. Acked-by: Muhammad Usama Anjum Signed-off-by: John Hubbard Signed-off-by: Shuah Khan

selftests/x86: build sysret_rip.c with clang

2024-07-11T17:23:55Z

When building with clang, via: make LLVM=1 -C tools/testing/selftests ...the build fails because clang's inline asm doesn't support all of the features that are used in the asm() snippet in sysret_rip.c. Fix this by moving the asm code into the clang_helpers_64.S file, where it can be built with the assembler's full set of features. Acked-by: Muhammad Usama Anjum Signed-off-by: John Hubbard Signed-off-by: Shuah Khan

selftests/x86: build fsgsbase_restore.c with clang

2024-07-11T17:23:55Z

When building with clang, via: make LLVM=1 -C tools/testing/selftests Fix this by moving the inline asm to "pure" assembly, in two new files: clang_helpers_32.S, clang_helpers_64.S. As a bonus, the pure asm avoids the need for ifdefs, and is now very simple and easy on the eyes. Acked-by: Muhammad Usama Anjum Signed-off-by: John Hubbard Signed-off-by: Shuah Khan

selftests/x86: fix Makefile dependencies to work with clang

2024-07-11T17:23:54Z

When building with clang, via: make LLVM=1 -C tools/testing/selftests ...the following build failure occurs in selftests/x86: clang: error: cannot specify -o when generating multiple output files This happens because, although gcc doesn't complain if you invoke it like this: gcc file1.c header2.h ...clang won't accept that form--it rejects the .h file(s). Also, the above approach is inaccurate anyway, because file.c includes header2.h in this case, and the inclusion of header2.h on the invocation is an artifact of the Makefile's desire to maintain dependencies. In Makefiles of this type, a better way to do it is to use Makefile dependencies to trigger the appropriate incremental rebuilds, and separately use file lists (see EXTRA_FILES in this commit) to track what to pass to the compiler. This commit splits those concepts up, by setting up both EXTRA_FILES and the Makefile dependencies with a single call to the new Makefile function extra-files. That fixes the build failure, while still providing the correct dependencies in all cases. Acked-by: Muhammad Usama Anjum Signed-off-by: John Hubbard Signed-off-by: Shuah Khan

selftests/x86/mm: Add new test that userspace stack is in fact NX

2023-10-03T19:00:45Z

Here is how it works: * fault and fill the stack from RSP with INT3 down until rlimit allows, * fill upwards with INT3 too, overwrite libc stuff, argv, envp, * try to exec INT3 on each page and catch it in either SIGSEGV or SIGTRAP handler. Note: trying to execute _every_ INT3 on a 8 MiB stack takes 30-40 seconds even on fast machine which is too much for kernel selftesting (not for LTP!) so only 1 INT3 per page is tried. Tested on F37 kernel and on a custom kernel which does: vm_flags |= VM_EXEC; to stack VMA. Report from the buggy kernel: $ ./nx_stack_32 stack min ff007000 stack max ff807000 FAIL executable page on the stack: eip ff806001 $ ./nx_stack_64 stack min 7ffe65bb0000 stack max 7ffe663b0000 FAIL executable page on the stack: rip 7ffe663af001 Signed-off-by: Alexey Dobriyan Signed-off-by: Ingo Molnar Link: https://lore.kernel.org/r/4cef8266-ad6d-48af-a5f1-fc2b6a8eb422@p183