Configuring a kernel
July 18, 2026 ยท View on GitHub
The kernel is a single cargo crate. What goes into an image, which capsules,
which drivers, and whether the spawn gate is enforced, is selected entirely by
cargo features. This document explains how to choose them.
Quick start
Configure a kernel interactively, then build it:
make menuconfig # choose a profile and options, writes .nonos-config
make from-config # build exactly what you chose
Plain make with no target builds the full production image instead: the
attested ZeroState kernel, the EFI System Partition, and a bootable ISO.
Profiles
A profile is a composite feature declared in Cargo.toml under [features],
named microkernel-<name>. Each one is a coherent, bootable selection: a base
runtime plus a fixed set of capsules and drivers. Profiles are the unit of
choice because an arbitrary mix of leaf features does not necessarily boot;
a profile is a combination that has been assembled to.
The catalogue, grouped:
The base profiles are microkernel-core (scheduler, memory, crypto, no capsules)
and microkernel-capsules (core plus proof-io, ramfs and keyring).
The single-capsule and single-driver profiles put one capsule or one driver on
top of the core, for bring-up and tests: microkernel-ramfs,
microkernel-driver-nvme, and so on.
The network profiles are the layered stack, each one adding a layer, from
microkernel-net-l2 through microkernel-net-sockets.
The desktop profiles are microkernel-desktop-gui (compositor, apps, core
drivers) and microkernel-full-gui (the desktop plus every driver).
List them at any time:
tools/nonos-config --list
The canonical production target
make nonos-mk-zerostate builds the complete, release-tested system: every
capsule and driver, the transparent STARK spawn gate enforced, dual-signature
(Ed25519 + ML-DSA-65), the anti-rollback index bound into the signature, and the
TPM measured-boot path. This is the reference image; the other -prod targets
are narrower cuts of the same recipe for a single capsule, driver, or lane.
Security options
Three choices change what a signed image is trusted to do. make menuconfig
prompts for each; you can also set them by hand in .nonos-config.
Capsule attestation (nonos-stark-attest) has the spawn gate verify a
post-quantum STARK proof that the capsule's measurement is enrolled under the
policy root before it runs. With attestation off, the legacy path is used.
Kernel self-attestation (NONOS_STARK_KERNEL_ATTEST) has the bootloader verify
the kernel's own STARK proof against the enrolled kernel root before the jump.
It is on by default, so a clean build ships the full STARK boot for the kernel
and the capsules alike; set NONOS_STARK_KERNEL_ATTEST := 0 for a build that
only wants signature trust.
The anti-rollback index (NONOS_ROLLBACK_INDEX) is the floor a signed image must
meet. The TPM monotonic counter refuses anything below it, so raising the index
at release time burns older images.
.nonos-config
tools/nonos-config writes .nonos-config at the repo root: plain make
variables, so the build reads them directly and you can edit them by hand.
NONOS_PROFILE := microkernel-full-gui
NONOS_ATTEST := 1
NONOS_STARK_KERNEL_ATTEST := 1
NONOS_ROLLBACK_INDEX := 1
The file is per-developer and is not committed.
Toolchain
The pinned toolchain is in rust-toolchain.toml. make nonos-mk-check-deps
verifies it is installed before a build starts. On macOS, ensure the rustup
toolchain is ahead of any Homebrew rust on PATH.