Asterinas: OS kernel written in Rust and providing Linux-compatible ABI

Original Article ↗ Hacker News Discussion ↗

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.