Ginux pivots from standalone Rust kernel to contract-based userspace kernel

Ginux is now a userspace kernel

Greg Kurtzer's Ginux project has changed course. After finishing a research phase in which an AI coding agent helped construct a standalone Rust kernel that booted through UEFI and ran a Rocky Linux 10 userspace, development now continues as a userspace kernel. According to the project's GitHub README, which reached the Hacker News front page, Ginux runs as an ordinary Linux process and places an explicit, versioned contract between the workloads it manages and the host kernel. The original bootable kernel's source is permanently preserved on a dedicated branch and tag.

Why the standalone kernel was shelved

The README is candid about the reasoning. The experiment proved that an AI coding agent, steered by an experienced human through architecture, gates and executable tests, could build a new kernel capable of running meaningful Linux userspace, but it also made the limits plain. Linux, the project argues, is more than source code: it is a stable interface, a development process, a global community, vendor and hardware alignment, and decades of compatibility and operational experience. Reimplementing kernel mechanisms does not reproduce that ecosystem, and competing with Linux was never the goal.

The valuable finding was the boundary itself. Linux must preserve a broad userspace ABI, quoting Linus Torvalds' rule that user space must not be broken. Ginux inverts that on purpose: it deliberately and selectively breaks the full Linux ABI guarantee, handing each managed instance only the capabilities and interface behaviour its approved workload actually needs. Every departure is intended to be explicit, versioned, reviewable and tested rather than an accidental incompatibility. The pivot also reflects the development method: the prototype was evidence, not an obligation to become a product.

How the dispatcher works

Ginux runs beneath the host's real systemd, which stays PID 1, while Ginux itself is a trusted ordinary process. It supervises native x86-64 programs and intercepts managed syscalls before they take effect on the host. A central dispatcher resolves the instance contract and picks one of three outcomes: emulate the request entirely from Ginux-owned state; mediate it by validating and translating the call into a narrow, Ginux-owned host operation; or deny it, returning a configured Linux-compatible error or terminating the task.

The current implementation, per the README, includes a security-focused x86-64 interpreter and a ptrace-based native backend, strict versioned instance configuration and lifecycle handling, a digest-pinned OCI root with an immutable filesystem index and bounded overlay, Ginux-owned process, credential, signal, synchronization, timer and event models, virtual devices with explicit assignment and revocation, and bounded virtual views of /proc, /sys, cgroup v2, mounts and namespaces. A host-shared network backend remains syscall-mediated.

There is one named compatibility baseline: a pinned Rocky Linux 10 systemd image that reaches multi-user.target, authenticates a managed console login, updates through Rocky's enabled repositories and shuts down cleanly. The project stresses this is a named baseline, not a claim of full Linux or systemd compatibility; compatibility claims apply only to named contracts backed by executable evidence.

Containment for AI agents

A second research thread tests Ginux as a containment boundary for AI agents and other automated software that can run commands, modify files, open network connections and spawn processes. Instead of giving an agent the host's complete ABI, an operator can run its process tree inside an instance whose contract exposes only what the task requires, for example reading the clock, inspecting its own processes and writing to one assigned workspace, while denying clock changes, host filesystem access, unapproved network listeners and unrelated devices. Contract decisions can then be audited. The README is explicit that this is an active verification target, not a production-grade sandbox: policy configuration, adversarial tests, performance costs and escape boundaries must be demonstrated through the project's gates first.

Where it sits among existing systems

The README situates Ginux in established territory. Linux seccomp filters the existing ABI rather than defining a virtual contract. User-Mode Linux reuses a complete kernel over virtual hardware. gVisor is described as a closely related userspace application kernel with different compatibility and performance goals. Gramine packages applications with a library OS, and Proxos makes trust placement configurable across the syscall interface. Ginux's distinguishing emphasis is treating the declared contract, virtual state, devices, resources and lifecycle as a single reviewable boundary. Development happens on macOS arm64, where QEMU boots a pinned Rocky Linux 10 x86-64 host that runs Ginux as an unprivileged process.

Why it matters

The pivot is notable on two fronts. First, it illustrates how AI-assisted development changes prototyping economics: a bootable kernel was cheap enough to build, learn from and discard, with the real value being the architectural lesson carried forward. Second, the contract-first isolation model targets a genuine gap between seccomp-style filtering and full virtual machines, and it is especially relevant for running semi-trusted AI agents, where operators need a boundary they can read, version and audit rather than an implicit promise of full compatibility.