Asterinas: a Rust framekernel that runs Linux binaries

What Asterinas is trying to replace, and why it is not Linux with Rust bolted on

The README frames the choice as clean slate versus incremental. Rust for Linux adds a second language to a large C codebase, and the README argues that this creates friction: Rust code inside Linux has to accommodate legacy interfaces, and new Rust code cannot remove vulnerabilities that already exist in the C it sits next to. Asterinas takes the other path. It builds a general-purpose, Linux-ABI-compatible kernel from the ground up in Rust, with no obligation to preserve compatibility for outdated platforms.

The audience follows from that. This is not a distribution you install on a laptop to browse the web. It is a kernel project for people who care how a kernel is structured: researchers, kernel engineers, and teams working on confidential computing, where the trusted computing base is a measurable property rather than a slogan. The README states the project has been under development for four years, supports 230+ Linux system calls, and has launched an experimental distribution called Asterinas NixOS. The stated goal is a production-grade, memory-safe Linux alternative with performance that matches Linux and in some scenarios exceeds it. That is the ambition; the rest of this article is about what the repository actually contains.

The framekernel split: unsafe Rust lives in OSTD, everything else is safe

Asterinas's architectural bet is the framekernel, described in the book's own chapter. A monolithic kernel keeps performance but puts all kernel code in one privileged, unsafe blob. A microkernel shrinks the trusted core but pays for it in message passing. The framekernel claims the middle: unsafe Rust is confined to a framework called OSTD, and the rest of the kernel is written in safe Rust, so the memory-safety TCB stays small and auditable.

You can see this in the repository layout. ostd/ is a top-level directory with its own libs (align_ext, id-alloc, ostd-pod, ostd-macros, ostd-test, and others), and the kernel lives separately under kernel/, split into kernel/core and a long list of components: block, console, framebuffer, i8042, input, network, nvme, pci, softirq, time, virtio, mlsdisk, and more. The Cargo.toml at the root is the workspace shared by in-kernel crates, and it says so explicitly: most crates are written and built for kernel space, with user-space and host-native exceptions listed under workspace.exclude. That single workspace is a deliberate choice, so each crate's Cargo.toml does not repeat common settings.

One design decision the README calls out by name is CortenMM, the memory management scheme that the project says improves CPU scalability. The linked paper, CortenMM: Efficient Memory Management with Strong Correctness Guarantees, received the Best Paper Award at SOSP 2025. That matters for evaluating the claim: the scalability argument is published and peer reviewed, not just asserted in a README.

Installing Asterinas and booting it with OSDK

Asterinas ships a purpose-built toolkit called OSDK, documented in the book under the OSDK guide. The README describes it as making kernel development as easy as writing a standard Rust application. The repository has an OSDK.toml at the top level and an osdk/ directory, and the root Makefile exposes the build options you would set.

The Makefile is the clearest source for what a build actually involves. Its global build options block declares TARGET_ARCH with a default of x86_64, BOOT_METHOD with a default of grub-rescue-iso, BOOT_PROTOCOL with a default of multiboot2, MEM with a default of 8G, and CONSOLE with a default of hvc0, which the comments say falls back to tty0 automatically if hvc0 is not available. Those defaults describe the intended path: build an ISO, boot it under a hypervisor with 8 GB of memory, and attach to the virtio console.

Because those keys are declared as Makefile variables, you override them on the command line rather than passing them to a separate tool. The relevant lines, copied from the Makefile, are:

TARGET_ARCH ?= x86_64
BOOT_METHOD ?= grub-rescue-iso
BOOT_PROTOCOL ?= multiboot2
MEM ?= 8G
CONSOLE ?= hvc0

Each uses the ?= assignment, so a value you supply wins and the default applies otherwise. ENABLE_KVM also defaults to 1, which means the default path already assumes hardware virtualization is available to you.

For debugging, the Makefile reserves GDB_TCP_PORT=1234 by default, alongside GDB_PROFILE_FORMAT=flame-graph, GDB_PROFILE_COUNT=200, and GDB_PROFILE_INTERVAL=0.1. That is a working setup rather than a placeholder, and it is the fastest way to see whether the kernel reaches the point you care about.

Conformance testing is opt-in. ENABLE_CONFORMANCE_TEST defaults to false, and when enabled, CONFORMANCE_TEST_SUITE defaults to ltp with CONFORMANCE_TEST_WORKDIR set to /tmp. The repository's test/ directory holds the initramfs sources the Makefile refers to. If you are evaluating Asterinas as a Linux alternative, the LTP suite is the number to look at, not the system call count.

Where Asterinas is the wrong tool

The README's own framing is honest about the stage: Asterinas aims to become a production-grade alternative, and 2026 is described as the year the project's priority is to advance maturity. That sentence is the limitation. Aims and priorities are not the same as a support commitment.

The driver surface is where this bites first. The component list under kernel/core/comps covers virtio, nvme, pci, network, input, console, framebuffer, and DRM, plus i8042 for legacy input. That is a virtualized and modern-hardware set. If your deployment depends on a storage controller, network card, or GPU that is not in that list, there is no compatibility shim to fall back on, because the whole point of the clean-slate approach is that the legacy assumptions were not carried over.

The boot path has a similar shape. The Makefile notes that the virtual terminal tty0 currently only works with the linux-efi-handover64 and linux-efi-pe64 boot protocols, and that Asterinas falls back to tty0 only when hvc0 is unavailable. So console behavior is coupled to your boot protocol choice, and that coupling is documented rather than hidden.

Finally, the ABI compatibility target is Linux, and the supported system call count is 230+. For most server workloads that is fine. For anything that leans on a rarely used syscall, an ioctl, or a procfs/sysfs detail that LTP does not cover, you are the one who finds out. Asterinas NixOS is explicitly labeled experimental in the README, which is the right label for a distribution built on a kernel at this stage.

Asterinas and Redox: two Rust kernels, two different bets

The obvious comparison for a Rust operating system is Redox, and the difference is not the language. Redox is a microkernel design with its own userspace and its own ecosystem, which means it is not trying to run Linux binaries as its primary compatibility story. Asterinas makes the opposite bet: keep the Linux ABI, keep monolithic-kernel performance, and get memory safety by shrinking the unsafe core rather than by moving functionality out of the kernel.

That choice has consequences in both directions. Keeping the Linux ABI means existing software is the reward, and the OSDK plus NixOS work is aimed at making that real. It also means the kernel inherits Linux's interface surface as a compatibility obligation, which is a large amount of behavior to reproduce correctly. A microkernel like Redox avoids that obligation but gives up the ability to run Linux workloads unmodified.

Asterinas's own research output is the better evidence for where the project is strong. The README lists papers at USENIX ATC 2025 (two, including one on Converos, practical model checking for Rust kernel concurrency), SOSP 2025 (CortenMM, Best Paper), ICSE 2026 (RusyFuzz, fuzzing for Rust OS kernels), and FAST 2026 (MlsDisk, trusted block storage for TEEs based on layered secure logging). MlsDisk is integrated into the kernel as kernel/core/comps/mlsdisk, and the repository carries Intel TDX test and benchmark workflows. If your interest is TEEs or kernel verification, Asterinas is producing directly relevant artifacts.

Maintenance, licensing, and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-22, one day before this article's reference point. Releases are frequent: v0.18.1 on 2026-08-18, v0.18.0 on 2026-06-03, and v0.17.2 on 2026-05-09. A VERSION file, a RELEASES.md, and a DOCKER_IMAGE_VERSION file sit at the top level, so version pinning is a first-class part of the workflow rather than an afterthought.

The upgrade cost is unusual for a kernel project. Because the whole in-kernel codebase shares one Cargo workspace, dependency bumps propagate across crates at once, and rust-toolchain.toml pins the compiler. That is good for consistency and bad for partial migration: you cannot move one component to a new Rust edition while leaving the rest behind without touching the shared workspace configuration. The presence of clippy.toml and rustfmt.toml also means the project enforces its own lint and formatting baseline, so out-of-tree components will need to match it.

Licensing is straightforward to state and worth stating precisely. The repository carries LICENSE-MPL, and the Makefile's first line is an SPDX-License-Identifier: MPL-2.0 header. The MPL-2.0 is file-level copyleft: modifications to MPL-covered files must be made available under the same license, while larger works that combine MPL files with other code can be licensed differently. That is the general shape of the license, not advice about your situation; if you plan to ship a product containing Asterinas code, have counsel read LICENSE-MPL and the COPYRIGHT file rather than relying on a summary.

Editorial conclusion

Asterinas is worth adopting if you are researching Rust kernel design, kernel fuzzing, or TEE storage, or if you want to write kernel components against a safe-Rust API instead of a C one. It is the wrong tool if you need a drop-in Linux replacement today, or if your workload depends on a driver the kernel/comps list does not contain. Before you commit time, read the framekernel architecture chapter in the book, then run the OSDK build for your target architecture and check that the boot path you need (grub-rescue-iso with multiboot2 is the default) actually comes up on your hardware.

Frequently asked questions

Official sources

1. asterinas/asterinas on GitHub
2. License: MPL-2.0
3. Project website
4. README
5. Releases