BareMetal: an x86-64 exokernel written entirely in assembly

A kernel that fits in less than 32 KiB

BareMetal is described as a very minimal, resource efficient exo-kernel, and the README puts it more bluntly as just enough kernel. The official repository of the open-source BareMetal exokernel, it is written from scratch in assembly, designed for x86-64 hardware, with no dependencies except for the virtual or physical hardware.

The scale is the headline. The kernel binary is less than 32 KiB, and BareMetal uses 4 MiB of RAM while running. The README explains where that RAM goes: the majority is required memory structures for operating in 64-bit mode, drivers and system buffers, and CPU stacks. All other system memory is dedicated to the running program.

That last sentence is the design in miniature. Instead of a kernel managing memory and handing out fragments, everything the kernel does not need for itself belongs to the application. The stated premise is to do one thing well, which is to execute a program with zero overhead, and the name is a play on bare metal, meaning running directly on physical or virtualized hardware.

The README is honest about the framing, calling BareMetal a very lean kernel that offers only the bare essentials required for a working operating system, and listing basic support for symmetric multiprocessing, network and storage access through a low-level abstraction layer.

Single address space, and what that costs

BareMetal is an exokernel and offers a single address space system. The README describes the approach as a just enough operating system approach, written in assembly to achieve high-performance computing with a minimal footprint.

A single address space is the defining constraint, and it cuts in two directions. The upside is that there is no address space switch, no page table management for isolation, and no system call path, which is exactly why the binary is tiny and the memory overhead is negligible. The downside is that everything running in the kernel shares one address space, so there is no hardware-enforced separation between kernel code and application code.

The README does not describe a memory protection unit, a privilege ring boundary or a preemptive scheduler, and the feature list says something slightly different from what a general-purpose kernel would offer: mono-processing, multi-core. The system is able to execute a single program but can spread the work load amongst available CPU cores. In other words, parallelism inside one program, not concurrency between programs.

For a unikernel use, where you ship exactly one workload and trust it, that is a coherent trade. For anything that intends to run untrusted code or several tenants, it is the wrong shape, and the project does not claim otherwise.

Boot comes from the Pure64 loader

The kernel does not boot by itself. Both BIOS and UEFI boot methods are supported via the companion Pure64 loader, and the project keeps those two paths in one feature line rather than leaving firmware support as an exercise for the reader.

The other deliberate choice is 64-bit only. The README gives the reason: to make use of the extra-wide and additional registers available in 64-bit mode. That is not a neutral statement, since it removes the 32-bit path entirely. There is no compatibility mode, and there is no way to run this on a 32-bit machine.

Hardware support is equally opinionated. The supported list covers multi-core 64-bit x86 systems from Intel and AMD, the PCIe and PCI buses, Virtio-Net for networking, Virtio-Blk for storage, and human interface devices: a PS/2 keyboard and serial input, with output to a linear frame buffer at native screen resolution falling back to 1024x768x32bpp, VGA text mode at 80x25 characters with 16 colors, and serial.

The Virtio choice is the practical one. It means the kernel can be developed against emulated devices that behave predictably, rather than against the long tail of real network and disk controllers, and it is why the same binary runs unchanged in a virtual machine and on a physical machine that exposes virtio drivers.

Building it means going through BareMetal-OS

There is no install command in the README, and that is not an omission so much as a division of labour. The kernel repository contains the kernel, while the README points you to a separate repository, BareMetal-OS, for a full build environment.

The kernel repository itself is small in layout terms. At the top level there is a `src/` directory holding the assembly sources, an `api/` directory for the exposed interface, a `doc/` directory, a `build.sh` script, a `clean.sh` script and an `LICENSE` file. The two shell scripts are the build and clean entry points, and the README does not document their flags, so the details of the toolchain live in the companion repository rather than here.

What you should expect from a first run is a small binary and a serial console. Since output goes to VGA text mode, serial, or a linear frame buffer, the fastest way to see the kernel alive is a virtual machine with serial output captured. The README states that the project develops on QEMU and VirtualBox, which means BareMetal can be run on Linux, Microsoft Windows and Apple macOS hosts without changing the target.

If you are evaluating rather than porting, that is the cheapest path: run it in the emulator the maintainers use, read the serial output, and only then think about physical hardware.

Where BareMetal is the wrong choice

The limits are structural rather than fixable, and the README is direct about them.

Architecture is the first. It is x86-64 only, and the README states that an ARM and/or RISC-V rewrite would be considered once hardware is standardized. For anyone building on Apple silicon, on ARM servers, or on RISC-V boards, there is no path here today, and the wording suggests the port is not imminent.

The second limit is the hardware list. Virtio-Net and Virtio-Blk cover the common virtual machine case well, and a physical x86-64 machine would need appropriate drivers, which the README states as a condition rather than something provided. Anything needing a specific real device, a GPU, or a filesystem the kernel does not implement is out of scope. The supported storage list is block devices, not filesystems.

The third is what an exokernel gives up. One program, one address space, no isolation, no multi-tenant story, no general-purpose process model. The README positions it as primarily targeted at physical and virtualized environments for cloud computing or HPC clusters, and says it could also be used as a unikernel. If your goal is to run many workloads on one machine with isolation between them, you want a different architecture, not a different configuration of this one.

There is also a project-level caveat. The commit history of a kernel written in assembly from scratch is a large amount of specialised knowledge, and the documentation here is a README, not a manual.

MIT terms and a June 2026 push

The licence field on the repository says MIT, which is permissive and short enough to read in a minute. For a kernel that people may want to read, copy and study, that is a sensible choice, and it also means an ARM or RISC-V port, when it comes, could start from this code rather than from scratch.

On maintenance, the facts are these: the last push was on 2026-06-12, and the tagged releases are dated releases named by year and month, with 2026.04 on 2026-04-29 and 2026.01 on 2026-01-31. A calendar-numbered release is unusual next to semantic versioning, and it tells you the project ships when the maintainer decides rather than on a semver contract. That is normal for a kernel and it means you should read the release notes rather than assume a minor bump is safe.

The dates also place the project in a steady state. Two releases roughly three months apart, with the most recent push a few months before the present, indicate a project that is still moving but at a measured pace rather than one in a burst of development.

For an adopter, the cost is knowledge rather than dependencies. There is nothing to upgrade in the usual sense, no package manager, and no compatibility matrix to track. What you take on is the assembly source, the Pure64 loader and the BareMetal-OS build environment, and the responsibility for the drivers your hardware needs.

Editorial conclusion

Use BareMetal when you are writing a single-purpose program that must run with no operating system around it, on x86-64, and you can accept virtio drivers and a single address space as the price. Skip it if you need ARM or RISC-V, a preemptive scheduler, or isolation between programs, since the project states an ARM or RISC-V rewrite would only be considered once hardware is standardized. Verify first that your device needs are covered by the virtio-Net and Virtio-Blk paths or by drivers you write, and build through the BareMetal-OS repository rather than the kernel repository alone, since the README points there for a full build environment. The licence field on the repository says MIT, and the last push was on 2026-06-12.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. ReturnInfinity/BareMetal on GitHub