ITISYOU_OS
PRE-ALPHA

Download ITISYOU OS

Experimental, pre-alpha boot images for x86_64 virtual machines. They exist so the claims on this site can be checked by booting the same bytes the release gate booted — not for daily use.

Physical-Hardware Warning

ITISYOU OS is an experimental, pre-alpha research kernel. It is developed and verified exclusively inside QEMU with project-generated disposable disk images. Do not install it on physical hardware, point it at a real disk, or expect it to preserve data. There are no production builds.

DO NOT BOOT ON PHYSICAL HARDWARE

These images have been tested only inside QEMU. They have never been booted on a physical machine and no physical hardware is supported. Never write them to a real disk or USB stick you care about, never point them at an existing disk, and never install them on a computer you use. If you boot them anywhere other than a virtual machine, you do so entirely at your own risk.

v1.0.0

EXPERIMENTAL EXPERIMENTAL
Version
1.0.0
Architecture
x86_64
Maturity
Experimental / pre-alpha
Commit
5593e5020670b983d34f5447c5103b19fc638f16
Built by
Local build on Windows 11 (x86_64), pinned nightly-2026-08-01. GitHub Actions was unavailable (the repository is private with no Actions minutes), so these are locally-built bytes, not a CI build. The build is deterministic: two full-clean builds on the same host (cargo clean of target/ and target-user/ between them) produced these exact digests. A Linux build (as CI produces) yields different bytes — Rust embeds the source path in panic locations, and the path separators differ (kernel\src on Windows, kernel/src on Linux) — so the CI-built SHA-256 will differ and will be added when the CI window opens.
Built at
2026-09-14T10:05:36Z

NOTICE

v1.0.0 supersedes v0.10.0. It carries the V0.11 AI-native layer (never tagged on its own) and V1.0's reliability and security work: IPC channel scoping, a Ring 3 syscall fuzzer and a decoder mutation fuzzer, long-use leak accounting, contained CPU exceptions, and a whole-attack-surface adversarial review that fixed every high-severity defect and 18 findings in all. Seven medium findings are documented, accepted, fail-closed availability limits a capability holder or a hostile disk can impose on this single-user VM (see docs/KNOWN_LIMITATIONS.md). VERIFICATION: this release is verified locally, not by GitHub CI — the full local QEMU matrix (74 legs), two-clean-build reproducibility, and UEFI+BIOS boot-tests of these exact bytes; there is no CI run id yet. Earlier releases stay downloadable at /downloads/v0.10.0/, /downloads/v0.9.0/ and /downloads/v0.8.1/, each with its own SHA256SUMS.txt.

01 // FILES

Checksum list: SHA256SUMS.txt. These are raw disk images (.img), not ISO files: the UEFI image carries a GPT with an EFI system partition, the BIOS image an MBR with the bootloader's BIOS stages.

02 // VERIFY BEFORE BOOTING

// Linux / macOS

sha256sum -c SHA256SUMS.txt

// Windows PowerShell

Get-FileHash .\itisyou-os-1.0.0-x86_64-uefi.img -Algorithm SHA256

The digest must equal the one above, character for character. Anything else is not the released image. Verify before booting: without a writable variable store, UEFI firmware writes an NvVars file into the image's EFI partition on every boot, so a booted copy no longer matches. The snapshot=on in the commands below keeps the downloaded file unchanged.

03 // REPRODUCIBILITY

Reproducible on the build host: two full-clean builds (target/ and target-user/ both removed between them, no shared cache for the kernel or the user programs) produced identical digests for every image. image-builder removes the non-determinism sources found in v0.8.1 (random GPT GUIDs; the link time and CodeView GUID in the embedded UEFI loader) and the user-program archive is a deterministic ustar. This release is Windows-built and reproducible on Windows; a Linux/CI build produces different bytes (path separators in panic-location strings) and is pending the CI window.

04 // BOOT IN QEMU

The system console is the first serial port; the graphical window shows the OS-rendered desktop. Type help at the console prompt. Devices are the ones the release gate tests: QEMU's pc machine, 256 MiB, a CPU with SMEP/SMAP/UMIP.

// UEFI (needs OVMF firmware; path varies by distribution)

qemu-system-x86_64 -m 256M -cpu qemu64,+smep,+smap,+umip \

  -drive if=pflash,format=raw,readonly=on,file=/usr/share/OVMF/OVMF_CODE_4M.fd \

  -drive format=raw,file=itisyou-os-1.0.0-x86_64-uefi.img,snapshot=on -serial mon:stdio

// BIOS (SeaBIOS, QEMU's default firmware)

qemu-system-x86_64 -m 256M -cpu qemu64,+smep,+smap,+umip \

  -drive format=raw,file=itisyou-os-1.0.0-x86_64-bios.img,snapshot=on -serial mon:stdio

// optional: persistent /data store (a blank 16 MiB disk, formatted on first write)

qemu-img create -f raw data.img 16M

  ... -drive file=data.img,if=none,format=raw,id=nvme0 -device nvme,serial=itisyou1,drive=nvme0

// optional: let the console's `shutdown` command exit QEMU

  ... -device isa-debug-exit,iobase=0xf4,iosize=0x04

// optional: network (QEMU user-mode; static 10.0.2.15/24 via 10.0.2.2 at boot)

  ... -netdev user,id=net0 -device e1000,netdev=net0

On Windows hosts QEMU's stdio console can stall on input; use -serial tcp:127.0.0.1:4555,server=on,wait=on and connect a raw TCP client (for example PuTTY in raw mode) instead. The exact command lines the release gate ran are recorded in its evidence. DNS through QEMU's user-mode forwarder failed on the test host, so DNS is verified only against the test harness's own network peer. What each release can do on the network is under “What this release is” below.

05 // TESTED ENVIRONMENTS

Environments these exact images were booted in
TestFirmwareEmulatorHostResult
Release boot test (these exact images) UEFI (OVMF, QEMU-bundled edk2) and BIOS (SeaBIOS) QEMU 11.1.0 Windows 11 (x86_64) Passed — UEFI + BIOS console boot reporting itisyou-os 1.0.0 with /sbin/init as pid 1 and the pinned diagnostic model, two-boot persistence on an NVMe data disk, and ping over QEMU user-mode networking; the images are unchanged afterwards.
Full local QEMU matrix (74 legs) + host tests, clippy, secret scan BIOS (SeaBIOS) and UEFI (OVMF) QEMU 11.1.0 Windows 11 (x86_64) Passed — scripts/verify.ps1 on the release commit; the two most timing-sensitive legs flake only under concurrent host load and pass in isolation. GitHub CI (the independent second-host run) is pending the CI window.

Supported: QEMU x86_64 with the devices above. Untested: other hypervisors (VirtualBox, VMware, Hyper-V) — they may work, but nothing here claims so. Unsupported: every physical machine.

06 // WHAT THIS RELEASE IS

Everything through V0.10 (TCP from Ring 3, DHCP, IPv6 foundations, the I/O APIC cutover, ACPI power-off, an offline-root package-signing hierarchy, audit anchoring, a userspace init and process tree, the desktop) plus the V0.11 AI-native layer (system view, pinned diagnostic model, inferd, the proposal→approve→execute→verify→rollback path) plus V1.0: IPC channel scoping (ADR-0025), the seeded Ring 3 syscall fuzzer, the kernel-core decoder mutation fuzzer, long-use leak accounting, contained CPU exceptions with the user FPU off, and the whole-attack-surface review’s fixes (SEC1/NET1/FS1/USB1/GUI1/CAP1). The images are raw disk images — GPT + EFI system partition for UEFI, MBR for BIOS — that boot in QEMU as documented.

All releases

07 // KNOWN LIMITATIONS

  • − Verified locally, not by GitHub CI: the repository is private with no Actions minutes, so there is no CI run id and no independent second-host CI build for this release. It is verified by the full local QEMU matrix (74 legs), two-clean-build reproducibility on the build host, boot-tests, and the adversarial review. CI evidence will be added when the CI window opens.
  • − Experimental and VM-only: physical hardware is explicitly unsupported and untested. Tested in QEMU (x86_64, SeaBIOS and OVMF); no other environment is claimed.
  • − The kernel is not preemptible: background programs run in bounded slices at audited points, and wait while a syscall or a storage/irq/xhciwait command runs.
  • − Seven medium findings from the V1.0 review are accepted, not fixed: availability limits a capability holder or a hostile disk can impose on this single-user VM (audit-window rotation, store/TCP-slot exhaustion, a scheduler stall) — each fails closed and is operator-recoverable; see docs/KNOWN_LIMITATIONS.md.
  • − The AI diagnostic model is trained on synthetic scenarios: its accuracy equals a one-rule baseline, so it shows the designed cases are separable, not that it diagnoses real machines. Three conditions, two reversible actions, all console-approved.
  • − One CPU; software rendering only; no suspend/resume; the boot image itself is not authenticated.
Full list

08 // PREVIOUS RELEASES

Earlier release images stay downloadable, unchanged: once a release is tagged, its published files are never replaced. They are older systems with more limits than the release above; the same rules apply — verify the SHA-256 before booting, and virtual machines only.

v0.10.0

V0.10 — Userspace System · 2026-09-13

V0.10 — Userspace System, on top of everything in V0.9 (TCP from Ring 3, DHCP, IPv6 foundations, the I/O APIC cutover, ACPI power-off, an offline-root package-signing hierarchy, audit anchoring): always-on co-scheduling at audited safe points (sched reports what the background got); a process tree with parent-only wait, wait_nohang, sleep, orphans, ps and kill; /sbin/init as pid 1 from /etc/init.conf, restarted by the kernel; a kernel-checked supervisor report (svc_report); program arguments; a Ring 3 shell (rsh at the console); ITFS space reclamation; Ring 3 desktop apps (desktop /bin/gui-echo) with click-to-focus and routed input; line-atomic Ring 3 output with the kernel’s marker prefix rewritten (not unforgeable after all: see the limitations); DF/AC cleared on every kernel entry; guard pages under the RSP0, double-fault, syscall and kernel-task stacks; user buffers the kernel writes must be writable by the program.

Built by GitHub Actions run 34782271250 (ubuntu-24.04, pinned nightly-2026-08-01), commit c936bc78379bbeb379f4f3b90186242c3aee4fb7

Checksum list: SHA256SUMS.txt.

v0.10.0 was the CI-built, reproducible release before v1.0.0. Superseded by v1.0.0, which fixes (among others) SEC10-era and V0.11-branch defects it carried; kept downloadable, unchanged, for reference.

  • − The kernel is not preemptible: background programs run in bounded slices at audited points, and wait while a syscall or a storage, irq or xhciwait command runs (measured up to 5 s for xhciwait).
  • − /etc/init.conf is part of the boot image: no persistent configuration, no reload.
  • − The Ring 3 shell has builtins and run — no pipes, redirection, job control or environment; administration stays on the kernel console.
  • − Desktop: one Ring 3 app per desktop session; click-to-focus without drag, resize or close.
  • − TCP is IPv4 only; no congestion control beyond an in-flight cap. The boot image itself is not authenticated.
  • − Found after the release (AUDIT11-001): a saved audit trail verifies only if it was saved once, in the first boot, before the in-memory ring dropped a record; saved by a later boot, or after audit verify, it reads as TAMPERED on the next boot although untouched. Fixed on the V0.11 branch.
  • − Found after the release (SEC11-001, AUDIT11-002): a program holding fs_write can rewrite the audit trail or delete a package’s commit marker through the filesystem syscalls, and a file name with a line break in it makes the kernel print a line that reads as a kernel marker. Also found after the release, by the V0.11 adversarial review (OUT11-002, SEC11-002, AUDIT11-003): a program can still print a genuine kernel marker line by splitting the prefix across the kernel’s 256-byte output chunks; ps prints the path a program passed to spawn, so a line break and a marker in it print as a kernel line; and a crafted multi-megabyte audit trail on the disk panics boot recovery. All fixed on the V0.11 branch.
  • − One CPU; software rendering only; no suspend/resume.

v0.9.0

V0.9 — Transport, Interrupt Cutover & Trust · 2026-09-13

V0.9 — Transport, Interrupt Cutover & Trust, on top of everything in V0.8: Ring 3 processes in per-process address spaces with preemptive scheduling, capability handles enforced at the syscall boundary, a persistent crash-consistent filesystem on NVMe, a compositor with PS/2 and USB input, AC97 audio, an IPv4 stack (ARP/ICMP/UDP/DNS) with capability-scoped sockets, Ed25519-signed packages with atomic update and rollback, a hash-chained audit trail, SMEP/SMAP/UMIP. New in this release: TCP from Ring 3 (connect and listen, with retransmission), a DHCP client (the console’s dhcp command), IPv6 foundations (link-local and SLAAC addresses, neighbour discovery, ICMPv6 echo), the I/O APIC cutover with the 8259 PIC retired, ACPI S5 power-off (poweroff), packages trusted through an offline-root key hierarchy with scoped certificates and signed revocation, audit anchoring off the disk, and guard pages under the kernel’s Ring 3 interrupt (RSP0) and double-fault stacks (not yet the syscall stack).

Built by GitHub Actions run 34760629701 (ubuntu-24.04), commit f06673e00f27c3e5ef3df756a452969464d2b558

Checksum list: SHA256SUMS.txt.

v0.9.0 has a denial of service found after its release and fixed in v0.10.0 (SEC10-001): any program could panic its kernel by pointing cap_list at its own read-only memory.

  • − TCP is IPv4 only: one connection per listen, no congestion control beyond an in-flight cap. IPv6 has no UDP, TCP or Ring 3 sockets.
  • − DHCP runs only on demand (dhcp); at boot the address is the static 10.0.2.15/24.
  • − No userspace init; the console is part of the kernel.
  • − Filesystem: ≤ 12 files, no directories, no space reuse.
  • − The boot image itself is not authenticated; no real package is signed by the release key yet.
  • − Found after the release (SEC10-001): any program can panic the kernel by pointing cap_list at its own read-only memory — the kernel checks that a user buffer is mapped, not that the program may write it. Fixed in v0.10.0.
  • − Found after v0.10.0 (AUDIT11-001, SEC11-001, AUDIT11-002), present since v0.8.0: a saved audit trail reads as TAMPERED once a later boot has saved it; programs holding fs_write can rewrite the trail or a package’s commit marker; and file names with line breaks let the kernel print forged marker lines; a crafted multi-megabyte trail on the disk panics boot recovery (AUDIT11-003). Fixed on the V0.11 branch.
  • − One CPU; software rendering only; no suspend/resume.

v0.8.1

V0.8 — release-integrity closeout · 2026-09-13

V0.8 — Networking, Authenticity & Hardening, as the v0.8.1 closeout: Ring 3 processes in per-process address spaces with preemptive scheduling, capability handles enforced at the syscall boundary, a persistent crash-consistent filesystem on NVMe, a compositor with PS/2 and USB input, AC97 audio, an IPv4 stack (ARP/ICMP/UDP/DNS) with capability-scoped sockets, Ed25519-signed packages with atomic update and rollback, a hash-chained audit trail, SMEP/SMAP/UMIP.

Built by GitHub Actions run 34750316003 (ubuntu-24.04), commit bf32b5337d9503b47bb4cece7d5436a0b1804cca

Checksum list: SHA256SUMS.txt.

The UEFI image first uploaded for v0.8.1 (SHA-256 eb7d566c7fcafd9a4ee672b0ede9b3c3456b9577b799698fd982d2ff72c45571) was replaced before the tag, because a clean rebuild did not reproduce it (it carried its loader’s link time). It boots the same system, but it is not the release and cannot be reproduced.

  • − No TCP, DHCP or IPv6; one static IPv4 address (10.0.2.15/24).
  • − No userspace init; the console is part of the kernel.
  • − Filesystem: ≤ 12 files, no directories, no space reuse.
  • − Package trust root is a published development key.
  • − Found after v0.10.0 (AUDIT11-001, SEC11-001, AUDIT11-002), present since v0.8.0: a saved audit trail reads as TAMPERED once a later boot has saved it; programs holding fs_write can rewrite the trail or a package’s commit marker; and file names with line breaks let the kernel print forged marker lines; a crafted multi-megabyte trail on the disk panics boot recovery (AUDIT11-003). Fixed on the V0.11 branch.
  • − One CPU; software rendering only; no power management.