Pith. sign in

REVIEW 3 major objections 4 minor 49 references

Securing Mixed Rust with Hardware Capabilities

T0 review · 3 major / 4 minor · reviewed 2026-08-06 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read CapsLock claims to be the first mechanism that enforces Rust's ownership, borrowing, and aliasing rules in mixed code at machine-code level, using a revoke-on-use capability design.

desk verdict Genuinely new revoke-on-use mechanism with a solid, reproducible evaluation; the 'cross-language enforcement' claim is a bit too strong for the prototype, and the §5.1 pointer-provenance heuristic is the main soft spot. read the letter →

arxiv 2507.03344 v1 pith:Y4V644WX submitted 2025-07-04 cs.CR cs.SE

Jason Zhijingcheng Yu , Fangqi Han , Kaustab Choudhury , Trevor E. Carlson , Prateek Saxena This is my paper · ORCID
classification cs.CRcs.SE
keywords Rustmemorysafetyhardwarecapabilitiesrevoke-on-usealiasingmodelsforeignfunctioninterfacecross-languageenforcementtemporaldynamicbugdetection
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

This paper argues that Rust's safety guarantees can be enforced even in the parts of a program the Rust compiler cannot see: unsafe blocks, foreign function calls, and inline assembly. The proposed system, CapsLock, does this at machine-code level by replacing raw pointers with hardware capabilities that carry bounds, permissions, and a record of which capability borrowed from which. Whenever a capability is used to read or write memory, CapsLock automatically invalidates other capabilities whose later use would conflict, an operation the paper calls revoke-on-use. The result is a run-time checker that a QEMU-based prototype applies to existing Rust code without recompiling external libraries, passing 99.7% of the test suites of the 100 most popular crates and surfacing 8 previously unknown principle violations in FFI-using crates. If this holds, Rust's guarantees extend across the boundary where they currently lapse.

What carries the argument

The central object is the revoke-on-use capability: a hardware capability carrying an address range, a permission (read-write, read-only, or no-access), and a parent identifier that links it into a borrow tree. When software uses such a capability for a load or store, the hardware implicitly revokes every conflicting capability in the tree, as formalized by the RevokeW and RevokeR rules. This distills the aliasing models Stacked Borrows and Tree Borrows into two invariants, well-nested borrowing and exclusive access, while removing the separate revocation-capability type and the linear/non-linear distinction of the baseline Capstone design. Borrow instructions are injected into Rust code by a modified rustc MIR pass, while foreign code needs no instrumentation; pointer provenance in uninstrumented code is resolved lazily at the first load or store by retaining the capability whose bounds match the accessed address.

What would settle it

Take a C function that receives two pointers to the same buffer with identical bounds and live capabilities, computes a third pointer from them by arithmetic such as subtraction or xor, and writes through that computed pointer; run it linked into a Rust program under CapsLock. If the write is a genuine AXM violation that goes unreported, or a benign write that is reported, the provenance heuristic of Section 5.1 is refuted.

Watch

Extended reading notes

Core claim

The paper's central claim is that the three Rust principles — ownership, borrowing, and Aliasing Xor Mutability (AXM) — can be captured by a single machine-level abstraction, revoke-on-use, and that this abstraction is implementable on recent capability-based hardware. CapsLock maintains a borrow tree for every memory object: a root capability is created at allocation, each new reference or raw pointer borrows a capability from an existing one, and each load or store implicitly revokes all conflicting capabilities in the tree. The security invariants are well-nested borrowing (a capability cannot outlive its parent) and exclusive access (no store from outside a capability's subtree before its last use, and no load from outside the subtree before a capability's last store). Because the checks live in the hardware, code that was not compiled by rustc, including C libraries and inline assembly, participates in the same enforcement. The paper presents proof sketches for the two invariants and evaluates a QEMU prototype on the 100 most popular crates, on 15 RustSec proof-of-concept exploits, and on crates whose FFI use makes Miri abort.

Load-bearing premise

Everything depends on a pointer-provenance heuristic: when a value computed in foreign code is used for its first memory access, CapsLock assumes that keeping only the capability whose bounds match the address is enough to know which pointer it really is and which other capabilities should be revoked.

Editorial extensions

If this is right

  • CapsLock can flag runs where Rust principles are violated even when the violation never produces a crash or memory error, because it checks the assumption violation itself rather than its after-effects.
  • Existing Rust code can be checked largely as-is: 99.7% of the top-100 crates' test cases pass, with only 12 failures on CapsLock while passing on Miri, all traced to UnsafeCell corner cases.
  • In mixed projects that Miri cannot run, CapsLock found eight previously unknown violations, seven of them AXM violations, using only the crates' ordinary built-in tests.
  • Memory-safety and data-race sanitizers are not a substitute for Rust-principle checking: AddressSanitizer and ThreadSanitizer together miss 6 of the 15 RustSec principle-violation PoCs that CapsLock catches.
  • A hardware implementation would likely enforce these invariants on all memory, including memory allocated by foreign allocators, since the prototype's heap protection is limited only by interposing on Rust's allocator.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The lazy provenance-resolution heuristic in Section 5.1 is where the cross-language claim rests: if a pointer is recomputed through arithmetic that combines two live capabilities with identical bounds, or through a foreign routine, CapsLock may attach the wrong capability and either miss a violation or raise a false positive; the paper reports high compatibility but does not quantify how often suc
  • Because CapsLock's model is deliberately more relaxed than both Stacked Borrows and Tree Borrows (no protectors for function arguments, lazy invalidation), there exist violations that Miri flags but CapsLock will not; the paper acknowledges this, so the system is a detector of a useful subset rather than a complete oracle.
  • The revoke-on-use abstraction could be lifted out of Rust entirely: it is a general aliasing discipline for capability hardware, so the same mechanism could enforce similar exclusive-access contracts in other languages that adopt borrow-like rules, or enforce alias annotations if such annotations were introduced.
  • A testable extension would be to run CapsLock under a fuzzer: since it flags violations at the violating instruction rather than at a later crash, it could make Rust-principle violations a directly optimizable coverage signal, provided the false-positive rate from provenance ambiguity stays low.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

3 major / 4 minor

Summary. The paper presents CapsLock, a capability-based mechanism that aims to enforce Rust's ownership, borrowing, and aliasing-xor-mutability principles at the machine-code level, so that violations in mixed Rust code (including unsafe Rust, FFI, and inline assembly) can be detected at run time. The design is built on the Capstone capability architecture and introduces a revoke-on-use operation that invalidates conflicting capabilities implicitly at each load/store. The authors formalize capabilities and instructions in Table 2 and Appendix A, give informal proof sketches for two invariants (well-nested borrowing and exclusive access), and implement a QEMU/RISC-V prototype with rustc instrumentation. The evaluation reports 99.7% compatibility on the built-in tests of the 100 most popular crates, detection of all 15 RustSec PoCs tested, 8 previously unknown bugs in crates using FFI or inline assembly, and an average runtime speedup of over 2x relative to Miri.

Significance. If the central claims hold, CapsLock is a significant contribution: it is a language-agnostic, hardware-oriented mechanism that goes beyond spatial memory safety to detect violations of Rust-specific aliasing principles across language boundaries, and it is evaluated with a public artifact against standard tools (Miri, AddressSanitizer, ThreadSanitizer) on a large corpus. The 8 reported bugs, several confirmed and fixed by maintainers, provide concrete evidence of practical utility. The design is notably simple and the paper is generally well written. However, the formal semantics as printed contain inconsistencies that the proofs rely on, and the implementation's pointer-provenance resolution is load-bearing for the cross-language claim but is neither formally justified nor adversarially evaluated.

major comments (3)
  1. [§4.2, Table 2 and Appendix A] The formal definitions contradict the prose and the proof sketches. The Store and Load rules define S = O_m(a) ∩ A_m(i), while the text immediately above says S contains overlapping capabilities that are not ancestors of i, and the Section 4.3 proof requires the set-difference reading (it concludes i1 is revoked from i1 ∉ A_m0(i2)). In addition, RevokeW(m,S) is described as invalidating the capabilities in S, but Eq. (5) keeps exactly S valid and invalidates the complement; RevokeR's prose says it demotes capabilities not in S to RO, but Eq. (7) maps RW capabilities outside S to NA. With the definitions as printed, the two invariants in Section 3.4 are not established, and the formal semantics do not correspond to the revoke-on-use behavior described in Section 3.2. Please correct these errors and re-verify the proofs.
  2. [§5.1] The pointer-provenance heuristic is load-bearing for the central claim that external code requires no instrumentation. The implementation resolves a value's provenance at its first load/store use by keeping "only the associated capability with memory bounds matching the requested load/store address." If two live capabilities have identical bounds and permissions, or if uninstrumented code computes a pointer from two capabilities (e.g., via pointer arithmetic), this resolution can select the wrong capability, causing either a missed violation or a false positive. This step is not modeled in the formal semantics of Table 2/Appendix A, which associate each memory location with a single capability identifier, and no formal argument, adversarial test, or coverage measurement is provided. The 99.7% compatibility rate in Section 6.1 is measured on the same 100-crate corpus used to motivate the §5.1 relaxations, so it does not validate the heuristic's generality for arbitrary foreign code.
  3. [§5.3] The paper explicitly states that the prototype "does not protect memory allocated in foreign code" because only the Rust-side heap allocator is interposed. This is a scoping gap for the cross-language claim: pointers to foreign-allocated objects carry no capability, so violations involving such objects are invisible to the QEMU prototype. Since the evaluation in Sections 6.2-6.3 and the bugs found are specifically about FFI, the implementation and evaluation should either interpose foreign allocators as well, or the abstract and evaluation claims should be restricted to Rust-allocated objects with the foreign-allocation limitation stated prominently.
minor comments (4)
  1. [§4.3] The proof of exclusive access contains a contradictory phrase: "i2 ∉ D_m0(i1) is the identifier of a capability in the subtree of i1." The intended statement appears to be that i2 is outside the subtree of i1, and the prose should be corrected.
  2. [Appendix A, Eq. (7)] The prose says RevokeR "demotes capabilities not in S to RO," but the definition maps read-write capabilities not in S to NA, which is a different operation. Please clarify which behavior is intended and align the text with the definition.
  3. [§6.1, Table 3 and Figure 6] The category labels are confusing: "O" is used both as a column/row label and as part of the legend, and the Venn diagram's numbers are not immediately reconcilable with Table 3. A more explicit legend would help.
  4. [§2.2, Listing 3] The "logically impossible double free" example is explained tersely; a short step-by-step trace of why the optimized program reaches an always-true branch would make the argument easier to verify.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation found: CapsLock's revoke-on-use mechanism is defined from independent invariants, evaluated against Miri, RustSec, and crates.io tests, and the Section 5.1 provenance heuristic is a soundness assumption rather than a fitted input.

full rationale

The claimed derivation is self-contained. Section 3 defines the revoke-on-use abstraction through two explicit invariants (well-nested borrowing and exclusive access), Section 4.2 gives operational semantics for Create, Borrow, Drop, Load, and Store, and Section 4.3 proves these invariants by induction on those rules. The evaluation targets are external: Miri (which implements Stacked Borrows and Tree Borrows), RustSec proof-of-concept exploits, and crates.io test suites. No parameter is fitted so that a later 'prediction' is forced by construction: the 99.7% compatibility figure is a measured outcome of running pre-existing test cases, not a quantity the derivation was designed to reproduce. Capstone [41] is a prior publication by the same group, but it is used only as a baseline whose distinguishing features (linear capabilities and revocation capabilities) are deliberately removed in CapsLock. The new mechanism's correctness is argued from the CapsLock rules themselves, not by appealing to Capstone's theorems. No uniqueness theorem is imported from the authors' prior work, and the 'first mechanism' claim is a novelty assertion rather than a derivation step. The only load-bearing assumption in the cross-language claim is the Section 5.1 pointer-provenance resolution heuristic: 'When the software later uses the result for load or store for the first time, our implementation resolves its provenance by keeping only the associated capability with memory bounds matching the requested load/store address.' If two live capabilities share identical bounds, the wrong one can be selected, causing missed detections or false positives in uninstrumented foreign code. That is a genuine soundness and completeness limitation of the prototype, and it should be weighed against the strongest claim, but it is not circularity: the mechanism's detection capability is not defined in terms of this heuristic, and the paper does not rename a fitted value as a predicted result. Under the review rules, this warrants a circularity score of 0, with the heuristic flagged as the principal correctness risk rather than a circular step.

Assumptions & free parameters 2 free parameters · 4 assumptions · 0 invented entities

No numeric free parameters are fitted; the load-bearing choices are semantic: the raw-pointer relaxation and UnsafeCell exception in Section 5.1 are ad hoc adjustments to eliminate false positives, and the two security invariants in Section 3.4 are an approximation of Rust principles that the paper itself says is more relaxed than Stacked Borrows and Tree Borrows (Section 3.5). The design assumes Miri's models are a valid ground truth and that safe-Rust static guarantees plus injected borrow instructions are sufficient to map Rust semantics onto capabilities. No new physical entities are introduced; revoke-on-use is a new mechanism, not a new particle or field.

free parameters (2)
  • Raw pointer alias relaxation
    Section 5.1 relaxes the exclusiveness invariant for raw pointers to allow interleaved aliasing raw pointers. This is an ad hoc design choice added to remove major false positives on the benchmark crates; no numeric value is fitted, but it acts as a free semantic parameter.
  • UnsafeCell interior-mutability exception
    Section 5.1 adds an exception permitting aliasing stores from within subtrees of UnsafeCell capabilities. This is another ad hoc relaxation to match Rust's interior mutability and suppress false positives; it is a free design parameter rather than a number fitted to data.
assumptions (4)
  • domain assumption The two revoke-on-use invariants (well-nested borrowing and exclusive access) adequately approximate the three Rust principles for the purpose of bug detection.
    Section 3.4 defines the invariants; Section 3.5 explicitly acknowledges that CapsLock is more relaxed than Stacked Borrows and Tree Borrows and is 'unable to detect all cases of Rust principle violations'. The adequacy of this approximation is the core assumption of the work.
  • domain assumption Miri's Stacked Borrows and Tree Borrows models are a valid ground truth for what constitutes a Rust principle violation.
    In Section 6.2, CapsLock is validated against Miri on RustSec PoCs, and in Section 6.3 the 8 new bugs are confirmed by reproducing simplified versions in Miri. The paper treats these aliasing models as the reference definition of Rust principle violations.
  • domain assumption Safe Rust code is correctly compiled and its static guarantees hold; only conversions between raw pointers and references need instrumentation.
    The MIR pass in Section 5.3 only injects borrow instructions at raw-pointer/reference conversion sites. The design assumes no other Rust-to-machine-code semantic mapping is required for the mechanism to track the borrow relationships.
  • domain assumption The shadow-memory capability metadata in QEMU user-mode emulation faithfully realizes the operational semantics of Section 4.
    Section 5.2 stores capability metadata in shadow memory, recycles metadata by reference counting, and scans registers to free dead metadata. These implementation choices are assumed not to change the semantics of Create, Borrow, Drop, Load, and Store.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Securing Mixed Rust with Hardware Capabilities." pith.science (2026). https://pith.science/paper/Y4V644WX

@misc{pith2026250703344,
  author       = {Pith},
  title        = {Pith review of: Securing Mixed Rust with Hardware Capabilities},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/Y4V644WX}},
  note         = {Machine review of arXiv:2507.03344}
}
read the original abstract

The Rust programming language enforces three basic Rust principles, namely ownership, borrowing, and AXM (Aliasing Xor Mutability) to prevent security bugs such as memory safety violations and data races. However, Rust projects often have mixed code, i.e., code that also uses unsafe Rust, FFI (Foreign Function Interfaces), and inline assembly for low-level control. The Rust compiler is unable to statically enforce Rust principles in mixed Rust code which can lead to many security vulnerabilities. In this paper, we propose CapsLock, a security enforcement mechanism that can run at the level of machine code and detect Rust principle violations at run-time in mixed code. CapsLock is kept simple enough to be implemented into recent capability-based hardware abstractions that provide low-cost spatial memory safety. CapsLock introduces a novel revoke-on-use abstraction for capability-based designs, wherein accessing a memory object via a capability implicitly invalidates certain other capabilities pointing to it, thereby also providing temporal memory safety automatically, without requiring software to explicitly specify such invalidation. Thus, CapsLock is the first mechanism capable of providing cross-language enforcement of Rust principles. We implemented a prototype of CapsLock on QEMU. Evaluation results show that CapsLock is highly compatible with existing Rust code (passing 99.7% of the built-in test cases of the 100 most popular crates) and flags Rust principle violations in real-world Rust projects that use FFI or inline assembly. We discovered 8 previously unknown bugs in such crates in our experiments.

Figures

Figures reproduced from arXiv: 2507.03344 by the authors.

Figure 1
Figure 1. A directed graph illustrating how Rust principle [PITH_FULL_IMAGE:figures/full_fig_p004_1.png] view at source ↗
Figure 2
Figure 2. Overview of the revocation mechanism in Cap [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 4
Figure 4. CapsLock capabilities and related constructs. that violate AXM (Section 6.2 explains how they were collected). Although all 5 entries can lead to memory errors, AddressSani￾tizer detected only one PoC program. The 4 entries categorized as vulnerabilities, including 2 with CVSS scores of 9.8 (Critical), are undetected because their PoC implementations have not yet elevated the bug to an observable level. Such vulnera… view at source ↗
Figures from the paper (3 more)
Figure 5
Figure 5. Figure 5: CapsLock in operation with an example program in Rust and C. The shade colour indicates if it is modified for CapsLock: blue for unmodified and orange for modified. Rust standard library. We modified the default heap allocator Global in the Rust standard library to cre…
Figure 6
Figure 6. Figure 6: A Venn diagram comparing the numbers of test [PITH_FULL_IMAGE:figures/full_fig_p010_6.png]
Figure 7
Figure 7. Figure 7: Histogram of the per￾formance of CapsLock com￾pared to Miri (bin size: 0.01). 1 let mut r = Box::new(N::new()); 2 let p = &mut *r as *mut _; 3 r.p = p; 4 // ... 5 unsafe { &mut *r.p } Listing 5: AXM violation in generator (simplified). take less time on CapsLock than o…

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

49 extracted references · 35 canonical work pages

  1. [1]

    [n. d.]. About RustSec › RustSec Advisory Database. https://rustsec.org/

    work page

  2. [2]

    [n. d.]. Crates.Io: Rust Package Registry. https://crates.io/

    work page

  3. [3]

    Supporting the Use of Rust in the Chromium Project

    2023. Supporting the Use of Rust in the Chromium Project

    work page 2023

  4. [4]

    Rust-Lang/Miri

    2024. Rust-Lang/Miri. The Rust Programming Language

    work page 2024

  5. [5]

    Hussain M. J. Almohri and David Evans. 2018. Fidelius Charm: Isolating Unsafe Rust Code. InProceedings of the Eighth ACM Conference on Data and Application Se- curity and Privacy. ACM, Tempe AZ USA, 248–255. doi:10.1145/3176258.3176330

    work page arXiv 2018

  6. [6]

    Vytautas Astrauskas, Christoph Matheja, Federico Poli, Peter Müller, and Alexan- der J. Summers. 2020. How Do Programmers Use Unsafe Rust? Proceed- ings of the ACM on Programming Languages 4, OOPSLA (Nov. 2020), 1–27. doi:10.1145/3428204

    doi:10.1145/3428204 2020

  7. [7]

    Inyoung Bang, Martin Kayondo, HyunGon Moon, and Yunheung Paek. 2023. TRust: A Compilation Framework for in-Process Isolation to Protect Safe Rust against Untrusted Code. In 32nd USENIX Security Symposium (USENIX Security 23). USENIX Association, Anaheim, CA, 6947–6964

    work page 2023

  8. [8]

    Fabrice Bellard. 2005. QEMU, a Fast and Portable Dynamic Translator. In 2005 USENIX Annual Technical Conference (USENIX ATC 05) . USENIX Association, Anaheim, CA

    work page 2005

Show all 49 references
  1. [9]

    Kyuwon Cho, Jongyoon Kim, Kha Dinh Duy, Hajeong Lim, and Hojoon Lee

  2. [10]

    Thomas Claburn. 2023. Microsoft Is Rewriting Core Windows Libraries in Rust. https://www.theregister.com/2023/04/27/microsoft_windows_rust/

    2023

  3. [11]

    Joe Devietti, Colin Blundell, Milo M. K. Martin, and Steve Zdancewic. 2008. Hardbound: Architectural Support for Spatial Safety of the C Programming Language. ACM SIGARCH Computer Architecture News 36, 1 (March 2008), 103–

    2008

  4. [12]

    Lawrence Esswood. 2020. CheriOS: Designing an Untrusted Single-Address-Space Capability Operating System Utilising Capability Hardware and a Minimal Hy- pervisor. Ph. D. Dissertation. Apollo - University of Cambridge Repository. doi:10.17863/CAM.74163

    2020 doi

  5. [13]

    Gutstein, Jonathan Woodruff, Jessica Clarke, Peter Rugg, Brooks Davis, Mark Johnston, Robert Norton, David Chisnall, Si- mon W

    Nathaniel Wesley Filardo, Brett F. Gutstein, Jonathan Woodruff, Jessica Clarke, Peter Rugg, Brooks Davis, Mark Johnston, Robert Norton, David Chisnall, Si- mon W. Moore, Peter G. Neumann, and Robert N. M. Watson. 2024. Cornucopia Reloaded: Load Barriers for CHERI Heap Temporal...

    2024

  6. [14]

    Fillo, S.W

    M. Fillo, S.W. Keckler, W.J. Dally, N.P. Carter, A. Chang, Y. Gurevich, and W.S. Lee. 1995. The M-Machine Multicomputer. In Proceedings of the 28th Annual International Symposium on Microarchitecture . IEEE, Ann Arbor, MI, USA, 146–

    1995

  7. [15]

    Merve Gülmez, Thomas Nyman, Christoph Baumann, and Jan Tobias Mühlberg

  8. [16]

    Sarah Harris, Simon Cooksey, Michael Vollmer, and Mark Batty. 2023. Rust for Morello: Always-On Memory Safety, Even in Unsafe Code. In 37th European Conference on Object-Oriented Programming (ECOOP 2023) (Leibniz International Proceedings in Informatics (LIPIcs), Vol. 263) , K...

    2023 doi

  9. [17]

    Jonathan Corbet. 2022. A First Look at Rust in the 6.1 Kernel [LWN.Net]. https://lwn.net/Articles/910762/

    2022

  10. [18]

    Ralf Jung, Hoang-Hai Dang, Jeehoon Kang, and Derek Dreyer. 2020. Stacked Borrows: An Aliasing Model for Rust. Proceedings of the ACM on Programming Languages 4, POPL (Jan. 2020), 1–32. doi:10.1145/3371109

    2020 doi

  11. [19]

    Martin Kayondo, Inyoung Bang, Yeongjun Kwak, Hyungon Moon, and Yunheung Paek. 2024. METASAFE: Compiling for Protecting Smart Pointer Metadata to Ensure Safe Rust Integrity. In USENIX Security ’24

    2024

  12. [20]

    Paul Kirth, Mitchel Dickerson, Stephen Crane, Per Larsen, Adrian Dabrowski, David Gens, Yeoul Na, Stijn Volckaert, and Michael Franz. 2022. PKRU-safe: Automatically Locking down the Heap between Safe and Unsafe Languages. In Securing Mixed Rust with Hardware Capabilities CCS ’...

    2022

  13. [21]

    Benjamin Lamowski, Carsten Weinhold, Adam Lackorzynski, and Hermann Härtig. 2017. Sandcrust: Automatic Sandboxing of Unsafe Components in Rust. In Proceedings of the 9th Workshop on Programming Languages and Operating Systems. ACM, Shanghai China, 51–57. doi:10.1145/3144555.3144562

    2017

  14. [22]

    Henry M. Levy. 1984. Capability-Based Computer Systems. Digital Press, Bedford, Mass

    1984

  15. [23]

    Zhuohua Li, Jincheng Wang, Mingshen Sun, and John C. S. Lui. 2022. Detecting Cross-language Memory Management Issues in Rust. In Computer Security – ESORICS 2022, Vijayalakshmi Atluri, Roberto Di Pietro, Christian D. Jensen, and Weizhi Meng (Eds.). Vol. 13556. Springer Nature ...

    2022 doi

  16. [24]

    Peiming Liu, Gang Zhao, and Jeff Huang. 2020. Securing Unsafe Rust Programs with XRust. In Proceedings of the ACM/IEEE 42nd International Conference on Software Engineering. ACM, Seoul South Korea, 234–245. doi:10.1145/3377811. 3380325

    2020 doi

  17. [25]

    Ian McCormack, Joshua Sunshine, and Jonathan Aldrich. 2024. A Study of Undefined Behavior Across Foreign Function Boundaries in Rust Libraries. arXiv:2404.11671 [cs]

    2024

  18. [26]

    J. Min, D. Yu, S. Jeong, D. Song, and Y. Jeon. 2024. ERASAN : Efficient Rust Address Sanitizer. In 2024 IEEE Symposium on Security and Privacy (SP) . IEEE Computer Society, Los Alamitos, CA, USA, 239–239. doi:10.1109/SP54263.2024.00182

    2024

  19. [28]

    Martin, and Steve Zdancewic

    Santosh Nagarakatte, Jianzhou Zhao, Milo M.K. Martin, and Steve Zdancewic

  20. [29]

    Elijah Rivera, Samuel Mergendahl, Howard Shrobe, Hamed Okhravi, and Nathan Burow. 2021. Keeping Safe Rust Safe with Galeed. In Annual Computer Security Applications Conference. ACM, Virtual Event USA, 824–836. doi:10.1145/3485832. 3485903

    2021 doi

  21. [30]

    Konstantin Serebryany, Derek Bruening, Alexander Potapenko, and Dmitry Vyukov. 2012. AddressSanitizer: A Fast Address Sanity Checker. In Proceedings of the 2012 USENIX Conference on Annual Technical Conference (Usenix Atc’12) . USENIX Association, USA, 28

    2012

  22. [31]

    Konstantin Serebryany and Timur Iskhodzhanov. 2009. ThreadSanitizer: Data Race Detection in Practice. In Proceedings of the Workshop on Binary Instrumen- tation and Applications . ACM, New York New York USA, 62–71. doi:10.1145/ 1791194.1791203

    2009

  23. [32]

    Nicholas Wei Sheng Sim. 2020. Strengthening Memory Safety in Rust: Explor- ing CHERI Capabilities for a Safe Language . Ph. D. Dissertation. University of Cambridge, Computer Laboratory

    2020

  24. [33]

    Lau Skorstengaard, Dominique Devriese, and Lars Birkedal. 2019. StkTokens: Enforcing Well-Bracketed Control Flow and Stack Encapsulation Using Linear Capabilities. Proceedings of the ACM on Programming Languages 3, POPL (Jan. 2019), 1–28. doi:10.1145/3290332

    2019 doi

  25. [34]

    Lluïs Vilanova, Muli Ben-Yehuda, Nacho Navarro, Yoav Etsion, and Mateo Valero

  26. [35]

    Neven Villani. 2023. Tree Borrows

    2023

  27. [36]

    Andrew Waterman, Krste Asanovic, John Hauser, and CS Division. [n. d.]. The RISC-V Instruction Set Manual (Volume II: Privileged Architecture)

  28. [37]

    Watson, Jonathan Woodruff, Peter G

    Robert N.M. Watson, Jonathan Woodruff, Peter G. Neumann, Simon W. Moore, Jonathan Anderson, David Chisnall, Nirav Dave, Brooks Davis, Khilan Gudka, Ben Laurie, Steven J. Murdoch, Robert Norton, Michael Roe, Stacey Son, and Munraj Vadera. 2015. CHERI: A Hybrid Capability-System...

    2015 doi

  29. [38]

    Nathaniel Wesley Filardo, Brett F. Gutstein, Jonathan Woodruff, Sam Ainsworth, Lucian Paul-Trifu, Brooks Davis, Hongyan Xia, Edward Tomasz Napierala, Alexander Richardson, John Baldwin, David Chisnall, Jessica Clarke, Khilan Gudka, Alexandre Joannou, A. Theodore Markettos, Alf...

    2020

  30. [39]

    Emmett Witchel, Josh Cates, and Krste Asanović. 2002. Mondrian Memory Pro- tection. In Proceedings of the 10th International Conference on Architectural Support for Programming Languages and Operating Systems . ACM, San Jose California, 304–316. doi:10.1145/605397.605429

    2002

  31. [40]

    Filardo, Michael Roe, Alexander Richardson, Peter Rugg, Peter G

    Hongyan Xia, Jonathan Woodruff, Sam Ainsworth, Nathaniel W. Filardo, Michael Roe, Alexander Richardson, Peter Rugg, Peter G. Neumann, Simon W. Moore, Robert N. M. Watson, and Timothy M. Jones. 2019. CHERIvoke: Characterising Pointer Revocation Using CHERI Capabilities for Temp...

    2019

  32. [41]

    Carlson, and Prateek Saxena

    Jason Zhijingcheng Yu, Conrad Watt, Aditya Badole, Trevor E. Carlson, and Prateek Saxena. 2023. Capstone: A Capability-based Foundation for Trustless Secure Memory Access. In 32nd USENIX Security Symposium (USENIX Security 23). USENIX Association, Anaheim, CA, 787–804

    2023

  33. [42]

    Securing Mixed Rust with Hardware Capabilities

    Zhijingcheng Yu, Fangqi Han, Kaustab Choudhury, Trevor E. Carlson, and Prateek Saxena. 2025. Artifacts of "Securing Mixed Rust with Hardware Capabilities". Zenodo. doi:10.5281/ZENODO.14625327

    2025 doi

  34. [43]

    unsupported operation

    Yuchen Zhang, Ashish Kundu, Georgios Portokalidis, and Jun Xu. 2023. On the Dual Nature of Necessity in Use of Rust Unsafe Code. In Proceedings of the 31st ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering . ACM, San Fr...

    2023

  35. [114]

    doi:10.1145/1353534.1346295

  36. [156]

    doi:10.1109/MICRO.1995.476822

    1995

  37. [2009]

    ACM SIGPLAN Notices 44, 6 (May 2009), 245–258

    SoftBound: Highly Compatible and Complete Spatial Memory Safety for c. ACM SIGPLAN Notices 44, 6 (May 2009), 245–258. doi:10.1145/1543135.1542504

    2009

  38. [2010]

    In Proceedings of the 2010 International Symposium on Memory Management (Toronto, Ontario, Canada) (ISMM ’10)

    CETS: compiler enforced temporal safety for C. In Proceedings of the 2010 International Symposium on Memory Management (Toronto, Ontario, Canada) (ISMM ’10). Association for Computing Machinery, New York, NY, USA, 31–40. doi:10.1145/1806651.1806657

    2010

  39. [2014]

    ACM SIGARCH Computer Architecture News 42, 3 (Oct

    CODOMs: Protecting Software with Code-Centric Memory Domains. ACM SIGARCH Computer Architecture News 42, 3 (Oct. 2014), 469–480. doi:10.1145/ 2678373.2665741

    2014

  40. [2023]

    arXiv:2306.08127 [cs]

    Friend or Foe Inside? Exploring In-Process Isolation to Maintain Memory Safety for Unsafe Rust. arXiv:2306.08127 [cs]

  41. [2024]

    In 33rd USENIX Security Symposium (USENIX Security 24)

    RustSan: Retrofitting AddressSanitizer for Efficient Sanitization of Rust. In 33rd USENIX Security Symposium (USENIX Security 24) . USENIX Association, Philadelphia, PA, 3729–3746

Pith tools

Reviewed August 6, 2026 · model on record in the stance chip above.