Rust 抽象机中充满了在实际硬件上不存在的奇妙细节。不可避免地，每次讨论这些时，总会有人问：“但如果我使用内联汇编呢？那指针来源、未初始化内存、树形借用以及你们发明的这些实际不存在的‘有趣’东西会怎样？”

这是个好问题，但要正确回答需要一些功夫。在这篇文章中，我将通过提出一个通用原则来阐述当前对内联汇编如何融入 Rust 抽象机的思考：该原则解释了我们对纯 Rust 语义的任何决定如何影响内联汇编可以或不可以做什么。

请注意，我在这里讨论的所有内容同样适用于外部函数接口调用，就像适用于内联汇编一样。这两种机制本质上非常相似：它们都允许 Rust 代码调用非 Rust 编写的代码。¹ 我不会在文章中反复重复“内联汇编或 FFI”，但每次我提到内联汇编时，也包含了 FFI。

首先，让我解释一下为什么有些事情是内联汇编从根本上就不允许做的。

为什么内联汇编不能为所欲为？

人们喜欢认为内联汇编能让他们摆脱抽象机所有复杂的要求。不幸的是，那只是个空想。下面是一个示例来证明这一点：

use std::arch::asm;

#[inline(never)]
fn innocent(x: &i32) { unsafe {
    // 在 x 给出的地址存储 0。
    asm!(
        "mov dword ptr [{x}], 0",
        x = in(reg) x,
    );
} }

fn main() {
    let x = 1;
    innocent(&x);
    assert!(x == 1);
}

当编译器分析 main 时，它意识到只有一个共享引用被传递给 innocent。这意味着无论 innocent 做什么，它都无法改变存储在 *x 中的值。因此，这个断言可以被优化掉。

然而，innocent 确实写入了 *x！因此，优化改变了程序的行为。确实，这正是当前版本的 rustc 所发生的情况：没有优化时，断言失败；但开启优化时，它通过。因此，要么优化是错误的，要么程序存在未定义行为（UB）。既然我们确实希望进行这种优化，那么我们只能选择第二种可能。²

然而，UB 从何而来？如果整个程序都是用 Rust 编写的，答案会是“别名模型”。栈借用（Stacked Borrows）和树形借用（Tree Borrows），以及任何其他为 Rust 考虑的值得考虑的别名模型，都会将通过从共享引用派生的指针进行写入视为 UB。但这次，程序的部分不是用 Rust 编写的，所以事情没那么简单。我们怎么能说内联汇编块违反了树形借用呢？它使用的语言甚至没有类似树形借用的东西。这就是本文剩余部分要讨论的内容。

我希望这个例子清楚地表明，我们无法让内联汇编完全忽略抽象机概念（如树形借用）。内联汇编块导致了 UB，我们只需要弄清楚它是如何以及为什么导致的——更重要的是，我们必须弄清楚人们如何确保他们的内联汇编块不会导致 UB。

内联汇编何时与优化兼容？

看起来我们现在必须定义一个能与汇编代码配合工作的树形借用版本。这将是一项不可能的任务（树形借用依赖于指针来源，这在汇编中并不存在）。³ 幸运的是，这也没必要。

相反，我们可以依托于已经存在的树形借用和抽象机的其余部分的定义。我们通过要求程序员用 Rust 术语来讲述一个故事，说明内联汇编块做了什么来实现这一点。⁴（如果这听起来很奇怪，请听我解释。我将解释为什么这合理。）具体来说，对于每个内联汇编块，都必须有一个对应的 Rust 代码片段，在纯 Rust 代码可观察的状态方面做同样的事情。在推理整体程序的行为时，内联汇编块将被该“故事”代码替换。你不必实际编写这段代码；重要的是这段代码存在，并且能与周围的 Rust 代码讲述一个连贯的故事。

对于上面的例子，这立即解释了哪里出错了：该内联汇编块的故事代码必须类似于 (x as *const i32 as *mut i32).write(0)，如果我们用这段代码代替内联汇编块，我们立即就能看出（Miri 也可以确认）程序存在 UB。一个内联汇编块可以有多种可能的故事，只要找到一个让一切合理的即可，但在这种情况下，这是不可能的。

那么，稍微详细一点，以下是我认为适用于内联汇编的规则：

1. 对于每个内联汇编块，选择一个“故事”：一段 Rust 代码，作为该汇编块在抽象机状态方面做了什么的代表。这段故事代码只能访问提供给该内联汇编块的数据（显式操作数和全局变量）。在抽象机层面推理程序的健全性和正确性时，我们假装故事代码被执行，而不是汇编代码。
2. 这段代码必须满足诸如 readonly 或 nomem 等属性强加给 asm 块的所有要求，并且尊重操作数约束，例如不修改 in 操作数。
3. 实际的汇编代码必须细化故事代码，即汇编代码对抽象机可观察状态（特别是操作数和全局变量）所做的任何事情，都必须是故事代码也能做到的事情。

我应该声明，我没有一个能证明这种方法正确性的形式化理论。然而，我相当有信心，因为这种方法与我们证明优化（如上面例子中的优化）正确性的方法非常吻合：正确性论证的核心是一个证明，即所有 Rust 代码都满足某些普遍属性。例如，我们可以形式化并证明这样一个主张：任何接受没有内部可变性的共享引用作为参数的 Rust 函数都不能写入该参数。这并非唯一的此类属性；事实上，此类属性的集合并未完全知晓：我们明天可能会发现所有 Rust 代码都遵循的一个新属性。关键在于，任何“对于所有 Rust 程序，……”形式的属性也必须适用于故事代码，因为它就是普通的 Rust 代码！最后，因为实际的汇编代码细化了故事代码，我们知道为了推理程序，我们可以假装实际上是故事代码被执行，然后在编译结束时用所需的汇编代码替换故事代码，而不会改变程序行为。

所以，这就是故事代码有效的原因。但是，这难道不是让内联汇编变得完全无用吗？毕竟，内联汇编的全部意义就在于做我在纯 Rust 中无法做到的事情！

通过示例理解内联汇编故事

为了说服你讲故事的方法是可行的，让我们考虑几个内联汇编使用的代表性示例，以及相应的故事可能是什么样子的。

纯指令

最简单的情况是代码想要访问语言中未暴露的新硬件操作。例如，内联汇编块可能只包含一条指令，该指令返回寄存器中设置为 1 的位数。在这里，讲故事很简单：我们可以手动编写一些位操作代码来计算设置为 1 的位数。

页表操作

那很简单，所以让我们加大难度，考虑一个操作页表的操作系统内核。Rust 没有页表的概念。这里的“故事”可能是什么样子？

答案是，Rust 有一些与向页表中放入新页面非常相似的东西——它叫做 alloc。它还有一些非常类似于移除页面（dealloc）和将页面移动到地址空间中不同位置（realloc）的东西。因此，操作系统内核要告诉编译器的故事是，操作页表实际上只是某种奇怪的内存分配器。

更具体一点，以一种与讲故事方法兼容的方式“分配”一个页面可能如下所示：

• 首先，一些 Rust 代码使用 volatile 加载和存储来执行实际的页表操作。⁵
• 然后，一个 asm 块执行当前系统上所需的任何屏障，以确保更新的页表生效。
• 接着，页面的地址被转换为指针（使用 with_exposed_provenance）。
• 最后，Rust 代码可以使用该指针来访问新页面。

这个 asm 块的故事是它执行了给定地址的内存分配，我们知道该地址未被分配。⁶ 这创建了一个代表新分配的新指针来源。该分配随后立即被故事代码暴露。

即使在页表更改后不需要屏障的架构上，asm 块仍然至关重要：它防止编译器在页表操作期间重排对新页面的访问！使用 Rust 程序的常规规则，编译器无法弄清这里有任何依赖关系。因此，asm 块充当了编译器栅栏：就编译器而言，这个块可能确实调用了我们编造的“故事代码”，因此新的指针以及基于它的操作不能移动到 asm 块之前。

这就是为什么有时人们认为 asm 块是编译器栅栏：一个 asm 块代表了编译器不知道的某个任意的“故事代码”，因此编译器必须好像有某个任意代码在此执行一样来对待这段代码，这阻止了大多数重排序。但这里的重点在于大多数：如果编译器有额外的别名信息，例如来自 &mut 类型，这能让编译器推理并在内存访问中重排序，即使跨越未知函数调用，因此也跨越内联汇编块。所以说 asm 块是阻止所有重排序的栅栏是错误的。以编译器栅栏的角度思考可以提供有用的直觉，但严谨的正确性论证需要更深入的细节。

这个故事中还有另一个注意事项：对于页表操作，不能只创建新的分配，也可以扩展现有分配。事实上，使用 mmap，从用户空间也可以做到同样的事情。结果证明扩大分配是无害的，因此这在 LLVM 中已正式认可，我们应该找到在 Rust 端也公开这一点的方法。然而，缩小分配是有问题的——LLVM 可能合理进行的简单优化会破坏缩小分配的代码！因此，需要进一步的工作来确保 Rust 代码（以及 C 和 C++ 代码）可以使用 munmap 而不会冒险导致错误编译。这就是为什么采取原则性的语言语义和正确性方法如此重要：否则，很容易错过这样的潜在问题。

页表操作 II：复制页面

接下来，让我们考虑另一个页表戏法：将单个物理内存页面映射到虚拟内存中的多个位置。这意味着该页面被“镜像”在多个地方，修改任何一个镜像都会更改所有镜像。首先，要注意这通常是不健全的。LLVM 会自由地假设 ptr 和 ptr.wrapping_offset(4096) 不别名，因此将相同内存映射到多个地方并自由访问所有地方可能导致微妙的错误编译。然而，有一种受限形式，我们可以使用内联汇编来构思一个符合抽象机的“故事”，因此是健全的。

关键的限制是程序一次只能使用此内存的“镜像”版本之一。更改哪个镜像是“活动的”需要一个显式屏障，并返回一个新的指针，该指针必须用于未来的访问。这个屏障可以是一个空的内联汇编块，只是返回未更改的指针，但我们附加给它的故事却非空：我们将说它的行为类似于 realloc，在逻辑上将分配从一个镜像移动到另一个。换句话说，就 Rust 抽象机而言，只有一个镜像版本的内存实际“存在”，切换到另一个意味着释放旧分配并创建新分配。关键在于，与 realloc 一样，在每次这样的切换后，所有指向该内存的旧指针都变为无效，而切换返回的新指针是访问该内存的唯一方式。⁷ 这些内联 asm 块还将阻止 LLVM 在不同的“镜像”访问之间重排序，从而避免了上述错误编译。换句话说，以一种让我们能够讲述恰当故事的方式修改我们的代码，也引入了足够的结构来防止优化器做它不应该做的事情。

这听起来可能有点牵强，但这种“纯逻辑的” realloc 确实出现在不止一种情况中；甚至有一个正在讨论的 RFC 提议将其添加到语言本身。

非时序存储

前一个例子已经表明，有些硬件特性过于侵入性，无法在 Rust 这样的高级语言中自由使用。非时序存储是另一个例子。具体来说，我指的是 x86 上的“流式”存储操作（_mm_stream_ps 及类似指令）。这些操作的主要目的是避免用可能很快不会再被读取的数据塞满缓存，但它们也有一个不幸的副作用：破坏了 x86 通常的“全存储顺序”内存模型。这是个坏消息，因为程序其余部分的编译依赖于该内存模型。

为了解释这个问题，让我们考虑一个非时序存储的“故事”可能是什么。显而易见的选择是让它只是一个常规的写访问——毕竟缓存并未在抽象机中建模。不幸的是，这行不通。考虑流式存储后跟一个原子释放写入的情况。由于 x86 的全存储顺序模型，这会被编译成没有任何额外栅栏的普通写入指令。然而，流式存储实际上确实需要一个栅栏（_mm_sfence）来正确同步。因此，可以编写一个看似无数据竞争（根据故事）但实际有数据竞争的 Rust 程序。换句话说，违反了规则 3（内联 asm 块必须细化故事代码）。

对此的原则性修复是扩展 C++ 内存模型（Rust 共享该模型），加入非时序存储的概念，以便能够推理它们与并发程序中可能发生的所有其他事情的交互。这是可能的，但它需要重新证明编译器正确性结果，而且至少在该论文中采取的方法是针对特定架构的，无法扩展到 Rust 支持的众多架构。然而，有一个更简单的替代方案：我们可以尝试构思一个更复杂的故事，使得规则 3 不被违反。这正是当人们发现非时序存储相关问题时所做的事情。故事是，进行非时序存储对应于生成一个线程，该线程将异步执行实际的存储，而 _mm_sfence 对应于等待所有这些线程完成。这解释了为什么释放-获取同步会失败：同步会获取释放线程执行的所有写入，但流式存储在概念上是在另一个线程上发生的！这个新故事代码成为了更新后的 x86 流式存储文档的基础，代码本身甚至可以在代码注释中找到。

有一个注意事项：我们选择的故事意味着执行流式存储的线程在 _mm_sfence 之前从该内存进行加载是未定义行为（UB），即使此操作在底层硬件上是定义良好的。这是我们为拥有一个关于使用流式存储的代码不会被错误编译的原则性论证所付出的代价。这个代价并不高：流式存储用于可能很快不会再被读取的数据，这就是它们的全部意义。我们在野外发现的所有流式存储示例都没有遇到这个限制的问题。⁸

栈绘制

内联汇编的另一个可能用途是使用栈绘制来测量程序的栈消耗量。这在 t-opsem Zulip 频道中被提出作为一个问题，我把它放在这里是因为它很好地展示了讲故事方法提供了多少自由度，以及它有哪些限制。

粗略地说，栈绘制意味着在程序开始之前，将稍后将成为栈的内存区域填充为固定的比特模式。之后，我们可以通过检查比特模式仍然完好的位置以及被覆盖的位置来测量程序的最大栈使用量。这可以使用直接读取栈的内联汇编代码来完成。

第一反应可能是说这显然是 UB：那块栈内存可能受到无别名约束（由于一个指向栈的可变引用）；你不能直接读取你没有权限读取的内存。然而，这预设了这个 asm 块的故事涉及读取内存。一个替代的故事是说这个 asm 块只是返回某个任意的、非确定性选择的值。这个故事的优点是，只要读取不陷入陷阱，根据我们的规则，故事总是正确的：无论汇编代码实际做什么，它肯定细化了返回一个任意值。然而，这个故事的缺点是，当推理我们的代码时，我们不能对读取的值做出任何假设！我们程序的正确性是在讲故事语义下定义的，即程序必须无论内联 asm 返回什么值都是正确的。这听起来可能是个问题，但在这个用例中，它实际上完全没问题：栈绘制反正只提供真实栈使用量的估计值。编译器不保证以这种方式产生的测量是大致准确的，但实验表明这在实践中效果很好。不准确的测量不会导致健全性或正确性问题，因此提供准确答案“只是”一个生活质量问题。

浮点状态和控制寄存器

我最后想考虑的例子是浮点状态和控制寄存器。这是一个讲故事方法主要用来解释为什么使用这些寄存器是不可能或没有用处的例子。

程序员有时想读取状态寄存器以检查是否发生了浮点异常，并写入控制寄存器以调整舍入模式或浮点计算的其他方面。然而，实际支持这样的控制寄存器更改对优化来说是灾难性的：控制寄存器是全局（好吧，是线程局部的）状态，这意味着它会影响所有后续操作，直到寄存器再次被更改。这意味着为了优化任何可能需要舍入的浮点操作，编译器必须静态预测控制寄存器的值将是什么。这通常不太可能，因此编译器通常改为假设控制寄存器始终保持在其默认状态。（有时它们提供退出该假设的方法，但这很难做好，Rust 目前没有相关设施。）状态寄存器问题不那么明显，但请注意，如果我们说浮点操作可以修改状态寄存器，那么它就不再是一个纯操作，因此不能自由地重排序。为了让编译器能够对浮点操作进行像公共子表达式消除这样的基本优化，语言通常也认为状态寄存器是不可观察的。

这对读取/写入这些寄存器的内联汇编代码意味着什么？对于读取状态寄存器，这意味着故事代码无法说出这与实际的浮点操作有任何关系。抽象机中没有故事代码可以读取的浮点状态位，因此最好的故事是返回一个非确定性的值。这直接反映了编译器不会对程序在状态寄存器中观察到的值做任何保证这一事实，并且由于浮点操作可以任意重排序，这应该被相当字面地理解。

对于写入控制寄存器，根本没有可能的故事：没有任何 Rust 操作会改变后续浮点操作的舍入模式。因此，任何更改舍入模式的内联 asm 块都具有未定义行为（同样适用于其他改变 Rust 编译器使用的指令行为的标志，如将非规格化数刷新为零）。

虽然这听起来令人沮丧，但完全有可能编写一个内联 asm 块，它更改舍入模式，执行一些浮点操作，然后将其更改回来！这个块的故事代码可以使用软浮点库来执行与非默认舍入模式下完全相同的浮点操作。关键是，由于 asm 块整体上没有改变控制寄存器，故事代码甚至不需要担心那个寄存器。换句话说，有一个执行浮点操作的大 asm 块，使用非默认舍入模式，这是可以的。从优化的角度来看，这也说得通：没有风险将浮点操作移动到舍入模式不同的代码区域。

结论

我希望这些例子有助于展示讲故事方法的灵活性和局限性。在许多情况下，无法构思出一个故事直接对应于潜在的错误编译。这很好！那些是我们必须规定为不正确的内联 asm 块。⁹ 然而，在某些情况下，没有明显的错误编译。而且确实，如果我们确切知道编译器依赖于哪些 Rust 程序的普遍属性，我们可以允许满足所有这些普遍属性的内联 asm 代码，即使它没有可以表示为 Rust 源代码的故事。不幸的是，这种方法要求我们承诺编译器可能使用的全部普遍属性集合。如果我们明天发现一个新的普遍属性，我们就不能使用它，因为可能有一个内联 asm 块不满足该普遍属性。

这就是为什么我建议采取保守的方法：只允许那些显然与所有实际 Rust 代码的普遍属性兼容的内联 asm 块，因为它们的故事可以表达为实际的 Rust 代码。如果我们想允许某个操作，而它目前没有有效的故事，我们只需添加一个新的语言操作，这相当于正式认可该操作是编译器将继续尊重的操作。

目前，我们没有关于内联 asm 块和 FFI 如何与 Rust 级别的 UB 交互的官方文档或指南，但正如文章顶部的 innocent 示例所示，我们不能让内联 asm 块像那样不受约束。讲故事的方法是我为填补这一空白而提出的建议。我计划最终将其作为内联汇编的官方规则提出。但在那之前，我想更确信这种方法真的能处理大多数现实场景。如果你有汇编块无法用讲故事解释的例子，但你确信它们是正确的，因此应该被支持，请告诉我们，可以在本文的即时讨论中（或者如果你是在稍后阅读此内容）在t-opsem Zulip 频道中。

脚注

由 mimo-v2.5 模型翻译，花费 16094 tokens

又到了写一篇“Miri近况如何”博文的时候了。 事实上，这确实拖得太久了，上一次更新已经是三年前的事了（时间到底是什么东西？！），但确实越来越难找到时间写博客了，所以……我们就这样吧。 迟到总比不到好。:)

对于不熟悉的人，Miri 是一个用于Rust的未定义行为测试工具。 这意味着它可以发现你unsafe代码中的bug，这些bug未能遵守诸如“所有访问必须对齐”、“可变引用绝不能别名”或“绝对不能有数据竞争”之类的要求。 Miri的成名之处在于它是一个实用工具，能够发现所有确定性Rust程序中事实上的未定义行为。 据我所知，没有其他免费工具能做到这一点——对任何语言来说都是如此。¹

我们只能谈论事实上的未定义行为，因为Rust尚未稳定其未定义行为的定义。 为此，我们仔细检查编译器的行为，尽最大努力确保Rust程序当前可能遇到的所有未定义行为都被Miri捕获。 这意味着通过Miri测试的程序应该能在当前的编译器上正确编译，但同一个程序在未来可能会遭受未定义行为。 此外，如果Rust程序是非确定性的，意味着它可以有多种执行方式，而Miri只会执行一次。 你可以使用 -Zmiri-many-seeds 让Miri随机探索多种可能的执行，但总可能还有Miri尚未发现的执行路径。 这是所有测试工具的根本局限；你通常需要借助模型检查或演绎验证来克服。

要了解更多关于Miri的信息，你可以阅读这篇论文。 是的，我们有一篇论文！这是第一个新闻。 《Miri：Rust实用未定义行为检测》已被POPL 2026接收，这是编程语言基础研究领域最负盛名、竞争最激烈的会议之一。

更新（2026-02-04）： 会议关于此论文的演讲录像现已上线。

Miri 进展

论文就说到这。过去三年里Miri取得了哪些进展？ 我们在此期间合并了超过1500个PR，不可能详述所有细节，但我会尽力概述总体趋势并指出一些重大事项。

垫片

为Miri添加的新功能主要是为在Rust外部实现的函数添加垫片，因此这些函数无法被Miri直接执行。 这主要涉及操作系统API以及CPU厂商提供的内部函数。 以下列表尝试总结自上次更新以来为Miri添加的垫片：

• 极大扩展了Windows API垫片的支持，特别涵盖基本文件访问（由 @beepster4096, @CraftSpider 完成）。
• 支持Unix（特别是Linux）上各种新的文件描述符类型，例如 socketpair（仅 SOCK_STREAM）、pipe 和 eventfd（由 @DebugSteven, @tiif, @RalfJung, @FrankReh 完成）。
• 支持 Linux 的 epoll（由 @tiif 主导，并得到 @DebugSteven, @FrankReh, @RalfJung 的一些基础工作和扩展支持）。
• 拓宽通用文件API支持（由 @Pointerbender, @Jefffrey, @tiif, @newpavlov 完成）。
• 支持许多Intel厂商内部函数，涵盖从SSE2到AVX2（主要由 @eduardosm 完成，并得到 @TDecking, @Kixunil 的帮助）。感谢 @folkertdev，Miri甚至支持一些AVX-512内部函数，使其成为你可能无法在真实硬件上运行的代码的合适测试平台。
• 支持FreeBSD上的基本功能（由 @devnexen 和 @LorrensP-2158466 完成）。
• 支持Illumos和Solaris上的基本功能（由 @devnexen 完成）。
• 支持Android上的基本功能（由 @YohDeadfall 完成）。
• 改进pthread同步操作的垫片（由 @Mandragorian, @LorrensP-2158466, @RalfJung 完成）。
• 扩展了对macOS特定API的支持（由 @joboet 完成）。
• 支持弱定义（由 @bjorn3 完成）。
• 支持各种小型系统API（由 @folkertdev, @Mandragorian, @tgross35, @rayslava, @LorrensP-2158466, @YohDeadfall, @vishruth-thimmaiah, @saethlin, @RalfJung 完成）。
• 支持在 main 之前执行的全局构造函数（由 @ibraheemdev 完成）。

诊断信息

自上次博文以来，我们的诊断能力有了显著提高，这主要归功于 @saethlin。 例如，数据竞争错误现在会指出导致竞争的两个访问：

error: Undefined Behavior: Data race detected between (1) non-atomic read on thread `unnamed-1` and (2) non-atomic write on thread `unnamed-2` at alloc87
  --> tests/fail/data_race/read_write_race.rs:24:13
   |
24 | ...   *c.0 = 64; //~ ERROR: Data race detected between (1) non-atomic read on thread `unnamed-1` and (2) non-atomic write on thread ...
   |       ^^^^^^^^^ (2) just happened here
   |
help: and (1) occurred earlier here
  --> tests/fail/data_race/read_write_race.rs:19:24
   |
19 |             let _val = *c.0;
   |                        ^^^^

释放后使用错误会显示指针指向的内存分配的创建和释放位置：

error: Undefined Behavior: memory access failed: alloc194 has been freed, so this pointer is dangling
 --> tests/fail/dangling_pointers/dangling_pointer_deref.rs:9:22
  |
9 |     let x = unsafe { *p }; //~ ERROR: has been freed
  |                      ^^ Undefined Behavior occurred here
  |
help: alloc194 was allocated here:
 --> tests/fail/dangling_pointers/dangling_pointer_deref.rs:6:17
  |
6 |         let b = Box::new(42);
  |                 ^^^^^^^^^^^^
help: alloc194 was deallocated here:
 --> tests/fail/dangling_pointers/dangling_pointer_deref.rs:8:5
  |
8 |     };
  |     ^

Stacked Borrows错误会显示相关指针的创建位置以及失效位置：

error: Undefined Behavior: attempting a write access using <254> at alloc115[0x0], but that tag does not exist in the borrow stack for this location
 --> tests/fail/stacked_borrows/illegal_write2.rs:8:14
  |
8 |     unsafe { *target2 = 13 }; //~ ERROR: /write access .* tag does not exist in the borrow stack/
  |              ^^^^^^^^^^^^^ this error occurs as part of an access at alloc115[0x0..0x4]
  |
help: <254> was created by a SharedReadWrite retag at offsets [0x0..0x4]
 --> tests/fail/stacked_borrows/illegal_write2.rs:5:19
  |
5 |     let target2 = target as *mut _;
  |                   ^^^^^^
help: <254> was later invalidated at offsets [0x0..0x4] by a Unique retag
 --> tests/fail/stacked_borrows/illegal_write2.rs:6:10
  |
6 |     drop(&mut *target); // reborrow
  |          ^^^^^^^^^^^^

@Vanille-N 为Tree Borrows实现了类似的跟踪，因此其错误输出质量与Stacked Borrows相当。 @Zoxc 也贡献了改进涉及别名模型的数据竞争错误的逻辑。

性能优化

Miri的速度仍然不算快，但一些性能工作显著提升了Miri的别名检查速度：

• @saethlin 为Miri添加了指针标签的垃圾回收器，使得Stacked Borrows可以跳过大量与跟踪已不存在指针相关的工作。
• @JojoDeveloping 为Tree Borrows检查器添加了各种优化。

改进的并发支持

Miri中的数据竞争检查器和弱内存支持最初基于一篇遵循C++11并发语义的论文。 然而，Rust指定使用C++20语义，这需要进行一些调整。 @cbeuw 完成了大部分工作，并得到 @SabrinaJewson 和 @michaliskok 的帮助。 （有关更多细节，请参见论文第4节。） 作为撰写论文的一部分，我还在弱内存实现的核心部分发现并修复了两个缺陷。

此外，@geetanshjuneja 调整了Miri的调度器以实现完全非确定性，使得发现轮询调度不会出现的问题成为可能。 Furthermore, @pvdrz 在调度器中增加了完全“虚拟”计时支持，使Miri能够以完全确定性的方式支持单调时钟。 我还让Miri正确执行了只读内存中原子访问的限制（这在大多数情况下是禁止的，但有少数例外）。

最后，@Patrick-6 为将GenMC集成到Miri中奠定了基础。 GenMC是@michaliskok编写的弱内存模型检查器，这意味着它可以枚举并发程序的所有行为（只要程序没有无限循环）。 通过将它与Miri结合，我们可以对所有这些执行路径进行完整的未定义行为检查。 （我在引言中提到模型检查，确实是在为此铺垫。:)) 目前，使用Miri+GenMC仍然是高度实验性的、速度缓慢的，并且需要自定义构建Miri，但第一步已经迈出，我对这种组合未来的潜力感到非常兴奋！

从Miri调用原生代码

你知道Miri可以通过FFI执行从Rust调用的原生代码吗？ 这种支持非常实验性且不完整，显然原生代码的运行没有任何未定义行为检查，但自上次更新以来取得了显著改进：

• @Strophox 实现了与原生代码共享Rust分配内存的支持。
• @nia-e 添加了一些真正的魔法，让Miri能够相当精确地追踪原生代码访问了哪些内存，并利用这些信息改进Miri的未定义行为检查。我听说她计划未来让这个功能更加强大。:)

其他杂项

最后，我们有一些足够重要值得一提的贡献，但不符合上述任何类别：

• 内存泄漏检测器现在可以考虑主线程的线程本地存储（由 @max-heller 完成）。
• 我们对文件描述符的表示变得更加灵活和可扩展（由 @Luv-Ray, @oli-obk, @RalfJung 完成）。
• Miri现在使某些浮点运算的精度具有非确定性，以捕获错误依赖精确或确定性结果的代码（由 @LorrensP-2158466 完成）。
• Miri非确定性地使 read 和 write 操作只处理缓冲区的一部分，以捕获错误依赖这些操作可靠立即完成的程序（由 @RalfJung 完成）。
• Tree Borrows现在默认以与Stacked Borrows相同的精度跟踪 UnsafeCell，当同一引用背后的其他字节被错误修改时捕获未定义行为（由 @yoctocell, @JojoDeveloping 完成）。
• Tree Borrows现在支持通配符来源，因此Miri可以检查使用整数到指针转换的程序，并仍然捕获涉及这些指针的一些错误（由 @royAmmerschuber 完成）。
• Miri可以检测与就地（“移动”）函数参数相关的未定义行为（由 @RalfJung 完成）。
• Miri支持精确性能分析，跟踪所有执行时间消耗在何处（由 @Stypox 完成）。
• Miri不再需要xargo，减少了设置工作量（由 @RalfJung 完成）。

除此之外，还有大量的错误修复以及持续的重构和清理，以保持代码可维护性。 感谢所有贡献者。 如果你的名字应该在这个名单上，那很抱歉我忘了你。

如何提供帮助

如果你想帮助改进Miri，那太棒了！ 问题跟踪器是一个很好的起点；问题列表很短，你可以快速浏览一遍，看看是否有任何感兴趣的内容。 特别适合入门的问题标有绿色标签。 另一个好的起点是尝试实现缺失的功能，以让你的测试套件能够工作。 不过，你应该在一些更简单的项目中积累一些Rust经验后再处理Miri；Miri不是一个适合Rust初学者的好代码库。 然而，如果你已经了解Rust，Miri可能是一个有趣且有成就感的下一个挑战！ 如果你需要任何指导，只需联系我们。:)

我们目前在寻找愿意维护Miri对wasm目标支持的人。 wasm API与其他操作系统API差异很大，如果没有真正了解和理解wasm生态系统的人的帮助，维护这些垫片变得不可持续。 此外，我们也在寻找有Android经验的人来担任Miri的Android目标维护者。 这主要是指修复因标准库变更而出现的Android特定问题——这种情况应该很少，但发生时有一个可以联系的人会非常有用。 Android也几乎通过了我们的整个测试套件，你可以将其作为挑战来修复剩余的部分。

就到这里吧！ 我对Miri的成就感到无比自豪，并深深感谢每一位帮助我们走到这里的人。 多亏了Miri以及其他基于Miri对未定义行为理解的工具，在大规模项目中避免unsafe代码中的未定义行为变得切实可行，同时也让我们有机会以满足现实世界unsafe代码需求的方式来定义未定义行为。 这比我想象的要成功得多， 如果没有整个优秀的Rust社区的支持，这是不可能实现的——我期待着接下来会发生什么。:D

由 mimo-v2.5 模型翻译，花费 8942 tokens

内存安全如今风头正劲。 但这个词究竟意味着什么？ 事实证明，其定义可能比你想象的更难界定。 通常，人们用这个术语来指代那些确保程序中不存在释放后使用或越界内存访问的语言。 这常被视为与其他安全概念（如线程安全）的区别，后者指的是程序不存在某些并发错误。 然而，本文将论证这种区分意义不大，我们真正希望程序拥有的特性是消除未定义行为。

通过数据竞争破坏内存安全

我对安全概念被细分为内存安全、线程安全等细粒度类别存在一个主要疑问：一个线程不安全的语言无法以任何有意义的方式提供内存安全。 要理解我的意思，请看这个用Go编写的程序，根据维基百科，Go是内存安全的：

package main

// 仅作为一个任意接口，以便后续使用接口类型。
type Thing interface {
    get() int
}

// 两种实现接口的类型，具有非常不同类型的字段。
type Int struct {
    val int
}
func (s *Int) get() int {
    return s.val
}

type Ptr struct {
    val *int
}
func (s *Ptr) get() int {
    return *s.val
}

// 一个接口类型的全局变量，我们将在指向 `Int` 和 `Ptr` 之间反复切换。
var globalVar Thing = &Int { val: 42 }

// 反复调用全局变量的接口方法。
func repeat_get() {
    for {
        x := globalVar
        x.get()
    }
}

// 反复更改全局变量的动态类型。
func repeat_swap() {
    var myval = 0
    for {
        globalVar = &Ptr { val: &myval }
        globalVar = &Int { val: 42 }
    }
}

func main() {
    go repeat_get()
    repeat_swap()
}

如果你运行这个程序（例如在Go playground上），它很快就会崩溃：

panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x2a pc=0x468863]

这是一个段错误（segfault），而非正常的Go panic，说明发生了严重的错误。 请注意，导致段错误的地址是0x2a，这是数字42的十六进制表示。 这是怎么回事？

这个例子利用了Go存储像Thing这样的接口类型值时，实际上是存储一个指向数据的指针和一个指向虚表（vtable）的指针对。 每次repeat_swap向globalVar存储新值时，它只是执行两次独立的存储操作来更新这两个指针。 因此在repeat_get中，当我们*在*那两次存储*之间*读取globalVar时，就存在一个小概率会得到一个指向Int数据但使用Ptr虚表的混合指针。 当这种情况发生时，我们将运行Ptr版本的get方法，该方法会将Int的val字段解引用为一个指针——因此程序访问地址42并崩溃。

很容易将这个例子改造成一个将整数转换为指针的函数，然后造成任意的内存损坏。

其他语言呢？

此时你可能会想，这不是在许多语言中都存在的问题吗？ Java不也允许数据竞争吗？ 是的，Java确实允许数据竞争，但Java开发者付出了大量努力以确保即使存在数据竞争的程序也完全定义良好且内存安全。 他们甚至为此开发了首个在工业中部署的并发内存模型，这比C++11内存模型早了许多年。 所有这些工作的结果是，在并发的Java程序中，你可能会看到某些变量的意外过期值，例如在你期望引用已被正确初始化的地方出现一个空指针，但你*永远*无法真正破坏语言并解引用一个无效的悬垂指针，然后在地址0x2a处段错误。 从这个意义上说，所有Java程序都是线程安全的。¹

通常，语言可以采取两种方案来确保并发不会破坏内存安全：

• 确保任意并发程序仍然遵守类型规则和关键的语言不变式。这代价高昂，因为它要求语言永不假设多字值的一致性，并限制编译器可以执行的优化。这是大多数语言采取的路线，从Java到C#、OCaml、JavaScript和WebAssembly。²
• 拥有足够强大的类型系统以完全排除大多数访问上的数据竞争，并仅为一小部分内存访问承担安全处理竞争的成本。这是Rust首次实践的方法，Swift现在也通过其“严格并发”在采用此方法。

遗憾的是，Go选择两者都不做。 这意味着严格来说，它不是一种内存安全的语言：该语言最多只能承诺，*如果*程序没有数据竞争（或者更具体地说，没有在接口、切片和映射等有问题的值上发生数据竞争），那么其内存访问永远不会出错。 公平地说，Go自带了开箱即用的数据竞争检测工具，可以快速发现我例子中的问题。 然而，在一个真实的程序中，这意味着你必须寄希望于你的测试套件能覆盖程序在实践中可能遇到的所有情况，而这*正是*强大的类型系统和静态安全保证旨在避免的那类问题。 因此，数据竞争在Go中是个大问题也就不足为奇了，并且有至少是传闻证据的实际内存安全违规。 即使是经验丰富的Go程序员也并不总是意识到，你可以在不使用任何unsafe操作或利用任何编译器或语言bug的情况下破坏内存安全。 Go是一门*为*并发编程*而设计*的语言，所以人们并不期望存在这类隐患。 我认为这是一个有问题的盲点。

当然，正如语言设计中所有事情一样，这最终是一个权衡，Go的开发者们非常清楚这个问题。³ Go在这里做出了最简单的选择，这与该语言的整体设计完全一致。 这从根本上没有什么错。 然而，将Go归入与那些*确实*努力解决了数据竞争问题的语言同一个类别，曲解了该语言的安全承诺。 Go的内存模型文档对此点也并未直言不讳：“非正式概述”强调“大多数竞争的结果是有限的”，并指出Go不同于“C和C++，其中任何存在竞争的程序的意义都是完全未定义的”。 你可以说这里的“大多数”是一个伏笔，但该节并未列出任何结果数量无限的情况，因此很容易错过这一点。 他们甚至声称Go“更像Java或JavaScript”，我认为这相当不公平，因为那些语言为实现它们所拥有的线程安全付出了巨大的努力。 只有后续一个小节明确承认了Go中*某些*竞争*确实*具有完全未定义的行为（这与Java或JavaScript非常不同）。

结论

我认为，人们在谈论内存安全时真正关心的特性是程序无法破坏语言。 所有这些由内存安全违规导致的安全漏洞，都是代码执行了在语言规范中甚至不可能的操作的情况，比如跳转到某个用户提供的数组并*将其作为汇编代码执行*。 我们通常用来形容破坏语言的程序的术语是未定义行为。 一旦你的程序有了UB，一切保证都将不复存在；攻击者随后是否能够控制这种UB如何显现并利用其获利，主要只是一个实现细节。⁴

在我看来，区分“安全”语言（程序不可能有UB）和“不安全”语言（程序可能有UB）有一条清晰的界限。 没有任何有意义的方式可以将此进一步细分为内存安全、线程安全、类型安全等等——你的程序有UB的*原因*并不重要，重要的是有UB的程序违背了语言本身的基本抽象，这是滋生漏洞的完美温床。 因此，如果一种语言不能系统地防止未定义行为，我们就不应称其为“内存安全”。

在实践中，安全性当然不是二元的，而是一个光谱，在这个光谱上，Go更接近典型的“安全”语言，而非C语言。 由数据竞争引起的UB，对于攻击者来说，其利用价值可能低于直接越界或释放后访问引起的UB，这是可信的。 但与此同时，我认为理解一种语言能可靠地提供哪些安全保证，以及权衡的模糊地带从何处开始，这很重要。 我的工作是证明语言的安全声明，而对于Go，实际上能证明的东西并不多。 希望这篇文章能帮助你更好地理解不同语言所做选择的一些非平凡后果。⁵ :)

由 mimo-v2.5 模型翻译，花费 9531 tokens

经过数年的工作，我们的Tree Borrows论文最近终于在首尔举行的PLDI 2025大会上进行了展示。 与之前在这个博客和Neven的网站上提到的内容相比，Tree Borrows本身并没有太大变化。 我们利用所有额外的时间进行了形式化证明，以证明Tree Borrows确实允许我们期望从中获得的至少部分优化，并对crates.io上下载量最高的30,000个crate进行了广泛的Tree Borrows评估。 这一集实现、证明和评估于一体的综合成果给PLDI程序委员会留下了深刻印象，使我们获得了杰出论文奖。:-) 非常感谢Neven和Johannes的所有辛勤工作，并祝贺他们完成了一篇了不起的论文！

如果您想亲自查阅论文，所有内容均可在开放获取下查看。 Neven精彩的论文介绍演讲可在此处找到。

由 mimo-v2.5 模型翻译，花费 889 tokens

几周前，许多Rust爱好者在乌得勒支参加了RustWeek，我们都度过了愉快的时光。 作为活动的一部分，我做了一个题为“MiniRust：一个用于规约Rust的核心语言”的演讲，介绍了MiniRust的现状。 这是我在一个（满座的）电影院里第一次发表演讲；不幸的是，我的特效预算无法赶上通常在那里放映的节目水平。 不过，如果您想了解更多关于我如何规约unsafe Rust复杂细节的愿景，请观看我的演讲视频。 :)

感谢在场所有人的精彩聆听，也感谢组织者带来了精彩的一周和高质量的录像！

由 mimo-v2.5 模型翻译，花费 680 tokens

我们团队产出的首篇论文最近在OOPSLA会议上发表。:) 这篇论文通过随机生成MIR程序，并确保这些程序在不同后端、不同优化级别以及Miri中行为一致，实现了对Rust编译器优化和代码生成阶段的模糊测试。 该工作的核心部分由Andy（王乾）在其硕士论文中完成。 这本已是一篇出色的论文，但Andy在开始全职工作后仍持续推进，最终成就了这篇非常优秀的论文。 他共计在Rust编译器中发现了22个新缺陷，其中12个位于已受到前人广泛模糊测试的LLVM后端。

要了解更多信息，请查阅论文或观看Andy的演讲（时间戳链接可能不稳定，若未自动跳转可手动定位至5小时40分处）。

由 mimo-v2.5 模型翻译，花费 988 tokens

Rust 语言中一个比较微妙的方面是，实际上存在两种表达式：值表达式和位置表达式。大多数时候，程序员不需要过多思考这种区别，因为 Rust 会在遇到一种表达式但期望另一种时，自动插入转换。然而，在编写 unsafe 代码时，正确理解这种表达式的二分法可能是必要的。请看以下示例：

// 作为“packed”结构体，此类型的对齐要求为 1。
#[repr(packed)]
struct MyStruct {
  field: i32
}

let x = MyStruct { field: 42 };
let ptr = &raw const x.field;
// 这一行没问题。
let ptr_copy = &raw const *ptr;
// 但这一行有未定义行为 (UB)！
// `ptr` 是一个指向 `i32` 的指针，因此在内存访问时需要 4 字节对齐，
// 但 `x` 只有 1 字节对齐。
let val = *ptr;

这里我使用了不稳定但即将稳定的“原始借用”运算符 &raw const。你可能通过其稳定形式的宏 ptr::addr_of! 了解它，但 & 语法使位置和值的交互更明确，因此我们在此使用它。

最后一行存在未定义行为（UB），因为 ptr 指向一个 packed 结构体的字段，其对齐不足。但为什么计算 *ptr 是 UB，而计算 &raw const *ptr 却是正常的？一个表达式的求值应该先求值其子表达式，然后对结果进行某种操作。然而，*ptr 是 &raw const *ptr 的子表达式，我们刚说 *ptr 是 UB，那么 &raw const *ptr 不也应该 UB 吗？这就是本文讨论的主题。

（你可能在 C 和 C++ 中已经遇到过位置表达式和值表达式的区分，它们分别称为左值表达式和右值表达式。虽然基本的语法概念与 Rust 相同，但构成 UB 的具体场景不同，因此我们将完全聚焦于 Rust。）

让隐式变得显式

位置表达式和值表达式这种二分法之所以如此难以捉摸，主要原因是它完全是隐式的。因此，要理解上述代码中实际发生了什么，第一步是引入一些新语法，让我们能够在代码中明确这种隐式区分。

通常，我们可能会认为 Rust 表达式（的片段）的语法大致如下：

Expr ::=
   Literal | LocalVar | Expr + Expr | & BorMod Expr | * Expr |
   Expr . Field | Expr = Expr | …
BorMod ::= ​ | mut | raw const | raw mut
Statement ::=
   let LocalVar = Expr ; | …

这直接解释了为什么我们可以编写像 *ptr = *other_ptr + my_var 这样的表达式。

然而，要理解位置和值，考虑一个显式包含两种表达式的不同文法会更有启发性。我将首先给出文法，然后用一些例子进行解释：

ValueExpr ::=
   Literal | ValueExpr + ValueExpr | & BorMod PlaceExpr |
   PlaceExpr = ValueExpr | load PlaceExpr
PlaceExpr ::=
   LocalVar | * ValueExpr | PlaceExpr . Field
Statement ::=
   let LocalVar = ValueExpr ; | …

值表达式是计算值的表达式：如 5 这样的字面量，像 5 + 7 这样的计算，也包括计算指针类型值的表达式如 &my_var。然而，根据此文法，表达式 my_var（引用一个局部变量）不是值表达式，它是一个位置表达式。这是因为 my_var 实际上表示内存中的一个位置，可以对一个位置执行多种操作：可以加载该位置的内容（产生一个值），可以创建一个指向该位置的指针（也产生一个值，但根本不访问内存），或者可以将一个值存储到此位置（在 Rust 中产生 () 值，但更重要的是改变内存内容的副作用）。除了局部变量，位置表达式的另一个主要例子是 * 运算符的结果，它接受一个值（指针类型）并将其转换为一个位置。¹ 此外，给定一个结构体类型的位置，我们可以使用字段投影来获取该字段的位置。

这可能听起来有些奇怪，因为这意味着 let new_var = my_var; 实际上在我们的文法中不是一个有效的语句！要接受此代码，Rust 编译器会自动将此语句转换为符合文法的形式，在需要的地方添加 load。² load 接受一个位置，并如其名所示，执行从内存的加载以获取当前存储在该位置的值。因此，该语句的脱糖形式是 let new_var = load my_var;。

考虑一个更复杂的例子，上面提到的赋值表达式 *ptr = *other_ptr + my_var 脱糖为 *(load ptr) = load *(load other_ptr) + load my_var。这里有很多 load 表达式！说服自己相信它们都是必要的，才能使该项符合文法，这会很有启发性。特别是，* 作用于一个值表达式（因此我们需要 load other_ptr 来获取存储在此位置中的值），并产生一个位置表达式（因此我们需要再次 load 来获取一个可以与 + 一起使用值表达式）。然而，= 的左侧是一个位置表达式，所以我们不会在那里 load * 的结果。

由于 load 运算符是隐式引入的，它有时被称为“位置到值的强制转换”。理解位置到值的强制转换或 load 表达式在何处被引入，是理解本博文顶部示例的关键。所以让我们使用我们更明确的文法，再次编写该示例的相关部分：

let ptr = &raw const x.field;
// 这一行没问题。
let ptr_copy = &raw const *(load ptr);
// 但这一行有未定义行为 (UB)！
let val = load *(load ptr);

突然之间，为什么最后一行有 UB 而前一行没有就变得完全合理了！表达式 &raw const *(load ptr) 仅仅是计算位置 *(load ptr) 而从未加载其内容，然后使用 &raw const 将该位置转换为一个值。这一点值得重复：* 运算符，通常被称为“解引用指针”，并不以任何方式访问内存。它所做的只是接受一个指针类型的值，并将其转换为一个位置。这是一个纯粹的运算，永远不会失败。在最后一行，有一个额外的 load 应用于 * 的结果，而那就是发生内存访问的地方——并且在这种情况下发生了 UB，因为该位置对齐不足。

求值一个产生未对齐位置的位置表达式是完全合法的，然后将该未对齐位置转换为一个原始指针值也是合法的。通常，从 UB 的角度来说，你应该认为位置就像原始指针：没有要求它们指向有效的值，甚至指向现有的内存。³ 然而，从未对齐的位置加载（或存储）是非法的，这就是为什么 load *(load ptr) 是 UB。

换句话说，当 *ptr 被用作值表达式时（正如我们在示例中那样），它不是 &raw const *ptr 的子表达式，因为隐式的位置到值强制转换在 *ptr 周围添加了一个额外的 load，而这个 load 在 &raw const *ptr 中并未添加。

位置表达式导致的其他意外示例

位置表达式可能导致意外行为的另一个主要例子是与 _ 模式结合使用。例如：

let ptr = std::ptr::null::<i32>();
let _ = *ptr; // 这没问题！
let _val = *ptr; // 这是 UB。

请注意，上面的文法无法表示此程序：在 Rust 的完整文法中，let 语法类似于“let Pattern = PlaceExpr ;”，然后模式脱糖决定如何处理该位置表达式。如果模式是绑定器（常见情况），会插入一个 load 来计算此绑定器所引用的局部变量的初始值。然而，如果模式是 _，则该位置表达式仍然会被求值——但其结果只是被丢弃。MIR 使用一个 PlaceMention 语句来表示这些语义。

特别地，这意味着 _ 模式不会引起位置到值的强制转换！此代码相关部分的脱糖形式是：

PlaceMention(*(load ptr)); // 这没问题！
let _val = load *(load ptr); // 这是 UB。

如你所见，第一行实际上并未从指针加载（唯一的 load 是为了从存储它的局部变量中加载指针本身）。当位置表达式与 _ 模式一起使用时，不会构造任何值。相比之下，最后一行实际创建了一个新的局部变量，因此插入了一个位置到值的强制转换来计算该变量的初始值。

match 语句也会发生同样的事情：

let ptr = std::ptr::null::<i32>();
match *ptr { _ => "happy" } // 这没问题！
match *ptr { _val => "not happy" } // 这是 UB。

match 表达式的审查对象是一个位置表达式，如果模式是 _，则不会构造值。然而，当存在实际的绑定器时，会引入一个局部变量，并插入一个位置到值的强制转换来计算将要存储在该局部变量中的值。

关于 unsafe 块的说明。请注意，将表达式包装在花括号中会强制它成为值表达式。这意味着 unsafe { *ptr } 总是从指针加载！换句话说：

let ptr = std::ptr::null::<i32>();
let _ = *ptr; // 这没问题！
let _ = unsafe { *ptr }; // 这是 UB。

花括号强制产生值表达式的事实有时可能有用，但 unsafe 块具有这种行为确实相当不幸。

是否也有从值到位置的强制转换？

到目前为止，我们已经讨论了在期望值表达式的地方遇到位置表达式时会发生什么。但相反的情况呢？请考虑：

let x = &mut 15;

根据我们的文法，&（在这种情况下带有 mut 修饰符）需要一个位置表达式，但 15 是一个值表达式。Rust 编译器如何能接受这样的代码？

在这种情况下，脱糖涉及引入新的“临时”局部变量：

let mut _tmp = 15;
let x = &mut _tmp;

引入此临时变量的确切作用域由非平凡的规则定义，这超出了本博文的范围；关键点是这种转换再次使程序符合更明确的文法。

此规则有一个例外，即赋值运算符的左侧：如果你写类似 15 = 12 + 19 的东西，值 15 不会被转换为临时位置，程序会被拒绝。在这里引入临时变量不太可能产生有意义的结果，因此没有充分理由接受此类代码。

结论

每当我们用在期望值的地方使用位置表达式，或者在期望位置的地方使用值表达式时，Rust 编译器会隐式地将我们的程序转换为符合上述文法的形式。如果你只编写安全代码，你几乎总是可以完全忘记这种转换。然而，如果你正在编写 unsafe 代码并想理解为什么一些程序有 UB 而另一些没有，理解到底发生了什么可能是至关重要的。如果你只能从本博文中记住一件事，那么请记住 * 解引用指针但不加载内存；相反，它所做的只是将指针转换为一个位置——是随后的隐式位置到值转换执行了实际的加载。我希望为这个隐式的 load 运算符命名可以帮助解开位置和值这个话题的神秘面纱。:)

由 mimo-v2.5 模型翻译，花费 14958 tokens

我们大家都习惯收到垃圾邮件，这些邮件据称来自谷歌，内容是“你赢了”，然后我只需发送所有个人数据到某个地方就能领取彩票奖金。最近当我收到一封关于谷歌“开源同行奖”计划的邮件时，我差点把它当作另一种垃圾邮件丢弃了。但事实证明，有时候这些邮件竟然是真的！与此同时，官方公告已经发布，将我列为该奖金的获得者，以感谢我在Rust语言方面的工作。所以这一次，它确实不是垃圾邮件！

非常感谢谷歌的这项计划，提供了250美元的奖励；看到开源工作能得到这样的表彰，真是太棒了。我已经将这笔款项全额捐赠给了noyb，我相信他们会将这笔钱用于正当事业。

更新（2024-01-07）： 事实上，这已经是我第二次获得谷歌开源同行奖了。第一次是在2023年上半年。由于支付流程问题，那笔奖金延迟了一段时间才到账，但我现在可以确认它已经到达我的银行账户。我得找个合适的非营利组织捐赠这笔钱……或者也可能再次捐给noyb，我们拭目以待。 /更新

由 mimo-v2.5 模型翻译，花费 1154 tokens

我最近在苏黎世的本地 Rust 聚会上做了一次关于未定义行为、不安全 Rust 和 Miri 的演讲。 录像可以在这里观看。 它针对的是熟悉 Rust 但对不安全代码的细节不熟悉的听众，所以我希望你们中很多人会喜欢它！ 玩得开心。:)

由 mimo-v2.5 模型翻译，花费 1259 tokens

自去年秋天以来，Neven 一直在实习，为 Rust 开发一种新的别名模型：树借用（Tree Borrows）。等一下，你可能会说——Rust 不是已经有一个别名模型了吗？Ralf 不是总在谈论那个“栈借用（Stacked Borrows）”吗？确实有，但栈借用只是一个可能别名模型的提案——它存在着相当多的问题。树借用旨在吸收从栈借用中学到的经验，构建一个问题更少的新模型，并做出一些不同的设计决策，以便我们在为 Rust 确定正式模型之前，了解这些模型可能涉及的权衡和微调。

Neven 在他的博客上撰写了一篇关于树借用的详细介绍，你应该先去阅读一下。他在最近的一次 RFMIG 会议上做了这个报告，所以你也可以观看他的演讲。在本文中，我将重点介绍与栈借用的区别。我假设你已经了解栈借用，并想理解树借用带来了哪些变化以及原因。

作为简写，我有时会用 SB 代表栈借用，用 TB 代表树借用。

两阶段借用

树借用的主要新奇之处在于它提供了对两阶段借用的恰当支持。两阶段借用是随着非词法生命周期（NLL）引入的一种机制，它允许接受如下代码：

fn two_phase(mut x: Vec<usize>) {
    x.push(x.len());
}

这段代码棘手的原因在于它的脱糖形式类似于这样：

fn two_phase(mut x: Vec<usize>) {
    let arg0 = &mut x;
    let arg1 = Vec::len(&x);
    Vec::push(arg0, arg1);
}

这段代码显然违反了常规的借用检查规则，因为在调用 x.len() 时，x 已经被可变借给了 arg0！然而，编译器会接受这段代码。其工作原理是存储在 arg0 中的 &mut x 被分成了两个阶段：在保留阶段，x 仍然可以通过其他引用被读取。只有当我们真正需要写入 arg0（或调用可能写入它的函数）时，该引用才会被“激活”，从此时起（直到借用生命周期结束），才不允许通过其他引用进行访问。更多细节，请参阅RFC和 rustc-dev-guide 中关于两阶段借用的章节。对于本博文，唯一相关的一点是：当为方法调用（如 x.push(...)）隐式发生借用时，Rust 会将其视为两阶段借用。当你在代码中显式写出 &mut 时，它被视为没有“保留”阶段的常规可变引用。

对于别名模型而言，两阶段借用是一个大问题：当执行 x.len() 时，arg0 已经存在，而作为一个可变引用，它本不应该允许通过其他指针进行读取。因此，栈借用在此放弃了，基本上将两阶段借用视为裸指针。这当然不能令人满意，因此对于树借用，我们正在添加对两阶段借用的恰当支持。更重要的是，我们将所有可变引用都视为两阶段借用：这比借用检查器允许的更为宽松，但让我们能够完全统一地处理可变引用。（这一点我们可能想要调整，但正如我们将很快看到的，这个决定实际上带来了一些主要的意外好处。）

这就是为什么我们首先需要一棵树：传递给 Vec::len 的 arg0 和引用都是 x 的子节点。栈不再足以表示这里的父子关系。一旦确定使用树，对两阶段借用的建模就相当直观了：它们以 Reserved 状态开始，容忍来自其他无关指针的读取。只有当引用（或其某个子节点）被首次写入时，其状态才转换为 Active，此时才不再接受来自其他无关指针的读取。（更多细节请参阅 Neven 的文章。特别要注意这里潜伏着一个令人不快的意外：如果涉及 UnsafeCell，那么一个保留的可变引用实际上必须容忍通过无关指针进行修改！换句话说，&mut T 的别名规则现在受到了 UnsafeCell 存在的影响。我认为在引入两阶段借用时人们并未意识到这一点，但即使事后看来，替代方案是什么也不明确，似乎也很难避免。）

可变引用唯一性的延迟

栈借用问题最常见的来源之一是它过早强制执行可变引用唯一性。例如，以下代码在栈借用下是非法的：

let mut a = [0, 1];
let from = a.as_ptr();
let to = a.as_mut_ptr().add(1); // `from` 在此失效
std::ptr::copy_nonoverlapping(from, to, 1);

它非法的原因是 as_mut_ptr 接受 &mut self，这断言了对整个数组的独占访问，因此使之前创建的 from 指针失效。然而，在树借用中，这个 &mut self 是一个两阶段借用！as_mut_ptr 实际上不执行任何写操作，因此引用保持保留状态，从未被激活。这意味着 from 指针保持有效，整个程序是良定义的。对 as_mut_ptr 的调用被视为对 *self 的读取，但 from（以及从中派生的共享引用）完全可以通过无关指针进行读取。

碰巧的是，在栈借用中，交换 from 和 to 的行确实能使这段代码工作。然而，这并非出于好的原因：这是 SB 中相当非栈式规则的结果，该规则说在读取时，我们只是禁用所有位于访问所用标签上方的 Unique，但我们保持从这些 Unique 指针派生的裸指针启用。基本上，裸指针可以比它们从中派生的可变引用存活更久，这非常违反直觉，并且可能对程序分析造成问题。使用 TB 时，交换后的程序仍然没问题，但原因不同：当 to 首先被创建时，它仍然是一个保留的两阶段借用。这意味着创建一个共享引用并从中派生 from（这相当于对 self 进行读取）是没问题的；保留的两阶段借用容忍通过无关指针进行读取。只有当 to 被写入时，它（或者更确切地说，从中创建的 &mut self）才会变成一个需要唯一性的活动可变引用，但那是在 as_ptr 返回之后，因此不存在冲突的 &self 引用。

事实证明，一致地使用两阶段借用让我们能够完全消除这个hacky的 SB 规则，并修复了 SB 下最常见的未定义行为来源之一。我完全没有预料到这一点，这是一个令人愉快的小意外。:)

但是请注意，以下程序在 SB 下是有效的，但在 TB 下是无效的：

let mut a = [0, 1];
let to = a.as_mut_ptr().add(1);
to.write(0);
let from = a.as_ptr();
std::ptr::copy_nonoverlapping(from, to, 1);

这里，对 to 的写入激活了两阶段借用，因此强制执行唯一性。这意味着为 as_ptr 创建的 &self（被认为读取整个 self）与 to 不兼容，因此当创建 from 时，to 失效了（好吧，它被设为只读）。到目前为止，我们没有证据表明这种模式在野外很常见。避免上述代码这类问题的方法是在开始做任何事情之前设置好你所有的裸指针。在 TB 下，调用接收引用的方法（如 as_ptr 和 as_mut_ptr）并使用它们返回的裸指针访问不相交的位置，即使这些引用重叠也是可以的，但你必须在第一次写入裸指针之前调用所有这些方法。一旦第一次写入发生，再创建引用可能导致别名违规。

不要严格限制可访问的内存范围

栈借用的另一个主要麻烦来源是限制裸指针只能访问其最初创建时的类型和可变性。在 SB 下，当一个引用被转换为 *mut T 时，生成的裸指针被限制只能访问 T 所覆盖的内存。当人们对数组的某个元素（或结构体的某个字段）取裸指针，然后使用指针算术访问相邻元素时，这经常绊倒他们。此外，当一个引用被转换为 *const T 时，它实际上是只读的，即使该引用是可变的！许多人期望 *const 与 *mut 在别名方面没有区别，因此这是一个常见的困惑来源。

在 TB 下，我们通过不再对引用到裸指针的转换进行任何重标记（retagging）来解决这个问题。一个裸指针简单地使用其从中派生的父引用相同的标签，从而继承其可变性和它可以访问的地址范围。此外，引用并不严格受限于其类型描述的内存范围：当从一个父指针创建一个 &mut T（或 &T）时，我们最初记录允许新引用访问 T 描述的内存范围（我们认为这是对该内存范围的读取访问）。然而，我们也执行延迟初始化：当访问此初始范围之外的内存位置时，我们会检查父指针是否有权访问该位置，如果有，我们也会授予子节点相同的访问权限。此过程递归重复，直到找到具有足够访问权限的父节点，或到达树的根节点。

这意味着 TB 与container_of风格的指针算术和extern类型兼容，克服了 SB 的另外两个限制。

这也意味着以下代码在 TB 下变得合法：

let mut x = 0;
let ptr = std::ptr::addr_of_mut!(x);
x = 1;
ptr.read();

在 SB 下，ptr 和对局部变量 x 的直接访问使用两个不同的标签，因此写入局部变量会使所有指向它的指针失效。在 TB 下，不再如此；直接对局部变量创建的裸指针被允许与对局部变量的直接访问任意别名。

可以说 TB 的行为更符合直觉，但它意味着我们不再能将写入局部变量作为所有可能别名已被失效的信号。然而，请注意，TB 仅在函数体中立即使用 addr_of_mut（或 addr_of）时才允许这样做！如果创建了引用 &mut x，然后其他某个函数从中派生了一个裸指针，那么这些裸指针在下一次写入 x 时确实会失效。所以对我来说，这是一个完美的折衷：使用裸指针的代码未定义行为的风险更低，但不使用裸指针的代码（从语法上很容易看出）可以像 SB 一样进行优化。

请注意，TB 中的这整个方法依赖于 TB 不需要上一节中提到的违反栈的 hack。如果 SB 中的裸指针只是继承了父标签，那么它们会与从中派生的唯一指针一起失效，从而禁止所有专门为支持这种 hack 而添加的代码。这意味着将这些改进移植回 SB 不太可能实现。

UnsafeCell

对 UnsafeCell 的处理在 TB 中也发生了很大变化。首先，SB 的另一个主要问题得到了修复：将 &i32 转换为 &Cell<i32> 然后从不写入它 最终被允许了。这源于 TB 处理 UnsafeCell 所允许的别名的方式：它们被视为转换为裸指针，因此借用 &Cell<i32> 只是继承父指针的标签（因此继承其权限）。

更具争议的是，TB 还改变了当 &T 在 T 中某处涉及 UnsafeCell 时，事物变为只读的精确方式。特别是对于 &(i32, Cell<i32>)，TB 允许修改两个字段，包括第一个是常规 i32 的字段，因为它只是将整个引用视为“允许别名”。¹相比之下，SB 实际上搞清楚了前 4 个字节是只读的，只有最后 4 个字节允许通过别名指针进行修改。

做出这个设计决策的原因是，TB 的总体哲学是倾向于允许更多代码，拥有更少的未定义行为（这与我使用 SB 的方向相反）。这是一个有意识的选择，旨在用这两个模型探索尽可能多的设计空间。当然，我们想确保 TB 仍然允许所有预期的优化，并且仍然有足够的未定义行为来证明 rustc 生成的 LLVM IR 是合理的——这些是我们所需的最小未定义行为量的“下限”。事实证明，在这些约束下，我们可以用相当简单的方法支持 UnsafeCell：对于 &T 的别名规则，只有 2 种情况。要么任何地方都没有 UnsafeCell，那么这个引用是只读的；否则，该引用允许别名。作为一个经常思考如何证明包含别名模型在内的完整 Rust 语义定理的人来说，这种方法看起来简单得令人愉悦。:)

我预计这个决定会有些争议，但我们收到的反对意见仍然出乎意料地多。好消息是，这远未板上钉钉：我们可以更改 TB，使其更像 SB 那样处理 UnsafeCell。与之前描述的差异不同，这个选择完全独立于我们的其他设计选择。虽然我更喜欢 TB 的方法，但就目前的情况来看，我确实预计我们最终会采用类似 SB 的 UnsafeCell 处理方式。

那优化呢？

我写了很多关于 TB 在哪些编码模式属于未定义行为方面与 SB 的不同之处。但硬币的另一面呢，优化？显然，由于 SB 有更多的未定义行为，我们不得不期望 TB 允许更少的优化。确实有一类主要的优化 TB 丧失了：推测性写入，即在以前不会写入此位置的代码路径中插入写入。这是一种强大的优化，我很高兴 SB 能做到这一点，但它也带来了巨大的代价：可变引用必须是“立即唯一”的。鉴于“过早强制唯一性”是多么常见的问题，我目前的倾向是我们可能宁愿让所有那些代码合法，也不愿允许推测性写入。我们仍然有关于读取的强大优化原则，并且当代码确实执行写入时，会产生更多优化，所以我的感觉是，坚持推测性写入有点过分了。

在另一方面，TB 实际上允许了一套关键的优化，而 SB 因意外而排除了这些优化：重排读取顺序！SB 的问题是，如果我们从“读取可变引用，然后读取共享引用”开始，然后重排为“读取共享引用，然后读取可变引用”，那么在新的程序中，读取共享引用可能会使可变引用失效——因此重排可能引入了未定义行为！这个优化无需特殊的别名模型就能实现，因此 SB 不允许它是一个相当尴尬的问题。如果不是因为上面多次提到的违反栈的 hack，我认为在 SB 中修复这个问题会相当容易，但唉，那个 hack 至关重要，如果我们移除它，太多现有代码将变成未定义行为。与此同时，TB 不需要这样的 hack，所以我们可以做正确的事（TM）：当进行读取时，相关的可变引用不会被完全禁用，它们只是被设为只读。这意味着“读取共享引用，然后读取可变引用”等同于“读取可变引用，然后读取共享引用”，因此优化得以保留。（一个结果是，重标签也可以彼此重排序，因为它们也充当读取。因此你设置各种指针的顺序无关紧要，直到你用其中一个进行第一次写入访问。）

未来的可能性：Unique

树借用为一个我们尚未实现但很兴奋去探索的扩展铺平了道路：赋予 Unique 含义。Unique 是 Rust 标准库中的一个私有类型，最初旨在表达 noalias 要求。然而，它从未真正连接到在 LLVM 层面发出该属性。Unique 主要在标准库的两个地方使用：Box 和 Vec。SB（和 TB）特殊处理 Box（与 rustc 本身匹配），但不处理 Unique，因此 Vec 不带有任何别名要求。而且 SB 的方法完全不适用于 Vec，因为我们实际上不知道这里要让多少内存唯一。然而，有了 TB，我们有了延迟初始化，所以我们不需要预先承诺一个内存范围——我们可以“在访问时”使其唯一。这意味着我们可以探索赋予 Vec 中的 Unique 含义。

现在，这可能实际上行不通。人们实际上确实对 Vec 进行了公然别名的事情，例如实现 arena。另一方面，Vec 的唯一性只会在它被移动或按值传递时出现，并且仅针对实际被访问的内存范围。因此这很可能与 arena 兼容。我认为最好的方法是在标志背后实现 Unique 语义并进行实验。如果成功了，我们甚至可能能够移除所有对 Box 的特殊处理，并依赖 Box 被定义为 Unique 上的新类型这一事实。这可能会略微降低优化潜力（Box<T> 已知指向至少与 T 一样大的内存范围，而 Unique 没有此信息），但让 Box 不那么魔法化是一个长期追求的目标，因此这可能是一个可以接受的权衡。

我应该注意到，有很多人认为 Box 和 Vec 都不应该有任何别名要求。我认为值得首先探索我们是否可以拥有足够轻量级的别名要求，使其与常见的编码模式兼容，但即使我们最终说 Box 和 Vec 的行为像裸指针，拥有 Unique 在我们的工具箱中并将其暴露给不安全代码作者以榨取最后一点性能仍然可能有用。

结论

这些是栈借用和树借用之间的主要区别。正如你所看到的，几乎所有情况都是 TB 允许比 SB 更多的代码，确实 TB 修复了我认为 SB 的两个最大问题：可变引用的过早强制唯一性，以及将引用和裸指针限制在它们创建时的类型大小。这对不安全代码作者来说是个好消息！

TB 没有改变的是“保护器”的存在，以确保某些引用在整个函数调用期间保持有效（无论它们是否再次被使用）；保护器对于证明我们想要发出的 LLVM noalias 注释绝对必要，它们也确实能实现一些比其他方式可能的更强的优化。我确实预计保护器将是树借用意外未定义行为的主要剩余来源，并且我认为我们在这里没有太多回旋余地，所以这可能只是一个我们需要告诉程序员调整代码，并投资于文档材料以使这个微妙问题广为人知的情况。

Neven 在 Miri 中实现了树借用，所以你可以通过设置 MIRIFLAGS=-Zmiri-tree-borrows 来玩一玩并检查你自己的代码。如果你遇到任何意外或疑虑，请告诉我们！t-opsem Zulip 和 UCG issue tracker 是提出此类问题的好地方。

以上就是我的全部内容，感谢阅读——并向 Neven 致意，他完成了所有实际工作（并在此博文中提供了反馈），监督这个项目非常有趣！记得阅读他的文章并观看他的演讲。

由 mimo-v2.5 模型翻译，花费 17145 tokens

你知道吗？标准库中充满了用户从未见过的有用检查。标准库中有许多调试断言，它们会检查诸如 char::from_u32_unchecked 是否被调用于有效的 char，CStr::from_bytes_with_nul_unchecked 是否没有内部空字节，或者指针函数如 copy 或 copy_nonoverlapping 是否被调用于适当对齐的非空（且不重叠）指针。然而，由 rustup 分发的常规标准库是在没有调试断言的情况下编译的，因此用户无法轻松受益于所有这些额外检查。

cargo careful 正是为了弥合这一差距而生：首次调用时，它会从源码构建带有调试断言的标准库，然后使用该标准库运行你的程序或测试套件。安装 cargo careful 就像 cargo install cargo-careful 一样简单，之后你可以执行 cargo +nightly careful run/cargo +nightly careful test 来以额外的调试检查运行你的二进制 crate 和测试套件。

这自然会比常规的调试或发布构建慢，但它比在 Miri 中执行你的程序快得多，并且仍然有助于发现一些未定义行为。与 Miri 不同，它完全兼容 FFI（尽管 FFI 边界后的代码完全未检查）。当然，Miri 更加彻底，cargo careful 会遗漏许多问题（例如，它无法检测越界指针算术——但它确实对 get_unchecked 切片访问执行边界检查）。

请注意，目前其中一些检查（特别是针对原始指针的方法）会导致程序通过 SIGILL 突然中止，而没有友好的错误消息或回溯。未来可能有方法改进这一点。与此同时，如果你有一些 unsafe 代码由于某些原因无法用 Miri 测试，可以试试 cargo careful 并告诉我它的表现如何。:)

顺便说一下，我即将在苏黎世联邦理工学院担任教授，因此如果你有兴趣作为硕士生、博士生或博士后与我一起研究编程语言理论，请联系我！

由 mimo-v2.5 模型翻译，花费 3844 tokens

我有一些非常激动人心的消息要分享：从11月1日起，我将在ETH苏黎世担任助理教授！ 成为教授本身就是一个梦想成真，而能在ETH苏黎世这样的地方当教授更是我从未敢梦想过的事。 我仍然不敢相信这真的发生了（我要当教授了？？？），但消息已经公布，所以我想这是真的。:D

我感到既兴奋又恐惧，而且两者的程度差不多。 兴奋于所有新的可能性，期待与学生合作并激励下一代研究者； 恐惧于所有的责任，以及几个月后就得站在教室里讲课的前景。 但不知为何，其他人似乎都相信我能做到，所以我想我只好顺其自然，希望不会让他们失望……

我也深感谦卑，并永远感激能获得这个机会。 能在ETH这样的环境中工作是无法想象的特权，我不知道自己怎么如此幸运。 我可能用尽了今生所有的福报，我会尽我所能不辜负这份特权。 我深深感激所有与我共事过的人，首先当然是我的博士导师Derek Dreyer。 但我也特别想感谢Rust社区，因为我认为如果没有Rust就不会有这一切——感谢每一位为这门语言做出贡献的人，我基本上是依托它建立自己的事业¹，特别感谢那些包容我对Rust如何处理不安全代码的想法、并帮助我塑造语言这一部分的人。

那么接下来呢？ 我即将完成在MIT的博士后研究，搬回欧洲，然后于10月搬到苏黎世。 接着我就得弄明白当教授是怎么回事了。;) 我的首要任务是建立一个研究团队：“编程语言基础实验室”²。 因此，如果你有兴趣攻读博士或从事博士后研究，研究，嗯，编程语言基础，特别是Rust的形式化基础，或者你是ETH的学生，对该领域有硕士论文兴趣——请联系我！ 我仍在摸索如何进行招聘和寻找合适的项目，但需要解决的开放问题和需要证明的定理并不少。:)

由 mimo-v2.5 模型翻译，花费 2132 tokens