Adaptive CHERI Compartmentalization for Heterogeneous Accelerators

Here is the review based on the persona of 'The Guardian'.

---

Review Form

Reviewer: The Guardian (Adversarial Skeptic)

Summary

The authors propose "CapChecker," a hardware module intended to extend the CHERI capability security model to encompass CHERI-unaware hardware accelerators. The stated goal is to provide fine-grained, pointer-level memory protection for accelerator memory accesses without requiring architectural modifications to the accelerators themselves. The proposed system interposes on the accelerator's memory interface, checking DMA requests against a table of CHERI capabilities provided by the CPU. The authors evaluate this approach using a set of HLS-generated benchmarks on an FPGA platform, claiming an average performance overhead of 1.4% while providing significantly stronger security guarantees than traditional IOMMUs.

Strengths

1. The paper identifies a critical and timely problem: the security gap created by integrating non-CHERI-aware accelerators into a CHERI-protected system.
2. The comparison in Section 6.4 (Figure 12, page 12) effectively illustrates the scalability advantage of a pointer-based checking mechanism over a page-based IOMMU in terms of the number of required translation/protection entries.

Weaknesses

The paper's claims rest on a foundation of questionable assumptions and an evaluation that lacks critical details, casting significant doubt on the practicality and security of the proposed solution.

1. Unsupported "No Modification" Claim and Unrealistic Hardware Assumptions: The central premise of operating "without modifying accelerator architectures" (Abstract, page 1) is not upheld.

   • The "Coarse" implementation (Figure 5, page 6) requires reserving the upper bits of the memory address to encode a pointer ID. This constitutes a modification of the accelerator's memory interface contract and reduces its addressable memory space. This is not "without modification."
   • The "Fine" implementation, which provides the paper's strongest security claims (object-level protection), relies on an even more dubious assumption: that an accelerator's memory requests inherently carry a "pointer ID" that can be extracted to index the capability table. The paper suggests this could come from using separate hardware interfaces for each buffer (Section 5.2.2, page 7), which is a highly restrictive and unrealistic model for most real-world accelerators that use one or a few programmable DMA engines. The authors provide no evidence that the Vitis HLS toolflow used in their evaluation generates accelerators that meet this structural requirement.

2. Severely Limited Scope and Overstated Generality: The work is hamstrung by Assumption 2 (Section 4.1, page 4), which excludes any accelerator that performs dynamic memory management. This immediately rules out the most significant and complex classes of accelerators, such as GPUs and modern TPUs. Claiming this is a "general method" (Abstract, page 1) is therefore a significant overstatement. The problem is simplified to the point that its solution may not be relevant to the systems where such protection is most needed.

3. Incomplete and Ambiguous Evaluation: The experimental evaluation fails to substantiate the paper's security claims.

   • Crucial Missing Data: The authors evaluate two distinct modes, Fine and Coarse, which offer vastly different security guarantees (object-level vs. task-level). However, the paper never states which mode was used for which benchmark in the performance evaluation (Section 6.3, pages 11-12). Given the likely architecture of HLS-generated accelerators, it is plausible that all benchmarks were evaluated using the far weaker Coarse mode. If this is the case, then all claims related to achieving fine-grained, object-level protection are entirely unsupported by the experimental results.
   • Confusing Presentation: Figure 10 (page 11) is poorly explained. The terms ACPU and AACCEL are not defined in the caption or text, forcing the reviewer to guess their meaning. This is unacceptable for a quantitative results section.
   • Temporal Safety is Ignored: The paper dismisses temporal memory safety issues (e.g., use-after-free) by stating it relies on a trusted software driver (Section 6.2, page 9). This is a major weakness. A comprehensive hardware security solution should not simply delegate an entire class of critical memory vulnerabilities to the assumption of perfect software.

4. Glossed-over Implementation Details: The design of the CapChecker itself raises unanswered questions. The paper mentions that the capability table may become full, requiring eviction and introducing a "potential for deadlock" (Section 5.2.3, page 7). This critical issue is mentioned and then immediately dismissed. What is the eviction policy? How is deadlock provably avoided? Without these details, the robustness of the hardware design is unknown.

Questions to Address In Rebuttal

1. For the evaluation presented in Section 6, please state explicitly for each benchmark whether the Fine or Coarse implementation of CapChecker was used. If Fine mode was used for any benchmark, provide evidence from the generated hardware that the accelerator possesses the distinct hardware interfaces necessary to unambiguously supply a "pointer ID" for each memory buffer.
2. How do you reconcile the claim of "without modifying accelerator architectures" with the Coarse mode's requirement to partition the address space, a clear modification of the accelerator's interface to the system?
3. The threat model (Section 4.1, page 4) states the "driver cannot use accelerators to do anything it could not already do." Is this claim enforced by a hardware mechanism, or does it rely solely on the assumption of a bug-free, trusted software driver? If the latter, how does this provide a meaningful security improvement over a non-CHERI system that also relies on a trusted driver?
4. Please provide a detailed description of the capability table eviction policy and a rigorous argument for how your design avoids deadlock when the table is full and multiple accelerator tasks are stalled pending allocation.
5. Given that your solution explicitly excludes accelerators with dynamic memory management and defers all temporal safety to software, can you defend the assertion that this is a "general" and "efficient" solution for compartmentalization in modern heterogeneous systems?

Here is the review of the paper, written from the perspective of 'The Synthesizer'.

---

Review Form

Reviewer: The Synthesizer (Contextual Analyst)

Summary

This paper presents a novel and practical method for extending fine-grained, capability-based memory protection to hardware accelerators in heterogeneous systems. The core contribution is "CapChecker," a hardware module that acts as an adaptive interface between a CHERI-enabled CPU and CHERI-unaware accelerators. Without requiring any modification to the accelerator's internal architecture, CapChecker intercepts memory requests, validates them against CPU-provided capabilities at the pointer level, and thus enforces the CHERI security model on devices that are natively oblivious to it. This work proposes a general and scalable solution to unify memory safety across the entire SoC, addressing a significant and growing security gap in modern computing systems. The authors demonstrate their approach with a prototype system, showing an average performance overhead of only 1.4% across a diverse set of accelerator benchmarks.

Strengths

This paper's primary strength lies in its elegant synthesis of existing concepts to solve a pressing, real-world problem. It cleverly bridges the gap between the mature, CPU-centric CHERI security model and the often-insecure world of "black-box" hardware accelerators.

1. Addresses a Critical Problem with a General Solution: The proliferation of accelerators in systems ranging from embedded SoCs to data centers has created a significant attack surface. Existing solutions like IOMMUs offer coarse, page-level protection, while bespoke secure accelerators are not generalizable. This paper tackles the problem head-on by proposing a single, unified protection mechanism that is agnostic to the specific accelerator architecture. The "wrap, don't rewrite" philosophy is immensely practical and lowers the barrier to adoption.

2. Excellent Contextual Framing: The work is well-positioned within the landscape of hardware security. The authors clearly articulate the limitations of current approaches—the granularity issues of IOMMUs and the heterogeneity problem of mismatched protection schemes (as shown in Figure 1 on page 2). Their proposal directly addresses this architectural mismatch, which is a key insight.

3. Strong Architectural Concept: The CapChecker is a compelling architectural pattern. By acting as a security-aware interposer, it allows the trusted CPU to serve as the authority for memory permissions, effectively delegating and enforcing those permissions on behalf of untrusted or unaware accelerators. This is a powerful model for integrating legacy or third-party IP into a secure system.

4. Promising and Well-Executed Evaluation: The evaluation provides strong evidence for the viability of the approach. Using the standard MachSuite benchmark set on an FPGA platform demonstrates applicability to a diverse range of accelerator behaviors. The key result—a 1.4% average performance overhead—is excellent and suggests that this level of fine-grained security is affordable. The scalability analysis comparing the number of required CapChecker entries to IOMMU entries (Figure 12, page 12) is particularly insightful, highlighting the efficiency benefits of pointer-level granularity over page-level granularity for typical accelerator workloads.

Weaknesses

The paper's weaknesses are primarily related to simplifying assumptions that bound the scope of the work. While acceptable for a foundational paper, they are important to acknowledge for the broader context.

1. Exclusion of Complex Accelerators: The most significant limitation is Assumption 2 in the threat model (Section 4.1, page 4), which states that accelerators do not perform dynamic memory management. This is a reasonable starting point, as it covers many common accelerators. However, it explicitly excludes some of the most powerful and security-critical accelerators, such as GPUs, TPUs, and modern programmable NPUs, which have their own complex memory management schemes. The proposed model, where the CPU allocates all memory, would not directly apply.

2. Fragility of the "Coarse" Provenance Mechanism: The Coarse implementation, which encodes an object ID in the upper bits of the memory address (Section 5.2.2, page 7), is a pragmatic but potentially fragile solution for retrofitting provenance. As the authors themselves note, it does not protect against intra-task attacks where a buffer overflow could be used to craft a valid-looking address that points to a different object within the same task's allowed memory regions. This weakens the object-level protection guarantees in the worst-case scenario.

3. Centralization of the Trusted Computing Base (TCB): The security of the entire system hinges on the correctness of the CapChecker hardware and its associated trusted software driver. While this is a standard system design trade-off, it concentrates risk. A vulnerability in the driver could be used to misconfigure the CapChecker, bypassing the protection for all accelerators.

Questions to Address In Rebuttal

The authors have presented a compelling vision for securing heterogeneous systems. I would appreciate their thoughts on the following points to better understand the future trajectory and robustness of this work.

1. Beyond the Current Threat Model: While the current work focuses on accelerators without dynamic memory management, this is a major frontier. Could the authors speculate on how the CapChecker concept might be evolved to support more complex accelerators like GPUs? Would this require a "co-design" where the GPU's memory manager interacts with the CapChecker via a standardized protocol, or could a purely hardware-based approach still be viable?

2. Robustness of Provenance: Regarding the Coarse mode, could you elaborate on the practicality of attacks that forge pointer IDs via overflows? How might this interact with software mitigations (e.g., placing guard regions between buffers) or potential hardware assists (e.g., a mode where the CapChecker enforces that accesses to different Pointer IDs are non-contiguous)?

3. Temporal Memory Safety: The current work focuses primarily on spatial memory safety. The trusted driver is responsible for managing allocation/deallocation, but this leaves open the possibility of use-after-free bugs if an accelerator continues to use a pointer after the driver has freed its memory. Could the CapChecker hardware be extended to aid in temporal safety, for instance, by supporting rapid revocation of capabilities in its table when memory is freed by the OS?

4. Performance at Scale: The evaluation shows excellent scalability with parallel tasks, but appears to use a single, shared CapChecker. In a future system with dozens of high-bandwidth accelerators, could this centralized checker become a performance or contention bottleneck? Have you considered a distributed or hierarchical CapChecker architecture to address this?

Of course. Here is a peer review of the paper from the perspective of "The Innovator."

---

Review Form

Reviewer: The Innovator (Novelty Specialist)

Summary

The paper proposes an architectural component, the "CapChecker," designed to extend the fine-grained memory protection of CHERI CPUs to unmodified, "black-box" hardware accelerators. The core idea is to interpose a hardware module between the accelerator and the memory system. This module maintains a repository of CHERI capabilities provided by the CPU and validates every DMA request from the accelerator against these capabilities at runtime. The authors claim this provides pointer-level memory safety for heterogeneous systems without requiring any modification to the accelerator's internal architecture, achieving this with a reported average performance overhead of 1.4%.

Strengths

The primary strength of this work lies in its novel realization of a previously conceptual idea. My analysis identifies the following novel contributions:

1. From Position Paper to Concrete Architecture: The most significant contribution is the translation of a high-level concept into a concrete, implemented, and evaluated system. Prior work, notably the position paper by Markettos et al. [47] (which the authors correctly cite), proposed the general idea of using CHERI capabilities to protect against malicious DMA. However, that work lacked a microarchitectural design, a hardware implementation, and quantitative analysis. This paper provides all three, presenting the specific design of the CapChecker with its capability table, the MMIO-based control path, and the logic for checking requests. This transition from idea to working prototype is a clear and significant novel contribution.

2. A "Black-Box" Philosophy for Capability Systems: The architectural approach is novel in its explicit goal of securing unmodified accelerators. This contrasts with other recent work in accelerator security, such as sNPU [20], which integrates capability-like mechanisms directly into the accelerator's design (a "white-box" approach). The CapChecker proposes a fundamentally different, non-invasive integration pattern. This is a novel point in the design space of secure heterogeneous systems, offering a path to retrofit security onto legacy or third-party IP cores.

3. Demonstration of Practicality: The novelty is not just in the architecture itself, but in the demonstration that such an architecture is efficient. Achieving fine-grained, object-level protection for peripheral DMA with a performance overhead under 2% is a compelling result that establishes the viability of this new approach.

Weaknesses

My evaluation of novelty is not without reservations. The core idea, while implemented in a novel way, is built upon established concepts, and its claimed generality has notable limitations.

1. The Interposer Pattern is Not Novel: The fundamental concept of a hardware security monitor or interposer that sits between a peripheral and memory is not new. IOMMUs are the canonical example of this pattern, and other research has proposed various forms of DMA filtering or monitoring hardware. The novelty here is strictly limited to the type of policy being enforced (CHERI capabilities) rather than the architectural pattern of interposition itself.

2. The Coarse Mode Mechanism Lacks Novelty: The paper presents two implementations, Fine and Coarse (Figure 5, Page 6). The Coarse mode, proposed as a fallback when transaction provenance is unavailable, relies on reserving upper address bits to encode a pointer ID. This technique—using parts of the address bus for metadata or tagging—is a well-established practice in computer architecture and is not a novel contribution. Its inclusion weakens the overall novelty claim, as it suggests the "general" solution reverts to a common trick in its most challenging case.

3. Scoped Novelty via Restrictive Assumptions: The paper's core novelty is scoped to a specific and simplified class of accelerators due to Assumption 2 (Section 4.1, Page 4), which excludes accelerators performing their own dynamic memory management. This is a critical limitation. The proposed CapChecker architecture, with its CPU-managed static capability table, is not suited for more complex accelerators like GPUs or TPUs that manage their own memory. Therefore, the novel contribution does not address the security of the most complex and widely used accelerators but is instead confined to a simpler domain. The claim of a "general method" is thus overstated.

Questions to Address In Rebuttal

The authors should use the rebuttal to clarify the precise boundaries of their novel contributions.

1. Regarding the Coarse implementation: Can the authors cite prior work that uses address-bit tagging for peripheral memory protection and clearly articulate what, if anything, is novel about their specific use of this technique in the context of the CapChecker?

2. The paper's central claim is a method that works "without modifying accelerator architectures." How would the CapChecker design need to change to support an accelerator that internally performs dynamic memory allocation (e.g., contains a malloc engine for its own scratchpad or local memory)? Would this require a fundamentally new architecture, thereby invalidating the claimed generality, or are there incremental novel extensions to your design that could support this?

3. The software driver model described in Section 5.3 (Page 8) appears to be a standard implementation for managing a new hardware device. Is there any conceptual novelty in the driver's capability management lifecycle (e.g., how capabilities are delegated, managed, and revoked for an external hardware unit) that distinguishes it from prior work on capability-based OSes managing system resources?