[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_getresgidExtracted 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: