Ginux sits between the host kernel and managed Rocky Linux instances, mediating syscalls according to a versioned contract.
GREG KURTZER'S GINUX SHIFTS TO USERSAPCE KERNEL
*Ginux, once a bootable Rust kernel, now runs as an ordinary Linux process. The pivot reflects AI‑driven prototyping limits and a new focus on explicit, versioned syscall contracts.*
Greg Kurtzer’s Ginux project has taken a decisive turn. After 1,854 commits and a bootable Rust kernel that launched Rocky Linux 10 directly via UEFI, the codebase now lives as an ordinary Linux process. The shift from a standalone kernel to a userspace kernel reflects lessons learned from an AI‑driven prototype that could assemble a functional kernel but could not replicate Linux’s broader ecosystem. The new architecture places an explicit, versioned contract between managed workloads and the host kernel, allowing selective emulation, mediation or denial of syscalls. This approach promises tighter security boundaries while acknowledging that Linux’s stability cannot be recreated from scratch.
What is Ginux now?
Ginux runs as a trusted host process under the real PID 1 systemd. It sits above the host Linux kernel and presents a configurable contract to each managed instance. The contract defines virtual processes, descriptors, devices and resource views. When a managed syscall reaches Ginux, the dispatcher consults the contract and either emulates the call, mediates it through a narrow host operation, or denies it with a Linux‑compatible error. The current build includes a security‑focused x86‑64 interpreter, a ptrace backend, immutable OCI root, bounded overlays, and virtual /proc, /sys, cgroup v2, mount and namespace views. A pinned Rocky Linux 10 systemd baseline reaches multi‑user.target, authenticates a console login, updates via Rocky repositories and shuts down cleanly.
How does Ginux enforce a limited ABI?
Linux guarantees a stable userspace ABI; Ginux deliberately breaks that guarantee in a controlled way. Each instance contract lists allowed syscalls, ioctls, filesystem paths and device assignments. On entry, Ginux decides among three outcomes: Emulate – answer entirely from its own state; Mediate – validate, translate and perform a narrow host operation; Deny – return a configured error or terminate the task. Every deviation from the full Linux ABI is explicit, versioned, reviewable and tested. This design lets operators expose only the capabilities a workload needs, reducing attack surface while preserving predictable behavior.
Why did the project pivot from a bootable kernel?
The standalone‑kernel experiment proved an AI coding agent, guided by an experienced human, could assemble a kernel that runs meaningful Linux userspace. It also exposed the limits of that approach. Linux is more than source code: it is a stable interface, a global development process, vendor and hardware alignment, and decades of compatibility. Re‑implementing kernel mechanisms cannot reproduce that ecosystem. The experiment showed the value of a boundary that isolates workloads without trying to replace Linux. Consequently, development shifted to a userspace kernel that leverages the host’s stable ABI while offering a smaller, explicit contract.
Can Ginux sandbox AI agents?
Ginux is being tested as a containment boundary for AI agents and other automated software. Instead of granting an agent the host’s full Linux ABI, an operator can place its process tree inside an instance whose contract exposes only required operations and virtual resources. A sample contract might allow reading the time, inspecting its own processes and modifying an assigned workspace, while denying clock changes, host filesystem access, unapproved network listeners and unrelated devices. The system can audit contract decisions in real time. The research goal is a reviewable boundary spanning syscalls, ioctls, filesystems, devices, networking and virtual /proc and /sys state, but the project does not claim production‑grade sandbox status.
Frequently asked questions
What was Ginux's original design?
Ginux began as an independent Rust kernel that booted directly through UEFI and ran a Rocky Linux 10 userspace.
How does Ginux decide what to do with a syscall?
Ginux consults the instance contract and either emulates the call, mediates it through a validated host operation, or denies it with a Linux‑compatible error.
Is Ginux ready as a production sandbox for AI agents?
The project is testing Ginux as a containment boundary for AI agents but does not claim it is currently production‑grade.
Ginux’s evolution underscores a pragmatic view of kernel innovation: AI can spin up disposable prototypes, but lasting value comes from augmenting, not supplanting, the existing Linux foundation. By exposing a narrow, contract‑driven ABI, Ginux offers a fresh tool for isolating workloads and testing AI agents, while keeping the host kernel intact. The project remains experimental, but its architecture may influence future containment strategies as the industry wrestles with increasingly autonomous software.
Sources: Hacker News, https://github.com/gmkurtzer/ginux