# 给 Linux 内核装个＂隔离舱＂——聊聊 HAOC

最近看到个挺有意思的项目，叫 HAOC。这是中关村实验室和 openEuler 社区搞的，全称 Hardware-assisted OS compartmentalization（硬件辅助的操作系统隔离技术）。简单说就是给 Linux 加个"隔离舱"，一个地方出问题不会把系统搞挂。

项目地址：https://gitee.com/openeuler/kernel

一个问题：为什么现在才做这件事？

说实话，Linux 内核的安全问题已经不是一天两天了。3000 多万行代码，每天还在增加，漏洞就像打地鼠——刚堵上一个，又冒出三个。

传统的思路是"修漏洞"。但有个尴尬的现实：从漏洞出现到被发现，平均要 60 天；从发现到修补，又要 20 多天。更惨的是，52% 的补丁根本没真正解决问题。

而且，现在的 Linux 就像一艘所有船舱都连通的老战舰。调度器、内存管理、文件系统、驱动程序，大家都在同一个地址空间里裸奔。一旦某个模块被攻破，攻击者就能在里面横着走，想干嘛干嘛。

在云时代、AI 时代，这越来越让人心里发毛。你的 Kubernetes 集群、你的数据库、你的 AI 模型训练环境，底层都依赖内核。内核一旦被控制，整个基础设施就全完了。

所以 HAOC 的思路变了——不是堵漏洞，而是造隔舱。就算某个地方漏水，也不会沉整艘船。

它到底是怎么工作的？

很多人第一次听说 HAOC 的反应是："这东西怎么用？我要改代码吗？"

不用。什么都不用改。

这就是 HAOC 最舒服的地方。你的 Java 程序照常跑，Docker 容器照常开，Kubernetes 照常调度，应用层完全感知不到它的存在。它在内核层默默干活，就像一个你看不见的保镖。

打个比方

想象你在一家公司上班：

• TEE（如 Intel SGX）像是公司里的保险柜：你有重要文件要存，得自己走过去、输密码、放进去、锁好。安全是安全，但麻烦，而且你的工作流程得跟着变。

• HAOC 像是整栋大楼升级了安保系统：你照常上下班，什么都不变。但电梯要刷卡了，走廊装了监控，重要房间加了防盗门。坏人就算混进大厅，也进不了董事长办公室。

HAOC 给 Linux 内核装的，就是这套"大楼安保"。

三步原理

第一步：圈出"禁区"

HAOC 在内核地址空间里划了一块禁区，把最关键的宝贝锁进去：

• 页表（记录内存映射的"地图"）
• 进程权限凭证（谁有 root 权限的"身份证"）
• 系统密钥（加密的"万能钥匙"）

第二步：硬件上锁

利用 CPU 自带的虚拟化能力（Intel VT-x / AMD-V / ARM PAN），给禁区加物理隔离：

• 普通内核代码无法直接读写禁区内存
• 想操作敏感数据，必须通过安全门
• 强行闯入会触发硬件异常，直接报错

第三步：受控访问

内核需要操作敏感数据时（比如创建新进程），流程是这样的：

1. 普通内核代码发起请求
2. 通过安全门（Secure Gate）进入 IEE 隔离环境
3. IEE 内部完成敏感操作
4. 返回结果，退出隔离环境

整个过程就像去银行办业务：你（普通内核代码）不能进金库，只能在柜台递申请，柜员（IEE）进去帮你操作，然后把结果递出来。

真实案例：CVE-2021-3490

这是个真实的 Linux 内核漏洞。攻击者利用 eBPF 子系统的越界写漏洞，可以直接修改进程凭证，把普通用户变成 root。

在传统系统上：

1. 攻击者触发 eBPF 漏洞
2. 直接写入 cred 结构（存储进程权限）
3. uid 变成 0，获得 root 权限
4. 控制系统

在启用了 HAOC 的系统上：

1. 攻击者还是能触发 eBPF 漏洞
2. 试图修改 cred 结构——但 cred 被锁在 IEE 禁区里
3. 硬件阻止非法写入，触发保护机制
4. 攻击失败，进程权限不变

看到区别了吗？漏洞还在（eBPF 的问题没解决），但利用路径被切断了。这就是 HAOC 的思路——承认漏洞无法杜绝，但让漏洞变得难以利用。

核心架构：三层隔离

如果把这个"安保系统"拆开看，内核被分成了三层：

三个关键技术模块：

• IEE（隔离执行环境）：基于 CPU 虚拟化扩展的硬件隔离
• PTP（页表保护）：防止攻击者篡改内存映射
• CREDP（凭证保护）：保护进程权限不被非法修改

从 openEuler 24.03 LTS 开始，这些已经默认集成，不用你手动开。

HAOC vs TEE：不一样，但可以一起用

可能你会问：那 TEE（像 Intel SGX、ARM TrustZone）呢？它们有什么区别？

一句话区分：

• TEE 是应用主动进保险柜——你把敏感代码和数据放进去保护
• HAOC 是内核被动加隔离——内核自己修墙，应用无感知

它们不冲突，反而很互补：HAOC 保护内核不被攻破，TEE 保护应用数据不被偷。一个筑墙，一个设柜。

我需要做什么？

如果你是应用开发者

什么都不用做。

你的代码不用改，Dockerfile 不用改，部署脚本不用改。HAOC 是内核层的事，跟你没关系。但你可以告诉运维："这玩意儿能防内核提权，要不试试？"

如果你是运维/系统管理员

确认开启就行：

# 检查系统版本（需要 openEuler 24.03 LTS+）
cat /etc/os-release | grep VERSION

# 检查 HAOC 是否已启用
grep -E "CONFIG_IEE|CONFIG_PTP|CONFIG_CREDP" /boot/config-$(uname -r)
# 应该输出：
# CONFIG_IEE=y
# CONFIG_PTP=y
# CONFIG_CREDP=y

# 查看启动日志
dmesg | grep -i haoc
# 应该能看到初始化成功的信息

如果是自己编译内核，在 make menuconfig 里找到：

Security options
  -> [*] HAOC (Hardware-assisted OS Compartmentalization)
    -> [*] Isolated Execution Environment (IEE)
    -> [*] Page Table Protection (PTP)
    -> [*] Credentials Protection (CREDP)

如果你好奇效果

可以用 LTP（Linux Test Project）测试套跑一下：

dnf install ltp
cd /opt/ltp
./runltp -f syscalls -s "cve" 2>&1 | tee haoc-test.log

这个项目现在什么状态？

HAOC 从 2024 年 6 月开始进入 openEuler，到现在（2025 年 4 月）已经迭代了三个版本：

• 1.0：先上了 ARM 架构，验证想法可行
• 2.0：加上 x86，驱动也能隔离了，性能优化了 20%
• 3.0：随 openEuler 25.03 发布，成为默认组件，开箱即用

它不是实验室里的玩具，已经用在一些关键基础设施场景了。当然，生态还在成长，文档和社区支持不如 Docker、K8s 那么丰富，遇到问题可能得自己看源码或者去社区问。

有什么坑？

性能开销：5-15% 的性能损耗是实打实的。如果你的业务对延迟极度敏感（比如高频交易），需要权衡一下。

调试更麻烦：以前内核出 Bug 就够难查的了，现在多了隔离域，一个 Bug 可能涉及多个域的交互，排查起来像破案。

不是万能药：它能防内核提权和横向移动，但防不了应用层漏洞、防不了社工、防不了内鬼。适合关键基础设施、金融、政务这些高安全场景；你跑个个人博客用它，确实是"杀鸡用牛刀"。

最后说两句

操作系统安全这东西，跟买保险有点像——平时感觉不到，真出事的时候才知道值不值。

HAOC 的思路我觉得挺对：不指望消灭所有漏洞，而是让漏洞难以利用。这是务实的做法。3000 万行代码，漏洞永远修不完，但如果我们能把"一艘连通的战舰"变成"有隔舱的现代航母"，那攻击者的难度就大了不止一个数量级。

如果你跑的是关键业务，或者单纯对操作系统安全感兴趣，可以关注一下 openEuler 社区。HAOC 还在快速发展，后面应该会有更多有意思的东西出来。