A Scheduling-Aware Defense Against Prefetching-Based Side-Channel Attacks

TL;DR

This work tackles prefetching-based side channels that threaten process isolation by proposing PreFence, a scheduling-aware, software-based defense that temporarily disables the prefetcher during security-critical code. It first systematizes existing attacks into five stages and shows training, triggering, and extraction are core, cache-based components shared across attacks. The authors implement a Linux kernel patch to allow per-process prefetcher control and extend it to handle SMT and shared prefetchers, demonstrating efficacy in preventing leakage (e.g., in an OpenSSL-based scenario) with negligible overhead for non-security workloads. The results suggest PreFence can be integrated into commodity OSes and potentially extended to signal security-relevant code to the kernel, offering a practical, low-overhead path to mitigating a broad class of prefetcher-based side channels.

Abstract

Modern computer processors use microarchitectural optimization mechanisms to improve performance. As a downside, such optimizations are prone to introducing side-channel vulnerabilities. Speculative loading of memory, called prefetching, is common in real-world CPUs and may cause such side-channel vulnerabilities: Prior work has shown that it can be exploited to bypass process isolation and leak secrets, such as keys used in RSA, AES, and ECDH implementations. However, to this date, no effective and efficient countermeasure has been presented that secures software on systems with affected prefetchers. In this work, we answer the question: How can a process defend against prefetch-based side channels? We first systematize prefetching-based side-channel vulnerabilities presented in academic literature so far. Next, we design and implement PreFence, a scheduling-aware defense against these side channels that allows processes to disable the prefetcher temporarily during security-critical operations. We implement our countermeasure for an x86_64 and an ARM processor; it can be adapted to any platform that allows to disable the prefetcher. We evaluate our defense and find that our solution reliably stops prefetch leakage. Our countermeasure causes negligible performance impact while no security-relevant code is executed, and its worst case performance is comparable to completely turning off the prefetcher. The expected average performance impact depends on the security-relevant code in the application and can be negligible as we demonstrate with a simple web server application. We expect our countermeasure could widely be integrated in commodity OS, and even be extended to signal generally security-relevant code to the kernel to allow coordinated application of countermeasures.

Figures (9)

• Figure 1: Stages of prefetching-based side channels
• Figure 2: Overview of the sequence of activities in prefetching-based attacks. Core activities required by all highlighted in red.
• Figure 3: PreFence at work: The prefetcher is disabled temporarily while security-critical code is executed. On SMT-capable cores and for shared prefetchers, the scheduler considers requested states of the relevant parallel processes.
• Figure 4: Prefetcher behavior when trained while disabled (compared to the behavior when trained while enabled). Blue boxes denote accesses, red boxes indicate prefetch locations. The tested prefetchers cannot be trained while it is disabled.
• Figure 5: Latency of accessing the prefetch location after calling the vulnerable OpenSSL function with the PreFence countermeasure not applied (prefetch_-disable flag cleared) and applied (flag set). Short access latency indicates unwanted leakage, which is prevented by activating our countermeasure.