by Paul Chaignon
At: FOSDEM 2020 https://video.fosdem.org/2020/K.4.201/debugging_strace_bpf.webm
strace is known to add significant overhead to any application it traces. Even when users are interested in a handful of syscalls, strace will by default intercept all syscalls made by the observed processes, involving several context switches per syscall.
Since strace v5.3, the ❮code❯--seccomp-bpf❮/code❯ option allows reducing this overhead, by stopping observed processes only at syscalls of interest.
This option relies on seccomp-bpf and inherits a few of its limitations.
In this talk, we will describe the default behavior of ptrace and strace, to understand the problem ❮code❯--seccomp-bpf❮/code❯ addresses.
We will then detail the inner workings of the new option, as seen from ptrace (seccomp-stops) and bpf (syscall matching algorithms).
Finally, we'll discuss limitations of the new option and avenues for improvement. ❮ul❯ ❮li❯Problem addressed and ptrace default behavior❮/li❯ ❮li❯seccomp-bpf, ❮code❯SECCOMP_RET_TRACE❮/code❯, and the new behavior❮/li❯ ❮li❯cBPF syscall matching algorithms❮/li❯ ❮li❯Main limitations: working together with ❮code❯-p❮/code❯ and ❮code❯-f❮/code❯❮/li❯ ❮li❯Avenues for improvements❮/li❯ ❮/ul❯
Part of this talk is covered in the following blog post: ❮a href="https://pchaigno.github.io/strace/2019/10/02/introducing-strace-seccomp-bpf.html"❯https://pchaigno.github.io/strace/2019/10/02/introducing-strace-seccomp-bpf.html❮/a❯.
Room: K.4.201 Scheduled start: 2020-02-02 12:40:00