NØNOS 0.8.10-alpha (test pre-release)

NØNOS 0.8.10-alpha (test pre-release)

This is a test pre-release. We are publishing the image so the community
can boot it, verify it against its checksums and attestation, and report what
happens on real machines and in the virtualizers they actually use. It is not
a finished system and nothing below is a guarantee. The whole point of this
build is to gather boot reports before the beta line opens.

We are targeting a beta within roughly 30 days. Every boot report, especially
the ones where something breaks, moves that beta forward.

If you read one thing: boot it, watch the serial log, and tell us where it
went. A failed boot with a serial capture is worth more to us than a quiet
success.

---

What NØNOS is, so the rest reads clearly

NØNOS is a microkernel. The privileged kernel is deliberately small: memory,
scheduling, the capability boundary, and the trap path in and out of user
mode. Everything else, the drivers, the entire network stack, the window
system, and the applications, runs as a user-mode "capsule" at CPL=3 with no
ambient authority. A capsule receives only the capabilities it is granted, and
it is granted nothing it cannot prove it is entitled to.

"Prove" is literal. Each capsule ships with a zero-knowledge attestation proof
(Groth16 over the BLS12-381 curve: a 192-byte proof over 7 public inputs).
When the kernel spawns a capsule it re-verifies that proof against a verifying
key fixed at build time, before it maps the capsule or grants a single
capability. The verifying key for this image has the SHA-256 prefix
6cd2015037ea6181 and comes from a five-contributor trusted-setup ceremony.
The check runs at every spawn, not once at install.

Underneath sits ordinary verified boot. UEFI hands control to our loader,
itself a UEFI application; the loader verifies the kernel image (Ed25519
signature over a BLAKE3 hash) before jumping into it, and carries forward a
measured record of what it loaded. The kernel then becomes the root of the
capsule attestation above. The trust argument is a chain: firmware to loader,
loader to kernel, kernel to every capsule, each link checked before the next
runs.

Memory isolation is by address space, not by trust. The kernel lives in the
upper half and reaches physical memory through a single direct map; user
capsules live in the lower half in their own ASIDs. The kernel never switches
to a capsule's page tables to read its memory; it walks the direct map with
bounds checks. None of this is a claim of correctness. It is a description of
the design you are testing.

---

What changed since 0.8.9-alpha

• Boots on VirtualBox. VirtualBox's default virtual CPU does not expose
  1 GiB pages (CPUID.80000001H:EDX[26], PDPE1GB). The loader had mapped the
  low identity range and the kernel direct map with 1 GiB hugepages, so the
  first walk into that range, the Local APIC write at physical 0xFEE00000,
  raised a reserved-bit page fault and the kernel stalled at APIC init. The
  loader now detects 1 GiB-page support and falls back to 2 MiB pages where it
  is absent, keeping the 1 GiB fast path on CPUs that have it (QEMU, most bare
  metal).
• Renders on a generic UEFI framebuffer. The loader hands the kernel the
  framebuffer it latched at GOP init, rather than re-querying GOP after
  exit_boot_services, which had dropped the linear framebuffer. The desktop
  composes on a plain framebuffer with no virtio-gpu, which is the path real
  hardware takes.
• Full hardware-driver set. The image now embeds every production driver
  capsule (NVMe, AHCI, e1000, RTL8139/8169, iwlwifi, HD Audio, USB MSC,
  I2C-HID) so matching devices have a chance to bind on real hardware. They are
  present and attested; they have not been exercised against their devices yet.
• Boot presentation. A continuous verified-boot splash with the live
  attestation log (BLAKE3, Ed25519, anti-rollback, Groth16) replaces the raw
  kernel console; the desktop shell drops the redundant left dock and keeps the
  bottom dock; the firmware-setup panels were enriched (CPU, memory, security,
  and a 1 GiB-page / paging-leaf readout reflecting this release's fix).

---

What we have tested, and what we have not

Tested:

• Reproducible build from the tagged commit.
• Boot to the desktop under QEMU with OVMF.
• Boot to the desktop under VirtualBox with EFI firmware, on a generic UEFI
  framebuffer.

Not tested, and therefore not claimed:

• Bare-metal boot. The two things that historically blocked it, the display
  path and the 1 GiB-page assumption, are addressed here, which is why we ask
  you to try it. We have not booted a physical machine ourselves. That report
  is the most valuable one you can send.
• Input under VirtualBox. Pointer motion is tracked, but keyboard delivery
  and click-to-act (window close, settings, wallpaper switch) are not yet
  reliable on the VirtualBox USB-HID path. We are actively debugging this; if
  you can report which interactions do and do not respond, that helps.
• VMware, Hyper-V, other hypervisors. Untested, not unsupported.
• The hardware driver capsules against real devices. Built and attested,
  not yet exercised on silicon.

---

Running it

NØNOS requires a UEFI host. The image is a hybrid UEFI ISO; the same file boots
from a virtual optical drive and, written to a USB stick, from a physical one.

QEMU

Bundled script (finds OVMF, picks KVM on Linux or HVF on macOS):

chmod +x run-nonos.sh
./run-nonos.sh nonos-0.8.10-alpha.iso

Manual, with every flag visible:

qemu-system-x86_64 -m 2G -machine q35 -smp 2 \
  -cdrom nonos-0.8.10-alpha.iso \
  -drive if=pflash,format=raw,readonly=on,file=/path/to/edk2-x86_64-code.fd \
  -drive if=pflash,format=raw,file=/path/to/edk2-x86_64-vars.fd \
  -device virtio-vga,xres=1024,yres=768 -device qemu-xhci \
  -device virtio-rng-pci -serial stdio

-serial stdio puts the boot log in your terminal, which is what you want for
a report. OVMF ships as edk2-ovmf on most Linux distributions, and with QEMU
on macOS via Homebrew.

VirtualBox

VirtualBox supplies its own UEFI firmware, so no OVMF files are needed. Create
the VM from the GUI (Type: Other / Unknown 64-bit, EFI enabled), or with
VBoxManage:

VM=NONOS
VBoxManage createvm --name "$VM" --ostype Linux_64 --register
VBoxManage modifyvm "$VM" --memory 2048 --cpus 1 --firmware efi \
    --graphicscontroller vboxvga --vram 64 \
    --mouse usbtablet --keyboard usb \
    --uart1 0x3f8 4 --uartmode1 file "$HOME/nonos-serial.log"
VBoxManage storagectl "$VM" --name SATA --add sata --controller IntelAhci
VBoxManage storageattach "$VM" --storagectl SATA --port 0 --device 0 \
    --type dvddrive --medium nonos-0.8.10-alpha.iso
VBoxManage startvm "$VM"

The --uart1 lines write the boot serial to ~/nonos-serial.log, which is the
easiest way to capture a report. Settings that matter:

Setting	Value	Why
Firmware	EFI (enabled)	NØNOS is UEFI only
Memory	2048 MB	the full capsule set needs headroom
CPUs	1 is fine	SMP works; 1 is simplest to debug
Graphics	VBoxVGA (VMSVGA also boots)	both expose a UEFI framebuffer
Video memory	64 MB	comfortable at the boot resolution
Storage	SATA (AHCI), ISO as a DVD	the loader boots from it
Pointing	USB tablet	absolute cursor (input still WIP)
Keyboard	USB	(delivery still WIP, see above)
Serial	port 1, file mode	captures the boot log for reports

If the VM lands on the EFI shell, type exit, open the Boot Manager, and pick
the DVD; or from the shell run fs0:\EFI\Boot\BOOTX64.EFI.

Reading the serial log

A healthy boot moves through these markers, roughly in order:

[NONOS] Kernel entry
[NONOS] ACPI tables parsed
[APIC] Local APIC enabled
[VM-INIT] LAPIC rebased to UC kernel mapping
[VM-INIT] low half cleared
[NONOS] Core ready
[UKERNEL] Entering userspace
[COMPOSITOR] capsule spawned
[BOOT-SPLASH] capsule spawned
... driver and net capsules ...
[INIT] Capsules spawned

Where it stops is the single most useful fact in a report. A stop at [APIC]
points at paging or interrupts; a stop after Entering userspace points at a
capsule or the display; a [TRAP ...] line with a cr2= address is a fault,
and the address tells us where.

---

Verifying the download

Every binary here is checksummed, and the build is attested. Confirm the image
is the one we built before you trust it:

sha256sum -c SHA256SUMS
b3sum -c BLAKE3SUMS

ATTESTATION.json records, for this exact build: the kernel commit, per-file
BLAKE3 and SHA-256 hashes, the Groth16 / BLS12-381 scheme (192-byte proofs,
7 public inputs), the verifying-key prefix 6cd2015037ea6181, the 59 capsules
covered by the policy root, the 56 embedded in this profile, and 0 failures.
The running kernel re-checks these proofs itself at every spawn; the file lets
you confirm the chain before you ever boot.

---

How to send a report that helps

1. Host: machine or VM, CPU, firmware, and the exact settings you used.
2. Outcome: did it reach the desktop, and if not, the last serial line.
3. The serial log, attached or pasted. This is the important one.
4. A photo or screenshot if the screen showed something the log did not.

Open an issue on the repository or reply on the release thread. Failed boots
are not noise; they are the map.

---

Scope and honest limits

• This is a test pre-release for verification and feedback. It is not a
  daily driver and not a place for data you care about.
• Input under VirtualBox (keyboard, clicks) is a work in progress.
• Anti-rollback wants a TPM for a persistent floor; without one the
  measured-boot floor is per session.
• The hardware drivers are present but unproven against real devices.
• An external security review is being arranged. Until it lands, treat every
  security property described here as a design intent under test.

License

GNU AGPL-3.0.