Flexible and Concise Spectre Mitigations for BPF
FGBS-Spring 2023 Presentation Abstract

Operating systems rely on system calls to allow the controlled communication of isolated processes with the kernel and other processes. Every system call includes a processor mode switch from the unprivileged user mode to the privileged kernel mode. Although processor mode switches are the essential isolation mechanism to guarantee the system’s integrity, they induce direct and indirect performance costs as they invalidate parts of the processor state. In recent years, high-performance networks and storage hardware has made the user/kernel transition overhead the bottleneck for IO-heavy applications. To make matters worse, security vulnerabilities in modern processors (e.g., Meltdown) have prompted kernel mitigations that further increase the transition overhead.

Linux’s extended Berkeley Packet Filter (BPF) allow unprivileged user processes to load safety-checked bytecode into the kernel. The code is just-in-time compiled and executes at near-native speed. Invoking BPF programs in the kernel and calling kernel functions from within BPF is much faster than the respective switch to/from user context [4].

To isolate the BPF programs from the kernel, the bytecode has to be statically verified for memory- and type-safety. Initially, only BPF program paths that could actually execute architecturally were considered during this static analysis. In response to the Spectre vulnerabilities disclosed in 2018 [1, 2, 8, 9, 11], kernel developers have extended the BPF verifier to prevent side-channel leaks from speculatively-executed BPF program paths. This includes (a) inserting instructions to make speculation safe (e.g., index masking), (b) inserting instructions to prevent speculation (e.g., x86 lfence), or (c) statically analyzing the behavior on speculative code paths to ensure they are safe. In summary, these mitigations limit the performance and expressiveness of unprivileged BPF programs in order make them safe¹ even in the face of the Spectre attacks.

In this talk, we show that there is significant potential to improve the performance and expressiveness of unprivileged BPF without sacrificing safety [3, 6, 10, 12]. Regarding performance, this includes preliminary microbenchmarks of the current Linux v6.1 BPF Spectre mitigations. We show that, depending on the system’s context, there are multiple feasible policies to be implemented by the verifier. To solve this, we propose to make the security policy implemented by the BPF verifier configurable at runtime, for example, by integrating instructions to inhibit speculation into the BPF bytecode instruction set [7].