strace --seccomp-bpf: a look under the hood
Channel: FOSDEM
Date: 23/09/2020

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