FAQ / System Queries

No. ITISYOU OS is an independent x86_64 kernel written in Rust (no_std). It contains no Linux kernel code at runtime and no GNU userland. It boots through the rust-osdev bootloader crate, not through a Linux boot chain.

No, and it does not claim to be. Linux is a mature, production-proven kernel ecosystem. ITISYOU OS is a research project testing different hypotheses — explicit authority boundaries, evidence-gated development, recoverability as architecture — for a constrained personal-computing target.

The project is experimental at v1.0.0, milestone “V1.0 — Experimental Personal OS (VM-verified)”. Verified in QEMU so far: the V0.1 kernel foundation; V0.2 Ring 3 userspace; V0.3 per-process isolation, concurrent processes and strict process isolation; V0.4 preemptive multitasking plus persistent storage; V0.5 a real graphical desktop (ownership-isolated windows, GUI syscalls, PS/2 keyboard + mouse); V0.6 hardware foundations (device model + UHCI HID + AC97 + unified input); V0.7 platform controls: capability default deny, sandboxed fs visibility, service supervision, manifest-launch apps, and atomic update+rollback with reboot recovery; and V0.8 networking (e1000 with ARP/IPv4/ICMP/UDP/DNS and port-scoped socket capabilities), Ed25519 package signatures, capability-scoped userspace filesystem writes, APIC/MSI-X interrupt delivery, xHCI enumeration and HID input, a hash-chained audit trail that survives reboots, and SMEP/SMAP/UMIP; and V0.9 (released as v0.9.0): TCP from Ring 3 verified against the host’s own TCP stack, a DHCP client, IPv6 foundations, the I/O APIC cutover with the 8259 PIC retired, ACPI power-off, a package-signing key hierarchy under an offline root, audit anchoring off the disk, and guard pages under the kernel’s RSP0 (Ring 3 interrupt) and double-fault stacks; and V0.10 (released as v0.10.0): background programs that keep running while the console is busy, a process tree, /sbin/init as pid 1 from /etc/init.conf, a Ring 3 shell, program arguments, filesystem space reclamation, and Ring 3 desktop apps with click-to-focus and routed input. The latest release is v1.0.0; the download page serves the v1.0.0 boot images for virtual machines. v1.0.0 also carries the V0.11 AI-Native System Layer (folded in — it was never tagged on its own): a read-only system view served only to a process the console grants it, a small diagnostic model trained at build time from synthetic scenarios (its accuracy equals a one-rule baseline), the inference service inferd in Ring 3, a diagnostic agent with no authority to act, kernel-checked proposals, approval only at the console, and two actions the kernel executes, verifies and rolls back. V1.0 itself is reliability and security: IPC authority scoped to named channels, a Ring 3 syscall fuzzer and a decoder mutation fuzzer that found real panics, long-use leak accounting, contained CPU exceptions, and a whole-attack-surface adversarial review (37 findings, each checked by an independent refuter) that fixed every high-severity defect and 18 findings in all, with seven documented accepted fail-closed availability limits remaining. v1.0.0 is verified locally — not by GitHub CI (the repository is private with no Actions minutes), so it carries no CI run id — by the full local QEMU matrix, two-clean-build reproducibility, and boot-tests; the CI-dependent acceptance rows are recorded BLOCKED on the CI window. The build page shows the live evidence-backed module table.

No — please don’t. The OS runs exclusively inside QEMU (BIOS and UEFI via OVMF) with project-generated disposable disk images. Physical-hardware boot is intentionally out of scope and untested, and the project’s own safety rules forbid pointing it at a real disk. Real hardware appears on the roadmap only for explicitly approved sacrificial devices, much later.

A QEMU-only execution target: x86_64 BIOS/UEFI on QEMU’s pc machine, single CPU, NVMe storage, PS/2 plus UHCI and xHCI USB keyboard input, AC97 audio output and an e1000 network adapter, as currently verified. It does not claim general desktop/laptop hardware coverage.

The kernel targets memory-safety discipline, testability and a minimal trusted computing base. Rust (no_std, x86_64-unknown-none) removes whole classes of memory errors by construction, keeps unsafe blocks localized and documented, and lets pure kernel logic be unit-tested on the host — the same code that runs in QEMU. See ADR-0001 in the repository.

A status becomes Verified only when an actual automated run proves it: the QEMU harness requires every expected boot-stage marker, an in-kernel selftest summary with zero failures, and a deterministic exit code — with serial logs and JSON results retained as evidence. “Implemented” (code exists) and “Verified” (evidence exists) are never interchangeable.

The rust-osdev bootloader hands the kernel a typed BootInfo (memory map, physical-memory mapping offset, framebuffer, RSDP). The kernel then walks a fixed stage contract, B000 through B150, emitting one machine-parseable serial marker per stage — the same contract the test harness asserts.

An AI layer may reason about the system and propose actions, but it never executes privileged kernel operations directly. Proposals flow through a deterministic pipeline — policy engine, risk/permission evaluation, user approval, a narrow privileged service — followed by verification, audit and rollback. Released images before v1.0.0 contain no AI component; the principle came first because it constrains kernel interface design.

v1.0.0 ships the first agent, which works this way. It reads an approved, read-only view of system state and asks a small model running in Ring 3 for a diagnosis. It may then file a proposal, which the kernel accepts only if it matches what the kernel knows itself: the shipped model, the view it served that agent, its own recomputation of the diagnosis and the current state of the system. Only an operator at the kernel console can approve it; the kernel then runs the action, checks that it worked and rolls it back if not. There are two actions, resume the scheduler and retry a failed service, and the agent cannot perform either itself.

The platform is not production hardened, but V0.7, V0.8 and V0.9 moved core trust controls into tested enforcement: default-deny capabilities as revocable handles re-checked on every use, filesystem sandboxing by normalized prefixes, deterministic service mediation, auditable denials, atomic update/rollback/recovery, crash containment, Ed25519 package authenticity, a hash-chained audit trail that survives reboots, and SMEP/SMAP/UMIP enforcing kernel/user separation in the CPU. v0.9.0 narrowed the gaps v0.8.1 carried — a published development signing key with no rotation or revocation, an audit chain blind to a whole-file rewrite, line IRQs on the legacy PIC — with an offline-root key hierarchy (scoped certificates, signed revocation), audit anchoring off the disk (an explicit command), and the I/O APIC cutover; it added TCP, DHCP and IPv6 foundations as new attack surface, guard pages under the kernel’s RSP0 (Ring 3 interrupt) and double-fault stacks, and a fix for a kernel panic any program could trigger with a null pointer and a zero length. v0.10.0 put the syscall stack and the kernel task stacks on guard pages too, and fixed a denial of service in every earlier release (the kernel wrote through user pages the program could not write). Found after v0.10.0 and fixed in v1.0.0: three audit-trail defects present since v0.8.0, disclosed on the security page. v1.0.0 also ran a whole-attack-surface adversarial review (37 findings, each checked by an independent refuter) that fixed every high-severity defect and 18 findings in all — unhandled CPU exceptions a Ring 3 program could turn into a kernel panic, a package launched outside its signing key’s scope, an ICMP responder a remote ping flood could recurse into the stack guard — with seven documented, accepted, fail-closed availability limits remaining; and it is verified locally, not by GitHub CI (private repo, no Actions minutes). Remaining gaps, stated plainly: the boot image itself is not authenticated, so whoever can rewrite it can replace the trust root; there is no persistent anti-rollback floor for revocation lists across boots; TCP initial sequence numbers are not keyed; and there is no Secure Boot or measured boot. The AI layer’s own limits: its model is trained on synthetic data, IPC carries no sender identity, and proposals are held only in memory.

The source repository is private. It has been made public only briefly, so that GitHub CI could run for releases, and the owner decides when it opens. Published releases, their checksums and the engineering evidence are on this site: the releases and download pages, the engineering documentation, the status data and the development ledger.

Not at present: the source repository is private. The engineering groundwork is public here: architecture, security model, testing strategy, roadmap and known limitations.