用 Rust语言 从 0 开始写 unikernel

在软件工程中，反模式（anti-pattern）指的是一些重复出现的、乍一看是有益的，但最终得不偿失的模式。过去，这个词仅仅用于形容那些在 Java 这样的语言中滥用设计模式，导致无效代码膨胀的现象。但随着时间的流逝，很多原本我们认为是理所当然的事，正在成为阻碍我们前进的障碍。

传统上，我们把操作系统定义为计算机软硬件之间的桥梁，负责操作和分配计算机硬件资源，并调度用户计算任务，为用户提供服务。从计算机这种机器诞生之初，在过去的五、六十年里，符合此种定义的操作系统不断进步，目前仍在几乎所有的计算机上运行。但最近的十年里，事情正在发生变化。云技术的进步使得许多个人用户分享同一台计算机的需求飞速发展。所有随之而来的隔离性、扩展性、移植性，以及快速启动和迁移，以及故障时快速恢复的需求，传统操作系统已无力承担，各种虚拟化软件随之而来。

内核态与用户态的隔离保证了操作系统的稳定运行，但也使得用户态享受内核服务需要通过中断与系统调用，开销比调用相同功能的函数大很多。但在虚拟机中，虚拟机监视程序（Hypervisor）必然需要也已经提供了更强的的安全保护，操作系统与应用程序之间隔离的重要性就变低了，为了这次隔离而付出的性能代价也开始变得越来越不可接受。

具体来说，隔离体现在特权级的隔离和地址空间的隔离。在应用程序的视角，系统调用（System Call）和函数调用（Function Call）并没有什么不同，甚至如今大部分高级语言中 POSIX 系统调用都是通过 libc 库提供的函数调用封装完成的。但系统调用的开销大得多，因为特权级的切换和地址空间的切换不止需要额外的操作，而且破坏了所有局部性，造成了各种缓存不命中损失。传统操作系统的核心技术，现在成为反模式了。

于是我们发明了库操作系统（Libary OS），去除操作系统的隔离性，让操作系统退化成类似 libc 的库，通过函数调用给应用程序提供服务。现在，操作系统和应用程序运行在同一个特权级、同一个地址空间了，由于运行在同一个地址空间，操作系统现在只能服务一个传统的独占地址空间的应用程序进程。这样的操作系统内核，被称为 Unikernel。类比于宏内核（Monolithic kernel）、微内核（Microkernel），可称为幺内核。

下表对比了几类内核的特点：

进程调度和地址空间管理是传统操作系统内核中的内核，是一个操作系统实现最重要的部分，然而幺内核要摒弃的正是这些。这样做实际上不仅解开了应用程序的性能瓶颈，也解开了内核本身的束缚。如果内核一次启动只服务一个应用程序进程，也不必费心去折腾特权级和地址空间了，能不能针对这个应用程序来定制一个最适用的内核呢（外核 Exokernel 的思想）？

外核概念早已有之，之所以没有形成主流，是因为为每个应用程序定制内核实际上等于没有内核、应用程序直接运行在裸机上。只有极特殊的场景才有这样做的价值（比如航天），对于大部分应用程序来说这在工程上是不现实的。但在幺内核的发展背景下，由于操作系统内核的极大简化，又变为可能的了。

Unikraft 项目 正是利用现代软件工程理论实现高度定制化的幺内核的一次尝试。利用清晰的模块化，Unikraft 可以通过组合子库（称为微库 micro-library）实现定制幺内核库，然后再应用程序直接链接在一起（甚至能实现内核和应用程序的链接时优化，对于传统操作系统是无法想象的），最后直接在裸机或虚拟机中运行。

Unikraft 是用 C 实现的，不可避免地遇到了 C 工程性差的问题：大量使用宏和条件编译等类型不安全、非结构化的工程手段、难以复用已有的领域代码，尤其是驱动。

用 Rust 重写所有那些传统上用 C 语言完成的工作，早已成为一种潮流。低开销的安全性带来了一系列直接的安全好处——根据已有的研究，预计 ⅔ 的由不安全语言的底层编程习惯引起的漏洞可以通过仅使用安全语言来消除，如果这个语言和原本一样快，就没有顾虑了。而且 Rust 还有优雅的模块管理和库分发能力以及方便的交叉编译工具链。如果用 Rust 重写基于 Unikraft 思想的幺内核，必然能带来巨大的优势。

构造一个幺内核系统，本质并不是怎么实现系统组件。毕竟软件一旦碰到硬件就只能跟着硬件走，实际上完全是身不由己的，在不考虑软硬协同设计的情况下实际上根本不需要设计。幺内核的重点是如何修改应用程序才能适应这个内核。毕竟，为了达成高性能，应用程序和内核的交互方式已经变了，不再有跨特权级的系统调用。所以首先必须修改 libc 库，把系统调用替换成函数调用。

接下来，需要制造一个链接方式，将应用程序和库操作系统链接成一个可执行文件。引导加载程序引导内核的方式是固定的，因此这个可执行文件必须能被正常的引导流程引导。同时要能以上一步修改过的 libc 要求的方式加载应用程序。如果只修改了系统调用方式的话，这基本上意味着用户会与内核地址空间冲突，因此内核必须开启虚地址空间，只不过从头到尾只需要这一个虚地址空间而已。

能编译出可执行文件、启动并加载应用程序，下一步才是真正的幺内核服务应用程序。这时需要考虑的就是内核模块的解耦合和装配。内核必须可以方便地插拔模块，以尽量匹配应用程序的需求。这需要一个强大的构建系统，它理解各个内核模块之间的依赖关系，能够从需求推导出最小的内核模块集合。另外还依赖对应用程序的分析。虽然一般不需要修改应用程序源码，但应用程序必须自述需求，才能让构建系统完成推导。

1、操作系统的定制化和模块组合

2、unikernel：定制化的上限，模块化的下限

3、课程内容

1）unikraft：unikernel+自动定制

2）忒修斯：语言内隔离性

3）rust：分配器、解析器和驱动 crate

4）rcore-os 实践

4.1）zCore

4.2）rCore

4.3）trapframe

4.4）buddy_system_allocator

4.5）rCore-Tutorial-in-single-workspace

4、课时分配

1）导论：unikraft 试用和论文解读

2）unikraft libc 库（nolibc musl-libc）

3）unikraft 模块解读

4）忒修斯论文解读

5）zCore 和库

5.1）zCore 的架构：粗粒度模块

5.2）trapsframe 库

5.3）buddy_system_allocator 库

5.4）naive-timer 库

5.5）rCore 的内存分配模块

6）rCore-Tutorial-in-single-workspace

课程任务

1、实现一个 RISC-V 上的 libos 或 unikernel

1）libos 定义为内核和应用程序位于同一个特权级；

2）unikernel 定义为内核只能运行一个应用程序，必须体现内核对应用程序的定制化适应，可以修改应用程 序；

2、分析并设计或修改一个 Rust lib crate 完成内核部分功能

1）必须描述 crate 的适用范围；

2）crate 必须在至少一个内核中能使用，可以是现有的也可以是新写的；