Greg Kurtzer's Ginux Evolves into a Userspace Kernel
Ginux shifts from a bootable kernel to a userspace supervisor for isolated Linux workloads.
1Transition to Userspace
Ginux has officially pivoted from an independent Rust-based bootable kernel to a configurable userspace kernel. This transition marks the end of its initial research phase, which focused on booting Rocky Linux 10 via UEFI. The project is now permanently preserved on the bootable-kernel branch, shifting focus toward managing isolated Linux process instances.
2Defining the Contract
The core function of Ginux is to place a versioned, explicit contract between managed workloads and the host kernel. Unlike standard Linux environments, Ginux deliberately breaks the full ABI guarantee. It selectively decides whether to emulate, mediate, or deny system calls, ensuring that instances only receive the specific capabilities their workloads require.
3AI-Driven Development
The project utilized AI coding agents directed by human architects to build and test the kernel. This methodology allowed for the creation of disposable, executable prototypes that served as evidence rather than final products. By testing architectural ideas rapidly, the team successfully identified the boundaries of the Linux userspace interface.
4Operational Mechanism
Ginux runs as an ordinary, trusted host process that supervises native x86-64 programs. It intercepts system calls before they reach the host kernel, using a central dispatcher to enforce the instance contract. This approach allows Ginux to maintain a smaller, more secure interface than the broad, stable Linux ABI provides.
5Containment for AI Agents
A primary research goal for Ginux is acting as a containment boundary for AI agents. By restricting an agent's process tree to a specific kernel contract, operators can limit access to filesystems, network listeners, and device drivers. This prevents agents from performing unauthorized actions on the host system during their execution.
6Selective vs Paranoid Modes
Ginux offers two primary syscall control modes: selective and paranoid. Selective mode permits direct host execution for operations classified as safe, while paranoid mode forces every system call through the userspace dispatcher. These configurations allow users to balance performance needs against the strict security requirements of their specific managed workloads.
7Development Environment
The reference environment for Ginux development is macOS arm64, utilizing QEMU TCG to boot a pinned Rocky Linux 10 x86-64 host. Ginux operates as an unprivileged process within this environment. The project provides a comprehensive Makefile suite to manage assets, build images, and execute deterministic tests offline for consistent results.
8Performance Benchmarking
The project maintains a strict performance budget, aiming for a 4% overhead compared to native execution. Developers use the make bench-compare command to validate performance against established baselines. These benchmarks ensure that the mediation layer introduced by Ginux does not impose unacceptable latency on the managed applications during standard operations.
9Instance Lifecycle Management
Users manage instances through a CLI that supports creation, import, and export of self-contained recipes. Instances are contract-locked by default to prevent unauthorized changes. Maintenance windows require an explicit unlock command, which relaxes restrictions while still maintaining the virtual kernel boundary, ensuring that host identity and privileges remain strictly controlled.
10Network and Hook Policy
Ginux allows for granular network configuration, including port forwarding and host network attachment, defined within the instance recipe. Hooks are restricted to mediated instance processes, preventing arbitrary host-context execution. This design ensures that all network interactions and pre-boot configurations remain within the audited, versioned boundary of the instance's specific contract.
11Security and Limitations
Ginux is currently research software and lacks independent security certification. While it provides a robust boundary for syscalls and filesystems, it still relies on the host kernel for critical functions like ELF loading and scheduling. The project explicitly warns that it is not yet ready for production-grade, high-security workloads.
12Future Research Trajectory
The project continues to track its progress through HDAE gates, which document the contract inventory and adversarial test results. By focusing on reproducible boundaries rather than full Linux compatibility, Ginux explores a specific design space for secure, isolated computing. Future development will rely on continued verification of these defined containment boundaries.
Original article: Hacker News — Greg Kurtzer's Ginux Evolves into a Userspace Kernel