Framekernel 架构
Framekernel: What and Why
微内核的安全性，宏内核的速度。
Asterinas推出了一种名为 _framekernel_的新型操作系统架构，该架构充分发挥Rust的强大能力，融合了宏内核和微内核的优势。
在framekernel架构中，整个操作系统驻留在同一地址空间中（类似于宏内核），并且必须使用Rust编写。不过，这里有一个特别之处——内核被分为两半：操作系统框架（类似微内核）和操作系统服务。只有操作系统框架允许使用_不安全的Rust_，而操作系统服务必须完全使用_安全的Rust_编写。
| Unsafe Rust | Responsibilities | Code Sizes | |
|---|---|---|---|
| OS Framework | Allowed | 将底层不安全代码封装在高层安全 API 中 | Small |
| OS Services | Not allowed | 实现操作系统功能，例如系统调用、文件系统、设备驱动程序 | Large |
因此，内核的内存安全性可降低至操作系统框架的水平，从而最小化与内核内存安全性相关的可信计算基（TCB）。另一方面，单一地址空间使内核的不同部分能够以最高效的方式通信，例如函数调用和共享内存。得益于framekernel架构，Asterinas 能够同时提供卓越的性能和更高的安全性。
操作系统框架的要求
虽然 framekernel 的概念很简单，但所需操作系统框架的设计和实现却面临挑战。它必须同时满足四个标准。
-
可靠。 若程序员使用该框架的安全 API 编写任何安全的 Rust 代码时，均不会触发任何未定义行为，则认为该框架的安全 API 具备可靠性
-
只要代码通过了 Rust 工具链的验证，可靠性就能确保操作系统框架与 Rust 工具链共同承担内核内存安全的全部责任。
-
**实用。**该框架应使开发者能够使用这些 API 在安全的 Rust 中实现大量操作系统功能。考虑到设备驱动程序在成熟的操作系统内核（如 Linux）中占代码的大部分，该框架能够支持在安全的 Rust 中编写设备驱动程序尤为重要。
-
**极简。**作为内存安全的 TCB，该框架应尽可能精简。如果某些功能可以在框架外部实现，则不应在框架内部实现。
-
**高效。**框架提供的安全API仅允许引入最小的开销。理想情况下，这些API应实现为零成本抽象。
幸运的是，我们设计和实现符合这些标准的操作系统框架的努力已取得成果，这就是Asterinas OSTD。以该框架为基础，我们开发了Asterinas内核；该框架还使其他人能够创建具有不同目标和权衡的自己的框架内核。