Maestro: A Linux-compatible kernel in Rust

Original Article ↗ Hacker News Discussion ↗

A new hobby operating system called Maestro aims to reimplement a Linux-compatible kernel in Rust, sparking debate over how far syscall-level compatibility can go without the vast driver ecosystem and unstable in-kernel APIs that Linux relies on. Commenters weigh the potential security gains of a mostly memory-safe kernel—especially for container isolation—against the reality that kernels still need substantial `unsafe` code, can suffer from logic bugs, and must interact with insecure hardware and firmware. The project also revives long-running arguments about monolithic vs. microkernel designs and GPL-style copyleft versus permissive licensing, with many seeing value in experimental Rust kernels but doubting they will replace Linux in the near term.

Project scope & goals

  • Maestro is a hobby OS that began as a school assignment: a 32‑bit, Linux‐syscall‑compatible, monolithic kernel written in Rust.
  • Goal is primarily educational; any external adoption is a bonus.
  • Currently implements roughly one‑third of Linux syscalls yet boots far enough to run bash and is close to running tools like vim and compilers.
  • Uses classic hardware drivers (VGA, PS/2, IDE/ATA); commenters suggest targeting VMs and virtio as a practical next step.
  • Full Linux app compatibility is seen as years away, mainly due to complex syscalls, TTY stack, and the huge driver ecosystem.

Rust, memory safety & security

  • Many see a Rust kernel as a major risk reduction: fewer memory bugs, better isolation of unsafe regions, and harder exploitation (anecdotes from Rust exploit attempts used as support).
  • Others stress “memory safer” not “memory safe”: kernel and drivers still need unsafe, and logic bugs, misconfiguration, hardware issues, and firmware remain major attack vectors.
  • Debate around containers: some argue kernel memory bugs are the main reason containers can’t be a strong boundary; others say most real‑world container escapes stem from configuration mistakes and broader kernel surface, not just memory errors.
  • Microkernels (e.g., seL4) and formal verification are discussed as alternative or complementary paths to stronger guarantees.

Drivers, ABI stability & reuse

  • Consensus that drivers are the hardest part of OS work.
  • Linux’s userspace ABI is highly stable; its in‑kernel driver ABI is intentionally unstable to ease internal evolution and discourage closed drivers, making cross‑kernel module compatibility unrealistic.
  • Suggestions for Maestro: focus on a small hardware set or VMs, reuse via rump kernels, or even run Linux in a VM for missing drivers.

Architecture & design debates

  • Some wish Maestro pursued a microkernel or more radical architecture; others note combining “Rust + Linux‑compat” is already enough experimentation.
  • Large subthread argues about writing kernels in RISC‑V assembly to avoid language/compiler “complexity”; most respondents call this impractical, unmaintainable, and not meaningfully safer or more portable.

Licensing discussions

  • Maestro is MIT‑licensed.
  • One camp warns this invites proprietary forks and “doing free work for future corporations,” arguing GPL (or AGPL) better preserves user freedoms and helped make Linux successful.
  • Others counter that permissive licenses also enable vibrant community ecosystems, that GPL doesn’t guarantee good behavior, and that users lose nothing if proprietary forks coexist with the original.
  • Some suggest matching Linux’s GPLv2 to ease code sharing and avoid endless license debates.