Ginux 与 Linux 操作系统核心差异对比,一个使用AI 并使用 Rust 语言从零开发的全新独立内核
Ginux 与 Linux 操作系统核心差异对比
Ginux 与 Linux 并不是同一种内核,Ginux 是由 CentOS 联合创始人利用 AI 并使用 Rust 语言从零开发的全新独立内核,通过兼容 Linux ABI 来运行 Linux 软件。
虽然它们在表现层面上看起来很像(Ginux 可以直接运行现有的 Linux 编译程序),但两者的底层设计、开发背景和技术架构有着本质的差异。
https://github.com/gmkurtzer/ginux

🛠️ Ginux 与 Linux 的核心技术差异
| 对比维度 | Linux 内核 🐧 | Ginux 内核 🚀 |
|---|---|---|
| 研发语言 | 主要使用 C 语言(近年来逐步引入少量 Rust)。 | 完全基于 Rust 语言 从零开发。 |
| 开发方式 | 历经数十年、全球无数顶级黑客和社区共同迭代的开源项目。 | 由 CentOS 联合创始人借助 大模型 AI 在 11 天内 快速构建(包含 13.9 万行新代码)。 |
| 底层功能架构 | 拥有原生、深厚且复杂的内存管理、进程调度与网络协议栈。 | 内存管理、进程调度、文件系统和网络功能均是 利用 Rust 重新实现 的全新架构。 |
| Linux 软件支持 | 原生支持。软件直接依托 Linux 内核的系统调用运行。 | ABI 级别兼容。通过模拟 Linux 的应用程序二进制接口(ABI)来“骗过”并运行 Linux 二进制程序。 |
| 生态成熟度 | 绝对成熟。服务于全球绝大多数服务器、超级计算机和 Android 手机。 | 处于初期技术探索阶段,主要验证“AI 辅助高难度底层开发”以及“非 Linux 内核兼容 Linux 生态”的可能性。 |
💡 形象比喻总结
- Linux:可以看作是几十年来精心建造的“老牌中式大院”,里面的砖瓦(C语言)都是传统且稳固的。
- Ginux:则是用现代化高强度轻量材料(Rust)在极短时间内赶工建成的“新式大楼”,但它的内部房间布局和水电气接口(ABI)完全模仿了大院,使得原本住在大院里的居民(Linux 软件)可以无缝搬进新大楼里生活。
Ginux — 可配置的用户态内核(用户空间内核)
Ginux 是一个可配置的用户态内核,为隔离的 Linux 兼容域提供支持。它作为普通 Linux 进程运行,在被管理的工作负载与宿主机内核之间放置一个显式、带版本号的契约。
⚠️ 重要:项目方向变更
Ginux 最初是一个独立 Rust 内核,通过 UEFI 直接引导,并运行 Rocky Linux 10 用户态。该研究阶段已完成。其最终源码永久保存在
bootable-kernel分支和bootable-kernel-final标签上。当前活跃开发已转到此处,以用户态内核形式继续推进。
目录
项目转型原因
独立内核实验证明:由经验丰富的人类通过架构、门禁和可执行测试来指导 AI 编码 Agent,可以构建出能够运行有意义的 Linux 用户态的新内核。但实验也让这个结果的局限变得清晰。
Linux 远不止是源代码。它是一套稳定的接口、一套开发流程、一个全球社区、厂商和硬件对齐,以及数十年的兼容性和运维经验。重新实现内核机制无法重现那个生态系统,而与 Linux 竞争也从来不是目标。
实验揭示的更有价值的结果是边界。Linux 必须保持广泛的用户态 ABI;正如 Linus Torvalds 所说:
“我们就是不破坏用户态。”
内核回归文档记录了这条规则。Ginux 可以站在 Linux 之上,有选择地为每个被管理的域提供更小的契约。在被管理的系统调用产生宿主机效果之前,Ginux 决定是模拟它、执行一个经过验证的中介操作,还是拒绝它。
说白了:
Linux 不能破坏用户态;Ginux 被设计为故意且有选择地打破完整的 Linux ABI 保证。 一个域只接收其获批工作负载所需的能力和接口行为。每一个偏离都被设计为显式的、带版本号的、可审查的、经过测试的,而非偶然的不兼容。
这次转型也是开发方法的结果。AI 使得构建一次性但可执行的原型代码、验证架构构想、从运行中的系统学习,并将有价值的部分带入更好的设计变得可行。原型是证据,不是把每个实验变成产品的义务。
Ginux 现在是什么
宿主机 Linux 内核
└─ 宿主 systemd(真正的 PID 1)
└─ ginux(普通的可信宿主机进程)
└─ 域契约 (domain contract)
├─ 虚拟进程与身份
├─ 虚拟描述符与内核视图
├─ 分配的设备与资源
└─ 被管理的 Rocky Linux 用户态
└─ 域内 systemd(虚拟 PID 1,计划中 Gate 9)
Ginux 监管原生 x86-64 程序,在被管理的系统调用产生宿主机效果之前拦截它们。其中央调度器解析域契约并在三种结果中选择一种:
- 模拟(Emulate):完全从 Ginux 自有的状态中给出答案。
- 中介(Mediate):验证并翻译请求,然后执行一个范围狭窄的 Ginux 自有宿主机操作。
- 拒绝(Deny):返回一个配置好的 Linux 兼容错误,或终止任务。
当前实现包括:
- 一个注重安全的 x86-64 解释器,以及一个平衡的原生 ptrace 后端;
- 严格、带版本号的域配置和生命周期;
- 摘要固定的 OCI 根文件系统、不可变文件系统索引和有界 overlay;
- Ginux 自有的进程、凭据、信号、同步、定时器和事件模型;
- 具有显式分配、所有权和撤销功能的虚拟设备;
- 有界虚拟
/proc、/sys、cgroup v2、挂载、命名空间、机器和启动身份视图。
Gate 8 已完成。 以虚拟 PID 1 引导 Rocky Linux systemd 是下一个计划中的兼容性门禁,目前还不是一个可宣称的能力。
与其他系统的关系
用户态内核的想法是已有的研究和工程领域。Ginux 在这个设计空间中探索一个特定的点:
| 方案 | 主要边界 | 侧重点差异 |
|---|---|---|
| Linux seccomp | 过滤宿主机系统调用 | 限制现有 ABI,而非定义完整的虚拟契约 |
| User-Mode Linux | 将 Linux 作为宿主机进程运行 | 在虚拟硬件上复用完整 Linux 内核 |
| gVisor | 在用户态中实现应用内核 | 模型高度相似,但兼容性和性能目标不同 |
| Gramine | 将应用与库 OS 打包 | 使用 manifest 和库 OS 边界 |
| Proxos | 在私有 OS 和商用 OS 之间路由调用 | 在系统调用接口上使信任放置可配置 |
| Ginux | 为每个域提供带版本号的内核契约 | 将声明的契约、虚拟状态、设备、资源和生命周期视为一个可审查的边界 |
Ginux 不承诺完整的 Linux ABI。兼容性声明仅适用于已命名的契约、工作负载和可执行证据。
开发与测试
参考开发环境是 macOS arm64。QEMU TCG 引导一个固定的 Rocky Linux 10 x86-64 宿主机,Ginux 在其中作为普通非特权进程运行。宿主机 systemd 仍然是真正的 PID 1。
环境检查
make doctor
准备固定资产(显式网络操作)
make host-image-fetch
make image-helper-fetch
make domain-image-fetch
构建与测试(缓存填充后离线运行确定性套件)
make build
make check
make test
检查最新已完成的能力
make demo-gate-8
各个组件和门禁目标的详细说明见 Makefile 以及 docs/ 和 hdae/ 下的对应文件。
安全模型与局限性
威胁模型
主要的攻击者控制着域内的一个进程。宿主机内核、硬件、Ginux 可执行文件和获批配置、引导链和操作者当前都是可信的。 平衡的原生后端仍然依赖宿主机来进行 ELF 加载、地址空间、页错误、信号、调度和 ptrace;这些仍然是宿主机内核的攻击面。
当前局限
- Ginux 是研究软件,尚未通过独立安全认证;
- 不提供完整的 Linux 兼容性;
- 尚未准备好用于生产工作负载;
- 未知的契约操作采用失败关闭策略(fail closed),但当前覆盖范围和保证仅限于已测试的门禁。
完整的意图、威胁模型、不变量和门禁计划见:
开发方法
Ginux 使用 Human-Directed Agentic Engineering (HDAE) 开发:
- 人类主导:产品意图、架构、约束和验收边界由人类掌握
- Agent 执行:实现、诊断和测试循环由 Agent 执行
每个获批的门禁(gate)都会在 hdae/ 目录中记录其范围、非目标、验收标准、验证方式、证据和停止点。
历史独立内核
独立可引导内核目前仍可用于研究和历史参考:
- 最终分支:bootable-kernel
- 最终标签:bootable-kernel-final
- 技术报告与 DOI:zenodo.org/10.5281/zenodo.23682548
它不再是活跃开发主线。代码仍按仓库现有条款开放,任何选择独立研究或 fork 它的人都可以使用。
项目命名
名字是 Linux 家族的一个玩笑:Ginux 组合了 Linux、GPT 和 Greg。为了把作者的自我保持在配置好的资源限制内,G 官方代表 GPT。
许可协议
Ginux 采用 Apache License 2.0。详见 LICENSE 和 NOTICE。
关于历史独立内核路线(bootable-kernel 分支补充)
以下内容摘自
bootable-kernel分支 README,作为转型前独立内核研究阶段的补充参考。
贡献冻结通知(2026-11-04)
太平洋时间 2026 年 11 月 4 日 23:59 之后,不再接受独立内核的新 PR 和 Issue。 届时之后打开的任何内容将在不审查的情况下关闭,无例外。
独立内核曾实现的能力
转型前的独立内核路线曾完成:
- 构建为单一可引导的
GINUX.EFI镜像 - 以普通 ring-3 进程启动嵌入式控制器
- 配置设备、网络、存储和持久域定义
- 拉取、验证、缓存并组装 OCI 镜像为域本地根
- 创建并运行多个独立进程、地址空间、文件系统、挂载、能力和生命周期的域
- 执行选定的未修改 Alpine musl/BusyBox 和 Rocky Linux glibc 程序
- 通过
multi-user.target引导 Rocky Linux 10 systemd - 引导原生 ring-3 控制器桌面、渲染可信窗口,并呈现经过测试的 Linux 域 Wayland 子集
Linux 兼容性状态(独立内核时期)
Linux 6.12 x86-64 账本对全部 375 个系统调用号进行了分类:
| 分类 | 数量 | 说明 |
|---|---|---|
| 完整实现 | 53 | — |
| 部分实现 | 257 | — |
有意拒绝(返回 ENOSYS) | 17 | 带 Linux 兼容的 ENOSYS |
| 策略拒绝 | 48 | 策略层面不允许 |
分类意味着每个系统调用号都有明确的处置方式,但不代表完整的 Linux 兼容。加载器、进程、VFS、终端、套接字、IPC、命名空间、cgroup、伪文件系统和设备行为的实现范围仅限于 LINUX-COMPATIBILITY.md 中记录的内容。
独立内核构建要求
- Rust 1.99.0(通过 rustup)
- Clang(含
x86_64-none-elf目标) - QEMU(含 x86-64 和 OVMF 支持)
- GNU Make
独立内核主要 Make 目标
make build # 构建统一 EFI 镜像
make test-linux-runtime # ELF、加载器、PIE、TLS、堆和 VM 行为
make test-alpine # 注册表拉取和 Alpine shell
make test-rocky-shell # Rocky glibc shell 和进程/文件行为
make test-multi-domain # 并发域生命周期
make test-rocky-systemd # 冷启动和缓存 Rocky systemd 引导
make test-storage # 卷初始化、恢复和重置
make test-controller-desktop-all # 集成桌面和 SMP 恢复
make run-gui # 在 macOS 上打开控制器 GUI
make check # 架构、ABI、格式、lint 和单元检查
独立内核仓库结构
| 目录 | 内容 |
|---|---|
boot/efi | UEFI 入口和统一镜像构建 |
kernel | 内核、Linux 人格、可执行加载器和 QEMU 硬件路径 |
control-plane/runtime | 嵌入式 ring-3 控制器 |
services | 隔离的原生服务运行时 |
crates | 共享的 no_std 契约和状态机 |
specs | 带版本号的引导、内核、ABI、域、镜像和服务契约 |
tests | ABI、生命周期和端到端 QEMU 门禁 |
tools | 镜像、manifest、架构和 QEMU 工具 |
skills | 可移植的 HDAE 开发和定期 PR/Issue 审查 Agent Skills |
openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构
更多推荐



所有评论(0)