-
Notifications
You must be signed in to change notification settings - Fork 165
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
new(bpf, modern_bpf): introduce socketcall
handling
#811
new(bpf, modern_bpf): introduce socketcall
handling
#811
Conversation
Since this depends on #809 that is wip, can we make wip this too? |
socketcall
handlingsocketcall
handling
I guess, I need to push #809 as branch into |
You are probably right; well let's keep this as is then! |
I will have a deeper look at it but it seems great! I think we can do something similar for the modern bpf probe 🤔 |
af390de
to
468f52f
Compare
socketcall
handlingsocketcall
handling
Hi @FedeDP , @Andreagit97 thanks for merging #809! So now here is the rebased version of the |
Hi @hbrueckner ! Does this PR fix support of old bpf probe for s390x? |
Yeah.. will do! Additional commit comes later today... |
driver/bpf/maps.h
Outdated
@@ -99,6 +99,15 @@ struct bpf_map_def __bpf_section("maps") stash_map = { | |||
}; | |||
#endif | |||
|
|||
#ifdef CAPTURE_SOCKETCALL | |||
struct bpf_map_def __bpf_section("maps") socketcall_args_map = { |
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.
you need to add also an enum for this map https://github.com/falcosecurity/libs/blob/master/driver/bpf/types.h#L216-L230, otherwise, the userspace could parse them out of order. something like SCAP_SOCKETCALL_MAP
should be ok
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.
Thanks @Andreagit97 . Should be solved with this commit.
Hi @Andreagit97, @FedeDP , need some hints from you regarding some initial What I actually realized with initial test failures is that The question is how to best handle this:
Wdyt? For modern BPF, this is quite similar and I already have a prototype which goes into direction b). And, ultimatively, I guess @incertum might be interesting here as well to install very specific system calls only. |
468f52f
to
2217dd4
Compare
Signed-off-by: Hendrik Brueckner <brueckner@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@de.ibm.com>
Signed-off-by: Hendrik Brueckner <brueckner@de.ibm.com>
socketcall
handlingsocketcall
handling
2217dd4
to
d63aa75
Compare
Hi @Andreagit97 , @FedeDP it took a while to complete this PR with @Andreagit97 suggested changes. Now the socketcall support should handle all cases along with respective tests (passing on kmod, bpf, and modern_bpf). From a testing perspective, currently those are missing (and hopefully will be added with the respective modern bpf probes):
The PR is very large due to copying the existing network related tests. The most interesting part of the review is the way to use Also some special handling was required for Take your time to review (better on commit base) ... I will on a conference next week and will be slow in response then. |
that's a huge work @hbrueckner thank you very much for that! I will take a look ASAP! |
@@ -1767,7 +1767,7 @@ static int record_event_consumer(struct ppm_consumer_t *consumer, | |||
} | |||
|
|||
// Check if syscall is interesting for the consumer | |||
if (event_datap->category == PPMC_SYSCALL) | |||
if (event_datap->category == PPMC_SYSCALL && event_datap->event_info.syscall_data.id != event_datap->socketcall_syscall) |
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.
Neat fix, thank you!
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.
All in all, this LGTM! Thank you very much for this huge effort!
Note, most of the lines changes are from test suites ;)
I'll wait for @Andreagit97 for the modern probe part!
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: dc60a823fc377ab93999d2d4d4851e6d021218eb
|
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.
the unique issue is the __NR_ACCEPT
macro that should be converted to __NR_accept
, but since the entity of the PR and the conflict risk I prefer to merge it and I will address these minor comments in another one :)
BTW Amazing work, thank you very much for that!
/approve
case SYS_ACCEPT: | ||
#if defined(CONFIG_S390) && defined(__NR_accept4) | ||
return __NR_accept4; | ||
#elif defined(__NR_ACCEPT) |
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.
#elif defined(__NR_ACCEPT) | |
#elif defined(__NR_accept) |
case SYS_ACCEPT: | ||
#if defined(__TARGET_ARCH_s390) && defined(__NR_accept4) | ||
return __NR_accept4; | ||
#elif defined(__NR_ACCEPT) |
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.
Same here
syscall_get_arguments_deprecated(current, args->regs, 0, 5, val); | ||
#ifndef UDIG | ||
else | ||
memcpy(val, args->socketcall_args, 5*sizeof(syscall_arg_t)); |
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.
syscall_arg_t
is correct but since args->socketcall_args
is a vector of unsigned long
and not of syscall_arg_t
, I would be as explicit as possible
memcpy(val, args->socketcall_args, 5*sizeof(syscall_arg_t)); | |
memcpy(val, args->socketcall_args, 5*sizeof(unsigned long)); |
syscall_get_arguments_deprecated(current, args->regs, 0, 5, val); | ||
#ifndef UDIG | ||
else | ||
memcpy(val, args->socketcall_args, 5*sizeof(syscall_arg_t)); |
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.
Same here
memcpy(val, args->socketcall_args, 5*sizeof(syscall_arg_t)); | |
memcpy(val, args->socketcall_args, 5*sizeof(unsigned long)); |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Andreagit97, FedeDP, hbrueckner 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 |
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Signed-off-by: Andrea Terzolo <andrea.terzolo@polito.it>
Hi @Andreagit97 ,
Thanks for spotting the |
What type of PR is this?
/kind feature
Any specific area of the project related to this PR?
/area driver-bpf
Does this PR require a change in the driver versions?
What this PR does / why we need it:
Add
socketcall
handling to enable capturing of network syscall events ons390x
. See #810 for details.Which issue(s) this PR fixes:
Fixes the BPF part in: #810
Depends-on: #809
Special notes for your reviewer:
I took an approach similar to the
kmod
driver to extract the socket call and its arguments. Arguments are stored and looked up in/from a BPF map. This becomes then transparent to the actual filler implementations.Note that this PR includes and is depending on #809, so for review please focus on the just the last commit.
cc: @FedeDP @Andreagit97 @Molter73
@Andreagit97 The
modern-bpf
version ofsocketcall
handling is not yet finalized and like to briefly discuss my approach in #810.Does this PR introduce a user-facing change?:
This should be transparent.