Flexible and Concise Spectre Mitigations for BPF
EuroDW’23 Submission by Luis Gerhorst, Henriette Hofmeier, and Timo Hönig

Abstract:

High performance IO demands low-overhead communication between user- and kernel space. This demand can no longer be fulfilled by traditional system calls, which involve frequent transitions between user and kernel context. Linux’s extended Berkeley Packet Filter (BPF) avoid user-/kernel transitions by just-in-time compiling user bytecode and executing it in kernel-mode with near-native speed. To still isolate BPF programs from the kernel, they are statically analyzed for memory- and type-safety which imposes some restrictions but allows for good expressiveness and high performance. However, to mitigate the Spectre vulnerabilities disclosed in 2018, BPF’s expressiveness and performance had to be severely limited for unprivileged users to prevent speculative side-channel attacks. This forces users to resort to unsafe alternatives such as privileged BPF programs, which can not be consistently mitigated.

We empirically show that there is potential to improve the performance and expressiveness of unprivileged BPF without sacrificing safety. For this, we present preliminary microbenchmarks and show that a significant portion of real-world programs can not be successfully mitigated by the current implementation. To solve this, we propose to make the mitigations configurable at run-time in order to allow for flexible and concise Spectre mitigations.

1. Introduction

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].

2. Related Work

To isolate the BPF programs from the kernel, the bytecode is statically verified for memory- and type-safety in the v6.1 Linux kernel. Traditionally, 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 safe1 even in the face of the Spectre attacks.

3. Preliminary Results

Our first contribution is a throughout analysis of current Linux BPF Sprectre mitigations. We empirically show that there is 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 Linux v6.1 BPF Spectre mitigations. Regarding expressiveness, we have collected BPF programs from multiple popular open-source projects and have found that a significant portion of these programs do not load with Spectre mitigations enabled. Finally, regarding safety, we rely on formal models as proposed by [3] and clearly state our attacker model and the assumptions about the hardware.

4. Work to be Done

Depending on the system’s context (guarantees from the hardware vendor and attack model), there are multiple feasible security policies to be implemented by the verifier. The current BPF verifier hard-codes on such policy for unprivileged programs and applies no consistent mitigation-policy to privileged programs.

We consider two approaches to solve this. First, the in-kernel verifier can be extended to apply mitigations more concisely, thereby improving performance and expressiveness. However, the verifier is already very complex which frequently leads to implementation bugs [5]. Second, as an alternative, the security policy implemented by the BPF verifier can be made configurable at runtime without increasing its complexity, for example, by integrating instructions to inhibit speculation into the BPF bytecode instruction set [7]. This would allow unprivileged programs to be concisely mitigated at load-time by a user space service. Further, this enables programmers and compilers to implement efficient mitigations for privileged programs manually at implementation-time, or automatically compile-time.

References:

[1]
Bhattacharyya, A., Sandulescu, A., Neugschwandtner, M., Sorniotti, A., Falsafi, B., Payer, M. and Kurmus, A. 2019. SMoTherSpectre. Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security (New York, NY, USA, Nov. 2019).
[2]
Canella, C., Van Bulck, J., Schwarz, M., Lipp, M., Von Berg, B., Ortner, P., Piessens, F., Evtyushkin, D. and Gruss, D. 2019. A systematic evaluation of transient execution attacks and defenses. 28th USENIX Security Symposium (USENIX Security 19) (2019), 249–266.
[3]
Cauligi, S., Disselkoen, C., Moghimi, D., Barthe, G. and Stefan, D. 2021. SoK: Practical foundations for software Spectre defenses. (May 2021).
[4]
Gerhorst, L., Herzog, B., Reif, S., Schröder-Preikschat, W. and Hönig, T. 2021. AnyCall: Fast and Flexible System-Call Aggregation. Proceedings of the 11th Workshop on Programming Languages and Operating Systems (Virtual Event Germany, Oct. 2021), 1–8.
[5]
[6]
Guarnieri, M., Köpf, B., Morales, J.F., Reineke, J. and Sánchez, A. 2020. Spectector: Principled Detection of Speculative Information Flows. 2020 IEEE Symposium on Security and Privacy (SP) (May 2020), 1–19.
[7]
Jeanpierre, D. and Carruth, C. 2020. Mitigating Spectre v1 Attacks in C++.
[8]
Mambretti, A., Neugschwandtner, M., Sorniotti, A., Kirda, E., Robertson, W. and Kurmus, A. 2019. Speculator: a tool to analyze speculative execution attacks and mitigations. Proceedings of the 35th Annual Computer Security Applications Conference (New York, NY, USA, Dec. 2019), 747–761.
[9]
Mcilroy, R., Sevcik, J., Tebbi, T., Titzer, B.L. and Verwaest, T. 2019. Spectre is here to stay: An analysis of side-channels and speculative execution. (Feb. 2019).
[10]
Patrignani, M. and Guarnieri, M. 2021. Exorcising spectres with secure compilers. Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (New York, NY, USA, Nov. 2021).
[11]
Schwarz, M., Schwarzl, M., Lipp, M. and Gruss, D. 2018. NetSpectre: Read arbitrary memory over network. (Jul. 2018).
[12]
Vassena, M., Disselkoen, C., Gleissenthall, K.v., Cauligi, S., Kıcı, R.G., Jhala, R., Tullsen, D. and Stefan, D. 2021. Automatically eliminating speculative leaks from cryptographic code with blade. Proceedings of the acm on programming languages. 5, POPL (Jan. 2021), 1–30. DOI:https://doi.org/10.1145/3434330.

Footnotes:

1

Not considering programming errors.