Greg Kurtzer's Ginux Evolves into a Userspace Kernel
Ginux shifts from a standalone kernel to a configurable userspace supervisor for isolated Linux workloads.
1Transition to Userspace
Ginux has officially pivoted from an independent Rust-based kernel that booted via UEFI to a userspace kernel. This new architecture runs as a standard Linux process. The original standalone research phase is now permanently preserved on the bootable-kernel branch, marking a shift toward more flexible, process-based isolation for managed workloads.
2Defining the Contract
The core innovation of Ginux is the explicit, versioned contract established between managed workloads and the host kernel. Unlike traditional Linux environments that prioritize broad compatibility, Ginux deliberately restricts the full Linux ABI. It selectively decides whether to emulate, mediate, or deny system calls before they ever reach the host.
3AI-Driven Development Method
The project utilized AI coding agents directed by human architects to build and test kernel mechanisms. This methodology allowed for the rapid creation of disposable, executable prototypes. By treating code as evidence rather than a final product, the team successfully identified the precise boundaries where Linux interface guarantees can be safely constrained.
4Selective Syscall Mediation
Ginux operates using two primary modes: selective and paranoid. In selective mode, the system permits direct host execution only for operations classified as safe. Paranoid mode forces every system call through the userspace dispatcher. This mechanism ensures that instances receive only the specific capabilities and interface behaviors required for their tasks.
5Agent Containment Strategy
A primary research goal is using Ginux as a containment boundary for AI agents. By placing an agent's process tree inside a restricted instance, operators can limit access to filesystems, network listeners, and device drivers. This prevents automated software from accessing host resources that are not explicitly defined in the contract.
6Technical Implementation Details
The reference development environment utilizes macOS arm64 running QEMU TCG. This setup boots a pinned Rocky Linux 10 x86-64 host where Ginux executes as an unprivileged process. The host systemd remains the real PID 1, while Ginux manages virtualized instances that maintain their own internal systemd as a virtual PID 1.
7Reproducible Performance Testing
The project emphasizes deterministic performance through a suite of Makefile targets. Benchmarks compare native execution against selective and paranoid Ginux modes. The system enforces a 4% performance overhead budget, ensuring that the mediation layer remains efficient. These tests are recorded in the hdae/gates-todo/9-systemd-baseline.md documentation for full transparency.
8Instance Management Workflow
Users manage instances through a CLI that supports creation, import, and export of self-contained recipes. Commands like ginux create and ginux import allow for atomic configuration changes. The system uses persistent overlays, meaning cached images and instance states remain available across reboots unless the user performs an explicit destructive reset.
9Contract-Locked Security
Instances are contract-locked by default to prevent unauthorized modifications. For maintenance, users must stop the instance and run an unlock command, which relaxes restrictions while keeping the virtual kernel boundary intact. This design ensures that security policies are consistently applied and that any departure from the baseline is intentional and reviewable.
10Network and Resource Policy
Network attachment and port forwarding are handled as deployment settings rather than internal instance properties. Users can define ingress and egress policies within the instance recipe. If a network configuration is invalid, the system rejects the change atomically, ensuring that the instance never launches with an insecure or unintended network state.
11Current Research Limitations
Ginux is currently classified as research software and is not ready for production environments. It lacks independent security certification and does not provide complete Linux ABI compatibility. The project explicitly states that unknown contract operations fail closed, and current security guarantees are limited strictly to the scenarios covered by existing tests.
12Future Verification Targets
The project continues to track contract inventory, adversarial tests, and escape boundaries through HDAE gates. Future development aims to expand the audit capabilities and refine the mediation of complex ioctls and filesystems. The goal remains to provide a reviewable, hardened boundary for automated agents without attempting to replace the Linux ecosystem.