Paul Chaignon

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 --seccomp-bpf 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 --seccomp-bpf 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.

• Problem addressed and ptrace default behavior
• seccomp-bpf, SECCOMP_RET_TRACE, and the new behavior
• cBPF syscall matching algorithms
• Main limitations: working together with -p and -f
• Avenues for improvements

Part of this talk is covered in the following blog post: https://pchaigno.github.io/strace/2019/10/02/introducing-strace-seccomp-bpf.html.

The bcc project [1], mostly known for its collection of Linux tracing tools, is a framework to ease the development of BPF programs for Linux. Indeed, in its recent releases, the Linux kernel can be extended with small BPF bytecode programs whose memory and fault safety is statically verified at load time. These programs are usually written in a subset of C and compiled to the BPF bytecode. To access kernel memory they must use special functions, called helpers.

The bcc framework provides Python, Lua, and C++ wrappers to install and interact with these programs, as well as syntactic sugar for the C subset. In particular, bcc allows developers to access kernel memory as easily as they would access the BPF stack. C programs are transparently rewritten at load time, before their compilation to BPF bytecode, to translate all dereferences of pointers to kernel memory (called external pointers) into calls to the appropriate helpers.

In this talk, after providing the necessary background on BPF, we will discuss bcc's use of Clang to track external pointers throughout the code and rewrite their dereferences. We will describe the problems we had to overcome with code examples and detail the limitations of the current implementation. Among other things [2], bcc performs three traversals of the AST to track external pointers across BPF programs (through persistent data structures), follows external pointers through assignments, return values, and structure members, and keeps track of their indirections levels.

1 - https://github.com/iovisor/bcc 2 - https://github.com/iovisor/bcc/blob/master/src/cc/frontends/clang/b_frontend_action.cc

The widely adopted Open vSwitch implements the OpenFlow forwarding model. Its simple match-action abstraction eases network management, while providing enough flexibility to define complex forwarding pipelines. OpenFlow, however, cannot express the many packets processing algorithms required for traffic measurement, network security, or congestion diagnosis because it lacks a persistent state and basic arithmetic and logic operations.

This talk presents Oko, an extension of Open vSwitch with support for BPF actions. We implemented a first userspace prototype over Open vSwitch-DPDK. Our userspace BPF VM relies on the ubpf project, extended with a rudimentary verifier and support for persistent data structures (BPF's maps).

We compare the performance of our prototype for several packet processing applications with a second setup in which applications run as secondary DPDK processes exchanging packets with Open vSwitch over a shared memory (zero-copy DPDK Ring Port setup). Our Oko setup offers a near 2x performance improvement over this alternative setup.