linux.git/tools/testing/selftests/x86/Makefile, branch vsnprintf

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

2024-08-27T07:16:35+00:00

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:55+00:00

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:55+00:00

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:55+00:00

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:54+00:00

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:45+00:00

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

selftests/x86: Add shadow stack test

2023-08-02T22:01:51+00:00

Add a simple selftest for exercising some shadow stack behavior:
 - map_shadow_stack syscall and pivot
 - Faulting in shadow stack memory
 - Handling shadow stack violations
 - GUP of shadow stack memory
 - mprotect() of shadow stack memory
 - Userfaultfd on shadow stack memory
 - 32 bit segmentation
 - Guard gap test
 - Ptrace test

Co-developed-by: Yu-cheng Yu 
Signed-off-by: Yu-cheng Yu 
Signed-off-by: Rick Edgecombe 
Signed-off-by: Dave Hansen 
Acked-by: Mike Rapoport (IBM) 
Tested-by: Pengfei Xu 
Tested-by: John Allen 
Tested-by: Kees Cook 
Link: https://lore.kernel.org/all/20230613001108.3040476-40-rick.p.edgecombe%40intel.com

selftests/x86/lam: Add malloc and tag-bits test cases for linear-address masking

2023-03-16T20:08:40+00:00

LAM is supported only in 64-bit mode and applies only addresses used for data
accesses. In 64-bit mode, linear address have 64 bits. LAM is applied to 64-bit
linear address and allow software to use high bits for metadata.
LAM supports configurations that differ regarding which pointer bits are masked
and can be used for metadata.

LAM includes following mode:

 - LAM_U57, pointer bits in positions 62:57 are masked (LAM width 6),
   allows bits 62:57 of a user pointer to be used as metadata.

There are some arch_prctls:
ARCH_ENABLE_TAGGED_ADDR: enable LAM mode, mask high bits of a user pointer.
ARCH_GET_UNTAG_MASK: get current untagged mask.
ARCH_GET_MAX_TAG_BITS: the maximum tag bits user can request. zero if LAM
is not supported.

The LAM mode is for pre-process, a process has only one chance to set LAM mode.
But there is no API to disable LAM mode. So all of test cases are run under
child process.

Functions of this test:

MALLOC

 - LAM_U57 masks bits 57:62 of a user pointer. Process on user space
   can dereference such pointers.

 - Disable LAM, dereference a pointer with metadata above 48 bit or 57 bit
   lead to trigger SIGSEGV.

TAG_BITS

 - Max tag bits of LAM_U57 is 6.

Signed-off-by: Weihong Zhang 
Signed-off-by: Kirill A. Shutemov 
Signed-off-by: Dave Hansen 
Acked-by: Peter Zijlstra (Intel) 
Link: https://lore.kernel.org/all/20230312112612.31869-13-kirill.shutemov%40linux.intel.com

selftests: x86: Fix incorrect kernel headers search path

2023-02-13T16:09:46+00:00

Use $(KHDR_INCLUDES) as lookup path for kernel headers. This prevents
building against kernel headers from the build environment in scenarios
where kernel headers are installed into a specific output directory
(O=...).

Signed-off-by: Mathieu Desnoyers 
Cc: Shuah Khan 
Cc: linux-kselftest@vger.kernel.org
Cc: Ingo Molnar 
Cc:   # 5.18+
Signed-off-by: Shuah Khan

selftests: x86: add 32bit build warnings for SUSE

2022-04-04T19:29:43+00:00

In order to successfully build all these 32bit tests, these 32bit gcc
and glibc packages, named gcc-32bit and glibc-devel-static-32bit on SUSE,
need to be installed.

This patch added this information in warn_32bit_failure.

Signed-off-by: Geliang Tang 
Signed-off-by: Shuah Khan