* 2025-12-08: **FAST 2026** accepted a paper on a novel secure storage solution having been integrated into Asterinas: _MlsDisk: Trusted Block Storage for TEEs Based on Layered Secure Logging_.
* 2025-10-14: [*CortenMM: Efficient Memory Management with Strong Correctness Guarantees*](https://dl.acm.org/doi/10.1145/3731569.3764836) received the **Best Paper Award** at **SOSP 2025**.
* 2025-07-23: **SOSP 2025** accepted another Asterinas paper: [*CortenMM: Efficient Memory Management with Strong Correctness Guarantees*](https://dl.acm.org/doi/10.1145/3731569.3764836).
* 2025-06-18: **USENIX _;login:_ magazine** published [*Asterinas: A Rust-Based Framekernel to Reimagine Linux in the 2020s*](https://www.usenix.org/publications/loginonline/asterinas-rust-based-framekernel-reimagine-linux-2020s).
* 2025-04-30: **USENIX ATC 2025** accepted two Asterinas papers:
1. [*Asterinas: A Linux ABI-Compatible, Rust-Based Framekernel OS with a Small and Sound TCB*](https://www.usenix.org/conference/atc25/presentation/peng-yuke);
2. [*Converos: Practical Model Checking for Verifying Rust OS Kernel Concurrency*](https://www.usenix.org/conference/atc25/presentation/tang).
The future of operating systems (OSes) belongs to Rust—a modern systems programming language (PL)
that delivers safety, efficiency, and productivity at once.
The open question is not _whether_ OS kernels should transition from C to Rust,
but _how_ we get there.
Linux follows an _incremental_ path.
While the Rust for Linux project has successfully integrated Rust as an official second PL,
this approach faces _inherent friction_.
As a newcomer within a massive C codebase,
Rust must often compromise on safety, efficiency, clarity, and ergonomics
to maintain compatibility with legacy structures.
And while new Rust code can improve what it touches,
it cannot retroactively eliminate _vulnerabilities_ in decades of existing C code.
Asterinas takes a _clean-slate_ approach.
By building a Linux-compatible, general-purpose OS kernel from the ground up in Rust,
we are liberated from the constraints of a legacy C codebase—its interfaces, designs, and assumptions—and from the need to preserve historical compatibility for outdated platforms.
**Languages—including PLs—shape our way of thinking**.
Through the lens of a modern PL, Asterinas rethinks and modernizes the construction of OS kernels:
* **Modern architecture.**
Asterinas pioneers the [_framekernel_](https://asterinas.github.io/book/kernel/the-framekernel-architecture.html) architecture,
combining monolithic-kernel performance with microkernel-inspired separation.
Unsafe Rust is confined to a small, auditable framework called [OSTD](https://asterinas.github.io/api-docs-nightly/ostd/),
while the rest of the kernel is written in safe Rust,
keeping the memory-safety TCB intentionally minimal.
* **Modern design.**
Asterinas learns from Linux's hard-won engineering lessons,
but it is not afraid to deviate when the design warrants it.
For example, Asterinas improves the CPU scalability of its memory management subsystem
with a novel scheme called [CortenMM](https://dl.acm.org/doi/10.1145/3731569.3764836).
* **Modern code.**
Asterinas's codebase prioritizes safety, clarity, and maintainability.
Performance is pursued aggressively, but never by compromising safety guarantees.
Readability is treated as a feature, not a luxury,
and the codebase is structured to avoid hidden, cross-module coupling.
* **Modern tooling.**
Asterinas ships a purpose-built toolkit, [OSDK](https://asterinas.github.io/book/osdk/guide/index.html),
to facilitate building, running, and testing Rust kernels or kernel components.
Powered by OSTD,
OSDK makes kernel development as easy and fluid as writing a standard Rust application, eliminating the traditional friction of OS engineering.
Asterinas aims to become **a production-grade, memory-safe Linux alternative**,
with performance that matches Linux—and in some scenarios, exceeds it.
The project has been under active development for four years,
detailed [here](https://github.com/asterinas/asterinas/blob/main/.licenserc.yaml). For the rationales behind the choice of MPL, see [here](https://asterinas.github.io/book/index.html#licensing).
