Asterinas: OS kernel written in Rust and providing Linux-compatible ABI
Asterinas is a new Rust-based operating system kernel that aims to provide a Linux-compatible userspace ABI while targeting x86‑64 virtual machines, with a roadmap toward production use in cloud and TEE scenarios. Commenters see value in a smaller, memory‑safe kernel that can run existing Linux applications, but note major hurdles around hardware support, syscall and `/proc` compatibility, and the lack of a stable Linux driver ABI, which prevents reusing existing kernel modules. The project’s MPL licensing, focus on Rust safety within a largely monolithic architecture, and comparison to efforts like Redox, Fuchsia, and unikernels highlight broader questions about whether such kernels can complement or eventually displace traditional Linux in certain niches.
Project scope and goals
- Kernel written in Rust aiming for Linux-compatible user-space ABI, not Linux kernel module compatibility.
- Currently targets only x86‑64 VMs; roadmap focuses on being “production-ready” for VM environments first, then more architectures and devices.
- Short-term concrete use case mentioned: safer, smaller TCB Linux-compatible kernel inside TEE/TDX guest VMs.
Architecture & design
- “Framekernel” described as a monolithic, single-address-space kernel partitioned into privileged and unprivileged Rust “services.”
- Unsafe Rust is quarantined to a minimal core; unprivileged services must be safe Rust.
- Some see this as essentially a layered monolithic kernel with marketing; others view it as a serious new architecture.
Linux compatibility and drivers
- Linux compatibility means implementing syscalls, /proc-/sys-/dev-like interfaces, futexes, epoll, signals, etc.; link to their syscall coverage is shared.
- Users stress that Linux kernel driver API/ABI is unstable, so Linux drivers cannot simply be reused.
- Several note the massive effort of matching Linux’s hardware support; VM-only focus is seen as a pragmatic way to bypass the driver problem.
Rust as kernel language
- Many comments debate Rust itself: safety via ownership/borrowing vs complexity (lifetimes, traits, async, nested types).
- Split between those who find the borrow checker a temporary hurdle and those who see Rust as overengineered and C++‑like in cognitive load.
- Discussion on
unsafe: it is required for low-level operations but should be encapsulated; disagreement on how widespread and problematic it is in real code. - Some argue tools like LLMs and valgrind don’t replace language-level safety guarantees.
Use cases and performance
- Intended use seen as VM kernels, possibly for backend/container-like workloads or high-performance networking on virtio devices.
- Debate over DPDK vs modern io_uring; consensus that DPDK’s advantages are shrinking but still relevant for some workloads.
- Unikernels and other minimal kernels are raised as alternative approaches.
Licensing and proprietary modules
- MPL license framed as allowing proprietary kernel modules; some see this as a plus for business, others as inviting “blob” ecosystems.
- Unclear whether a stable driver API/ABI will be promised; speculation that a stable API (not ABI) is more likely.
Trust, geopolitics, and realism
- Some express distrust of a Chinese-origin kernel in production; others note extensive existing Chinese hardware/software in Western infrastructure.
- Broad agreement that interesting Rust kernels will not “replace Linux” soon due to Linux’s decades of driver and hardware support, but can fill important niches.