feat!: default to sched_process_exec tracepoint on all architectures
#2726
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
poiana
added
kind/design
release-note
dco-signoff: yes
kind/feature
|
Please double check driver/SCHEMA_VERSION file. See versioning. /hold |
Contributor
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ekoops The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #2726 +/- ##
=======================================
Coverage 77.02% 77.02%
=======================================
Files 296 296
Lines 30818 30818
Branches 4670 4670
=======================================
Hits 23738 23738
Misses 7080 7080
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Contributor
Author
|
False positive 👉 https://github.com/falcosecurity/libs/actions/runs/19668840295/job/56332370933?pr=2726 |
Leverage `sched/sched_process_exec` tracepoint to generate `execve` exit events for both successful `execve` and `execveat` system calls. For failing calls, use dedicated programs/fillers to generate `execve` and `execveat` exit events. This architectural choice is motivated by the fact that the kernel haven't consistently called the correct tracepoint for `execve` and `execveat` calls on all architectures, as well as haven't consistently identified the correct system call in the tracepoint context: - on `x86_64`, a successful `execveat` call is identified as `execve`, and a failing one is identified as `execveat` - on `aarch64`, till version 5.18 (actually, the fix was back-ported up to 5.15: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y&id=42eede3ae05bbf32cb0d87940b466ec5a76aca3f), neither successful `execve`s nor successful `execveat`s used to trigger the `sys_exit` (see https://www.spinics.net/lists/linux-trace/msg01001.html) tracepoint; only failing ones have always triggered the correct behaviour - on `s390x`, each call correctly triggers `sys_exit` tracepoint and is correctly identified as `execve` and `execveat` Indeed, the `sched/sched_process_exec` is correctly triggered on all architectures for successful calls. Moreover, failing calls correctly trigger the `sys_exit` tracepoint, and are correctly associated to the right syscall number. In the past, this design was applied just for `aarch64`, but since it works consistently on all architectures, its application was extended. The only issue seems to be that now we generate `execve` exit events for both `execve` and `execveat`, on call success: this is not a big problem because, in the previous implementation, for successful `execveat` calls, we were only able to generate `execveat` exit event on `s390x`. For this latter case, users will not be impacted by the new design if they rely on rule conditions matching both `execve` and `execveat` event (e.g.: `... evt.type in (execve, execveat) ...`). This patch rearranges `execve` and `execveat` driver tests, by moving tests related to successful calls in `test/drivers/test_suites/generic_tracepoints_suite/sched_process_exec.cpp`, and keeping tests related to failing calls in `test/drivers/test_suites/syscall_exit_suite/execve_x.cpp` and `test/drivers/test_suites/syscall_exit_suite/execveat_x.cpp`. Old tests relate to new tests in the following way: - `execveX_success` -> `sched_proc_exec_execve` - `execveX_not_upperlayer` -> `sched_proc_exec_execve_not_upperlayer` - `execveX_upperlayer_success` -> `sched_proc_exec_execve_upperlayer` - `execveX_success_memfd` -> `sched_proc_exec_execve_memfd` - `execveX_symlink` -> `sched_proc_exec_execve_symlink` - `execveatX_correct_exit` -> `sched_proc_exec_execveat` - `execveatX_execve_exit` -> `sched_proc_exec_execveat` - `execveatX_execve_exit_comm_equal_to_fd` -> `sched_proc_exec_execveat_comm_equal_to_fd` - `execveatX_success_memfd` -> `sched_proc_exec_execveat_memfd` BREAKING CHANGE: emit `execve` exit event instead of `execveat` exit event in case of successful `execveat` call on `s390x` Signed-off-by: Leonardo Di Giovanna <leonardodigiovanna1@gmail.com>
ekoops
force-pushed
the
ekoops/switch-to-sched-process-exec
branch
from
6a440bc to
5e7043b
Compare
X64 kernel testing matrix
ARM64 kernel testing matrix
|
leogr
approved these changes
Dec 3, 2025
gnosek
approved these changes
Dec 4, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What type of PR is this?
/kind design
/kind feature
Any specific area of the project related to this PR?
/area driver-kmod
/area driver-bpf
/area driver-modern-bpf
/area libpman
/area tests
Does this PR require a change in the driver versions?
What this PR does / why we need it:
This PR (spiritual continuation of #416) is an attempt to align
execveandexecveathandling on all architectures:sched/sched_process_exectracepoint to generateexecveexit events for both successfulexecveandexecveatsystem callsexecveandexecveatexit events.This architectural choice is motivated by the fact that the kernel haven't consistently called the correct tracepoint for
execveandexecveatcalls on all architectures, as well as haven't consistently identified the correct system call in the tracepoint context:x86_64, a successfulexecveatcall is identified asexecve, and a failing one is identified asexecveataarch64, till version 5.18 (actually, the fix was back-ported up to 5.15: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-5.15.y&id=42eede3ae05bbf32cb0d87940b466ec5a76aca3f), neither successfulexecves nor successfulexecveats used to trigger thesys_exit(see https://www.spinics.net/lists/linux-trace/msg01001.html) tracepoint; only failing ones have always triggered the correct behaviours390x, each call correctly triggerssys_exittracepoint and is correctly identified asexecveandexecveatIndeed, the
sched/sched_process_execis correctly triggered on all architectures for successful calls. Moreover, failing calls correctly trigger thesys_exittracepoint, and are correctly associated to the right syscall number.In the past, this design was applied just for
aarch64, but since it works consistently on all architectures, its application was extended.The only issue seems to be that now we generate
execveexit events for bothexecveandexecveat, on call success: this is not a big problem because, in the previous implementation, for successfulexecveatcalls, we were only able to generateexecveatexit event ons390x. For this latter case, users will not be impacted by the new design if they rely on rule conditions matching bothexecveandexecveatevent (e.g.:... evt.type in (execve, execveat) ...).This patch rearranges
execveandexecveatdriver tests, by moving tests related to successful calls intest/drivers/test_suites/generic_tracepoints_suite/sched_process_exec.cpp, and keeping tests related to failing calls intest/drivers/test_suites/syscall_exit_suite/execve_x.cppandtest/drivers/test_suites/syscall_exit_suite/execveat_x.cpp.Old tests relate to new tests in the following way:
execveX_success->sched_proc_exec_execveexecveX_not_upperlayer->sched_proc_exec_execve_not_upperlayerexecveX_upperlayer_success->sched_proc_exec_execve_upperlayerexecveX_success_memfd->sched_proc_exec_execve_memfdexecveX_symlink->sched_proc_exec_execve_symlinkexecveatX_correct_exit->sched_proc_exec_execveatexecveatX_execve_exit->sched_proc_exec_execveatexecveatX_execve_exit_comm_equal_to_fd->sched_proc_exec_execveat_comm_equal_to_fdexecveatX_success_memfd->sched_proc_exec_execveat_memfdWhich issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
/milestone next-driver
Does this PR introduce a user-facing change?: