-
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
fix(driver): manage syscalls only defined with socketcall #1128
Conversation
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it> Co-authored-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
f690ff8
to
87bed4b
Compare
/* we need to use `return_code + 1` because return_code | ||
* is the enter event. | ||
*/ | ||
record_event_all_consumers(return_code + 1, return_code == PPME_GENERIC_E ? UF_ALWAYS_DROP : UF_USED, &event_data, KMOD_PROG_SYS_EXIT); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Missing return
statement?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Btw i'd avoid this at all, just setting data to be used by the record_event_all_consumers
at the end of the function. Same for sys enter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great catch!
#define SYS_RECVMMSG 19 /* sys_recvmmsg(2) */ | ||
#define SYS_SENDMMSG 20 /* sys_sendmmsg(2) */ | ||
|
||
int socketcall_code_to_syscall_code(int socketcall_code, bool* is_syscall_return) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This feels weird; still, we will need to come back at this impl later, therefore no blocker for me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
agree this is just a patch needed because we are near the release, we need to find something better for all the engines
@@ -362,17 +370,21 @@ TEST(SyscallEnter, socketcall_acceptE) | |||
evt_test->assert_header(); | |||
|
|||
#ifdef __s390x__ | |||
/* socketcall uses accept4 event for SYS_ACCEPT */ | |||
if(!evt_test->is_kmod_engine()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We are not testing kmod on s390x here, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yep, we are testing it, in the else
case of this ifdef
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it> Co-authored-by: Federico Di Pierro <nierro92@gmail.com>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it> Co-authored-by: Federico Di Pierro <nierro92@gmail.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
LGTM label has been added. Git tree hash: 144068c418c4d878c9bdcc84e441398c1a1574ec
|
driver/socketcall_to_syscall.c
Outdated
return PPME_SOCKET_ACCEPT_5_E; | ||
|
||
case SYS_ACCEPT4: | ||
return PPME_SOCKET_ACCEPT4_5_E; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ACCEPT4_5
or ACCEPT4_6
or it makes no difference?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great catch!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great catch Luca !
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it> Co-authored-by: Luca Guerra <luca.guerra@sysdig.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks for this fix!
LGTM label has been added. Git tree hash: 5dc27973805355895a8209ec8ff748418b015534
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/approve
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Andreagit97, FedeDP, LucaGuerra The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
What type of PR is this?
/kind bug
Any specific area of the project related to this PR?
/area driver-kmod
/area tests
Does this PR require a change in the driver versions?
Already bumped both patch versions
What this PR does / why we need it:
Please note: the following changes regard only the kernel module, at least at the moment, since it is the unique driver which supports 32-bit syscall. We will need to find a valid solution for all the drivers in the next future:
As explained in the code there are cases in which given a specific
socketcall
code we are not able to obtain the corresponding syscall code. There are 2 possibilities:SYS_ACCEPT
is defined but__NR_accept
is not. In this case, instead of converting to the syscall code, we will convert to the corresponding event. The only difference in converting to the event is that we lose the capability to use the simple consumer (the simple consumer logic is syscall driven...).Let's imagine the case in which we receive an
SYS_ACCEPT
socketcall code on s390x. We will try to convert it to__NR_accept
but this is not defined in the system. For this reason, we will covert it toPPME_SOCKET_ACCEPT_5_E/X
. Note that the syscall id is not changed to__NR_accept
, we cannot do that as we said, so we keep the__NR_socketcall
id. Now when we face the simple consumer logic we will decide to keep this event looking at the__NR_socketcall
code. If it is interesting we will keep this event, if not we will drop the event.TL;DR; in these corner cases in which we need to convert the socketcall code to an event code we use the
__NR_socketcall
code as a knob to keep or drop these events.Known cases in which the socket call code is defined but the corresponding syscall code is not:
s390x
SYS_ACCEPT
is defined but__NR_accept
is not definedx86 with CONFIG_IA32_EMULATION
SYS_ACCEPT
is defined but__NR_accept
is not definedSYS_SEND
is defined but__NR_send
is not definedSYS_RECV
is defined but__NR_recv
is not definedWhich issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?: