Redox：一款用Rust语言开发的操作系统
- 汪明军 崔广章 译
Redox是纯用rust实现的通用操作系统。目标是提供一个功能完整的类Unix微内核，既安全又是免费的。Redox操作系统兼容POSIX，
可以执行许多程序无需二次开发。开发Redox灵感源于Plan9、Minix、Linux和BSD。并综合多年的研究和经验目的是要实现一个具有现代感的操作系统。
目前Redox支持硬件包括：
- 所有的X86-64 CPU
- 所有英伟达、英特尔和AMD显卡
- AHCI盘
- E1000和RTL8168网卡
- 英特尔HDA音频控制器
- 支持PS/2接口鼠标和键盘
设计哲学
Redox认可自由软件哲学
Redox只和兼容自由软件理念的软件集成，确保整个系统都可以自由的检查、修改和发布。不具备这些特征的私有软件是有背安全和自由的设计理念的。
Redox不认可私有软件，而赞同GNU自由系统发布指南。要查看兼容许可列表，请参考 GNU许可列表
Redox OS所有的软件、文档和字体主要采用MIT X11-style授权，只有如下部分单独授权：
- GNU Unifont使用GPLv2授权
- Fira font使用SIL Open Font License 1.1
- Faba and Moka icons使用GPLv3
- Newlib C library多数使用BSD
- NASM使用BSD 2-clause
而MIT X11-style授权有如下属性：
- 对软件用户提供完整而不受限的访问，用户可检测、修改和发布自己的更改。
- 与GPL许可兼容
- 允许和GPL不兼容的自由软件合并，例如OpenZFS
授权许可不会限制在Redox上运行软件，基于微内核架构，即使传统紧耦合的组件例如驱动程序也可以单独发布，因此运维人员可以
自由地为他们的项目选择他们认为合适的授权许可方式。
为何开发Redox
可能大家有这种疑惑，现在已经存在这么多种操作系统，为何要从零开始开发一个新的，直接在已有的开源操作系统上面继续贡献不好么？Redox社区认为已有的项目存在弊端，他们的
设计哲学需要从零构建一个项目来实现。
下面我们看看3个已有操作系统项目：
Linux
目前在高性能服务器和嵌入式设备基本上安装的是Linux OS。Redox很多社区的成员也是用Linux来运行他们的工作站。然而Linux并不是开发创新操作系统的理想平台。
- 存在很多历史遗留问题：老的系统调用永远存在，长期不可购买的硬件驱动程序作为强制组件存在于内核当中。有些驱动程序无需运行在内核当中，会导致系统奔溃、安全问题。
- 代码库庞大：要在Linux上面贡献，就内核代码2500w行，非常复杂。这是由于Linux是一体化内核架构所致。
- Linux是基于GPL2授权许可方式，不允许其他自由软件在内核当中使用。
- 缺乏内存安全：Linux在内存安全方面一直有问题，C语言本身的特点导致。
BSD
Redox社区更喜欢BSD设计哲学，不是什么秘密。在过去20年中，BSD社区引领了许多创新。例如jails和ZFS这样的系统提供了可靠性，并且其他操作系统还在追赶当中，但是BSD还是不满足Redox的要求：
- BSD也是一个一体化内核架构，这意味着一个驱动程序bug可能导致软件奔溃、挂起甚对系统造成损害。
- 内核使用c实现，存在内存安全的问题可能性较大
MINIX
MINIX的微内核架构，对Redox的设计影响很大，尤其在可靠性方面。MINIX最符合Redox的理念，具有类似的设计和许可证。
- 内核使用C实现：redox希望用rust来实现内核和驱动程序来提高可靠性和组织性，捕捉更多的潜在隐患。
- 缺少驱动支持，MINIX在实际硬件上面运行的不是很好，部分原因是对实际硬件关注较少。
- 对"Everything is a File"关注较少。我们特别关注这个习惯用法，以创建更统一的程序基础结构。
现代操作系统需要创新
对比其它操作系统
系统调用Syscalls
Redox系统调用接口是Unix-y，例如包含open、pipe、pipe2、lseek、read、write、brk、execv等等。目前，我们支持31个常用的Linux系统调用。与Linux系统调用比Redox调用接口更小型化，不是开发规模小型而是极简的设计。
"Everything is a URL"
这是"Everything is a file"的泛化，主要受plan9的启发。在Redox中，资源比如类套接字、类文件可以实现很快的速度。这样可以得到一个更加统一的系统API。将在后面的URL、schemes和资源中介绍。
内核
Redox内核是微内核架构，受MINIX启发。和Linux或BSD相比，Redox只有16000行的内核代码，这个数字还在减少。大多数服务都在用户空间提供。少量的代码使得更容易发现和修复错误/安全问题。
Andrew Tanenbaum (MINIX的作者)指出，每1000行正确编写的代码中就有一个bug。这意味着对于一个有将近25,000,000行代码的一体化内核来说，可能有将近25000个bug。一个只有16000行代码的微内核就意味着大约有16个bug。
需要注意的是，其他功能的代码是基于内核空间之外，使得它们的危险更小，不一定是更小的数目。主要目的还是将内核中的驱动程序和部分组件移到用户空间来实现。遵循最小权限原则。
- 作为独立用户进程在内存中完全隔离， 一个组件异常不会影响到其他的组件；外部不受信任的代码不会暴露整个系统；bug和恶意软件不能传播到其他组件。
- 是否限制与其他组件通信
- 没有管理员权限，bug转移到用户空间，降低影响能力
所有这些都大大提高了系统的安全性。这对于一些关键性应用程序以及希望将计算机系统问题最小化的用户很有帮助。
为何选Rust
rust有很大的优势是因为，对于操作系统来说，安全至关重要。操作系统是执行任何软件的基础，其本身安全性是很关键的。一直以来，Linux、BSD、Glibc等都存在大量的bug和漏洞，这仅仅是因为内存和类型缺乏安全性导致。
rust具有静态内存安全性，可以弥补其他系统中出现的不足。rust试图避免软件的内存不安全。
内核/用户空间分离的基本设计与类unix系统非常相似。其思想大致相同:通过管理内存和其他关键资源的内核的严格执行，将内核和用户空间分离开来。然而，rust优势在于强制内存和类型的安全，消除了很多意外的bug。
Linux和BSD的设计初衷都是安全的，但是实现缺没能达到目标。如下所示：
Unsafes
rust中unsafe关键词总会提示，开发者知道在干啥，在写底层的代码是必要的，提供了对安全的抽象。不可能在写内核的时候，不考虑unsafe条件的。在这种情况下，内核不可能是100%安全的，但是不安全的部分必须用一个不安全的标识来标记，
这样就可以将不安全的部分与安全代码隔离开来。我们寻求在可能的地方消除不安全的武器，当我们使用不安全的武器时，我们非常小心。在redox内核代码中，快速grep发现有300处unsafe调用。每一个都经过仔细审核确保正确性的。这与C写的
内核形成鲜明的对比，C编写的内核如果不进行昂贵的分析，即无法保证安全性。
衍生项目
Redox不仅包含一个完整的操作系统，还要很多其他的衍生项目
- TFS：以后收ZFS启发的文件系统
- ION: Redox操作系统的shell
- OrbitalRedox的显示服务
- pkgutilsRedox的包管理库和命令行前端
- sodium类似vi的编辑器
- relloc内存收集器
汪明军
之江实验室助理研究员 专注边缘计算、容器、kubernetes和云计算等方面技术研究。
崔广章
从2014年接触云计算以来，完整经历了多次云计算技术的出现、落地和普及，参与过多 个云 计算生产项目，项目涉及多个行业，其中比较有代表性的有基于OpenStack进行定制开发的运营商私有云、政务云，基于开源容器云方案进行定制开发的浙江移动数据中心操作系统 (DCOS)。2017年开始从事边缘计算，主导参与了以函数计算为实现载体的边缘计算在运营商车联网的尝试，主导参与了通过定制应用运行时和应用编排框架的边缘计算方案在运营商CDN的落地。目前在之江实验室。 e-mail：cuiguangzhang@gmail.com
