Rust ｜ 批判性回顾

“原文：Rust: A Critical Retrospective：https://www.bunniestudios.com/blog/?p=6375[1]

“说明：国内机器之心公众号对这篇文章进行了编译，发布了标题为《编写完10万行代码，我发了篇长文吐槽Rust》的一篇文章，我看了以后发现机器之心的这篇文章对原文原意的传达并不正确与完整，并且省略了很多对 Rust 开发者有帮助的关键细节，比如，作者如何防范 Rust 供应链攻击等，以及 Rust 超出作者预期的优点有哪些。所以特此全文翻译，供大家参考。当然，也要感谢机器之心对这篇文章的传播，让我有机会看到此文。

正文翻译

由于在大流行期间我有几年无法旅行，所以我决定利用我新获得的时间并真正专注于 Rust。在编写了超过 10万行 Rust 代码之后，我想我开始对这门语言有了一种感觉，并且像每一个脾气暴躁的工程师一样，我已经形成了我自己的观点，因为这是互联网，所以我要分享。

我学习 Rust 的原因是充实 Xobs 编写的 Xous[2] OS 的一部分。Xous 是一个用纯 Rust 编写的微内核消息传递操作系统。它的近亲可能是 QNX[3]。Xous[4] 是为轻量级（物联网/嵌入式规模）安全优先平台（如 Precursor[5] ）编写的，支持 MMU 以实现硬件强制的页面级内存保护。

在过去的一年里，我们设法为操作系统增加了很多功能：网络（TCP/UDP/DNS）、中间件图形抽象（用于模版和多语言文本）、存储（以加密的、看似可否认的数据库的形式，称为PDDB[6]）、可信启动，以及具有自配置和密封（sealing）属性的密钥管理库。

我们决定编写自己的操作系统而不是使用 SeL4、Tock、QNX 或 Linux 等现有实现的原因之一是我们想真正了解我们设备中的每一行代码在做什么。特别是对于 Linux，它的源代码库是如此庞大和动态，即使它是开源的，你也不可能审计内核中的每一行。代码更改的速度比任何人都可以审计的要快，除非是自己开发的。Xous的范围也很窄，只支持我们的平台，以尽可能地保持内核中不必要的复杂性。

范围狭窄意味着我们还可以充分利用CPU运行在FPGA中[7]的优势。因此，Xous的目标是一个不寻常的RV32-IMAC配置：一个有MMU+AES扩展的配置。毕竟是2022年，而且晶体管很便宜：为什么我们所有的微控制器都不像桌面上的同类产品那样具有页级存储器保护功能？作为一个FPGA，也意味着我们有能力在硬件层面修复API错误，使内核更加精简和简化。这在通过抽象破坏（abstraction-busting）过程的工作中尤其重要，比如从RAM中挂起和恢复。但这都是另一篇文章的内容：这篇文章是关于Rust本身，以及它如何作为Xous的系统编程语言。

Rust 的「卖点」

在我们启动Xous的时候，我们看了大量的系统编程语言，Rust脱颖而出。尽管它的 "no-std "支持在当时还不成熟，但它是一种强类型、内存安全的语言，拥有良好的工具和一个蓬勃发展的生态系统。我个人是强类型语言的超级粉丝，内存安全不仅对系统编程有好处，它还能让优化器更好地生成代码，此外它还能让并发性不那么可怕。实际上，我希望Precursor有一个CPU，它对标记指针和内存能力有硬件支持，类似于在CHERI[8]上所做的，但在与做CHERI的团队讨论后，显然他们非常专注于使C语言变得更好，没有带宽来支持Rust（尽管这可能正在改变[9]）。从总体上看，C语言对CHERI的需求远远大于Rust对CHERI的需求，所以这是一个公平的资源优先排序。然而，我是一个安全方面的粉丝，所以我仍然希望有一天，硬件强制的胖指针会进入Rust。

虽然如此，我并不打算回到C语言阵营，只是为了踢一踢硬件改造的"轮胎"，以弥补C语言的一个糟糕的方面。Rust 光鲜的手册还宣传它能够通过其严格的 「借用检查器」在错误发生之前就加以预防。此外，它的发布理念应该是为了避免我所说的 「Python的问题」：“如果你不主动跟上语言的最新版本，你的代码就会停止工作”。另外，与Python不同的是，Rust并非天生就不卫生，因为宣传的安装包的方式也不是错误的安装包的方式。与Python相反，在Python中，关于包的官方文档会引导你把它们添加到系统环境中，但却会被Python的“长老们”骂：“但你当然应该使用venv/virtualenv/conda/pipenv/...，大家都知道”。如果这个细节没有被归入官方教程的16章中的第12章[10]，我对Python的体验会好得多。当有人取消发布一个流行的包时，Rust 也应该比 Node 更好地避免“哎呀，我删除了互联网”问题，至少如果你为你的包使用完全指定的语义版本。

从长远来看，Xous背后的哲学是，最终它应该 "变得足够好"，到那时我们就应该停止对它的操纵。我相信，工程师的使命就是最终把自己的工作搞好：系统应该变得足够稳定和牢固，以至于它 "只是能用"，没有任何注意事项。在这一点上，任何额外的工程都只会增加错误或臃肿。Rust的 "稳定就是永恒 "的理念，以及承诺永远不破坏向后兼容的理念，从让Xous变得如此完美，以至于不再需要我这个工程师的角度来看，是非常一致的，从而使我能够将更多的时间和精力用于支持用户和他们的应用程序。

Rust 欠打磨的地方

网上已经有很多写给 Rust 的「情书」了，所以，我打算先列举我遇到的一些 Rust 的缺陷。

语法中的噪音（Line Noise）

这是一个肤浅的抱怨，但我发现 Rust 的语法很密集、很沉重，而且难以阅读，就像试图阅读附带噪音的UART输出一样：

Trying::to_read::<&'a heavy>(syntax, |like| { this. can_be( maddening ) }).map(|_| ())?;

用更通俗的话说。上面这句话的作用是在对象（实际上是结构体）Trying上调用一个名为to_read的方法，其类型注释为&heavy，生命周期为 'a，参数为 syntax，闭包的参数为like，在另一个名为 this 的结构体实例上调用can_be方法，参数为 maddening，任何非错误返回值都映射到Rust单元类型`()`，如果有错误，会被自动unwrap并返回给调用者。

深呼吸。当然，我有一些地方是错的，但你会明白这种语法有多密集。

在此基础上，你可以将宏和指令分层，而这些宏和指令不需要遵循Rust的其他语法规则。例如，如果你想条件编译代码，你可以使用一个指令，如：

#[cfg(all(not(baremetal), any(feature = “hazmat”, feature = “debug_print”)))]

这就是说，如果启用了 hazmat 或 debug_print 特性（feature），而且你不是在裸机上运行，就使用下面的代码块（我肯定也弄错了）。对我来说，这个语法最令人困惑的部分是使用单一的=来表示等价而不是赋值，因为，配置指令中的东西不是Rust代码。它就像一种独立的元语言，有一个你可以查询的键值对的字典。

我甚至不打算讨论Rust宏的不可读性--即使我自己写了一些Rust宏，我也不得不承认，我觉得它们 "只是勉强能用"，而且可能在它们的某个地方有“龙”（Bug）。这不是你在一门自称可靠的语言中应该有的感觉。是的，这是我的错，因为我不够聪明，无法解析语言的语法，但同时，我的生活中还有其他事情要做，比如构建硬件。

无论如何，这是一个肤浅的抱怨。随着时间的流逝，我最终克服了学习曲线并变得更加自在，但这是一条艰难而陡峭的曲线。这部分是因为所有的 Rust 文档要么是用eli5 风格[11]编写的（形容文档写的非常简陋），要么你会看到一个正式的语法定义[12]（从技术上讲，定义一个“feature”在那里，但没有用简单的英语概括）。

要说明的是，我非常同情写好文档有多难，所以这不是在挖苦那些努力写出这么多优秀语言文档的人。我真的很欣赏文档生态系统的总体质量和丰富性。

Rust只是在语法方面有一个陡峭的学习曲线（至少对我来说）。

Rust 虽然强大，但并不简单

Rust 很强大。我很欣赏它的标准库，它包含了 HashMaps、Vecs 和 Threads 等数据结构，既“美味”又令人上瘾。一旦我们在 Xous 中获得了 std 支持，就再回不去了。来自 C 和汇编的背景，Rust 的标准库感觉丰富且有用。我读过一些负面评价，说它缺乏一些功能，但就我的目的而言，它确实达到了最佳状态。

话虽如此，我对 Rust std 库的依赖并没有在构建可审计的代码库方面带来任何好处。我以前对Linux的批评之一是：“天哪，内核的源代码包括红黑树的实现，怎么会有人来审计它呢”。

现在，在写过操作系统之后，我对这些丰富的动态数据结构的重要性有了深刻的理解。然而，Xous 没有在其存储库中包含 HashMap 的实现这一事实并不意味着我们比 Linux 更简单：事实上，我们只是把一大堆代码“隐藏”了起来。仅仅是标准库的 "collection "部分就代表了大约1万多行源代码，而且复杂度非常高。

因此，虽然 Rust 的 std 库允许 Xous 代码库专注于成为内核而不是其自己的标准库，但从构建最小攻击面、“完全由一个人可审计”代码库的角度来看，我认为我们对 Rust 的 std 库的依赖意味着我们在这个目标上失败了，尤其对于我们需要继续跟踪 Rust 的最新版本（我将在下一节中解释为什么我们必须这样做）来说。

理想情况下，在某些时候，事情会 "稳定下来"，我们可以把Rust 仓库分叉，然后说 "这是我们的攻击面，我们不打算改变它"。即便如此，Rust std 存储库的大小仍使 Xous 存储库相形见绌，这还不包括编译器本身的复杂性。

Rust 还未完善

接下来的这一点与Rust还不适合做完全可审计的内核的原因相吻合：语言还未完善。例如，在我们编写Xous的时候，引入了常量泛型（const generic）。在这之前，Rust没有处理大于32个元素的数组（Array）的能力。这种限制有点让人抓狂，即使在今天也有一些缺点，比如Default trait 无法初始化大于32个元素的数组。这种阻碍导致我们把许多东西限制在32个元素：例如，当我们在进程之间传递 SSID 扫描的结果时，该结构只为最多 32 个结果保留空间，因为去更大、更多通用结构是不值得的。这是直接驱动面向用户的功能的语言级别限制。

另外，在编写Xous的过程中，像内联汇编（inline assembly）和工作空间（workspaces）这样的东西终于成熟了，这意味着我们需要回到过去，重新审视我们所做的一些“危险”的事情，使那些关键的几行用汇编编写的初始启动代码能够集成到我们的构建系统中。

我经常问自己“我们什么时候才能离开 Rust 发布火车（火车式发布）”，我认为的答案是他们最终让alloc稳定下来。目前，no-std target 无法访问堆，除非它们跳上“Nightly”列车，在这种情况下，你又回到了 Python 式的噩梦，你的代码经常因语言版本而中断。

我们绝对给了用no-std和 Stable Rust编写操作系统一个公正的机会。Xous第一年的开发都是用no-std完成的，在内存空间和复杂性方面付出了代价。我们有可能只用预先分配好的静态数据结构来编写操作系统，但我们必须在所有情况下满足最坏情况下的元素数量，这导致了臃肿。此外，我们还不得不推出很多自己的核心数据结构。

大约一年前，当Xobs将Rust的std库移植到Xous时，这一切都改变了。这意味着我们能够在稳定的Rust中访问堆，但这是有代价的：现在Xous被捆绑在一个特定的Rust版本上，因为每个版本的Rust都有自己独特的std打包版本。这个版本的绑定是有原因的：std是可以将内存分配和线程创建等基本 Unsafe 的硬件结构变成 Safe 的Rust结构的地方。(我最近还了解到一个有趣的事实。Rust对于大多数 target 没有本地分配器--它只是简单地使用libc的malloc()和free()函数！) 换句话说，Rust能够有力地保证稳定版本的“火车”不破坏旧的功能，部分原因是所有的松散部分都被扫进了std。

我必须不断提醒自己，拥有 std 并不能消除关键代码中严重安全漏洞的风险——它只是将许多关键代码移到了标准库中。是的，它是由一群比我聪明的天才程序员维护的，但归根结底，我们都只是人类，我们都是软件供应链攻击的公平目标。

Rust有一个发条式的发布时间表：每六周就会推送一个新版本。由于我们的 "std "分叉与特定的Rust版本相联系，这意味着每六周，Xobs都要承担更新我们的分叉并为其建立新的 "std "版本的艰巨任务（我们不是Rust的一级平台，这意味着我们必须维护自己的 "std "库）。这意味着我们同样迫使所有Xous开发者在他们的工具链上运行rustup update，这样我们才能保持与语言的兼容性。

这可能是不可持续的。最终，我们需要锁定代码库，但我没有一个明确的退出策略。也许我们可以考虑回到 "nostd "的下一个时间点，就是我们可以获得稳定的 "alloc "功能，这让我们可以再次访问堆。这样我们就可以把Xous从Rust发布的列车上解开，但我们仍然需要回填一些功能，如 Vec、HashMap、Thread和 Arc/Mutex/Rc/RefCell/Box结构，使 Xous 能够有效地进行编码。

不幸的是，[alloc' crate 非常难](https://rust-lang.github.io/rfcs/2480-liballoc.html "")，而且已经开发了很多年了。虽然如此，我真的很欣赏Rust在开发这一功能背后的透明度，以及为稳定这一功能所做的努力和思考。

“译者注：这一点，也许学习一下 Android 和 Fuchsia 如何引入 Stable Rust 工具链会对他有所启发。当然，因为 Xous 是纯 Rust 实现，而 Android 和 Fuchsia 是部分模块或组件用 Rust，后者可能没有 Xous 的麻烦。

Rust 对供应链安全的观点有局限

我认为这一立场被rustup.rs安装页面推荐的安装方法很好地概括了: “嗨，在你机器上运行这个来自随机服务器的 shell 脚本。”

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

公平地说，你可以下载脚本并在运行前检查它，这比 Windows .MSI安装程序的vscode要好得多。然而，这种做法充斥着整个构建生态系统：每当你从crates.io Pull 一个新的crate时，一个名为build.rs的桩代码就有可能被编译和执行。这一点，加上 "宽松 "的版本定位（你可以指定一个版本，例如，简单的 "2"，这意味着你将抓取任何最新发布的版本，主要版本为2），使我对通过crates.io生态系统发起软件供应链攻击的可能性感到不安。

Crates.io还受到一种错别字的影响，很难确定哪些是 "好 "的，哪些是 "坏 "的；一些名字和你想要的一模一样的 crate，结果只是旧的或被放弃的早期尝试，给你提供了你想要的功能，而更受欢迎的、积极维护的 crate 不得不采取不太直观的名字，有时与其他 crate 只有一两个字符的差别（公平地说，这不是Rust的包管理系统特有的问题）。

还有一个事实是，依赖关系是链式的--当你从crates.io Pull 一个东西的时候，你也 Pull 了该crate的所有附属依赖关系，以及所有最终会在你的机器上运行的build.rs脚本。因此，仅仅审核Cargo.toml文件中明确指定的crate是不够的，你还必须审核所有依赖的crate，以防止潜在的供应链攻击（upply chain attacks）。

幸运的是，Rust允许你使用 Cargo.lock 文件将 crate 固定在一个特定的版本上，你可以完全指定一个依赖 crate ，直到次要版本。在Xous中，我们试图通过发布Cargo.lock文件和指定所有第一阶的依赖 crate 到次要版本的政策来缓解这一问题。我们还对某些 crate 做了本地备份（vendored）和 forked，否则会使我们的依赖树增长而没有什么好处。

这就是说，我们的大部分调试和测试框架都依赖于一些相当花哨和复杂的 crate，这些crate Pull 了大量的依赖关系，而令我懊恼的是，即使我试图为我们的目标硬件运行一个构建，用于在主机上运行模拟的依赖 crate 仍然被 Pull 了下来，build.rs脚本即使没有运行，至少也被构建了。

针对这种情况，我写了一个叫 `crate-scraper`[13]的小工具，它可以下载Cargo.toml文件中指定的每一个源码包，并将它们存储在本地，这样我们就可以有一个用于构建Xous版本的代码快照。它还可以进行快速的 "分析"，即搜索名为build.rs的文件，并将它们整理成一个文件，这样我就可以更快速地通过grep来寻找明显的问题。当然，人工审查并不是检测嵌入build.rs文件中的巧妙伪装的恶意软件的实用方法，但它至少让我了解我们正在处理的攻击面的规模: 它是令人惊叹的[14]，大约有5700行来自不同第三方的代码，它们操纵文件、目录和环境变量，并且在我每次进行构建时在我的机器上运行其他程序。

我不确定这个问题是否有好的解决方案，但是，如果你是超级偏执狂，而且你的目标是能够构建可信赖的固件，那么就要警惕Rust的广泛的软件供应链攻击面。

你无法重现（reproduce）别人的 Rust 构建

我对Rust的最后一个问题是，在不同的计算机之间，构建是不可重现的（如果我们禁用我在Xous中为$reasons而嵌入的时间戳，它们至少在同一台机器上的构建之间是可重现的）。

我认为这主要是因为Rust将源代码的完整路径作为二进制文件中的恐慌（panic）和调试（debug）字符串的一部分拉进来。这导致了一些不舒服的情况，我们在 Windows 上构建了工作，但在 Linux 下失败了，因为我们的路径名在两者上的长度非常不同，这会导致一些内存对象在目标内存中移动。公平地说，这些失败都是由于我们在 Xous 中存在的错误，这些错误已经得到修复。但是，知道我们最终会有用户向我们报告我们无法重现的错误，这感觉并不好，因为他们在构建系统上的路径与我们的不同。对于想要通过构建自己的版本并将哈希值与我们的哈希值进行比较来审核我们发布的用户来说，这也是一个问题。

在Rust的维护者那里有一些bug，以解决可重复构建的问题，但由于他们必须处理语言中的许多问题，我对这个问题能否很快得到解决并不感到乐观。假设导致不可重现性的唯一原因是二进制文件中包含了操作系统的路径，那么解决这个问题的一个办法就是重新配置我们的构建系统，使其在某种chroot环境或虚拟机中运行，以一种几乎任何人都能重现的方式修复路径。我说 "几乎任何人 "是因为这个修复方法将取决于操作系统，所以我们将能够在例如Linux下获得可重复的构建，但它不能帮助Windows用户，因为chroot环境不是一个东西。

Rust 超乎预期的地方

尽管这里列出了所有的抱怨，但我认为如果我必须重新做一遍，Rust 仍然是我用于 Xous 的有力竞争语言。我做过 C、Python 和 Java 的大型项目，所有这些项目最终都背负着“不断增加的技术债务”（可能有一个软件工程师的术语来描述这种情况，我只是不知道）。问题往往是从一些数据结构开始的，我在第一遍的时候不能完全弄好，因为我还不知道这个系统是如何组成的；所以为了弄清楚这个系统是如何组成的，我就用一个半生不熟的数据结构拼凑出一些代码。

于是就开始陷入混乱：一旦我对事情的运作有了一个概念，我就回去修改数据结构，但现在在其他地方出现了一些未曾预料到的、微妙的破坏。也许这是一个逐个击破的问题，或者一个符号的极性似乎被颠倒了。也许这是个轻微的竞态条件，很难说清楚。没关系，我可以通过把<=改成<，或者修改符号，或者增加一个锁来解决这个问题。我仍然在充实这个系统，对整个结构有一个概念。最终，这些小的 hack 代码（意指非正规写法，只图完成功能）往往会转移到每一个依赖的模块中，因为事情的全部原因是由于 "作弊 "而产生的；当我回去切除这些 hack 代码时，我最终得出结论，它不值得努力，所以下一个最好的选择是把整个事情烧掉重写...但不幸的是，我们已经落后于计划和预算，所以重写从未发生，而hack代码继续生存。

Rust是一种很难编写代码的语言，因为它使这些 "作弊 "变得很难：只要你有纪律，不使用 Unsafe 的结构来使作弊变得容易。然而，真正的困难并不意味着不可能--在构建Xous的过程中，肯定有一些作弊行为被掩盖了起来。

这就是 Rust 真正超出我预期的地方。该语言的结构和工具非常擅长追捕这些作弊并对重构代码库有帮助，从而能达到“治愈癌症而不杀死患者”的效果，可以这么说。这就是 Rust 非常严格的类型和借用检查器将生产力负债转换为生产力资产的点。

我把它比作在穿过建筑物的复杂电缆束中更换电缆。在 Rust 中，可以保证电缆槽中的每一根线，无论线束变得多么复杂和糟糕，都是可分离的，并且两端都有清晰的标签。因此，您始终可以“拉到一端”并通过更改结构中元素的类型或方法的返回类型来查看另一端在哪里。在较不严格类型的语言中，您不会获得此属性；电缆可以在电缆槽内的某处合并并相互影响，因此在进行更改后，您只能通过手动测试“嗡嗡作响”每条电缆。即使这样，您也永远无法确定当有人打开浴室灯时，您更换的东西是否会导致咖啡机关闭。

这里有一个能说明Rust的重构能力在Xous中的作用的示例。在我们的图形子系统（我称之为GAM（Graphical Abstraction Manager[15]））中，处理信任级别的方式有一个问题。系统中的每个Canvas都有一个`u8'分配给它，这是一个信任等级。当我开始写GAM时，我只知道我想要一些关于Canvas的可信任度的概念，所以我添加了这个变量，但并不确定它到底会被如何使用。几个月后，系统增加了带布局的上下文概念，布局是定义特定类型互动的多画布结构。现在，你可以有多个信任等级与一个上下文相关联，但我已经忘记了我之前放在Canvas结构中的信任变量--并且在上下文结构中也添加了另一个信任等级数字。你可以看到这是怎么回事：只要我有简单的测试案例，一切都能正常工作，但当我们开始在应用程序上弹出窗口，然后在窗口之上的菜单等等，疯狂的行为开始显现，因为我已经混淆了信任值的存储位置。有时我在更新Context中的值，有时我在更新Canvas中的值。它有时会表现为一个逐个击破的错误，有时则表现为一个并发错误。

这一直是困扰我的一件难以描述的事，而GAM已经成长为一个有许多移动部件的5千行的畸形代码。最后，我决定必须对此做些什么，但我真的不希望这样做。我认为我搞砸了什么，这次调查将以重写整个模块而告终。

幸运的是，Rust给我留下了一根小小的绳子。Clippy，也就是Rust中的 "linter"，在我认为应该使用信任度变量的地方发出了一个警告--我在Context中存储了它，但之后没有人提到它。这很奇怪--它应该在每次重绘上下文时都是必要的！因此，我开始删除变量。所以，我开始删除这个变量，看看有什么问题。这很快让我想起，当画布被创建时，我也在画布内存储了信任度，这就是为什么我有这个悬空的引用。一旦我有了这个线索，我就能够重构信任的计算，只参考那个基础真理的来源。这也让我发现了其他一直潜伏着的错误，因为事实上我从来没有行使过一些我认为是常规使用的代码路径。经过几个小时的探究，我对这一切是如何运作的有了清晰的认识，我用简单易懂的API重构了信任计算系统，而不必折腾整个代码库。

这只是我在维护Xous代码库时使用Rust的许多积极经验之一。这是我第一次抬头挺胸，以积极的态度走进一个大版本，因为这是第一次，我觉得也许我有机会能够以诚实的方式处理困难的bug。我花在脑子里找借口的时间越来越少，以证明为什么事情是这样做的，为什么我们不能接受那个 Pull Request，而花更多的时间思考所有的事情可以变得更好，因为我知道Clippy在支持我。

对看此篇文章的 Rust 开发者的告诫

无论如何，对于一个硬件人(指作者本人)来说，这是很多关于软件的吐槽。很快就会有软件开发者提醒我，首先，我做的是电路和铝壳，而不是写代码的，所以我没有资格抱怨软件。他们是对的。我实际上没有接受过“以正确的方式”编写代码的“正式”培训。当我在大学时，我学习了麦克斯韦方程，而不是算法。我永远不可能成为一名专业的程序员，因为我连最简单的编码面试都过不了。不要让我写链表：我已经知道我不知道如何正确地去做；你不需要向我证明这一点。这是因为每当我发现自己在写一个链表（或任何其他基础数据结构）时，我都会立即停下来，质疑所有让我走到那一步的人生选择：这不是库的用途吗？难道我真的需要重新发明轮子吗？如果在编码面试中表现出色与实际编码能力之间存在任何关联，那么您绝对应该对我的意见持保留态度。

尽管如此，在花了几年时间使用Rust并阅读了无数关于该语言的文章之后，我觉得也许发表一篇关于该语言的批判性观点的文章会让人耳目一新。

参考资料

[1]

Rust: A Critical Retrospective：https://www.bunniestudios.com/blog/?p=6375: https://www.bunniestudios.com/blog/?p=6375

[2]

Xous: https://betrusted.io/xous-book/

[3]

QNX: https://en.wikipedia.org/wiki/QNX

[4]

Xous: https://github.com/betrusted-io/betrusted-wiki/wiki

[5]

Precursor: https://precursor.dev/

[6]

称为PDDB: https://www.bunniestudios.com/blog/?p=6307

[7]

CPU运行在FPGA中: https://github.com/betrusted-io/betrusted-soc

[8]

CHERI: https://www.cl.cam.ac.uk/research/security/ctsrd/cheri/

[9]

正在改变: https://gankra.github.io/blah/fix-rust-pointers/

[10]

第12章: https://docs.python.org/3/tutorial/venv.html

[11]

eli5 风格: https://doc.rust-lang.org/rust-by-example/attribute/cfg.html

[12]

正式的语法定义: https://doc.rust-lang.org/reference/conditional-compilation.html

[13]

crate-scraper: https://github.com/betrusted-io/crate-scraper

[14]

令人惊叹的: https://github.com/betrusted-io/crate-scraper/blob/main/builds.rs

[15]

Graphical Abstraction Manager: https://github.com/betrusted-io/xous-core/tree/main/services/gam