kernel/linux.git/tools/testing/selftests/seccomp, branch v6.1.168

minmax: make generic MIN() and MAX() macros available everywhere

2025-10-02T11:40:43+00:00

[ Upstream commit 1a251f52cfdc417c84411a056bc142cbd77baef4 ] This just standardizes the use of MIN() and MAX() macros, with the very traditional semantics. The goal is to use these for C constant expressions and for top-level / static initializers, and so be able to simplify the min()/max() macros. These macro names were used by various kernel code - they are very traditional, after all - and all such users have been fixed up, with a few different approaches: - trivial duplicated macro definitions have been removed Note that 'trivial' here means that it's obviously kernel code that already included all the major kernel headers, and thus gets the new generic MIN/MAX macros automatically. - non-trivial duplicated macro definitions are guarded with #ifndef This is the "yes, they define their own versions, but no, the include situation is not entirely obvious, and maybe they don't get the generic version automatically" case. - strange use case #1 A couple of drivers decided that the way they want to describe their versioning is with #define MAJ 1 #define MIN 2 #define DRV_VERSION __stringify(MAJ) "." __stringify(MIN) which adds zero value and I just did my Alexander the Great impersonation, and rewrote that pointless Gordian knot as #define DRV_VERSION "1.2" instead. - strange use case #2 A couple of drivers thought that it's a good idea to have a random 'MIN' or 'MAX' define for a value or index into a table, rather than the traditional macro that takes arguments. These values were re-written as C enum's instead. The new function-line macros only expand when followed by an open parenthesis, and thus don't clash with enum use. Happily, there weren't really all that many of these cases, and a lot of users already had the pattern of using '#ifndef' guarding (or in one case just using '#undef MIN') before defining their own private version that does the same thing. I left such cases alone. Cc: David Laight Cc: Lorenzo Stoakes Signed-off-by: Linus Torvalds Signed-off-by: Eliav Farber Signed-off-by: Greg Kroah-Hartman

selftests/seccomp: fix syscall_restart test for arm compat

2025-06-27T10:07:08+00:00

[ Upstream commit 797002deed03491215a352ace891749b39741b69 ] The inconsistencies in the systcall ABI between arm and arm-compat can can cause a failure in the syscall_restart test due to the logic attempting to work around the differences. The 'machine' field for an ARM64 device running in compat mode can report 'armv8l' or 'armv8b' which matches with the string 'arm' when only examining the first three characters of the string. This change adds additional validation to the workaround logic to make sure we only take the arm path when running natively, not in arm-compat. Fixes: 256d0afb11d6 ("selftests/seccomp: build and pass on arm64") Signed-off-by: Neill Kapron Link: https://lore.kernel.org/r/20250427094103.3488304-2-nkapron@google.com Signed-off-by: Kees Cook Signed-off-by: Sasha Levin

selftests: seccomp: Fix incorrect kernel headers search path

2023-03-10T08:34:18+00:00

commit 07d42dd854446ba3177ad7a217870a5b4edee165 upstream. 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 Signed-off-by: Greg Kroah-Hartman

selftests/seccomp: Fix compile warning when CC=clang

2022-07-27T19:12:16+00:00

clang has -Wconstant-conversion by default, and the constant 0xAAAAAAAAA (9 As) being converted to an int, which is generally 32 bits, results in the compile warning: clang -Wl,-no-as-needed -Wall -isystem ../../../../usr/include/ -lpthread seccomp_bpf.c -lcap -o seccomp_bpf seccomp_bpf.c:812:67: warning: implicit conversion from 'long' to 'int' changes value from 45812984490 to -1431655766 [-Wconstant-conversion] int kill = kill_how == KILL_PROCESS ? SECCOMP_RET_KILL_PROCESS : 0xAAAAAAAAA; ~~~~ ^~~~~~~~~~~ 1 warning generated. -1431655766 is the expected truncation, 0xAAAAAAAA (8 As), so use this directly in the code to avoid the warning. Fixes: 3932fcecd962 ("selftests/seccomp: Add test for unknown SECCOMP_RET kill behavior") Signed-off-by: YiFei Zhu Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220526223407.1686936-1-zhuyifei@google.com

selftests/seccomp: Fix spelling mistake "Coud" -> "Could"

2022-05-04T20:31:21+00:00

There is a spelling mistake in an error message. Fix it. Signed-off-by: Colin Ian King Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220504155535.239180-1-colin.i.king@gmail.com

selftests/seccomp: Add test for wait killable notifier

2022-05-03T21:20:49+00:00

This verifies that if a filter is set up with the wait killable feature that it obeys the semantics that non-fatal signals are ignored during a notification after the notification is received. Cases tested: * Non-fatal signal prior to receive * Non-fatal signal during receive * Fatal signal after receive The normal signal handling is tested in user_notification_signal. That behaviour remains unchanged. On an unsupported kernel, these tests will immediately bail as it relies on a new seccomp flag. Signed-off-by: Sargun Dhillon Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220503080958.20220-4-sargun@sargun.me

selftests/seccomp: Refactor get_proc_stat to split out file reading code

2022-05-03T21:20:49+00:00

This splits up the get_proc_stat function to make it so we can use it as a generic helper to read the nth field from multiple different files, versus replicating the logic in multiple places. Signed-off-by: Sargun Dhillon Cc: linux-kselftest@vger.kernel.org Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220503080958.20220-3-sargun@sargun.me

selftests/seccomp: Ensure that notifications come in FIFO order

2022-04-29T18:49:18+00:00

When multiple notifications are waiting, ensure they show up in order, as defined by the (predictable) seccomp notification ID. This ensures FIFO ordering of notification delivery as notification ids are monitonic and decided when the notification is generated (as opposed to received). Signed-off-by: Sargun Dhillon Cc: linux-kselftest@vger.kernel.org Acked-by: Tycho Andersen Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/20220428015447.13661-2-sargun@sargun.me

selftests/seccomp: Add SKIP for failed unshare()

2022-04-29T18:28:43+00:00

Running the seccomp tests under the kernel with "defconfig" shouldn't fail. Because the CONFIG_USER_NS is not supported in "defconfig". Skipping this case instead of failing it is better. Signed-off-by: Yang Guang Signed-off-by: David Yang Reviewed-by: Shuah Khan Signed-off-by: Kees Cook Link: https://lore.kernel.org/r/7f7687696a5c0a2d040a24474616e945c7cf2bb5.1648599460.git.yang.guang5@zte.com.cn

selftests/seccomp: Test PTRACE_O_SUSPEND_SECCOMP without CAP_SYS_ADMIN

2022-04-29T18:28:42+00:00

Add a test to check that PTRACE_O_SUSPEND_SECCOMP can't be set without CAP_SYS_ADMIN through PTRACE_SEIZE or PTRACE_SETOPTIONS. Signed-off-by: Jann Horn Co-developed-by: Kees Cook Signed-off-by: Kees Cook