EDBT 2026 Demo / reviewers in the wild / expert
Kaustab Choudhury
dblp:412/7502
· DBLP profile ↗
1ranked-venue papers
0as first author
1since 2021 · last 2025
0009-0000-4835-4076ORCID · reported
Domains — the database's venue-derived domains; a paper can count in several
Security and privacy · 1 · 1 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Network and information security
1 paper |
Systems and software security · 75% Authentication and access control · 25% | |
| Software engineering, system software, and programming languages
1 paper |
Programming languages and type systems · 100% |
Topics — the 5 heaviest of 5, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Authentication and access control › authorization
capability revocation |
0.9 | 1 | 2025 | Securing Mixed Rust with Hardware Capabilities · CCS 2025 |
Systems and software security
memory safety |
0.9 | 1 | 2025 | Securing Mixed Rust with Hardware Capabilities · CCS 2025 |
Systems and software security › memory safety
spatial memory safety |
0.9 | 1 | 2025 | Securing Mixed Rust with Hardware Capabilities · CCS 2025 |
Systems and software security › memory safety
temporal memory safety |
0.9 | 1 | 2025 | Securing Mixed Rust with Hardware Capabilities · CCS 2025 |
Programming languages and type systems
rust |
0.3 | 1 | 2025 | Securing Mixed Rust with Hardware Capabilities · CCS 2025 |
Methods — techniques the papers use, named apart from their topics
revoke-on-use · 1.7capability-based hardware · 1.7
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2025 | Securing Mixed Rust with Hardware CapabilitiesabstractThe 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. Zhijingcheng Yu, Fangqi Han, Kaustab Choudhury, Trevor E. Carlson, Prateek Saxena |
CCS | 3 |