Move event scope filter into the kernel

[yanivagman]

Event scope filter is currently running in userspace, but it should be straight forward to move it into the kernel since we can use the same logic we use today to compute our scopes in the kernel. This can be done by having new bpf maps like the current existing filters maps, with the difference that the key will be now composed of the event id and the field we are looking for. A potential problem to this move can be instruction limit, and to solve this we might need to add another tail call.

[NDStrahilevitz]

There's another challenge here: some context fields are only enriched in userspace (particularly container ones) so we would need to add a cgroup id map for them.

[itaysk]

to keep the scope of this issue manageable, let's start with just the easy ones, and we can open a new issue for the complex ones later

[NDStrahilevitz]

to keep the scope of this issue manageable, let's start with just the easy ones, and we can open a new issue for the complex ones later

There's some issues with doing it that way: Consider the case where a user sets --trace event1.context.image=redis:latest --trace event1.context.comm=ls. Since comm was easy to migrate but image wasn't we only migrated comm to kernel. Now let's say an event passes the kernel comm filter, we now need to flag it for further checking in userland for the image context filter.

[yanivagman]

to keep the scope of this issue manageable, let's start with just the easy ones, and we can open a new issue for the complex ones later

There's some issues with doing it that way: Consider the case where a user sets --trace event1.context.image=redis:latest --trace event1.context.comm=ls. Since comm was easy to migrate but image wasn't we only migrated comm to kernel. Now let's say an event passes the kernel comm filter, we now need to flag it for further checking in userland for the image context filter.

Why is it a problem? We simply run all userspace filters for the given event like we do today

[NDStrahilevitz]

Just that it would add complexity by splitting the same filters action between the kernel and user space instead of keeping it in only one of them. Since this is v0.14.0 targeted we can add an issue targeting v0.13.0 to add maps for container enriched fields.

[yanivagman]

Just that it would add complexity by splitting the same filters action between the kernel and user space instead of keeping it in only one of them. Since this is v0.14.0 targeted we can add an issue targeting v0.13.0 to add maps for container enriched fields.

But these are different filters, not the same

[NDStrahilevitz]

Just that it would add complexity by splitting the same filters action between the kernel and user space instead of keeping it in only one of them. Since this is v0.14.0 targeted we can add an issue targeting v0.13.0 to add maps for container enriched fields.

But these are different filters, not the same

They are all part of the ContextFilter struct. Anyway if we don't move it all together we will need to add some context flag for that (to complete filtering in user space if needed).

[yanivagman]

Depends on the implementation. Let's discuss this offline.

[geyslan]

@geyslan keeping an eye.

[geyslan]

@rscampos I think that this will be future effort of yours, is that right?