Ginux, a kernel research project led by Gregory Kurtzer, has shifted from a bootable Rust kernel to a userspace program that supervises Linux workloads. The active version runs as an ordinary process and gives each managed instance an explicit, versioned contract defining which parts of the host system it may use.
The earlier experiment booted directly through UEFI and ran a Rocky Linux 10 userspace. Its source remains preserved in the project repository, but the developer says that research phase is complete. The prototype showed that an AI coding system, directed by an experienced engineer and constrained by tests and architectural gates, could produce a kernel capable of running meaningful Linux userspace. It also exposed the gap between implementing mechanisms and reproducing Linux’s enormous compatibility, hardware and community ecosystem.
The revised design accepts Linux as the host and focuses on mediation. When a managed program makes a system call, Ginux can allow a validated operation, emulate it or deny it according to the instance contract. The aim is to expose only the behavior a particular approved workload needs, rather than promise Linux’s broad application binary interface to every program. Departures from normal Linux behavior are intended to be documented, reviewable and tested.
That smaller contract is also being explored as a boundary for AI agents and other automated programs. An instance could, for example, allow a process tree to inspect its own state and modify one workspace while denying access to unrelated files, devices, network listeners or clock controls. Ginux can record the decisions it makes while the workload runs.
The project is careful not to present that work as a finished security product. Its documentation calls agent containment an active verification target and says capability inventories, adversarial tests, performance costs and escape boundaries still have to be demonstrated. Compatibility claims likewise apply only to named contracts and tested workloads, not to Linux or systemd in general.
Ginux currently supervises native x86-64 programs. Its reference development setup uses an Apple Silicon Mac running a pinned Rocky Linux 10 x86-64 host under QEMU. The real host systemd remains PID 1; Ginux operates as an unprivileged process inside that environment.
Two syscall-control modes reflect different tradeoffs. The default selective mode permits direct execution only when both the instance contract and Ginux’s catalog classify an operation as safe. A paranoid option routes every system call through the userspace dispatcher. The repository includes benchmarking workflows intended to compare those modes with native execution and track whether selected tests remain within defined performance budgets.
The pivot narrows the project’s ambition while making its research question more concrete. Instead of replacing Linux, Ginux now investigates whether a deliberately smaller, auditable compatibility contract can provide useful isolation for tightly defined workloads while retaining the host kernel’s mature foundation.
