-
Notifications
You must be signed in to change notification settings - Fork 164
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[FEATURE] Address last inconsistencies in our syscalls #1004
Comments
I've used milestone /next-driver but we will probably focus on that in the next release |
/milestone next-driver |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
/remove-lifecycle stale |
Issues go stale after 90d of inactivity. Mark the issue as fresh with Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle stale |
Stale issues rot after 30d of inactivity. Mark the issue as fresh with Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with Provide feedback via https://github.com/falcosecurity/community. /lifecycle rotten |
/remove-lifecycle rotten |
Motivation
Today an event pair could be associated with more than one syscall/ppm_sc ! This is a wrong behavior because any syscall should have its dedicated event pair in order to correctly manage all its params (pipe2/pipe and inotify_init/inotify_init1 are an example of possible issues that this approach could generate #515).
This is the list of syscalls that use an event pair already associated with another syscall:
->
means: "uses an event pair already associated with"__NR_ugetrlimit
->__NR_getrlimit
__NR_fcntl64
->__NR_fcntl
__NR_sendfile64
->__NR_sendfile
__NR_setresuid32
->__NR_setresuid
__NR_setresgid32
->__NR_setresgid
__NR_setuid32
->__NR_setuid
__NR_setgid32
->__NR_setgid
__NR_getuid32
->__NR_getuid
__NR_geteuid32
->__NR_geteuid
__NR_getgid32
->__NR_getgid
__NR_getegid32
->__NR_getegid
__NR_getresuid32
->__NR_getresuid
__NR_getresgid32
->__NR_getresgid
Extracted from: #911
Due to this inconsistency, we didn't implement them yet into the modern bpf probe! More in detail these are the syscalls that still miss a filler into the modern bpf:
Extracted from: #723
As you can notice the 2 sets are almost identical so the idea here is to create a new dedicated event pair for each syscall and add it into the modern bpf probe
The text was updated successfully, but these errors were encountered: