Skip to content
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

argument filtering in eBPF #1536

Closed
mtcherni95 opened this issue Mar 8, 2022 · 9 comments
Closed

argument filtering in eBPF #1536

mtcherni95 opened this issue Mar 8, 2022 · 9 comments

Comments

@mtcherni95
Copy link
Contributor

mtcherni95 commented Mar 8, 2022

We would like to have the option to inject filters to eBPF events. For example, security_open_file event is fired many times, and most of it is non-suspicious paths. The idea here would be to limit the order of magnitude the event is triggered, by inserting for example a filter to the event. For a real case example think about that: security_open_file will be sent to users-pace for further processing, only if the file path is /etc/password.

Lets use this as a major issue for the eBPF filtering (roadmap)

@itaysk
Copy link
Collaborator

itaysk commented Mar 8, 2022

How is this different than current argument based fillers?

@mtcherni95
Copy link
Contributor Author

The filtering here as at event level. The ones we already have are per user/process etc.

@itaysk
Copy link
Collaborator

itaysk commented Mar 9, 2022

we have filters at the event level as well: e.g --trace openat.pathname=/tmp*

@yanivagman
Copy link
Collaborator

The difference is in where you do the filtering.
The filters you refer to happen in userspace, meaning that all the events have to go through the perf buffer, thus might cause lost events in high volumes.
Filtering in the bpf code will avoid such lost events by not sending irrelevant events to userspace.

@mtcherni95
Copy link
Contributor Author

mtcherni95 commented Mar 9, 2022

we could move filtering logics from user to kernel (keeping the same frontend like --trace openat.pathname=/tmp*). The question is if we can do so with potentially all the events we have.

@itaysk itaysk changed the title Perfomance | POCing eBPF filtering argument filtering in eBPF Apr 7, 2022
@rafaeldtinoco rafaeldtinoco reopened this May 3, 2022
@rafaeldtinoco
Copy link
Contributor

@NDStrahilevitz this is one issue you should keep track of (for the major 'filtering improvement' effort you're handling).

@cdelzotti
Copy link
Contributor

Hello, can I be assigned to this ? And would a hashmap to give the required information to the probes do the trick ?

@yanivagman
Copy link
Collaborator

Hello, can I be assigned to this ? And would a hashmap to give the required information to the probes do the trick ?

Thanks @cdelzotti, actually, this is something I already started to tackle and have plans for.
It is probably not the best issue to start with in tracee anyway, as it will also require partitioning the bpf programs using tail calls due to reaching instructions limit.

@yanivagman
Copy link
Collaborator

Closing in favor of #4430

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants