8000 tracee-ebpf: turn MAX_PATH_COMPONENTS down to 48 by rafaeldtinoco · Pull Request #889 · aquasecurity/tracee · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

tracee-ebpf: turn MAX_PATH_COMPONENTS down to 48 #889

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

Merged
merged 1 commit into from
Aug 8, 2021
Merged

tracee-ebpf: turn MAX_PATH_COMPONENTS down to 48 #889

merged 1 commit into from
Aug 8, 2021

Conversation

rafaeldtinoco
Copy link
Contributor

Fixes: #851

For the kprobe security_sb_mount, the save_path_to_str_buf() complexity
is too big with the unroll logic + MAX_PATH_COMPONENTS of 80, even on
higher kernels (like 5.4 in Ubuntu). Reducing to 64 did NOT help.
Reducing to 48 DID help and it worked.

Ubuntu kernel contains c04c0d2b968a ("bpf: increase complexity limit and
maximum program size") commit with no reversions. The commit states
that:

BPF_COMPLEXITY_LIMIT_INSNS is the kernel internal limit
and success to load the program no longer depends on program size,
but on 'smartness' of the verifier only.

which might indicate that the eBPF verifier in older kernels, like 5.4,
is not smart enough to consider an unroll of 80 iterations, in the path
resolution function, a logic less complex than it should.

Fixes: #851

For the kprobe security_sb_mount, the save_path_to_str_buf() complexity
is too big with the unroll logic + MAX_PATH_COMPONENTS of 80, even on
higher kernels (like 5.4 in Ubuntu). Reducing to 64 did NOT help.
Reducing to 48 DID help and it worked.

Ubuntu kernel contains c04c0d2b968a ("bpf: increase complexity limit and
maximum program size") commit with no reversions. The commit states
that:

    BPF_COMPLEXITY_LIMIT_INSNS is the kernel internal limit
    and success to load the program no longer depends on program size,
    but on 'smartness' of the verifier only.

which might indicate that the eBPF verifier in older kernels, like 5.4,
is not smart enough to consider an unroll of 80 iterations, in the path
resolution function, a logic less complex than it should.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

failed to attach to raw tracepoint 'sys_enter': invalid argument in kernel 5.4
2 participants
0