内存安全最棘手的问题

matklad 2026/07/20 00:00 论文

memory-safety type-safety tagged-unions programming-languages zig ada buffer-overflow

摘要

本文讨论了一个基本的内存安全挑战，涉及带标签的联合体，其中指向一个变体的指针在联合体被覆盖为另一个变体后被使用，导致类型混淆。作者还认为，缓冲区溢出是最容易被利用的内存错误，如果采用更好的数组语法本可以缓解。

<header> <h1>内存安全最棘手的问题</h1> <time class="meta" datetime="2026-07-20">2026年7月20日</time> </header> 提升一个 <a href="https://lobste.rs/s/vzkmtj/forget_borrow_checkers_c3_solved_memory#c_uuhbpy">lobsters 评论</a> 以便于参考。 核心的内存安全反例，即最难解决的问题，与析构函数或堆无关： <figure class="code-block"> <pre><code>const std = @import("std"); const E = union(enum) { a: u128, b: []const u8, }; pub fn main() void { const bad_addr: u128 = @intFromPtr(&main); var e: E = .{ .b = "hello" }; const oh_no_pointer: *const []const u8 = switch (e) { .a => unreachable, .b => |*p| p, }; e = .{ .a = (16 << 64) + bad_addr }; const oh_no: []const u8 = oh_no_pointer.*; std.debug.print("{s}\n", .{oh_no}); }</code></pre> </figure> <figure class="code-block"> <pre><code>$ zig run main.zig ��C�� </code></pre> </figure> 这种例子同样也会破坏 Ada 的安全性： <a href="https://www.enyo.de/fw/notes/ada-type-safety.html" class="url">https://www.enyo.de/fw/notes/ada-type-safety.html</a> 我们有一个带标签的联合体，可以容纳 <code>A</code> 或 <code>B</code>。我们将联合体初始化为 <code>A</code>，获取指向其内部数据的指针，将原始内容覆盖为 <code>B</code>，然后使用该指针。指针的类型仍然是 <code>A</code>，但它指向的字节现在属于 <code>B</code>：这就产生了类型混淆。 <hr> 话虽如此，我们关注内存不安全主要是因为它们会导致可被利用的软件，而上面这个例子在实际中的影响程度尚不清楚。巧合的是，在实践中迄今为止最容易被利用的内存错误——臭名昭著的缓冲区溢出——通过编译器插入的边界检查来修复是微不足道的。工业界在内存安全方面最大的失误是没有听取 Walter Bright 的意见： <a href="https://digitalmars.com/articles/C-biggest-mistake.html" class="url">https://digitalmars.com/articles/C-biggest-mistake.html</a> 我敢打赌，如果我们在 C11 左右有了 <code>char a[..]</code> 语法，很多问题就不会发生了！ 另见 <a href="https://matklad.github.io/2025/12/30/memory-safety-is.html">什么是内存安全？</a>

查看原文

查看缓存全文

缓存时间: 2026/07/20 21:23

# 内存安全中最棘手的问题来源：https://matklad.github.io/2026/07/20/memory-safety-hardest-problem.html 2026年7月20日为了方便参考，将 Lobsters 上一条令人振奋的评论（https://lobste.rs/s/vzkmtj/forget_borrow_checkers_c3_solved_memory#c_uuhbpy）提炼出来。内存安全的核心反例，那个最难解决的问题，与析构函数或堆根本无关： `` const std = @import("std"); const E = union(enum) { a: u128, b: []const u8, }; pub fn main() void { const bad_addr: u128 = @intFromPtr(&main); var e: E = .{ .b = "hello" }; const oh_no_pointer: *const []const u8 = switch (e) { .a => unreachable, .b => |*p| p, }; e = .{ .a = (16 << 64) + bad_addr }; const oh_no: []const u8 = oh_no_pointer.*; std.debug.print("{s}\n", .{oh_no}); } `` `` $ zig run main.zig ��C�� `` 这类示例同样也破坏了 Ada 的类型安全： https://www.enyo.de/fw/notes/ada-type-safety.html 我们有一个标签联合，它既可以存放 `A` 也可以存放 `B`。我们将联合初始化为 `A`，取一个指向其内部数据的指针，然后将原始值覆盖为 `B`，最后再使用这个指针。该指针的类型仍然是 `A`，但它指向的字节现在已经属于 `B`：这就造成了类型混淆。 --- 话虽如此，我们之所以关心内存不安全，主要是因为它会导致可利用的软件漏洞，而上述示例在实践中的影响力尚不确定。幸运的是，实际中最容易利用的内存错误——臭名昭著的缓冲区溢出——通过编译器插入边界检查就能轻松修复。整个行业在内存安全方面最大的失误，就是没有听从 Walter Bright 的建议： https://digitalmars.com/articles/C-biggest-mistake.html 我敢打赌，如果我们在 C11 时代就有了 `char a[...]` 这种语法，不少问题压根就不会发生！另请参阅：*什么是内存安全？*（https://matklad.github.io/2025/12/30/memory-safety-is.html）

内存安全最棘手的问题

相似文章

安全变得简单第1部分：单一所有权（并非）可选

内存安全是生死攸关的问题

Rust与C/C++在内存安全CVE上的差异

安全 Rust 的边界

关于C数组类型语义的讨论

提交意见反馈