Greg Kurtzer's Ginux Evolves into a Configurable Userspace Kernel
Ginux shifts focus from bootable kernel research to a specialized userspace containment boundary.
1Transition to Userspace
Ginux has officially pivoted from its initial phase as an independent Rust-based bootable kernel to a userspace kernel. While the original research successfully booted Rocky Linux 10, the project now focuses on running as an ordinary Linux process. This shift emphasizes creating a controlled boundary rather than replacing the host kernel.
2Defining the Contract
The core innovation of Ginux is the explicit, versioned contract established between managed workloads and the host kernel. By sitting above the host, Ginux intercepts system calls before they reach the kernel. It then decides whether to emulate, mediate, or deny these operations based on the specific requirements of the instance.
3Deliberate ABI Incompatibility
Unlike standard Linux distributions that prioritize maintaining a stable Application Binary Interface, Ginux is designed to break the full Linux ABI guarantee. It provides only the capabilities required by the approved workload. This intentional restriction ensures that any incompatibility is explicit, reviewable, and tested rather than an accidental byproduct of system updates.
4AI-Driven Development Method
The project utilized AI coding agents to build disposable, executable prototypes. This method allowed for rapid testing of architectural ideas and learning from the running system. The development team treated these prototypes as evidence for design decisions, ensuring that only the most valuable components were carried forward into the current architecture.
5Containment for AI Agents
Ginux is currently being tested as a containment boundary for AI agents and automated software. By placing an agent within a restricted instance, operators can limit its access to files, network connections, and system processes. This approach ensures that agents only interact with the virtual resources explicitly granted by the contract.
6Operational Security Boundaries
The research goal involves creating a reviewable boundary that spans system calls, ioctls, filesystems, and device access. For instance, a contract might allow an agent to read the system time while simultaneously denying it the ability to modify clock settings or access unapproved network listeners, significantly reducing the potential attack surface.
7Selective vs Paranoid Modes
Ginux offers two primary operational modes for system call management. The default selective mode permits direct host execution for operations classified as safe. Conversely, the paranoid mode forces every system call through the Ginux userspace dispatcher. This allows users to balance performance needs against the desired level of security and isolation.
8Performance and Benchmarking
The development team maintains a strict performance budget, targeting a four percent overhead compared to native execution. Automated benchmarks compare native performance against both selective and paranoid Ginux modes. These tests are recorded in the repository, ensuring that any performance regressions are identified and addressed during the ongoing development process.
9Development Environment Setup
The reference environment for Ginux development is macOS arm64, utilizing QEMU to boot a pinned Rocky Linux 10 x86-64 host. Ginux runs as an unprivileged process within this environment. The project provides a comprehensive Makefile to manage pinned assets, build processes, and deterministic test suites for consistent and reproducible results.
10Instance Lifecycle Management
Users manage instances through a command-line interface that supports creating, importing, and exporting recipes. Instances are contract-locked by default, preventing unauthorized changes. For maintenance, users can unlock an instance, perform necessary updates, and relock it. This lifecycle ensures that the defined security policy remains enforced throughout the instance's operational duration.
11Current Research Limitations
Ginux is currently classified as research software and is not ready for production workloads. It has not undergone independent security certification and does not claim full Linux compatibility. The project relies on the host kernel for essential functions like scheduling and memory management, which remain part of the trusted attack surface.
12Future Verification Targets
The project continues to track its progress through HDAE gates, which document the contract inventory and adversarial test results. Future development will focus on refining these boundaries and demonstrating stronger containment claims. Users are encouraged to inspect the documented security boundary and limitations before attempting to use Ginux for sensitive tasks.