Exokernel — 把抽象推到用户态的极致设计

是什么

Exokernel 是 1995 年 MIT 的 Engler、Kaashoek、O’Toole 提出的新型操作系统架构：把传统 OS 里许多”抽象”（虚拟内存策略、文件系统、协议栈）从内核里挪出去，放到叫 libOS（库操作系统） 的用户态库里。内核（exokernel）只剩一件事——安全地把硬件资源多路复用给应用。

日常类比：传统 OS 像酒店——前台决定你住几楼、几点退房、毛巾几条。exokernel 像一栋只有保安和钥匙的写字楼——管理员只检查”你有没有这把钥匙能进这间房”，房间里怎么布置完全你自己决定。

口号是 “separate protection from management”——保护（你能不能用）归内核，管理（怎么用）归应用。

内核变”薄”，不是变”没”：安全多路复用还在；变薄的是策略与抽象。

为什么重要

不理解 exokernel，下面这些事都没法解释：

• 为什么后来出现 unikernel（MirageOS / IncludeOS）这种”应用和 OS 编成一个二进制”——它是 exokernel + libOS 思路的孙辈
• 为什么高频交易用 DPDK 让程序直接碰网卡、绕过 Linux socket——像”secure binding”的工业版
• 为什么 Linux 有 io_uring、存储侧有 SPDK——都在把功能往用户态搬
• 为什么 Arrakis（OSDI 2014）会自称”现代 exokernel”

一句话：exokernel 没赢装机量，但它的思想到处开花。

核心要点

exokernel 的设计哲学拆成 三块：

1. 保护与管理分离：内核只检查”你能不能用这块物理页”，不管”你怎么用”。缓存替换、文件系统布局、TCP 策略等下放到 libOS。

2. 安全绑定（secure binding）：第一次申请资源时，内核检查权限并发”能力券”（capability）。之后访问主要靠硬件 + 能力验证，不再每次重做策略。

3. 可见的资源回收（visible revocation）：内核要收回资源时先通知 libOS；不配合就走 abort protocol 强制收回并 unmap。

论文原型：Aegis（exokernel）+ ExOS（仿 UNIX 的 libOS）。

实践案例

案例 1：libOS 自己写页替换

传统 OS：大家共用内核那一套 LRU。数据库想”我自己懂哪页热”也插不进去。

exokernel：内核只发”物理页 #3742 给你了”。数据库 libOS 可用更贴业务的替换策略，文件服务器 libOS 用另一套——同一台机器多种策略共存。

案例 2：把 UNIX 抽象放进 ExOS，而不是内核

1995 文的重点不是某个网红 HTTP 服务器，而是：VM、IPC 等传统抽象可以在应用级实现。ExOS 在 Aegis 之上仿真 UNIX 接口；测下来许多原语比同期 Ultrix 快一个数量级以上，同时仍能跑常见 UNIX 应用。

（常被一起讲的 Cheetah 高速 Web 服务器，出自后续 SOSP 1997 的 exokernel 系统论文，不在 1995 这篇里。读 1995 文时请把焦点放在 Aegis 接口与 ExOS 抽象下沉。）

案例 3：abort protocol 长什么样

内核 → libOS：「我要收回物理页 #3742，你尽快交出来」
libOS → 保存必要状态 → 交还
        ↓ 若超时/不响应
内核：直接 unmap；libOS 下次访问自己吃 fault

这保证有 bug / 恶意的 libOS 卡不死内核。

关键性能数据（论文里给的）

论文原表述（不要背成”万能对照表”）：

操作	论文说法（Aegis）
exception dispatch	约 1.5µs；相对当时最佳实现约 5×；相对 Ultrix 可达 两个数量级
protected control transfer	相对当时最佳实现约 7×
若干内核原语整体	相对 Ultrix 约 10–100×

ExOS 跑 UNIX 应用时，整体可与 Ultrix 持平或更好——而 ExOS 本身是用户态库。具体微秒数随硬件/测量口径变，引用时以论文表格为准。

三句话讲清楚 secure binding

普通人以为每次系统调用都是：陷入内核 → 检查 → 执行 → 返回。其实混了两件事：检查权限和执行操作。

secure binding 把它们拆开：

1. 第一次申请：陷入内核，发能力券
2. 之后访问：硬件 + 能力验证，尽量少陷入

类比：第一次办健身房年卡，之后刷卡进门——前台不再每次审身份证。这和后来 io_uring 用共享队列减少往返，是同一类直觉。

踩过的坑

1. POSIX 兼容靠模拟：要跑老应用得装 ExOS；Aegis+ExOS 总复杂度并不自动更小。
2. 多 libOS 抢资源：谁来仲裁 CPU/内存？1995 文承认这是难题；后来硬件辅助方案（如 Arrakis）才更好做。
3. 硬件不一定能切片：页和磁盘块好切，某些设备寄存器/GPU 状态不好切，只能独占。
4. 安全绑定吃硬件特性：当年 x86 段机制好用；64 位时代成本变了，也影响普及。
5. 协议栈多副本：每个高性能 libOS 自己实现 TCP，bug 要修多遍——工业界很抗拒。

适用 vs 不适用场景

适用：

• 单一专用应用占满整机（数据库、HFT、CDN 节点）
• 要绕开通用 OS 不可预测延迟的实时/嵌入式思路
• 现代 unikernel 部署（MirageOS / OSv）

不适用：

• 桌面 / 通用服务器——多应用要一致接口
• 强依赖完整 POSIX/glibc 生态
• 团队没能力维护自己的 libOS
• 设备无法安全切片、又必须多租户共享的场景

历史小故事（可跳过）

• 1995 SOSP：Exokernel 论文发表；同场还有 L4 等”把内核做小”路线
• 1997：后续文把应用性能与 Cheetah 等案例写得更满
• 2013+：Unikernel、DPDK/SPDK、后来 io_uring，把”功能下放用户态”做成工程常态
• 2014 Arrakis：论文语境里明确对标现代 exokernel

一句话：不是 Linux”变成了 exokernel”，而是 Linux 生态在用几十年时间，渐进吸收它的若干思想。

学到什么

1. OS 强加的抽象不是上帝设的——可质疑，但要说清”谁决定怎么用资源”
2. 保护与管理分离 比”内核 vs 用户态”更深一层
3. 工业没赢 ≠ 思想没赢——装机量失败仍能定义方向
4. 先找”必须留在内核的最小集” 是反复出现的母题——L4（l4-1995）同场不同答卷

延伸阅读

• 论文 PDF：Exokernel SOSP 1995
• 后续：Application Performance and Flexibility on Exokernel Systems, SOSP 1997
• Arrakis, OSDI 2014
• l4-1995 —— 同年另一种”做小内核”
• sel4-2009 —— 可证明微内核

关联

• l4-1995 —— L4 砍接口数，exokernel 砍抽象
• the-os-1968 —— OS 该不该有抽象层的长争论
• sel4-2009 —— 继承微内核线，同属”内核宜小”
• hyperkernel-2017 —— “内核小到能验证”的现代延伸
• eros-1999 —— capability 另一条线
• certikos-2016 —— 验证过的 hypervisor，功能下放思路相近
• arrakis-2014 —— 论文语境里对标”现代 exokernel”的系统
• io-uring —— 减少内核往返的现代接口，和 secure binding 同直觉

反向链接

• arrakis-2014 —— Arrakis 2014 — 让操作系统退出数据路径
• barrelfish-2009 —— Barrelfish / Multikernel — 把多核机器当成一个小型网络来设计 OS
• denali-2002 —— Denali — 在一台机器上同时跑上千个轻量 VM 的早期实验
• ffs-1984 —— FFS — 把磁盘几何写进文件系统
• flexsc-2010 —— FlexSC — 把系统调用从同步陷入改成异步队列
• ghost-2021 —— ghOSt — 把 Linux 调度策略搬到用户态去写
• haven-2014 —— Haven — 在不信任的云里给程序造一间安全屋
• ix-2014 —— IX 2014 — 用硬件保护做高吞吐低延迟的数据面 OS
• linux-kernel —— Linux kernel — 三层解释开源内核如何协作
• mach-vm-1987 —— Mach VM — 把虚拟内存抽象成”对象”，与硬件解耦
• mirage-2013 —— MirageOS 2013 — 应用和内核合体成一个超轻虚拟机
• selinux-2001 —— SELinux — 给 Linux 装上不可绕过的安检门
• soltesz-2007 —— Soltesz 2007 — 容器：比虚拟机轻一档的隔离方案
• v-system-1988 —— V 分布式系统 — 把局域网当成一台机器，内核只剩进程加 IPC