strace

Mentors: Student: SuHsueyu

The purpose of this project is to extract BTF information for eBPF maps, process it in a human-readable manner, and improve decoding for the bpf() syscall's map manipulation sub-calls.

Mentors: Student: Srikavin Ramkumar

<p>Many system call decoders in <code>strace</code> are very similar in structure. This proposal aims to incorporate a system for generating syscall decoders from a system call description language into strace’s build system. This proposal would allow the strace project to leverage descriptions of a large number of system calls and <code>ioctl</code>s that are already described in a similar format.</p>

Mentors: Student: Ákos Uzonyi

<p>When strace is tracing a process which is in an other process namespace than strace itself, PIDs in system call arguments and return values are printed as PIDs in the target process' namespace. This is normal behavior, as these are the actual values that are passed between the process and the kernel. But it would be useful to have an option for strace to translate these ids to strace's own pid namespace. For example when tracing a process inside a Docker container, the translated PIDs allows us, to access these the processes from the host environment (eg. inspecting processes created by the clone syscall). The goal of the project is to add a flag to strace, which enables this translation.</p>

Mentors: Student: Zhibin Li

<p>Direct Rendering Manager subsystem has pretty elaborate ioctl interface, and it might be useful to be able to support its decoding.</p>

Mentors: Student: Paul Chaignon

<p>strace currently adds significant overhead to any application it traces. Even when users are interested in a handful of syscalls, strace will intercept all syscall made by the observed processes, involving several context switches per syscall.</p> <p>Since Linux 3.5, userspace applications can rely on seccomp-bpf to filter the syscalls they want to trace. In that case, the set of monitored syscalls is filtered in the kernel, using cBPF, before any context switch to userspace. strace could leverage seccomp-bpf to avoid tracing syscalls users don't want. The tracing landscape of Linux also drastically evolved in recent years. In particular, user applications can rely on eBPF programs to filter and aggregate data of interest in the kernel, with low overhead.</p> <p>During this Google Summer of Code, I will finish and merge the works started to 1) rely on seccomp-bpf to filter syscalls in kernel space and 2) allow strace to use alternative backends. That second work will come with a tracepoint/BPF proof of concept to ensure strace supports diverse backends, beyond the usual ptrace model.</p>