OpenBSD 8.0 ships a 512G kernel address space and a 64-VCPU VMM

Theo de Raadt announced OpenBSD 8.0 on October 20, 2026, the project’s 61st release, and buried in the platform notes is the number that matters most: the amd64 kernel virtual address space goes from 4G to 512G. That is a 128x jump in one release. The same changelog adds MP support for up to 64 VCPUs per guest in vmm(4), enables Intel Arc A-Series (DG2/Alchemist) graphics in inteldrm(4), and bumps drm(4) to Linux 6.18.53. For an operating system that most people file under “firewall appliance,” this is a release aimed squarely at the machines people now run models on.

Tessera’s take: OpenBSD is not an AI operating system, and it is not trying to become one. But the release is a useful bellwether. The constraints that used to keep OpenBSD off serious compute boxes, small kernel address space, weak virtualization, no discrete GPU support, are being removed one by one, and the people doing the removing are volunteers with an allergy to hype. That is worth watching.

What actually changed

The 512G kernel virtual address space on amd64 is the headline. The changelog ties it directly to graphics: “Increased kernel virtual address space on amd64 allows mapping more than 4GB of VRAM.” That is the mechanism. A 4G kernel window cannot map a modern GPU’s memory, and GPUs with 24GB, 48GB, or more of VRAM are exactly what anyone doing local inference wants. The release also places the pmap(9) direct map at a random location, which is a security hardening move that costs nothing at runtime.

On virtualization, vmm(4) and vmd(8) get a substantial rewrite. MP support for up to 64 VCPUs per guest VM. x2apic mode for guests. MSI/MSI-X virtio interrupt support. Checksum offload for vmd(8) guests. Split virtqueues actually split. The changelog is unusually specific here, and the pattern is clear: the VMM is being made usable for guests that want many cores and fast I/O, not just a single-core test image.

The riscv64 work is the other thread worth pulling. OpenBSD 8.0 adds kernel support for the ‘V’ vector extension, detects CPU extensions and advertises them to userland through elf_aux_info(3) AT_HWCAP and AT_HWCAP2 queries, adds RISC-V Advanced Interrupt Architecture with new imsic(4) and aplic(4) drivers, and adds Sstc timer extension support. Vector extensions are the piece of RISC-V that matters for numerical work. OpenBSD is not going to run your training job, but it is now a kernel that understands the hardware a RISC-V inference box would present.

Why an AI newsroom should care

Three reasons, and none of them involve OpenBSD running a frontier model.

First, the security record is the product. De Raadt’s announcement repeats the line the project has used for years: “more than thirty years with only two remote holes in the default install.” In an industry where the supply chain of the AI stack is now a live attack surface, an OS with that record and a fresh batch of hardening is relevant. The 8.0 security section is long. It fixes a pledge(2) issue in vfs(9), tightens pledge_sockopt() checks, hardens syspatch(8) against malicious scripts, stops pax(1) extracting archives outside the working directory, and updates libexpat to 2.8.4 for CVE-2026-66046, CVE-2026-76641, and CVE-2026-76957. Anyone shipping inference endpoints on a BSD base gets those fixes for free.

Second, the virtualization work matters for isolation. The most common way to run untrusted model-generated code is to put it in a VM. vmd(8) getting 64-VCPU guests, MSI/MSI-X virtio interrupts, and better qcow handling makes it a more credible sandbox host. The changelog also notes fixes for out-of-bounds reads by vmd(8) in 32 and 64-bit elf(5) loaders with malformed elf(5) files. That is the kind of bug that matters when the thing inside the VM is adversarial.

Third, the hardware support list is a map of where cheap compute is going. The release adds SpacemiT K3 SoC support to smtclock(4) and dwpcie(4), fixes MSI interrupts on the SpacemiT K1, adds Qualcomm Glymur (X2) ACPI IDs, and enables the GXTP7936 touchscreen on the Samsung Galaxy Book4 Edge. These are the ARM and RISC-V parts that show up in edge inference boxes and developer laptops. OpenBSD supporting them is a signal that the silicon is shipping in volume.

The honest caveats

OpenBSD 8.0 does not make OpenBSD an AI platform. There is no CUDA, no ROCm, no PyTorch wheel, and the Intel Arc support is a DRM driver update, not a compute stack. The 512G address space removes a ceiling; it does not install a runtime. Anyone reading this release as a sign that OpenBSD is courting ML workloads is reading it wrong.

The project also retired the loongson architecture because it does not work with Clang 22, and switched sparc64 to the LLVM toolchain. Those are housekeeping moves, but they show the release is as much about shedding dead weight as adding capability.

The most interesting item for AI infrastructure people is the one that gets the least attention: the amd64 kernel address space change. It is the prerequisite for everything else. Without it, the Arc VRAM mapping does not happen, and without GPU memory mapping, the “run it on a BSD box” conversation does not start.

OpenBSD is not an AI operating system, and it is not trying to become one. The constraints that kept it off serious compute boxes are being removed one by one.

What to watch

The next question is whether the 512G address space and the Arc support translate into usable GPU compute on OpenBSD, or whether they remain a driver-level curiosity. The changelog mentions a workaround for inteldrm(4) GuC timeout errors on some Alder Lake systems, which suggests the graphics stack is still being stabilized rather than tuned for throughput.

For AI builders, the practical read is narrower. If you run inference or agent sandboxes on a BSD base, 8.0 is a straightforward upgrade with real isolation and memory-mapping gains. If you run on Linux with CUDA, nothing here changes your day. The release is a reminder that the boring layer underneath the AI stack is still being maintained by people who measure progress in address-space bits and VCPU counts, not benchmark scores.

OpenBSD 8.0 is available now. The 512G number is the one to remember.