[FEATURE] Address last inconsistencies in our syscalls

Andreagit97 commented 1 year ago

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 https://github.com/falcosecurity/libs/issues/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:

[ ] fcntl64
[ ] stat64
[ ] fstat64
[ ] sendfile64
[ ] setresuid32
[ ] setresgid32
[ ] setuid32
[ ] setgid32
[ ] getuid32
[ ] geteuid32
[ ] getgid32
[ ] getegid32
[ ] getresuid32
[ ] getresgid32

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

Please note: These syscalls should be never compiled unless you have the following kernel config enabled: CONFIG_64BIT.

Andreagit97 commented 1 year ago

I've used milestone /next-driver but we will probably focus on that in the next release

FedeDP commented 1 year ago

/milestone next-driver

poiana commented 9 months ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

Andreagit97 commented 9 months ago

/remove-lifecycle stale

poiana commented 6 months ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

Andreagit97 commented 6 months ago

/remove-lifecycle stale

poiana commented 3 months ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

Andreagit97 commented 3 months ago

/remove-lifecycle stale

poiana commented 4 days ago

Issues go stale after 90d of inactivity.

Mark the issue as fresh with /remove-lifecycle stale.

Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Provide feedback via https://github.com/falcosecurity/community.

/lifecycle stale

falcosecurity / libs

[FEATURE] Address last inconsistencies in our syscalls #1004