Citadel: Rethinking Memory Allocation to Safeguard Against Inter-Domain Rowhammer Exploits

---

Review Form

Reviewer: The Guardian (Adversarial Skeptic)

Summary

The authors propose Citadel, a memory allocator designed to mitigate inter-domain Rowhammer exploits by physically isolating security domains. The core idea is a two-level allocation scheme that uses coarse-grained "chunks" for large domains to amortize guard row overhead, and fine-grained, high-overhead "zonelets" (akin to ZebRAM) for small domains. The paper claims this design supports thousands of domains with a modest 7.2% average memory overhead and no performance loss.

While the conceptual approach of balancing allocation granularities is sound, the paper's central claims are built on a fragile foundation. The evaluation is conducted almost exclusively under a simplified, best-case DRAM addressing model that does not reflect the complexity of many modern systems. The authors' own analysis in Section 8.5 reveals that under more realistic conditions, the overhead would likely approach 25%, a figure that undermines the paper's primary contribution. Furthermore, the claim of "no performance loss" is unsubstantiated, and the decision to completely disable inter-process memory sharing severely curtails the system's practical applicability.

Strengths

1. The fundamental concept of a two-level allocation strategy to balance the trade-offs between capacity loss (from guard rows) and memory stranding (from coarse-grained reservations) is a logical and interesting direction for research in this area. It correctly identifies the primary weaknesses of prior art like ZebRAM and Siloz.

2. The paper's design is more flexible than its predecessors, offering a mechanism to support domains of highly variable sizes, from single kernel pages to large multi-gigabyte applications.

Weaknesses

My analysis reveals several critical weaknesses that question the validity and practicality of the presented results.

1. The Evaluation Rests on an Unrealistic Model: The entire quantitative evaluation (Figures 9-12) is performed using a simple DRAM mapping model. The paper relegates the far more common and complex mappings (involving scrambling, mirroring, etc.) to a brief, analytical discussion in Section 8.5. In that section, the authors concede that zone expansion becomes less effective, and capacity loss is "more likely to dominate and approach memory overheads of 25%." This is a fatal flaw. The headline claim of 7.2% overhead is not representative of many real-world systems, and the paper provides no empirical data to validate its performance under these more challenging, realistic conditions. The work has been evaluated in its best-case scenario, not its typical one.

2. Unsupported and Misleading Performance Claims: The Abstract claims "no performance loss," yet Figure 10 (page 10) shows performance variations from -13% to +15%. More troublingly, the authors report a 4.1% average speedup but state they "could not pinpoint the gain's root cause." Unexplained performance improvements are as suspect as unexplained slowdowns and often point to uncontrolled variables or artifacts in the experimental setup. A rigorous paper cannot make a strong performance claim on the back of an unexplained result. The claim should be, at best, "negligible average performance impact," but even that is questionable without understanding the source of the variance.

3. Disabling Core OS Functionality: The authors disable inter-process memory sharing to "simplify our implementation" (Section 6.3, page 9). They justify this by showing their chosen workloads make little use of it (Section 8.6, page 12). This is a textbook case of shaping the experiment to hide a system's deficiency. Memory sharing via copy-on-write (CoW) after fork() is a cornerstone of Unix-like operating systems, and features like Kernel Samepage Merging (KSM) are critical in virtualization environments. A memory allocator that cannot support this without massive memory duplication is not a practical solution for general-purpose servers.

4. Security Guarantees Are Brittle: The security model is predicated on the assumption that NG guard rows are sufficient to stop any attack (Section 4.7, page 5). While the authors acknowledge attacks like Half-Double, the landscape of Rowhammer is constantly evolving. Claiming the design offers "complete protection coverage against future unknown RH attacks" (Section 1, page 1) is a dangerously strong and unsubstantiated claim for a software-only defense that relies on a fixed, small number of guard rows.

5. Re-introduction of "Impractical" Overheads: The authors rightly criticize ZebRAM's 50-67% capacity loss as "impractical." However, their "zonelet" primitive for small domains uses the exact same striping mechanism and incurs the same high overhead (Section 4.6, page 5). While the two-level design mitigates this at a system level, it does not solve the underlying problem. For workloads dominated by a vast number of small domains (a plausible scenario in microservice architectures or with per-page-table isolation), the average overhead would trend towards ZebRAM's impractical levels, a scenario not adequately stressed in the evaluation.

Questions to Address In Rebuttal

1. The discrepancy between the empirically-measured 7.2% overhead under a simplified model and the analytically-derived ~25% overhead under a complex model is the most significant issue. Can you provide empirical results from a full evaluation on a system with complex DRAM address mappings to show the true overhead of Citadel?

2. Please provide a clear, evidence-based explanation for the 4.1% average speedup. If the cause remains unknown, on what basis can you claim your system has "no performance loss" rather than "unpredictable performance impact"?

3. The decision to disable memory sharing is a major limitation. Please provide a quantitative analysis of the memory overhead Citadel would incur on a workload that heavily utilizes fork() and CoW (e.g., a pre-forking web server like Apache under load) or KSM. How can Citadel be considered a general-purpose solution without supporting this fundamental OS feature efficiently?

4. Given that your system's headline 7.2% overhead is only achievable under an idealized mapping, and that you disable a key OS feature, how do you justify the claim that Citadel is "readily deployable across legacy, contemporary, and future platforms"?

5. What is the quantified duration of the system's window of vulnerability during the bootstrapping process described in Section 6.4 (page 9)?

---

Review Form

Reviewer: The Synthesizer (Contextual Analyst)

Summary

The paper presents Citadel, a novel memory allocator for the Linux kernel designed to provide robust protection against inter-domain Rowhammer (RH) exploits. The work correctly identifies the fundamental challenge in software-based RH isolation: a difficult trade-off between the high memory capacity loss of fine-grained, row-by-row isolation schemes (e.g., ZebRAM) and the excessive memory stranding and limited domain scalability of coarse-grained, subarray-level schemes (e.g., Siloz).

Citadel's core contribution is a practical and elegant synthesis of these two approaches. It introduces a two-level allocation strategy that reflects the typical memory usage patterns in modern systems. For the numerous, small-footprint domains (like background processes or individual page table pages), it uses fine-grained "zonelets." For the few, large-footprint application domains, it uses coarser "reservation chunks." This hybrid approach allows Citadel to amortize the cost of guard rows effectively, supporting thousands of security domains of arbitrary size. The authors implement their design in the Linux kernel and demonstrate through a comprehensive evaluation that it incurs a modest 7.2% average memory overhead and no performance degradation, while successfully supporting complex workload mixes that prior solutions cannot handle.

Strengths

1. Elegant and Principled Core Idea: The central contribution of this work is its recognition that a one-size-fits-all approach to RH isolation is inefficient. The dual-granularity design based on "zonelets" and "chunks" is a clear and powerful idea that directly addresses the primary weaknesses of its predecessors. The paper's problem formulation, especially as illustrated in Figure 1 (Page 2), is exceptionally clear and provides a strong motivation for the proposed solution.

2. Excellent Contextualization and Positioning: The authors have done a superb job of placing their work within the broader landscape of RH mitigations. They clearly articulate the limitations of both hardware defenses and existing software isolation schemes, positioning Citadel as the logical and necessary next step in this line of research. The work serves as a perfect synthesis of the ideas presented in ZebRAM [41] and Siloz [45], combining their respective strengths to create a more general and practical system.

3. Thorough and Realistic Evaluation: The experimental methodology is a significant strength. The creation of 11 diverse workload mixes (Table 3, Page 10) that include not only main applications but also background processes and emulated per-page-table domains demonstrates a deep understanding of real-world system behavior. Evaluating at the scale of a 128GB server with up to ~57K domains shows that the solution is designed for contemporary challenges, such as high core counts and the need for fine-grained process isolation. The main results in Figure 9 (Page 10) are compelling and clearly show the benefits of Citadel.

4. Pragmatic and Well-Considered Design: The implementation as a Linux memory allocator shows a commitment to practical application. The design thoughtfully considers complex, real-world issues that are often overlooked in purely academic proposals. This includes the bootstrapping process (Section 6.4, Page 9), integration with kernel subsystems, and most importantly, the implications of complex internal DRAM addressing schemes like row scrambling and mirroring (Section 6.1, Page 7). This foresight significantly strengthens the paper's credibility.

Weaknesses

1. The "Oracle" Problem of DRAM Address Mappings: The most significant dependency of this work, shared by all similar software-only spatial isolation schemes, is the requirement of knowing the physical-to-DRAM address mapping. The authors acknowledge this in Section 6.1.4 (Page 8), but the practicality of this step for widespread deployment remains a major hurdle. While reverse-engineering is possible, it is a non-trivial, system-specific process. This dependency moves Citadel from a "drop-in software patch" to a solution requiring significant, expert-level per-system calibration, which could limit its adoption.

2. Overhead Under Complex Mappings: The paper's headline result of ~7% memory overhead is based on a simple DRAM mapping. The authors' own analysis in Section 8.5 (Page 12) projects that for more complex (and common) mappings, the overhead could approach 25% due to reduced opportunities for zone expansion. This is a crucial point that significantly tempers the paper's main claims. While the honesty is commendable, the core evaluation does not use what might be the more common case, potentially presenting a best-case scenario as the primary result.

3. Handling of Shared Memory: The prototype simplifies its implementation by disabling inter-process memory sharing (Section 6.3, Page 9). The authors justify this by noting the low sharing factor in their chosen workloads. However, in other important scenarios, such as virtualization or environments with high degrees of library sharing or copy-on-write forks, this could be a significant limitation, leading to either security vulnerabilities or increased memory pressure. The proposed solution of placing shared pages in zonelets is plausible but unevaluated.

Questions to Address In Rebuttal

1. Regarding the dependency on DRAM address mapping: Could the authors elaborate on the practical path to deployment for Citadel? Would this involve creating a community-maintained database of DIMM mappings, or do they envision an automated profiling tool that a system administrator could run? How robust is the system to partially incorrect mapping information?

2. The analytical projection of ~25% overhead for complex DRAM mappings is a significant departure from the 7.2% demonstrated. Can you provide more intuition on why the overhead increases so dramatically? Is this a hard ceiling, or could further allocator optimizations (e.g., more sophisticated placement algorithms) mitigate this? It would strengthen the paper immensely if you could provide even a single data point from an experiment on a real system known to have complex mappings to validate this analytical model.

3. Could you elaborate on the design for safely handling shared memory? You propose placing shared pages in zonelets, which seems to imply that processes sharing a page must be co-located in the same data row. How would this impact the allocator's flexibility and potentially fragment the address space for shared pages? Are there fundamental challenges beyond mere implementation complexity?

---

Review Form

Reviewer: The Innovator (Novelty Specialist)

Summary

This paper presents Citadel, a memory allocator designed to provide software-based isolation against inter-domain Rowhammer (RH) exploits. The authors identify a key trade-off in prior art: fine-grained, row-level isolation schemes (e.g., ZebRAM) incur prohibitive capacity loss due to guard rows, while coarse-grained, subarray-level schemes (e.g., Siloz) suffer from a limited number of domains and excessive memory stranding.

The authors claim novelty in their two-level allocator design that aims to resolve this trade-off. The core mechanism is a new software primitive called a "reservation chunk," a configurable group of contiguous global rows. For small memory footprints (e.g., page tables, daemons), Citadel employs "zonelets," which are regions of memory striped with guard rows, functionally similar to ZebRAM. For larger footprints, it allocates memory in "zones" composed of one or more reservation chunks, amortizing the guard row cost by only placing them at the boundaries of a zone. This hybrid approach claims to support thousands of variably sized domains with modest memory overhead.

Strengths

The primary strength of this work lies not in the invention of a single new mechanism from first principles, but in the novel synthesis of existing concepts into a new, and demonstrably more practical, point in the design space for RH mitigation.

1. A Novel Intermediate Granularity: The "reservation chunk" primitive (Section 4.3, page 4) is a well-defined software abstraction that sits neatly between the hardware-dictated granularities of a single row (ZebRAM) and an entire subarray (Siloz). While creating software-defined memory chunks is not new in general memory allocation, its specific application here—as a tunable unit to balance guard-row loss against stranding for RH protection—is a novel contribution.

2. A Novel Hybrid Allocation Strategy: The two-level design (zones and zonelets, described in Sections 4.3-4.6, pages 4-5) is the paper's most significant novel idea. Prior solutions have been monolithic, applying a single strategy (either fine-grained or coarse-grained) to the entire memory space. Citadel is the first system I am aware of to propose a dynamic, hybrid approach that applies a high-cost, high-granularity strategy only where necessary (for small domains) and a low-cost, lower-granularity strategy for the bulk of memory. This targeted application of different techniques is a genuinely new approach in this specific problem domain.

3. Significant Delta Over Prior Art: The quantitative "delta" between Citadel and the closest prior works is substantial. By moving from the monolithic approaches of ZebRAM and Siloz to a hybrid model, the authors convert what were largely academic curiosities (due to extreme overheads or limitations) into a potentially deployable system. The results in Figure 9 (page 10), which show Citadel succeeding on workloads where both prior systems fail, underscore that the novelty is not merely incremental but enabling.

Weaknesses

The novelty of the work is based on combination and refinement, not fundamental invention. Therefore, the paper's claims must be carefully scoped.

1. Constituent Components are Not New: The core mechanisms used by Citadel are, in isolation, well-established. The use of guard rows for spatial isolation is the central idea of ZebRAM [41] and GuardION [68]. The concept of isolating domains in larger, physically distinct regions is the core of Siloz [45]. The "zonelet" primitive is, functionally, a reimplementation of ZebRAM's striping within a bounded region. The novelty is exclusively in the combination and the management logic, a point that could be stated more explicitly.

2. Novelty is Predicated on Complex Engineering: The entire premise of Citadel, like Siloz, relies on the ability to know or reverse-engineer the physical DRAM address mapping (Section 6.1, page 7). This makes the solution an engineering construct built atop another complex, and potentially fragile, engineering construct. While practical, it detracts from the conceptual purity of the novel allocator design, tying its fate to the continued feasibility of address mapping discovery. The paper's own analysis of complex DRAM mappings in Section 8.5 (page 12) reveals that the overhead can jump to 25%, significantly eroding the benefit that makes the design so compelling. This suggests the novelty may be less robust than presented.

Questions to Address In Rebuttal

1. The core components of your system—guard rows and coarse-grained isolation—are directly inherited from ZebRAM and Siloz, respectively. The novelty appears to be in the synthesis and the management layer that decides which strategy to apply. Could the authors clarify if there is any other element of Citadel they consider fundamentally new, beyond this novel synthesis?

2. The "reservation chunk" is proposed as a key primitive. The effectiveness of this primitive relies on the ability to form contiguous "zones" to amortize guard row overhead. Your own analysis in Section 8.5 (page 12) shows that prevalent, complex DRAM addressing schemes can increase overhead to 25% due to reduced opportunities for zone expansion. Does this not significantly weaken the novelty of your contribution by constraining its effectiveness to simpler, and perhaps less common, memory systems? How does the core idea remain novel if its primary benefit is so sensitive to underlying hardware complexities that are outside the allocator's control?