• 文档

本文基于 rust-lang/rfcs 仓库中的 text/3855-mitigation-enforcement.md，完整解读 Rust 编译器 RFC 3855 提出的 "mitigation enforcement"（缓解措施强制执行）机制：当以启用内存安全缓解措施（如-C stack-protector）的方式编译某个 crate 时，若最终产物中混入了未启用同等缓解措施的 Rust 代码，编译器将直接报错，从而保证浏览器、内核等安全敏感软件中缓解措施"全有或全无"，并系统讲解其动机、适用缓解措施清单、-C allow-partial-mitigations/-C deny-partial-mitigations的语义与兼容性矩阵，以及与 target modifiers、build-std 等机制的边界划分。

一、机制概述：什么是 mitigation enforcement

RFC 3855（Feature Name:mitigation_enforcement，起始日期 2025-09-13）的核心思想只有一句话：

当以启用缓解措施的方式编译一个 crate 时（例如传入-C stack-protector），如果产生的产物中会包含未启用同样缓解措施的 Rust 代码，就应当产生编译错误。

其动机很直接：缓解措施（stack protector、retpoline、kCFI、shadow call stack 等）是降低内存漏洞可利用性的关键手段。Rust 虽比 C 更少出现内存不安全，但缓解措施仍然重要，原因有三：

1. Spectre 类漏洞在 Rust 中同样存在。例如直线投机缓解（straight line speculation mitigation，-Z harden-sls）针对的漏洞与 Rust 无关语言属性；
2. 大量 Rust 程序包含 C/C++ 组件，其中可能存在内存漏洞；同一地址空间内"裸奔"的 Rust 代码会加剧这些漏洞被利用的难度下降；
3. Rust 中的unsafe代码本身就可能引入内存不安全与漏洞。

而缓解措施通常通过编译器开关启用（如-Z harden-sls、-Z stack-protector）。在复杂的多 crate 构建流程中，极易漏传某个开关给某个目标文件，且这种"部分启用"状态往往是静默的——程序照常编译、运行，但安全属性被悄悄削弱。RFC 3855 就是要把这种静默降级变成编译期错误。

需要注意一个重要的实践前提：该机制在很多场景下会要求使用-Z build-std。因为预编译的标准库对每个 target 只带有一组固定的缓解措施配置，用户 crate 若启用额外的缓解措施，就必须自己重编标准库才能通过强制检查。

二、为什么部分启用缓解措施是危险的：四类后果

RFC 按"混用缓解措施设置"的后果把问题分成四类，这也是理解整个机制设计的关键背景：

1. 改变 ABI 的缓解措施（例如-Z fixed-x18、-Z sanitizer=shadow-call-stack）：混用不同缓解设置的目标文件会导致即使没有攻击也出现崩溃等未定义行为。这类情况应当做成 target modifier 而不是走本 RFC 的机制（参见仓库中的 text/3716-target-modifiers.md）。
2. Spectre 类缓解措施（如harden-sls）：只要地址空间中存在任何可达的、没有 retpoline 的代码，攻击者就可以发起 Spectre 攻击——即使你自己的代码里一行 UB 都没有。
3. CFI 类缓解措施（如 kCFI）：只要地址空间中存在可达的未启用 CFI 的代码，攻击者就能把一个已存在的内存漏洞升级为 ROP 执行——哪怕内存漏洞在完全不相干的模块里。
4. "局部"缓解措施（如 stack protector，或 C 的-fwrapv——Rust 目前没有后者）：这类缓解措施只在"保护对了位置"时才有意义。stack protector 基本只在保护了发生溢出的那个缓冲区时才有帮助，其他函数有没有它并不重要。

第 2、3 类决定了高安全需求的团队（浏览器、Linux 内核）必须有办法确保产物中缓解措施完整启用——这正是 mitigation enforcement 的核心价值；第 4 类则说明该机制不能是"一刀切"的：对于局部型缓解措施，允许按对象文件逐步启用（progressive deployment）往往是唯一可行的部署方式——一次给一个 crate 加缓解措施，远比一次性给整个程序加缓解措施现实，即使最终目标是全量启用。

三、适用哪些缓解措施：稳定项与不稳定项

RFC 明确列出"会对本特性感兴趣"的缓解措施清单，分为稳定与不稳定（以 rustc 1.89 为基准）两组，并强调本 RFC 不决定具体哪个不稳定缓解措施启用强制——那应在各自的稳定化过程中决定。

已经稳定的缓解措施

1. -C control-flow-guard：Windows 上的 CFI 类缓解措施，只部分启用会大幅降低防护效果。由于它已经稳定，需要引入-C deny-partial-mitigations=control-flow-guard或-C control-flow-guard-enforce（命名待 bikeshed）才能让它进入强制模式；也可以考虑在 edition 边界上默认强制。
2. -C relocation-model：如果二进制中混入了位置相关代码，ASLR 就无法生效。在 Rust 中这个问题不如 C 严重（位置无关代码是很少改动的默认值），且可以通过hardening-check(1)等工具检查 ELF 头。但仍可能引入-C deny-partial-mitigations=position-independent或-C enforce-position-independent。此外，作者指出目前似乎没有稳定的 Rust 编译开关可以关闭relro。
3. -C overflow-checks：从某种意义上也可视为缓解措施。为它添加强制开关或许合理，但默认强制没有意义——因为它与"只为正在开发的 crate 打开溢出检查"这一常用用法相矛盾。因此可能引入-C deny-partial-mitigations=overflow-checks或-C enforce-overflow-checks，且跨 edition 边界默认不强制。这一条可能需要单独的 RFC/FCP。

当前不稳定的缓解措施（rustc 1.89 时点）

RFC 认为强制机制与 sanitizer 的契合度尤其值得关注：

1. -Z branch-protection/-Z cf-protection：ARM 或 Intel 的控制流保护。大概率需要强制机制。它们通过.note.gnu.property生效——只有当地址空间中每个目标文件都使用时才激活，因此hardening-check(1)类工具容易检测；但因为它不是默认值，强制机制能更可靠地保证它被启用。
2. -Z ehcont-guard：针对 Windows 异常处理器的类似机制——若地址空间所有目标文件都启用，NtContinue只允许跳转到有效异常处理器。同样易于检测，但仍有纳入的价值。
3. -Z indirect-branch-cs-prefix：x86 上 retpoline（Spectre）缓解措施的一部分。
4. -Z no-jump-tables：CFI 类缓解措施？即将以-C jump-tables的形式稳定化。是否连该稳定化也一并暂缓，留待讨论。
5. -Z retpoline与-Z retpoline-external-thunk：Spectre 类缓解措施。
6. -Z sanitizer系列：相当大的使用场景。据作者判断，强制机制适用于-Zsanitizer=kcfi、-Zsanitizer=memtag、-Zsanitizer=shadow-call-stack；而不适用于-Zsanitizer=address、-Zsanitizer=dataflow、-Zsanitizer=hwaddress、-Zsanitizer=leak、-Zsanitizer=memory、-Zsanitizer=thread（-Z sanitizer=address或许应当是 target modifier）。
7. -Z stack-protector：栈破坏保护，属于局部型缓解措施。
8. -Z ub-checks：据作者判断它并非以缓解措施为目的设计的，但由于它能阻止部分 UB，也可以被视为一种缓解措施。

四、指南级说明：使用体验与错误信息

指南级行为非常直观：当你使用某个缓解措施（例如-C stack-protector=strong），而某个依赖没有启用该缓解措施时，编译失败，并给出类似如下错误：

Error: your program uses the crate `foo`, that is not protected by `-C stack-protector=strong`. Recompile that crate with the mitigation enabled, or use `-C allow-partial-mitigations=stack-protector` to allow creating an artifact that has the mitigation only partially enabled. It is possible to disable `-C allow-partial-mitigations=stack-protector` via `-C deny-partial-mitigations=stack-protector`.

另一类情况：默认允许部分启用的缓解措施（例如-C overflow-checks=on这类开关），如果想保证依赖与自己有一致的缓解设置，可以传-C deny-partial-mitigations=overflow-checks；该开关又会被-C allow-partial-mitigations=overflow-checks覆盖。

也就是说，每个缓解措施有一个"允许/拒绝部分启用"的布尔状态，由成对的 allow/deny 开关控制，且终端用户总可以通过编译器开关关掉强制（这是 Summary 中明确要求的设计约束）。

五、参考级语义：标志优先级、元数据与兼容性矩阵

5.1 标志的"最后写入者获胜"与重置行为

对每个缓解措施类选项，编译器 CLI 开关决定其允许还是拒绝部分启用：

• 打开允许：-C allow-partial-mitigations=<mitigation>
• 打开拒绝：-C deny-partial-mitigations=<mitigation>

例如-C allow-partial-mitigations=stack-protector与-C deny-partial-mitigations=stack-protector。这些标志与其他编译器标志一样，同一缓解措施出现多个值时后出现的生效。

关键的一条规则是：缓解措施选项本身出现时会"重置"强制状态为拒绝。例如-C stack-protector=strong出现后，stack-protector 的强制状态回到 deny。这样做的目的是：让发行版等可以在默认配置里"允许部分启用"（便于全量打开缓解措施），而用户只要正常显式传入缓解开关，就自动回到"强制"这一更安全的状态，不会削弱用户的安全性。

RFC 给出的完整示例：

-Callow-partial-mitigations=stack-protector -Callow-partial-mitigations=overflow-checks -Callow-partial-mitigations=kcfi -Cdeny-partial-mitigations=overflow-checks -Csanitizer=kcfi

解释：

• stack-protector：允许部分启用（有 allow，且没有后续的 deny 或重置）；
• overflow-checks：拒绝部分启用（后出现的 deny 覆盖了先前的 allow）；
• kcfi：拒绝部分启用（-Csanitizer=kcfi重置了 CFI 的强制状态，覆盖了先前的 allow）。

5.2 crate 元数据与报错时机

• 每个 crate 都会获得一个元数据字段，记录它启用了哪些缓解措施。
• 编译当前 crate 时，如果当前 crate 对某个缓解措施开启了强制，而某个依赖未启用该缓解措施（无论其自身是否强制），就产生编译错误。
• 分级兼容规则：若某个缓解措施有多个"级别"，依赖侧使用更严格的级别与当前 crate 的宽松级别兼容，反之则不兼容。例如标准库若以-C stack-protector=all编译（RFC 不讨论这是否明智），则与所有用户 crate 配置兼容。
• 与 crate 类型无关：错误发生在任意编译目标类型下——构建 rlib 时也会报错，不只是最终可执行文件。这对"渐进式部署"很重要：中间 crate 的构建就能发现问题。

5.3 stack-protector 的兼容性矩阵

以-C stack-protector为例，RFC 给出了完整的兼容性表（行 = 依赖侧设置，列 = 当前 crate 设置）：

从矩阵可以读出两条规律：其一，依赖侧等级 ≥ 当前侧等级时永远 OK（依赖更强不伤害当前 crate 的保护）；其二，依赖侧等级低于当前侧时，只有当前 crate 显式允许部分启用（allow partial）才不报错。这正是"更严格兼容更宽松"规则的表格化呈现。

六、语法替代方案的权衡

6.1-C my-mitigation-noenforce变体

一种替代设计是不引入allow-partial-mitigations，而是把每个希望支持强制的缓解措施取值拆成两个值："强制"（默认）与"非强制"。非强制模式通过在取值名后加-noenforce构造，例如：

• -C stack-protector=strong-noenforce
• -C sanitizer=shadow-call-stack-noenforce

同一类别的多个标志仍然"后者获胜"，因此-C stack-protector=strong-noenforce -C stack-protector=strong等价于-C stack-protector=strong。

对于-C stack-protector=none-noenforce：它与-C stack-protector=none等价。RFC 不确定是否两者都要保留，但认为正交性（orthogonality）倾向于是保留。

6.2 限制允许绕过强制的 crate 集合

可以设计类似-C allow-partial-mitigations=stack-protector=@stdlib+foo、-C stack-protector=strong-noenforce=@stdlib+foo的语法（用+连接 crate 名，因为,应有不同的优先级语义），只允许指定集合中的 crate 部分启用。@stdlib用来代表所有 sysroot crate，避免用户逐一列出。

这与假想的-C pretend-mitigation-enabled（缓解措施版的-C unsafe-allow-abi-mismatch）有本质区别：前者反映的是应用作者（依赖方）的决策，而pretend类标志反映的是库作者的决策。RFC 认为这种按 crate 限定集成的能力可以在核心特性稳定化之后的后续工作中再做。

两种语法若同时存在，语义可分工为：noenforce语法对所有 crate禁用强制（便于标志拼接传递），allow-partial-mitigations只对特定 crate禁用。

6.3 与-C unsafe-allow-abi-mismatch的交互

本 RFC 的规则与-C unsafe-allow-abi-mismatch完全不交互。设想一个 sanitizer runtime crate 以如下选项编译：

-C no-fixed-x18 -C sanitizer=shadow-call-stack=off -C unsafe-allow-abi-mismatch=fixed-x18 -C unsafe-allow-abi-mismatch=shadow-call-stack

那么依赖它的 crate 必须使用-C allow-partial-mitigations=shadow-call-stack，而不是-C sanitizer=shadow-call-stack，否则会报错。作者认为目前尚无此类 sanitizer runtime 的实际需求，但如果未来需要，可以考虑增加-C pretend-mitigation-enabled=shadow-call-stack（像-C allow-unsafe-api-mismatch一样把 crate 标记为"通配符"），并可能让-C unsafe-allow-abi-mismatch对同时是 target modifier 的缓解措施也起到pretend-mitigation-enabled的作用。

七、默认值设计：发行版与用户的博弈

RFC 对默认值的诉求有三点：

1. 最直觉的启用方式应当自动开启强制。例如-C stack-protector=strong或-C sanitizer=shadow-call-stack直接启用强制，让默认路径落在"缓解措施全局启用"的安全一侧。
2. 发行版需要一条轻松的"非强制"通道。例如 Ubuntu 今天就以-fstack-protector-strong的方式全局开启栈保护。发行版很难以强制方式引入新缓解措施（会造成大面积构建失败），但可以很容易地以非强制方式打开。
3. 默认组合要"可预测地收敛"。具体规则：若发行版设置了-C stack-protector=strong -C allow-partial-mitigations=stack-protector，用户再追加-C stack-protector=strong，最终结果应当是 stack-protector=strong且强制。实现方式就是前文说的"重置"行为——-C stack-protector=strong -C allow-partial-mitigations=stack-protector -C stack-protector=strong的效果等同于从未传过-C allow-partial-mitigations=stack-protector。

发行版/打包者设置默认值的途径：通过RUSTFLAGS传参，或修改编译器使其表现得像存在一组"隐式前置"的RUSTFLAGS参数。

八、标准库问题：为什么 build-std 绕不开

缓解措施最容易"混用"的地方就是标准库。标准库以单一的一组缓解措施预编译（截至 Rust 1.88：PIC、NX、-z relro -z now），在不使用-Z build-std时，用户只能沿用这些设置。

RFC 的预期方向是：如果发现某些缓解措施对标准库有正的成本收益比（很可能至少包括-Z stack-protector），那么应当默认附带支持它们的标准库，但方式上要允许用户继续无缓解地编译自己的代码——例如发布带-C stack-protector=strong的libstd，同时允许用户以-C stack-protector=none编译自己的代码并链接它——当用户的性能/安全权衡确实如此偏好时。

这与仓库中 build-std 系列的 RFC 直接相关：text/3873-build-std-context.md 系统梳理了 build-std 的动机与分阶段提案（build-std context、build-std="always"等），text/3874-build-std-always.md 中也专门讨论了 target modifiers 与预编译标准库不匹配的场景。从这些文档的脉络可以推断，mitigation enforcement 若要真正可用，build-std 的稳定化是重要的配套前提。

九、为什么不用其他机制：target modifiers、外部工具、lint 等

这是本 RFC 篇幅最大、也最能体现设计权衡的部分。

9.1 为什么不用 target modifiers

target modifier（见 text/3716-target-modifiers.md）目标相似——防止编译器设置不匹配——但不适合缓解措施：

• 名称问题：允许混用 target modifier 的开关叫-C unsafe-allow-abi-mismatch。对非"ABI 不安全"的场景，这个名字不合适；且 "unsafe" 一词在 Rust 生态中倾向只保留给可能导致真正 soundness 问题的场合。
• 行为问题：该开关把 crate 标记为"通配符 target modifier"，允许它与任意取值的 crate 混编。这对原始用途（"我知道自己在做什么"的逃生舱，如内核中个别编译单元使用真实浮点，通过特殊函数切换寄存器状态后再调用）很合适；但对缓解措施，关闭它的预期用户更多是"不同意该性能/安全权衡"的人，而非"深谙底层"的人。此时应当让可执行文件的作者知悉权衡，而不是让中间的库替它做决定。
• 划分判据：RFC 给出了对每个"缓解措施类开关"的四分法：
  1. 混用会导致 unsound 行为、sanitizer 误报或崩溃 →target modifier；
  2. 混用会损害生产程序的安全姿态（但不 unsound）→enforced mitigation（本 RFC 的机制）；
  3. 只用于 fuzzing/测试、混用不导致 unsound 的 sanitizer →两者都不是；
  4. 混用有时损害安全姿态、有时 unsound →两者都是（作者未发现当前有符合此模式的开关）。

9.2 为什么不用外部工具

外部工具很难做到，因为没有办法查看一个二进制就能得知其各组件启用了哪些缓解措施。现有工具均有局限：

1. hardening-check(1)存在，但其栈保护检查只验证"至少有一个函数带 stack cookie"，而非检查每个关键函数；
2. Linux 内核的objtool可检查 retpoline 等其他缓解措施，但它需要访问.o目标文件而非最终链接产物——要求使用者控制链接过程——且其硬编码的局限使其只适合 Linux 内核；
3. Fedora 的annobin能解析.gnu.build.attributes节（编译器可用它标注缓解措施支持），比较契合需求，但仅限 GNU/Linux 世界，而希望有全平台方案；
4. checksec类似，有类似的局限。

9.3 程序头可见的缓解措施与.note.gnu.property

部分缓解措施通过 ELF 程序头的标志对整个可执行文件生效：

• 需要所有组成目标文件兼容才生效的：位置无关代码（ET_DYN）、不可执行栈（PT_GNU_STACK）、.note.gnu.property类缓解措施；
• 链接期选择、无需改动目标文件编译的：relro（PT_GNU_RELRO）。

这类情形下hardening-check(1)等工具常可直接检查程序头。

.note.gnu.property的机制值得展开：它包含一组属性（如GNU_PROPERTY_AARCH64_FEATURE_1_BTI）用于指示代码含特定缓解措施（如 BTI，对应-Zbranch-protection=bti）。链接多个目标文件时，链接器把结果属性设为各组成目标文件属性的逻辑与（AND）。对 BTI 这类保护，只有二进制内所有代码都支持时才能开启——任何一个目标文件不支持，加载器就必须整体关闭该缓解措施；ELF 加载器依据已加载可执行文件中的属性值决定是否开启。

如果能让 C 代码也走上这条路，缓解措施追踪甚至可以跨语言传播，最终编译步骤在属性未启用时故意报错。但缺点明显：新增.note.gnu.property属性需要各 target 拥有者的合作，如果希望不依赖全平台配合就能添加新的强制缓解措施，这条路就不好。因此它更适合作为"与 target 拥有者合作"的未来步骤。

9.4-emit=component-info：把检查挪到 Cargo 的取舍

一个较大的替代方案：通过-emit=component-info输出一份组件信息文件，例如：

{ "components": [ { "type": "crate", "name": "foo", "mitigations": ["a"] } ] }

然后由 Cargo 遍历该文件查找缺失的缓解措施。利弊如下：

• 没有 Cargo 支持就不够好——人工扫描生成的 JSON 文件太麻烦；
• 要避免这类 JSON 陷入 bikeshed 泥潭；
• 优点：用户可以写自定义策略，减轻 overflow checks 之类问题的 bikeshed 压力；
• 缺点：本质上把复杂度从 rustc 挪到了 Cargo，未必减少总复杂度；可以通过RUSTFLAGS只在 rustc 启用缓解而不在 Cargo 启用，使其"名义启用、实际不强制"；最大的缺点是给不用 Cargo的项目增加了远超必要深度的集成负担——它们得自己实现扫描逻辑。

即便该方案不中选，RFC 仍认为某种-emit=component-info是好特性，值得单独的 RFC；它与-C allow-partial-mitigations并不冲突。

9.5 为什么不用 lint 机制

理论上缓解措施强制可以做成一组 lint，通过标准 lint 基础设施暴露（例如经 Cargo 现有的 lint 配置）。问题在于：

• lint 的设计预期是"可以被 cap"（--cap-lints=warn）的——对存在疑似 bug 但不在活跃开发的代码，用户倾向于照用并压制警告；
• 需要一个"force-error-but-allow-allow"级别的选项：能压过 lint capping 但压不过allow。这会使 lint 等级从全序变为格（lattice），不 desirable；
• 对缓解措施而言，"带着已知缺失的缓解措施部署"本身就是不想要的状态；
• 此外 lint 通常由开发者控制，而缓解措施通常由 DevSecOps 工程师控制，保持这种职能分工是合理的。

9.6.gnu.build.attributes

这是 Fedora 的一个特性，行为与期望的 mitigation enforcement 相当接近：Fedora 的编译器插件让 C/C++ 编译器输出.gnu.build.attributes节，标注哪些缓解措施存在或缺失；链接器聚合这些节，annocheck可检查某目标文件是否声明缺失关键缓解措施。目前这基本还是 "Fedora-ism"，虽然可以配合非 Fedora 链接器使用（但那样 C 代码通常不会标注自己缺什么）。与 Fedora 协调让 rustc 也输出该元数据可能是好主意，但它只在 Linux 平台工作，不宜作为唯一依赖。

9.7 把强制缓解措施传给链接器

当前版本对该 RFC不处理原生（C）依赖——带缓解措施的程序中可以混入无缓解措施编译的原生代码。从源码结构看，rustc目前不读取原生依赖的目标文件，而是把让链接器找到并链接这些目标文件的参数传给链接器。若链接器接受强制某些缓解措施的标志（目前主要是"程序头可见"的那类），编译器应当把这些标志传给相应链接器。由于这会破坏与现有 C 代码的混合编译，可能需要跨 edition 或链接器变更边界来做。

十、Prior Art：Rust 已有的不匹配检测基础设施

RFC 指出，Rust 编译器已经有检测标志不匹配的基础设施——panic strategy：

• 相关开关为-C panic与-Z panic-in-drop；
• 预编译标准库会根据使用的策略附带不同的组件，尽管在-C panic=abort下 panic landing 相关部分并未完全移除，因为只切换了预编译 stdlib 的一部分。

这说明"crate 元数据 + 编译期不匹配检查"这一模式在 rustc 中已有先例，mitigation enforcement 属于同族机制的扩展。另一个 prior art 是前文讨论的.note.gnu.property——C 代码在链接期检测标志不匹配的例子；target modifiers（RFC 3716）则是最接近的在制品方案，两者的关系已在 9.1 节的四分法中厘清。

十一、未来扩展方向

RFC 的 Future possibilities 部分明确了两条：

1. 跨语言的缓解措施强制：在 C 代码与 Rust 代码之间强制执行一致的缓解措施。这是一个有意思的扩展，但需要跨语言社区协作，周期较长；
2. 动态链接场景下的缓解措施不匹配检测。

结合仓库中的路线图文档，可以注意到project-exploit-mitigations团队的目标持续出现在 text/3849-Project-Goals-2025h2.md（如 MemorySanitizer 与 ThreadSanitizer 支持的稳定化）和 text/3935-Project-Goals-2026.md 中——这说明缓解措施方向在 Rust 项目目标体系中是活跃的、持续投入的方向，RFC 3855 的机制正是为这一方向的落地提供"不静默降级"的保障。

十二、小结：一张机制地图

把 RFC 3855 的关键要素收敛为一张清单，便于在实现与评审中对照：

对阅读该仓库的开发者，建议的深入路径是：先读 text/3716-target-modifiers.md 理解"ABI 不匹配"一侧的机制（尤其是其 "Exploit mitigations" 一节，正是本 RFC 问题域的原始讨论），再看 text/3873-build-std-context.md 与 text/3874-build-std-always.md 理解标准库重编这一配套前提，最后回到 text/3855-mitigation-enforcement.md 本体，即可完整掌握"缓解措施一致性"这一主题在 Rust 工具链中的整体设计版图。

• 文档