[Feature] implement new event pairs for a restricted set of syscalls

[Andreagit97]

Motivation

Working on the new dynamic syscall selection, we faced some issues regarding the resolution from the event type to the associated syscall. The 2 main issues are:

• we are not able to recover the syscall associated with an event if the syscall is not defined on that architecture. This is because we use the syscall_table to perform the conversion and this table is architecture dependent. Issue related to this fact: [Bug] Incorrect log output on arm64 in application::check_for_ignored_events falco#2326
• we are not able to associate a syscall with all its event pairs. A syscall could be associated with more than one event pair (if there are old versions of the events). Consider for example the clone syscall, there are several event pairs corresponding to it.

We can address this issue by adding a new field to the event_table, a sort of "source" of the event, in this way we are able to perform, in an architecture-indigent way, an exact conversion from events to ppm_sc and vice-versa.

One blocker to this solution is the fact that today we have an event pair 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"

First set

• __NR_pipe2 -> __NR_pipe
• __NR_inotify_init1 -> __NR_inotify_init
• __NR_eventfd2 -> __NR_eventfd
• __NR_signalfd4 -> __NR_signalfd

Second set

• __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

I've split them into 2 sets because the first one is a real blocker, while the second set is composed of syscalls that are never defined on our supported architectures so the solution will work also if they are associated with an already used event pair. BTW this is an inconsistent approach so we need to address all of them in order to obtain a clear final design.

Please note: a syscall can have multiple event pairs associated while the opposite relation should be forbidden! An event pair should be associated with just one syscall! (the generic event pair is an exception since by definition it is associated with more syscalls)

Feature

Implements new event pairs for the aforementioned syscalls ☝️
Example:
a new event pair for pipe2 -> PPME_SYSCALL_PIPE2_E/PPME_SYSCALL_PIPE2_X

[Andreagit97]

to these syscalls we need to add other 2 corner cases:

• umount/umount2 where umount is handled as a generic syscall while umount2 has 2 associated events. Moreover, today if we want to get umount2 events we need to write umount as the event name, which is an inconsistency.
• accept/accept4 both syscalls are associated with the same event name, so in the event table we have 2 different event pairs PPME_SOCKET_ACCEPT_5_E/PPME_SOCKET_ACCEPT_5_X and PPME_SOCKET_ACCEPT4_5_E/PPME_SOCKET_ACCEPT4_5_X with the same event name "accept"!

[FedeDP]

accept/accept4 both syscalls are associated with the same event name, so in the event table we have 2 different event pairs PPME_SOCKET_ACCEPT_5_E/PPME_SOCKET_ACCEPT_5_X and PPME_SOCKET_ACCEPT4_5_E/PPME_SOCKET_ACCEPT4_5_X with the same event name "accept"!

#975 addresses this by adding a new event pair (PPME_SOCKET_ACCEPT4_6) whose event name is accept4.

[leogr]

/milestone 0.11.0

[Andreagit97]

/milestone 0.11.0

Probably we won't finish it for libs 0.11.0, we will just address the "first set". To close this issue I would like to remove all inconsistencies :)!

[Andreagit97]

Collected the remaining points into #1004 we can close this :)
/close