# Motor OS: a microkernel operating system written entirely in Rust

> Motor OS is an operating system for virtualized workloads, written in Rust from the kernel to the shell, with a microkernel of about 18,600 lines of no_std Rust and only four syscalls. It runs as an x86-64 KVM guest under QEMU, Cloud Hypervisor and Firecracker, and boots in roughly 100 milliseconds.

**moturus/motor-os** — A simple, fast, and secure operating system for the cloud.

- Repository: https://github.com/moturus/motor-os
- Stars: 1,098 · Forks: 33
- Language: Rust
- License: Apache-2.0
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/moturus-motor-os

## The argument is that Linux was not designed for the guest

Motor OS is described as a simple, fast and secure operating system built for the cloud, and it targets virtualized workloads such as web serving, serverless computing and edge caching, avoiding the overhead a general-purpose OS carries when it runs inside a VM.

The reasoning section is worth reading in full, because it is a specific argument rather than a general complaint about Linux. Linux has many advanced features that in many situations make it the only reasonable choice, and the project says so. The objection is that in theory, for some virtualized workloads, several things make it less than ideal.

The first is that Linux is optimized for bare metal, which leads to duplicated work when it runs inside a VM on a Linux host: duplicate block caches, duplicate page table walks, and a host scheduler that can preempt a vCPU while it holds a spinlock in the guest kernel. That last point is the sharpest. A spinlock held across a preemption is a latency spike, and in a host that runs many guests the scheduler has no idea that the guest is mid-critical-section.

The second is usability. The project points at Docker, NixOS, serverless platforms and similar projects as existing because of Linux's complexity, which is an argument that a simpler OS would not need a whole ecosystem of isolation tooling.

The third is that Linux has, historically, not been very secure. That is a historical claim rather than a present one, and the project frames it that way deliberately.

The conclusion is that a new operating system built from the ground up for virtualized workloads can be much simpler and more secure than Linux, while matching or exceeding its performance and efficiency. Whether it does that is the open question, and the status section is more careful about it than the argument is.

## Five design decisions, each one removing something

The list of what Motor OS does differently is six items, and each one is a removal rather than an addition.

Only VirtIO. Motor OS runs inside a VM, so it needs drivers for VirtIO block and network devices and nothing else. No SATA, no NVMe, no USB, no framebuffer, no legacy keyboard controller. Every driver that is not needed is a driver that cannot have a bug.

A microkernel. The kernel manages memory, threads and IPC, and never blocks. Drivers, the filesystem and the network stack are one userspace process, and if that process dies, the machine halts with a clear log rather than limping on. That is a deliberate trade, and the trade is visible: a failure in the I/O path stops the machine instead of degrading it. The project is explicit that this is what happens rather than pretending the architecture is fault tolerant.

Rust all the way down. Memory safety in the kernel, the runtime and the services, a Rust system interface instead of a C one, and no dynamic linking.

A small process model. No fork, no signals, no pseudo-terminals, no users. Processes carry an immutable capability word, and three roles derived from it, System, Interactive and None, drive filesystem permissions. The capability word is the interesting part, because it is the entire security model in one integer, and the three roles are derived from it rather than being a separate concept.

Configuration is part of the image. Services, networking and permissions are declared in a few files and a declarative image policy, so a machine's configuration is a build artefact rather than a mutable file edited at runtime.

And boot time matters. Motor OS boots in about 100 ms. The status section gives a slightly different figure, about 200 ms for MBR or PVH boot, so the 100 ms number is presumably a different measurement, but the order of magnitude is the point.

## Four syscalls, and the userspace services around them

The architecture section gives the most concrete numbers in the project, and they are the ones to hold on to.

The kernel is about 18,600 lines of no_std Rust with four syscalls, and it manages address spaces, threads, scheduling, capabilities and wait/wake objects. Everything else runs in userspace.

The userspace services are named, which makes the design easy to picture. `sys-io` owns the VirtIO block and network devices, the journaling filesystem called Motor FS, and the networking stack called moto-netstack. `sys-init` starts services. `sys-tty` drives the serial console. `strobe` collects logs and metrics. `dns-resolver` resolves names. `russhd` serves SSH.

That last list is a good summary of the maturity of the project. A DNS resolver, an SSH server, a metrics collector, a filesystem, a network stack and a service manager, all in userspace, over four syscalls.

The bridge between Rust and the system is worth understanding, because it is the trick that makes a Rust-only OS practical. A per-process runtime object, `rt.vdso`, implements the system interface that Rust's standard library calls through the small `moto-rt` crate. So the standard library is ported, with `x86_64-unknown-motor` as a Tier-3 Rust target, and it works because the standard library's system calls are redirected to the microkernel through that object rather than through a C shim. That is what lets Tokio and mio, rustls, hyper, axum and russh work unmodified.

The kernel's own behaviour is described precisely. Scheduling is cooperative in the kernel with preemption in userspace, which is an unusual split and means a kernel thread is never preempted while the userspace side is preemptible. SMP goes up to 16 vCPUs, there are guarded lazy stacks, and there is admission control that keeps the machine out of physical memory exhaustion instead of an OOM killer.

The admission control point is the one most server operators would care about, and it is a different failure model from Linux. Instead of an OOM killer choosing a victim at random under pressure, the machine refuses work, and the hypervisor's view of the guest stays coherent.

## What actually works today, and what does not

The status section is unusually honest for an operating system project, and it should be read as a specification of scope rather than a marketing page.

What works is listed in detail. Boot and kernel: MBR under QEMU or PVH under Cloud Hypervisor and Firecracker, cooperative in-kernel scheduling with preemptive userspace, SMP up to 16 vCPUs, guarded lazy stacks and the admission control described above.

I/O in userspace: VirtIO block and network drivers with checksum and TSO offload, Motor FS with per-role permissions and advisory locks, and moto-netstack with IPv4 and IPv6, DHCPv4, TCP with CUBIC, SACK, RACK-TLP, timestamps and SYN cookies, UDP and ICMP echo, at about 10 Gbps host to guest, plus a DNS resolver service.

The networking feature list is worth pausing on, because TCP with CUBIC, SACK, RACK-TLP, timestamps and SYN cookies is the list of what a modern stack needs to not fall over under load, and having all of it in a new userspace network stack is a serious amount of work.

On the language side, the standard library is ported and `x86_64-unknown-motor` is a Tier 3 Rust target, with Tokio and mio, rustls, hyper, axum and russh working. For C and C++ there is a C library, mlibc, the LLVM C++ runtime and a Clang target for Motor OS, and Rust is preferred while C and C++ are fully supported, and Lua runs.

The programs list is what tells you this is usable rather than a demo. The rush shell, the rmux terminal multiplexer, the red and kibim editors, an SSH server with SFTP, two static web servers with TLS, the usual commands including ls, ps, top, ss, ping and free, and ripgrep.

And there is a self-hosting developer image with native Clang and LLVM, a native rustc, and Lorry, which is described as a smaller and stricter Cargo replacement for security-sensitive environments. The comparison with Cargo is precise: Cargo-compatible, the same `Cargo.toml` and `Cargo.lock`, byte-identical binaries, but offline, with every dependency fetched once, checked and approved before it is built. That is a supply chain control, not a build tool, and it is a good example of what a purpose-built OS can do that a general-purpose one cannot.

## Beta quality, with the caveats stated

The status paragraph is short and carries the project's real maturity claim.

Motor OS is approaching beta quality. Development started in 2021, and in 2026 it went through weeks of systematic AI-assisted review and hardening, of the networking stack in particular. Networking is considered ready for production use within its supported feature set. The rest of the system is exercised daily by the full test suite, by long soak runs, and by the website, which is served from Motor OS VMs.

And then the sentence that matters most for an evaluator: there has been no independent security audit yet.

That is a reasonable place for the project to be, and the fact that it is stated plainly is a good sign. The testing claim is also more substantial than a typical project of this size could make: a full test suite run daily, long soak runs, and a real website served from Motor OS VMs, which is the kind of dogfooding that finds the bugs a test suite does not.

The AI-assisted review and hardening is worth noting as a development method rather than a product feature. Weeks of systematic review of the networking stack, with an emphasis on the part of the system most likely to be subtly wrong, is a reasonable use of that kind of tooling, and it is also a signal that the project is aware of where its own risk sits.

The repository itself is Rust, with a `rust-toolchain.toml` at the root, a `Makefile`, `docs/`, `src/`, a `CHANGELOG.md`, `CONTRIBUTING.md`, `AGENTS.md`, an `.helix/` directory for the editor configuration, and both `LICENSE-APACHE` and `LICENSE-MIT`, so it is dual licensed. The project is MIT and Apache-2.0 licensed.

The README is explicitly a summary, with the details on motor-os.org, and the repository carries the build instructions, the VM scripts and tools, the toolchain versioning and update documentation, and a recipes directory of examples.

## The build system refuses to build with the wrong toolchain

The Makefile is short but the guard rails in it are unusually strict, and they show how the toolchain is versioned.

Before anything else, the build checks that `rustc` is on the path, and errors out with a message telling you to open a new shell or source `$HOME/.cargo/env`, because a rustup installed by the build script only reaches the path in a new shell.

Then it looks for the toolchain stamp. The toolchain sysroot comes from `rustc --print sysroot`, and the build reads a file at `lib/rustlib/MOTOR-TOOLCHAIN-KEY` in that sysroot, which must contain a 64-character hexadecimal string. If the file is missing or the content does not match that pattern, the build stops with the message that the selected Rust toolchain is not a stamped Motor toolchain and tells you to run `src/build-motor-os.sh`.

The key is then used in the object directory path, `build/obj/$(MOTOR_TOOLCHAIN_KEY)`, so different toolchain versions get different build directories and do not corrupt each other. That is the mechanism behind the toolchain versioning documentation the README points to.

The build itself is `cargo build --target x86_64-unknown-motor`, with a clippy target alongside it, and a debug and a release mode, where release additionally strips the installed image. The target sub-directory is `x86_64-unknown-motor` under debug or release, and the image command differs between the two.

There is also a comment explaining the structure of the top-level invocation. A top-level invocation runs its goals in one logged sub-make through the driver, which ends a failed build with a summary of exactly what failed. That is a small thing that makes a large multi-target build much easier to use, since a Rust and a kernel and an image build can fail in a dozen different ways and the summary tells you which.

## Where Motor OS is the wrong choice

The first case is anything that needs Linux. The ported ecosystem is a specific list, Tokio and mio, rustls, hyper, axum and russh, plus mlibc for C, the LLVM C++ runtime and Lua, and the rest of your dependency tree is not on it. A service that depends on a native library, a kernel feature, a system call or a Linux-specific tool is not a candidate, and the project does not pretend otherwise.

The second case is a production system where an unaudited microkernel is a hard no. A 18,600-line kernel with four syscalls is a small attack surface, which is the point, but small and un-audited is a different proposition from small and audited, and the project says plainly that there has been no independent security audit. The same caution applies to the userspace network stack with its own TCP implementation, which is the kind of component where a subtle bug is a security problem rather than a performance problem.

The third case is a workload that needs a rich operating system. There is no fork, no signals, no pseudo-terminals, no users, and a process model with three roles. A development environment, a build system that expects a full POSIX surface, or anything running an off-the-shelf application server is out of scope.

The fourth is a team that wants to adopt an operating system now. The project says it is approaching beta quality, the Rust target is Tier 3 rather than Tier 1, and the security story is unverified. That is a research project with real production aspirations, which is a fine thing to be, but it is not a platform to put a revenue-generating service on this quarter.

A last practical note on the AI-assisted review claim. It is a legitimate development method and the project is upfront about using it, and it is also a signal that the quality of the output depends on the quality of the review, which you cannot audit from outside. For a project that wants to be taken seriously as an operating system, the independent audit is the missing piece rather than another month of internal review.

## Conclusion

Motor OS fits a team building cloud or edge workloads that want an OS with a tiny trusted computing base and no C in the kernel, and it fits a Rust team that needs to target a unikernel-like environment. It does not fit a project that needs Linux compatibility, since the ported ecosystem is a specific list and the Rust target is Tier 3. Before you evaluate it, read the status section carefully, because the networking stack is described as production ready within its supported feature set while there has been no independent security audit, and check the four-syscall surface before assuming the system calls you need exist.

## FAQ

### What is Motor OS?

It is a simple, fast and secure operating system built for the cloud, targeting virtualized workloads such as web serving, serverless computing and edge caching. It is written entirely in Rust from the kernel to the shell, and its system interface is Rust rather than C.

### How big is the Motor OS kernel and what does it do?

About 18,600 lines of no_std Rust with four syscalls, managing address spaces, threads, scheduling, capabilities and wait/wake objects. Drivers, the filesystem and the network stack all run in userspace, in a single process that owns the VirtIO devices.

### Which hypervisors can run Motor OS?

It runs as an x86-64 KVM guest under QEMU, Cloud Hypervisor and Firecracker, booting via MBR under QEMU or PVH under the other two, with SMP up to 16 vCPUs.

### Is Motor OS ready for production?

The project says it is approaching beta quality. Networking is considered ready for production use within its supported feature set, and the rest of the system is exercised by the test suite, long soak runs and the project website, but there has been no independent security audit yet.

## Sources

- [Issues](https://github.com/moturus/motor-os/issues)
- [License: Apache-2.0](https://github.com/moturus/motor-os/blob/main/LICENSE)
- [moturus/motor-os on GitHub](https://github.com/moturus/motor-os)
- [README](https://github.com/moturus/motor-os/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/moturus-motor-os