support dirty_pipe_splice in unexploited kernels (final fix)

rafaeldtinoco commented 2 years ago

Prerequisites

[x] This affects latest released version.
[x] This affects current development tree (origin/HEAD).
[x] There isn't an issue describing the bug.

Select one OR another:

[ ] I'm going to create a PR to solve this (assign to yourself).
[x] Someone else should solve this.

Bug description

This is a continuation of https://github.com/aquasecurity/tracee/pull/1663 and Alon is compromised in fixing it after we implement the kernel versioning dependency (per event) support.

Steps to reproduce

Steps to reproduce the issue:

docker run --rm --privileged -v $(pwd):/tracee:rw -e kvm_accel="kvm" -e kern_version=5.4.166-ubuntu+ -e test_name=TRC-2 -e is_noncore=1 -t rafaeldtinoco/tracee-test-kernels:latest
...
llc \
    -march=bpf -mcpu=v2 \
    -filetype=obj \
    -o dist/tracee.bpf.5_4_166-ubuntu+..o \
    dist/tracee.bpf.5_4_166-ubuntu+..ll
rm dist/tracee.bpf.5_4_166-ubuntu+..ll
./pkg/ebpf/c/tracee.bpf.c:4946:39: error: use of undeclared identifier 'PIPE_BUF_FLAG_CAN_MERGE'
    if ((out_pipe_last_buffer_flags & PIPE_BUF_FLAG_CAN_MERGE) == 0) {
                                      ^
1 error generated.
llc: error: llc: dist/tracee.bpf.5_4_166-ubuntu+..ll: error: Could not open input file: No such file or directory
rm: cannot remove 'dist/tracee.bpf.5_4_166-ubuntu+..ll': No such file or directory

This error will be fixed, but in a hacky way as commented at: https://github.com/aquasecurity/tracee/pull/1663#issuecomment-1099092194

Context

Relevant information about my setup:

Linux version: tracee-test-kernels
Linux kernel version: 5.4.166-ubuntu+
Tracee version (or commit id of your tree): 0f28a2cc
LLVM version: 12
Golang version: 1.17

Additional Information (files, logs, etc)

AlonZivony commented 1 year ago

I am bringing this up again, but as a general issue. We should create a method for events to announce which kernels they support (or don't support) and announce to the user + avoid being loaded if they are not supported. We should think if it should be in the event level, or the probe level.

AlonZivony commented 1 year ago

We will need the dependency on the kernel version to support fine tuning of major, minor and patch versions. For example, event works only for 6.3.4 and forward for patch versions (aka 6.3.x), and for 6.4 and forward for minor versions (and any major afterwards by default).

rafaeldtinoco commented 1 year ago

We should create a method for events to announce which kernels they support (or don't support) and announce to the user + avoid being loaded if they are not supported.

@yanivagman should comment here based on previous discussions IMO.

Yaniv and I thought about this, but there is a bigger problem. Versions don't mean anything for eBPF features in LTS kernels from distros (RedHat or SuSe). Well, mostly for RedHat, as they backport features for their older kernels.

With that said, we ended up thinking that the eBPF features probe (in our TODO list) + multiple eBPF objects (in our TODO list) could help: By probing if features are available, and possibly having more than 1 version of the eBPF programs, we could support different kernel versions, or disable policies/filters/events if they can't be supported.

OTOH, we could have a list of known(supported) distros and kernel versions and know exactly what features they support before the feature probing feature. Either way, I believe it hasn't been fully developed due to lack of time in our roadmap (and priorities).

aquasecurity / tracee