Skip to content
Dev Tools Article

NetBSD 11.0 Bets Big on RISC-V and 10 ms MicroVMs

The most portable BSD closes its RISC-V gap, modernizes Linux binary compat, and ships with unusual security candor.

Mariana Souza
Mariana Souza
Senior Editor · Aug 1, 2026 · 4 min read
NetBSD 11.0 Bets Big on RISC-V and 10 ms MicroVMs

Two and a half years after 10.0, NetBSD 11.0 landed on August 1 — and the headline features read like a checklist of everywhere the industry has drifted since: first-class 64-bit RISC-V, a Linux compatibility layer that finally speaks the modern Linux ABI, and a purpose-built x86 kernel that boots in roughly 10 milliseconds for microVM workloads. For a project whose unofficial motto is "of course it runs NetBSD," this release is less about new ambitions and more about closing gaps that had started to undercut the motto itself.

The portability OS was late to RISC-V — now it isn't

Here's the uncomfortable bit of history: NetBSD, the BSD that exists specifically to run on everything, was the last of the major BSDs to ship RISC-V in a stable release. FreeBSD has built riscv64 since the 12.x era and OpenBSD added its port back in 2021, while NetBSD's RISC-V work lingered in -current for years. NetBSD 10.0 shipped in 2024 without it.

11.0 fixes that with a real port, not a QEMU-only checkbox. Supported hardware includes the Allwinner D1 boards (MangoPi MQ Pro, Nezha) and the StarFive JH7110 family — the VisionFive 2 and PINE64 Star64 — with PCIe, hardware RNG, and temperature sensors wired up, plus the usual VirtIO device set under QEMU. That maps almost exactly onto the sub-$100 RISC-V single-board computers people actually own. The practical gaps are the ones you'd expect: the JH7110's Imagination GPU isn't a supported graphics target, so treat these as headless or serial-console machines. But for embedded and firmware developers who want a genuinely small, auditable, BSD-licensed OS on RISC-V silicon — the license question matters a lot to silicon vendors — NetBSD just became a credible option, and its cross-build system (build.sh builds the whole OS from any POSIX host) remains the best in class for exactly this kind of target.

The Linux compat layer joins the 2020s

The sleeper feature is compat_linux. NetBSD has run Linux binaries since the mid-90s, but the emulation had fossilized around an old kernel ABI, and modern Linux userland quietly moved past it. Almost everything current — glibc 2.34+, anything built on libuv, container-era tooling — assumes syscalls NetBSD didn't implement: epoll, clone3, statx, close_range, inotify. Miss those and the compat layer isn't "mostly works," it's "nothing links."

11.0 adds the lot: epoll reimplemented on top of NetBSD's native kqueue, inotify, POSIX message queues, clone3, statx, renameat2, waitid, syncfs, and friends, plus procfs entries like /proc/self/limits that Linux software probes on startup. If that list looks familiar, it's because FreeBSD's Linuxulator went through the same modernization to keep running current binaries — clone3 in particular is the syscall that broke Docker's seccomp defaults when glibc 2.34 adopted it. This is the unglamorous treadmill of Linux compatibility: the ABI isn't frozen, and every emulation layer either tracks it or dies.

The realistic payoff isn't running Chrome. It's running the occasional proprietary Linux-only blob — an EDA tool, a vendor's flasher utility, a closed-source agent — on a NetBSD box without a VM. That's a niche, but it's precisely the niche NetBSD users occupy.

A 10 ms kernel aimed at the Firecracker era

The most forward-looking piece is MICROVM, a stripped x86_64 kernel configuration using PVH direct boot and VirtIO-over-MMIO that boots in about 10 ms on 2020-era CPUs. For calibration, Firecracker advertises ~125 ms to launch a Linux microVM. The numbers aren't apples-to-apples — kernel boot isn't full userland readiness — but an order-of-magnitude-faster kernel is exactly what you want for scale-to-zero functions, per-request isolation, and ephemeral CI sandboxes, a space currently dominated by trimmed Linux guests. Whether anyone builds a serious NetBSD-guest platform on it is an open question; that it exists at all shows the project understands where VMs are headed. (The same release also adds virt68k, a paravirtualized Motorola 68000 port for QEMU — the whimsical end of the same engineering spectrum.)

Elsewhere: initial Snapdragon X Elite bring-up on aarch64, POSIX.1-2024 and C23 compliance work, NPF firewall layer-2 and per-user filtering, and TCP's initial retransmission timeout dropped from 3 seconds to 1 per RFC 6298 — a small change that meaningfully improves tail latency on lossy links.

Shipping with known bugs, and saying so

One decision deserves more attention than any feature. The release announcement openly lists three unresolved security issues — in hdaudio, ipfilter, and pf's fragment reassembly — and explains that the team shipped anyway rather than slip further, noting that the volume of reported and suspected security issues "has massively increased with the advent of AI tools," with an 11.1 targeted within about two months to mop up. That matches what maintainers everywhere are living through — curl's maintainers have been vocal about AI-generated vulnerability reports swamping triage — and NetBSD's response, radical transparency plus a fast point release, is a more honest posture than silently sitting on the same queue. If you run pf on NetBSD at an edge, read those PRs before upgrading; everyone else should note the precedent, because more projects will face this exact call.

Should you care?

If your daily driver is Linux on amd64, nothing here changes your week. The base toolchain (GCC 12.5) is conservative, and desktop hardware support still trails. But three groups should look seriously: embedded developers wanting a BSD-licensed, cross-buildable OS on cheap RISC-V boards; virtualization tinkerers who want to benchmark MICROVM against their Linux guest images; and long-time BSD users who've been waiting for compat_linux to be useful again. Upgrades are the usual sysupgrade path, with images on netbsd.org and ARM board images via armbsd.org — and 25,000-plus packages waiting in pkgsrc.

NetBSD 11.0 won't win converts on features. It wins on coherence: every major item — RISC-V, modern Linux ABI, instant-boot VMs — is the same bet, that portability and smallness are worth more in 2026 than they've been in a decade. On the evidence of where hardware is going, that bet looks better than it has in years.

Sources & further reading

  1. NetBSD 11.0 released — blog.netbsd.org
  2. Announcing NetBSD 11.0 — netbsd.org
  3. NetBSD 11.0 Released With RISC-V Support, Enhanced Linux System Call Compatibility — phoronix.com
Mariana Souza
Written by
Mariana Souza · Senior Editor

Mariana covers the fast-moving world of machine learning and generative AI, with a particular focus on how these technologies are reshaping development workflows. When she isn't stress-testing the latest foundation models, she's usually at a local hackathon.

Discussion 2

Join the discussion

Sign in or create an account to comment and vote.

Larry Pike @legacy_larry · 6 hours ago

the 10ms microvm boot claim is doing a lot of work here, but i'd want to see how that compares when you actually load anything real. in my experience with embedded bsd deployments, raw kernel startup time is rarely the bottleneck — it's always been the userland setup and driver initialization. probably still a solid improvement, just don't think it's the thing that moves the needle.

Bob Feldman @benchmark_bob · 4 hours ago

exactly right — and the article doesn't say whether that 10ms is cold boot or warm, what hardware, or if they're measuring from bootloader entry or post-firmware. 10ms kernels are neat, but if your init scripts and network stack still take 500ms, you've optimized the wrong part. need to see actual microvm launch times end-to-end before that claim means anything practical.

Related Reading