summaryrefslogtreecommitdiff
path: root/tools/testing/selftests/seccomp/seccomp_benchmark.c
AgeCommit message (Collapse)AuthorFilesLines
2024-06-11selftests: seccomp: fix format-zero-length warningsAmer Al Shanawany1-3/+3
fix the following errors by using string format specifier and an empty parameter: seccomp_benchmark.c:197:24: warning: zero-length gnu_printf format string [-Wformat-zero-length] 197 | ksft_print_msg(""); | ^~ seccomp_benchmark.c:202:24: warning: zero-length gnu_printf format string [-Wformat-zero-length] 202 | ksft_print_msg(""); | ^~ seccomp_benchmark.c:204:24: warning: zero-length gnu_printf format string [-Wformat-zero-length] 204 | ksft_print_msg(""); | ^~ Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202312260235.Uj5ug8K9-lkp@intel.com/ Suggested-by: Kees Cook <kees@kernel.org> Signed-off-by: Amer Al Shanawany <amer.shanawany@gmail.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-03-13Merge tag 'seccomp-v6.9-rc1' of ↵Linus Torvalds1-2/+36
git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux Pull seccomp updates from Kees Cook: "There are no core kernel changes here; it's entirely selftests and samples: - Improve reliability of selftests (Terry Tritton, Kees Cook) - Fix strict-aliasing warning in samples (Arnd Bergmann)" * tag 'seccomp-v6.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux: samples: user-trap: fix strict-aliasing warning selftests/seccomp: Pin benchmark to single CPU selftests/seccomp: user_notification_addfd check nextfd is available selftests/seccomp: Change the syscall used in KILL_THREAD test selftests/seccomp: Handle EINVAL on unshare(CLONE_NEWPID)
2024-02-07selftests/seccomp: Pin benchmark to single CPUKees Cook1-2/+36
The seccomp benchmark test (for validating the benefit of bitmaps) can be sensitive to scheduling speed, so pin the process to a single CPU, which appears to significantly improve reliability, and loosen the "close enough" checking to allow up to 10% variance instead of 1%. Reported-by: kernel test robot <oliver.sang@intel.com> Closes: https://lore.kernel.org/oe-lkp/202402061002.3a8722fd-oliver.sang@intel.com Cc: Andy Lutomirski <luto@amacapital.net> Cc: Will Drewry <wad@chromium.org> Reviewed-by: Mark Brown <broonie@kernel.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2024-01-30kselftest/seccomp: Report each expectation we assert as a KTAP testMark Brown1-20/+41
The seccomp benchmark test makes a number of checks on the performance it measures and logs them to the output but does so in a custom format which none of the automated test runners understand meaning that the chances that anyone is paying attention are slim. Let's additionally log each result in KTAP format so that automated systems parsing the test output will see each comparison as a test case. The original logs are left in place since they provide the actual numbers for analysis. As part of this rework the flow for the main program so that when we skip tests we still log all the tests we skip, this is because the standard KTAP headers and footers include counts of the number of expected and run tests. Tested-by: Anders Roxell <anders.roxell@linaro.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2024-01-30kselftest/seccomp: Use kselftest output functions for benchmarkMark Brown1-21/+24
In preparation for trying to output the test results themselves in TAP format rework all the prints in the benchmark to use the kselftest output functions. The uses of system() all produce single line output so we can avoid having to deal with fully managing the child process and continue to use system() by simply printing an empty message before we invoke system(). We also leave one printf() used to complete a line of output in place. Tested-by: Anders Roxell <anders.roxell@linaro.org> Acked-by: Kees Cook <keescook@chromium.org> Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-12-11selftests/seccomp: remove ARRAY_SIZE define from seccomp_benchmarkShuah Khan1-1/+1
ARRAY_SIZE is defined in several selftests. Remove definitions from individual test files and include header file for the define instead. ARRAY_SIZE define is added in a separate patch to prepare for this change. Remove ARRAY_SIZE from seccomp_benchmark and pickup the one defined in kselftest.h. Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
2021-06-28selftests/seccomp: Avoid using "sysctl" for reportKees Cook1-2/+6
Instead of depending on "sysctl" being installed, just use "grep -H" for sysctl status reporting. Additionally report kernel version for easier comparisons. Signed-off-by: Kees Cook <keescook@chromium.org>
2021-06-28selftests/seccomp: Flush benchmark outputKees Cook1-0/+2
When running the seccomp benchmark under a test runner, it wouldn't provide any feedback on progress. Set stdout unbuffered. Suggested-by: Will Drewry <wad@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org>
2020-11-20selftests/seccomp: Compare bitmap vs filter overheadKees Cook1-22/+129
As part of the seccomp benchmarking, include the expectations with regard to the timing behavior of the constant action bitmaps, and report inconsistencies better. Example output with constant action bitmaps on x86: $ sudo ./seccomp_benchmark 100000000 Current BPF sysctl settings: net.core.bpf_jit_enable = 1 net.core.bpf_jit_harden = 0 Benchmarking 200000000 syscalls... 129.359381409 - 0.008724424 = 129350656985 (129.4s) getpid native: 646 ns 264.385890006 - 129.360453229 = 135025436777 (135.0s) getpid RET_ALLOW 1 filter (bitmap): 675 ns 399.400511893 - 264.387045901 = 135013465992 (135.0s) getpid RET_ALLOW 2 filters (bitmap): 675 ns 545.872866260 - 399.401718327 = 146471147933 (146.5s) getpid RET_ALLOW 3 filters (full): 732 ns 696.337101319 - 545.874097681 = 150463003638 (150.5s) getpid RET_ALLOW 4 filters (full): 752 ns Estimated total seccomp overhead for 1 bitmapped filter: 29 ns Estimated total seccomp overhead for 2 bitmapped filters: 29 ns Estimated total seccomp overhead for 3 full filters: 86 ns Estimated total seccomp overhead for 4 full filters: 106 ns Estimated seccomp entry overhead: 29 ns Estimated seccomp per-filter overhead (last 2 diff): 20 ns Estimated seccomp per-filter overhead (filters / 4): 19 ns Expectations: native ≤ 1 bitmap (646 ≤ 675): ✔️ native ≤ 1 filter (646 ≤ 732): ✔️ per-filter (last 2 diff) ≈ per-filter (filters / 4) (20 ≈ 19): ✔️ 1 bitmapped ≈ 2 bitmapped (29 ≈ 29): ✔️ entry ≈ 1 bitmapped (29 ≈ 29): ✔️ entry ≈ 2 bitmapped (29 ≈ 29): ✔️ native + entry + (per filter * 4) ≈ 4 filters total (755 ≈ 752): ✔️ [YiFei: Changed commit message to show stats for this patch series] Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/1b61df3db85c5f7f1b9202722c45e7b39df73ef2.1602431034.git.yifeifz2@illinois.edu
2020-07-11selftests/seccomp: Improve calibration loopKees Cook1-18/+32
The seccomp benchmark calibration loop did not need to take so long. Instead, use a simple 1 second timeout and multiply up to target. It does not need to be accurate. Signed-off-by: Kees Cook <keescook@chromium.org>
2020-07-11selftests/seccomp: Expand benchmark to per-filter measurementsKees Cook1-7/+29
It's useful to see how much (at a minimum) each filter adds to the syscall overhead. Add additional calculations. Signed-off-by: Kees Cook <keescook@chromium.org>
2017-08-14selftests/seccomp: Add simple seccomp overhead benchmarkKees Cook1-0/+99
This attempts to produce a comparison between native getpid() and a RET_ALLOW-filtered getpid(), to measure the overhead cost of using seccomp(). Signed-off-by: Kees Cook <keescook@chromium.org>