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 — 可配置的用户态内核(用户空间内核)

仓库地址: https://github.com/gmkurtzer/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/ 目录中记录其范围、非目标、验收标准、验证方式、证据和停止点。


历史独立内核

独立可引导内核目前仍可用于研究和历史参考:

它不再是活跃开发主线。代码仍按仓库现有条款开放,任何选择独立研究或 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/efiUEFI 入口和统一镜像构建
kernel内核、Linux 人格、可执行加载器和 QEMU 硬件路径
control-plane/runtime嵌入式 ring-3 控制器
services隔离的原生服务运行时
crates共享的 no_std 契约和状态机
specs带版本号的引导、内核、ABI、域、镜像和服务契约
testsABI、生命周期和端到端 QEMU 门禁
tools镜像、manifest、架构和 QEMU 工具
skills可移植的 HDAE 开发和定期 PR/Issue 审查 Agent Skills
Logo

openEuler 是由开放原子开源基金会孵化的全场景开源操作系统项目,面向数字基础设施四大核心场景(服务器、云计算、边缘计算、嵌入式),全面支持 ARM、x86、RISC-V、loongArch、PowerPC、SW-64 等多样性计算架构

更多推荐