Control-Flow Integrity (CFI) mitigates code-reuse attacks by restricting indirect control-flow transfers to a predetermined set of valid targets. While prior work has demonstrated that finer-grained, dynamic policies can provide stronger security guarantees, enforcing such policies typically incurs substantial performance overhead. Recent approaches have explored offloading security checks to parallel monitors as a means to reduce this cost. In particular, Software-Driven Logging (SDL), enabled by processor extensions such as Intel Processor Trace (PT), has shown promise for secure and efficient offloading of CFI enforcement to a separate monitor process. However, existing SDL-based solutions are limited to conventional, statically-derived CFI policies (e.g., LLVM-CFI) and only marginally improve their performance.We present StreamCFI, an SDL-based framework that efficiently enforces dynamic CFI through a hybrid approach combining type-based and per-input policies. StreamCFI is built for x86-64 and leverages Intel PT along with the PTWRITE instruction to capture run-time metadata, introducing several novel optimizations to minimize logging overhead. Our evaluation on SPEC CPU2017 benchmarks shows that StreamCFI reduces geometric-mean overhead from 26.67% to 8.63% compared to the state-of-the-art per-input CFI solution, while reducing code-size overhead by 5×. Notably, StreamCFI makes dynamic CFI practical for deployment on commodity hardware, remaining reasonably close to LLVM-CFI’s 3.45% geometric-mean overhead while providing stronger security by reducing the set of allowed targets at run time.

The drivers of modern operating systems use Direct Memory Access (DMA) to efficiently communicate with peripheral devices. Since the memory accessed by DMA is a shared resource between driver and device, it is a possible source of race conditions. Peripheral devices are also often untrusted, so these race conditions open up a new potential attack vector against a trusted OS kernel. In this paper, we present DMARacer, a dynamic detector called for these DMA-based race conditions in kernel code. DMARacer tracks memory accesses to DMA memory throughout the kernel's lifetime and analyses them for various indicators of race conditions. Additionally, upon detecting a race condition, DMARacer uses taint tracking to trace its impact and identify any potential vulnerabilities it may trigger, such as memory corruption or denial-of-service. We used DMARacer to search the drivers of the Linux kernel for DMA-based errors and find that DMA-based race conditions are a systemic issue in driver code. In total, DMARacer was able to detect 817 problematic memory accesses and 344 vulnerable operations in the scanned Linux kernel drivers.

While greybox fuzzing is routinely applied in production environments with great success, directed greybox fuzzing has struggled to gain real-world adoption—despite the great (intuitive) promise and the many optimizations proposed in literature. In practice, directed fuzzers struggle for three critical issues. First, popular implementations build on and compare to ancient baselines, often derived from AFLGo. Unfortunately, none of the optimizations that are essential for performance in modern greybox fuzzers are available in these baselines. As a result, we find reported improvements in directed fuzzing are often only "imaginary" and do not lead to better performance on a modern baseline. Second, directed fuzzing evaluations commonly ignore or misinterpret important factors affecting fuzzing overhead—such as build times and timeouts. As design decisions now build on unreliable data, we find the directed fuzzers perform worse than expected in practice. Third, while almost all directed fuzzers rely on (expensive) analysis stacks, such as points-to and reachability analysis components, they often opt for very different implementations. Since these implementations have their own unique benefits and drawbacks, we find performance differences of directed fuzzers are frequently due to these components rather than the proposed directed fuzzing optimization.In this paper, we investigate the practical impact of these issues by means of an analysis and evaluation of a representative set of popular directed greybox fuzzers. As a way forward, we then present LibAFLGo, a modular directed fuzzing framework that addresses all three issues and allows one to directly compare different directed fuzzing policies on top of a modern fuzzing stack. Our experimental results on state-of-the-art directed fuzzing policies provide two main insights. First, the original AFLGo policies outperform more recent directed fuzzing policies when testing on a modern fuzzing stack. Second, none of the directed fuzzing policies can favorably compete with (nondirected) LibAFL, which scored better overall performance across benchmarks. As such, the quest for efficient directed fuzzing policies must continue.

Spectre-v2 vulnerabilities have been increasingly gaining momentum, as they enable particularly powerful cross-domain transient execution attacks. Attackers can train the indirect branch predictor in one protection domain (e.g., user process) in order to speculatively hijack control flow and disclose data in a victim domain (e.g., kernel). In response to these attacks, vendors have deployed increasingly strong domain isolation techniques (e.g., eIBRS and IBPB) to prevent the predictor in one domain from being influenced by another domain's execution. While recent attacks such as BHI and Post-barrier Spectre have evidenced (now patched) implementation flaws of such techniques, the common assumption is that, barring implementation issues, domain isolation can close the attack surface in the practical cases of interest. In this paper, we challenge this assumption and show that even perfect domain isolation is insufficient to deter practical attacks. To this end, we systematically analyze self-training Spectre-v2 attacks, where both training and speculative control-flow hijacking occur in the same (victim) domain. While self-training attacks are believed to be limited to the in-domain scenario-where attackers can run arbitrary code and inject their own disclosure gadgets in a (default-off) sandbox such as eBPF-our analysis shows cross-domain variants are possible in practice. Specifically, we describe three new classes of attacks against the Linux kernel and present two end-to-end exploits that leak kernel memory on recent Intel CPUs at up to 17 KB/sec. During our investigation, we also stumbled upon two Intel issues which completely break (user, guest, and hypervisor) isolation and re-enable classic Spectre-v2 attacks.

Despite nearly a decade of mitigation efforts by both industry and academia, the community has yet to find comprehensive and efficient countermeasures against pernicious hardware vulnerabilities such as Spectre and Rowhammer. While Spectre mitigations have mostly focused on patching dangerous disclosure gadgets in high-value codebases such as the Linux kernel, mitigating Rowhammer in software is still challenging and security often hinges on the (im)practicality of real-world attacks. Indeed, some Rowhammer attacks are entirely nondeterministic, triggering random bit flips in the hope of corrupting victim data-but at the risk of corrupting critical data and crashing the system. More reliable attacks rely on techniques such as memory templating and massaging, but achieving fully deterministic behavior is still difficult in face of complex memory management abstractions in both hardware and software. In this paper, we show that fully deterministic Rowhammer attacks are feasible. To this end, we exploit synergies with Spectre and specifically focus our attention on so-called half-Spectre gadgets. We show these gadgets, previously deemed unexploitable on last-generation CPUs due to their inability to directly disclose secret data, do enable powerful disclosure primitives to harden other attacks such as Rowhammer. Specifically, we use half-Spectre gadgets to build Preload+Time, a generic primitive to monitor a controlled victim's physical memory activity at the cache line granularity, without sharing memory with the victim. We use this capability to craft ProbeHammer, the first crash-free end-to-end Rowhammer exploit that does not rely on templating or massaging. In detail, we spray physical memory with aggressor (i.e., user) and victim (i.e., page table) data and disclose their location with Preload+Time. This primitive allows us to select safe hammering patterns and avoid unintended bit flips that may crash the system. Our evaluation confirms ProbeHammer attacks yield no false positives (hence, no crashes) by construction and can compromise real-world systems in a matter of hours.

Transient execution vulnerabilities have affected CPUs for the better part of the decade, yet, we are still missing methods to efficiently uncover them at the design stage. Existing approaches try to find programs that leak explicitly defined secrets, sometimes including the transmission over a side-channel, which severely restricts the space of programs that can trigger detection. As a result, current fuzzers are forced to constrain the search space using templates of known vulnerabilities, which risks overfitting. What is missing is a general detection mechanism that (1) makes it easy for the fuzzer to trigger a violation and (2) catches vulnerabilities at their root cause — similarly to sanitizers in software. In this paper, we propose Phantom Trails, an efficient yet generic method for discovering transient execution vulnerabilities. Phantom Trails relies on a fuzzer-friendly detection model that can be applied without the need for templating. Our detector builds on two key design choices. First, it concentrates on finding microarchitectural data leaks independently of the covert channel, thereby focusing on the core of the attack. Second, it automatically infers all secret locations from the architectural behavior of a program, making it easier for the detector to find leaks. We evaluate Phantom Trails by fuzzing the BOOM RISC-V CPU, where it finds all known speculative vulnerabilities in 24-hours, starting from an empty seed and without pre-defined templates, as well as a new Spectre variant specific to BOOM — Spectre-LoopPredictor.

Artifact Evaluation ("AE") is now an accepted practice in the systems community. However, AE processes are inconsistent across venues and even across different editions of the same venue. AE processes regularly encounter the same problems across venues and years. Based on our collective experience in chairing various and heterogeneous AE committees for five consecutive editions of EuroSys, a large systems conference, we present the challenges we believe most pressing. We propose concrete steps to address these challenges in future AEs, serving as guidelines for future chairs and AE committees.

Sanitizers for spatial and temporal memory errors have become a cornerstone of security testing. Popular redzone-based sanitizers such as AddressSanitizer (ASan) offer high compatibility and effectiveness through the use of redzones, but incur significant runtime overhead. A major cause of this overhead is the traditional use of per-object redzone metadata, which constrains the sanitizer to check individual addresses rather than entire ranges of memory at once—as is done by classic bounds checkers based on per-pointer metadata. In this paper, we introduce RangeSanitizer (RSan), a redzone-based sanitizer that introduces a novel metadata and check paradigm. RSan combines the compatibility of red-zones with a rich per-object metadata format that allows for range (rather than address) checks and powerful optimizations. RSan stores bounds information inside the underflow redzone associated with each memory object. By combining pointer tagging with power-of-two size classes, RSan can swiftly locate metadata and validate an access to an arbitrary memory range with a single check. RSan incurs a geomean runtime overhead of 44% on SPEC CPU2017, faster than all state-of-the-art redzone-based sanitizers and twice as fast as ASan. Additionally, fuzzing with AFL++ and RSan as sanitizer improves state-of-the-art throughput by up to 70%.

Double-fetch bugs (or vulnerabilities) stem from in-kernel system call execution fetching the same user data twice without proper data (re)sanitization, enabling TOCT-TOU attacks and posing a major threat to operating systems security. Existing double-fetch protection systems rely on the MMU to trap on writes to syscall-accessed user pages and provide the kernel with a consistent snapshot of user memory. While this strategy can hinder attacks, it also introduces nontrivial runtime performance overhead due to the cost of trapping/remapping and the coarse (page-granular) write interposition mechanism. In this paper, we propose SafeFetch, a practical solution to protect the kernel from double-fetch bugs. The key intuition is that most system calls fetch small amounts of user data (if at all), hence caching this data in the kernel can be done at a small performance cost. To this end, SafeFetch creates per-syscall caches to persist fetched user data and replay them when they are fetched again within the same syscall. This strategy neutralizes all double-fetch bugs, while eliminating trapping/remapping overheads and relying on efficient byte-granular interposition. Our Linux prototype evaluation shows SafeFetch can provide comprehensive protection with low performance overheads (e.g., 4.4% geomean on LMBench), significantly outperforming state-of-the-art solutions.

Linear Address Masking (LAM) is a recently announced Intel feature that enables the CPU to mask off some upper bits before dereferencing a 64-bit pointer. The key idea behind LAM (as well as the similar Upper Address Ignore or UAI from AMD), is to allow software to efficiently make use of untranslated bits of 64-bit linear addresses for metadata. The assumption is that, with LAM (or UAI) features enabled, one can implement fast security (e.g., memory safety) checks and ultimately improve security of production systems. In this paper, we challenge this assumption and show that LAM features can actually degrade security in production by dramatically increasing the Spectre attack surface. To support this claim, we present a new Spectre covert channel based on noncanonical address translation and address key challenges to implement it in practice. For instance, we exploit properties of modern TLBs to craft a reliable signal and LAM features to (crucially) bypass canonicality checks. Moreover, we show that, unlike classic Spectre covert channels, ours unlocks generic (or unmasked) Spectre gadgets encoding high-entropy secrets as dereferenced pointers. Unlike classic (or masked) gadgets, we show the latter escape deployed mitigations and are pervasive in high-value targets such as the Linux kernel. To showcase the new attack surface, we present an end-to-end exploit for Spectre based on LAM (SLAM) targeting upcoming Intel CPUs. We specifically focus on the BHI Spectre variant and show that, despite mitigations believed to eradicate the attack surface, our exploit can abuse a variety of gadgets in the latest Linux kernel and leak the root password hash within minutes from kernel memory. We conclude by evaluating mitigations.

Spatial memory errors such as buffer overflows still rank among the top vulnerabilities in C/C++ programs. Despite much research in the area, the performance overhead of (even partial) mitigations is still too high for practical adoption. To reduce the cost, recent solutions are shifting towards hardware-assisted techniques such as Arm's Memory Tagging Extension (MTE). Unfortunately, state-of-the-art MTE solutions incur high overhead due to frequent memory (re)tagging, especially on the stack. Moreover, they rely on the secrecy of random memory tags and offer probabilistic security guarantees. In this paper, we first provide evidence that random tagging offers limited protection as attackers can deduce the memory tags by means of speculative probing. We then present StickyTags, a deterministic MTE solution that efficiently mitigates bounded spatial memory errors. By organizing the stack and heap layout into per-size-class regions, we can apply persistent memory tags to each region in a predetermined pattern. Hence, the memory tags need only be initialized once, after which they can be reused by objects of the same size class. This eliminates the need for costly memory retagging and allows for a fixed, round-robin assignment of the tags, surrounding every object with large implicit spatial guards. While the size of such guards is bounded by the 4-bit MTE entropy (16 tags), the protection is efficient and deterministic. Indeed, we show StickyTags significantly outperforms existing solutions with realistic runtime overheads for practical adoption (<= 4% on SPEC CPU2006), while fully mitigating 7 out of 8 spatial CVEs evaluated by a recent probabilistic MTE solution.

As control-flow hijacking is getting harder due to increasingly sophisticated CFI solutions, recent work has instead focused on automatically building data-only attacks, typically using symbolic execution, simplifying assumptions that do not always match the attacker's goals, manual gadget chaining, or all of the above. As a result, the practical adoption of such methods is minimal. In this work, we abstract away unnecessary complexities and instead use a lightweight approach that targets the vulnerabilities that are both the most tractable for analysis, and the most promising for an attacker. In particular, we present EINSTEIN, a data-only attack exploitation pipeline that uses dynamic taint analysis policies to: (i) scan for chains of vulnerable system calls (e.g., to execute code or corrupt the filesystem), and (ii) generate exploits for those that take unmodified attacker data as input. EINSTEIN discovers thousands of vulnerable syscalls in common server applications—well beyond the reach of existing approaches. Moreover, using nginx as a case study, we use EINSTEIN to generate 944 exploits, and we discuss two such exploits that bypass state-of-the-art mitigations.

Coverage-guided fuzzers expose bugs by progressively mutating testcases to drive execution to new program locations.Code coverage is currently the most effective and popular exploration feedback.For several bugs, though, also how execution reaches a buggy program location may matter: for those, only tracking what code a testcase exercises may lead fuzzers to overlook interesting program states.Unfortunately, context-sensitive coverage tracking comes with an inherent state explosion problem.Existing attempts to implement contextsensitive coverage-guided fuzzers struggle with it, experiencing non-trivial issues for precision (due to coverage collisions) and performance (due to context tracking and queue/map explosion).In this paper, we show that a much more effective approach to context-sensitive fuzzing is possible.First, we propose function cloning as a backward-compatible instrumentation primitive to enable precise (i.e., collision-free) context-sensitive coverage tracking.Then, to tame the state explosion problem, we argue to account for contextual information only when a fuzzer explores contexts selected as promising.We propose a prediction scheme to identify one pool of such contexts: we analyze the data-flow diversity of the incoming argument values at call sites, exposing to the fuzzer a contextually refined clone of the callee if the latter sees incoming abstract objects that its uses at other sites do not.Our work shows that, by applying function cloning to program regions that we predict to benefit from context-sensitivity, we can overcome the aforementioned issues while preserving, and even improving, fuzzing effectiveness.On the FuzzBench suite, our approach largely outperforms state-of-the-art coverageguided fuzzing embodiments, unveiling more and different bugs without incurring explosion or other apparent inefficiencies.On these heavily tested subjects, we also found 8 enduring security issues in 5 of them, with 6 CVE identifiers issued.

Race conditions arise when multiple threads attempt to access a shared resource without proper synchronization, often leading to vulnerabilities such as concurrent use-after-free. To mitigate their occurrence, operating systems rely on synchronization primitives such as mutexes, spinlocks, etc. In this paper, we present GhostRace, the first security analysis of these primitives on speculatively executed code paths. Our key finding is that all the common synchronization primitives can be microarchitecturally bypassed on speculative paths, turning all architecturally race-free critical regions into Speculative Race Conditions (SRCs). To study the severity of SRCs, we focus on Speculative Concurrent Use-After-Free (SCUAF) and uncover 1,283 potentially exploitable gadgets in the Linux kernel. Moreover, we demonstrate that SCUAF information disclosure attacks against the kernel are not only practical, but that their reliability can closely match that of traditional Spectre attacks, with our proof of concept leaking kernel memory at 12 KB/s. Crucially, we develop a new technique to create an unbounded race window, accommodating an arbitrary number of SCUAF invocations required by an end-to-end attack in a single race window. To address the new attack surface, we also propose a generic SRC mitigation to harden all the affected synchronization primitives on Linux. Our mitigation requires minimal kernel changes and incurs only similar to 5% geomean performance overhead on LMBench.

Spectre v2 is one of the most severe transient execution vulnerabilities, as it allows an unprivileged attacker to lure a privileged (e.g., kernel) victim into speculatively jumping to a chosen gadget, which then leaks data back to the attacker. Spectre v2 is hard to eradicate. Even on last-generation Intel CPUs, security hinges on the unavailability of exploitable gadgets. Nonetheless, with (i) deployed mitigations—eIBRS, no-eBPF, (Fine)IBT—all aimed at hindering many usable gadgets, (ii) existing exploits relying on now-privileged features (eBPF), and (iii) recent Linux kernel gadget analysis studies reporting no exploitable gadgets, the common belief is that there is no residual attack surface of practical concern. In this paper, we challenge this belief and uncover a significant residual attack surface for cross-privilege Spectre-v2 attacks. To this end, we present InSpectre Gadget, a new gadget analysis tool for in-depth inspection of Spectre gadgets. Unlike existing tools, ours performs generic constraint analysis and models knowledge of advanced exploitation techniques to accurately reason over gadget exploitability in an automated fashion. We show that our tool can not only uncover new (unconventionally) exploitable gadgets in the Linux kernel, but that those gadgets are sufficient to bypass all deployed Intel mitigations. As a demonstration, we present the first native Spectre-v2 exploit against the Linux kernel on last-generation Intel CPUs, based on the recent BHI variant and able to leak arbitrary kernel memory at 3.5 kB/sec. We also present a number of gadgets and exploitation techniques to bypass the recent FineIBT mitigation, along with a case study on a 13th Gen Intel CPU that can leak kernel memory at 18 bytes/sec.

Memory sanitizers are powerful tools to detect spatial and temporal memory errors, such as buffer overflows and use-after-frees. Fuzzers and software testers often rely on these tools to discover the presence of bugs. Sanitizers, however, incur significant runtime overhead. For example, Address-Sanitizer (ASan), the most widely used sanitizer, incurs a slowdown of 2x. The main source of this overhead consists of the sanitizer checks, which involve at least a memory lookup, a comparison, and a conditional branch instruction. Applying these checks to confirm the validity of the memory accesses in a program can greatly slow down the execution. We introduce FloatZone, a compiler-based sanitizer to detect spatial and temporal memory errors in C/C++ programs using lightweight checks that leverage the Floating Point Unit (FPU). We show that the combined effects of "lookup, compare, and branch" can be achieved with a single floating point addition that triggers an underflow exception in the case of a memory violation. This novel method to detect illegal accesses greatly improves performance by avoiding the drawbacks of traditional comparisons: it prevents branch mispredictions, enables higher instruction-level parallelism due to offloading to the FPU, and also reduces the cache miss rate due to the lack of shadow memory. Our evaluation shows that FloatZone significantly outperforms existing systems, with just 37% runtime overhead on SPEC CPU2006 and CPU2017. Moreover, we measure an average 2.87x increase in fuzzing throughput compared to the state of the art. Finally, we confirm that FloatZone offers detection capabilities comparable with ASan on the Juliet test suite and a collection of OSS-Fuzz bugs.

Type confusion bugs are a common source of security problems whenever software makes use of type hierarchies, as an inadvertent downcast to an incompatible type is hard to detect at compile time and easily leads to memory corruption at run-time. Where existing research mostly studies type confusion in the context of object-oriented languages such as C++, we analyze how similar bugs affect complex C projects such as the Linux kernel. In particular, structure embedding emulates type inheritance between typed structures. Downcasting in such cases consists of determining the containing structure from the embedded one, and, like its C++ counterpart, may well lead to bad casting to an incompatible type. In this paper, we present UNCONTAINED, a systematic, twopronged solution to discover type confusion vulnerabilities resulting from incorrect downcasting on structure embeddings-which we call container confusion. First, we design a novel sanitizer to dynamically detect such issues and evaluate it on the Linux kernel, where we find as many as 11 container confusion bugs. Using the patterns in the bugs detected by the sanitizer, we then develop a static analyzer to find similar bugs in code that dynamic analysis fails to reach and detect another 78 bugs. We reported and proposed patches for all the bugs (with 102 patches already merged and 6 CVEs assigned), cooperating with the Linux kernel maintainers towards safer design choices for container manipulation.

Sanitizers are widely used compiler features that detect undefined behavior and resulting vulnerabilities by injecting runtime checks into programs. For better performance, sanitizers are often used in conjunction with optimization passes. But doing so combines two compiler features with conflicting objectives. While sanitizers want to expose undefined behavior, optimizers often exploit these same properties for performance. In this paper, we show that this clash can have serious consequences: optimizations can remove sanitizer failures, thereby hiding the presence of bugs or even introducing new ones. We present LookUB, a differential-testing based framework for finding optimizer transformations that elide sanitizer failures. We used our method to find 17 such sanitizer-eliding optimizations in Clang. Next, we used static analysis and fuzzing to search for bugs in open-source projects that were previously hidden due to sanitizer-eliding optimizations. This led us to discover 20 new bugs in Linux Containers, libmpeg2, NTFS-3G, and WINE. Finally, we present an effective mitigation strategy based on a customization of the Clang optimizer with an overhead increase of 4%.

Hybrid fuzzing, the combination between fuzzing and concolic execution, holds great promise in theory, but has so far failed to deliver all the expected advantages in practice due to its high overhead. The cause is the large amount of time spent in the SMT solver. As a result, hybrid fuzzers often lose out to simpler, yet faster techniques. This issue remains despite novel query pruning techniques that reduce the number and complexity of solver queries as they preclude other crucial optimizations like incremental solving. We introduce TRIEREME, a method to speed up the hybrid fuzzer's concolic engine by reducing the time spent in the SMT solver. TRIEREME uses a trie (or prefix tree) data structure to schedule and cache solver queries, exploiting common prefixes. This design is made possible by decoupling concolic tracing from concolic solving. As a result, TRIEREME manages to reconcile pruning with incremental solving, reaping their combined benefits. In our tests, TRIEREME speeds up concolic executions by 6.1x on average in FuzzBench [22] and improves coverage progress in 79% of the benchmarks.

Despite nearly decade-long mitigation efforts in academia and industry, the community is yet to find a practical solution to the Rowhammer vulnerability.Comprehensive software mitigations require complex changes to commodity systems, yielding significant run-time overhead and deterring practical adoption.Hardware mitigations, on the other hand, have generally grown more robust and efficient, but are difficult to deploy on commodity systems.Until recently, ECC memory implemented by the memory controller on server platforms seemed to provide the best of both worlds: use hardware features already on commodity systems to efficiently turn Rowhammer into a denial-of-service attack vector.Unfortunately, researchers have recently shown that attackers can perform one-bit-at-a-time memory templating and mount ECC-aware Rowhammer attacks.In this paper, we reconsider ECC memory as an avenue for Rowhammer mitigations and show that not all hope is lost.In particular, we show that it is feasible to devise a softwarebased design to both efficiently and effectively harden commodity ECC memory against ECC-aware Rowhammer attacks.To support this claim, we present Copy-on-Flip (CoF), an ECCbased software mitigation which uses a combination of memory migration and offlining to stop Rowhammer attacks on commodity server systems in a practical way.The key idea is to let the operating system interpose on all the error correction events and offline the vulnerable victim page as soon as the attacker has successfully templated a sufficient number of bit flipswhile transparently migrating the victim data to a new page.We present a CoF prototype on Linux, where we also show it is feasible to operate simple memory management changes to support migration for the relevant user and kernel memory pages.Our evaluation shows CoF incurs low performance and memory overhead, while significantly reducing the Rowhammer attack surface.On typical benchmarks such as SPEC CPU2017 and Google Chrome, CoF reports a <1.5% overhead, and, on extreme I/O-intensive scenarios (saturated nginx), up to ∼11%.1 We use the term memory (or page) offlining as used in the Linux kernel source and by hardware vendors to refer to those pages which are poisoned and rendered unavailable to the system [19], [26].