OpenBSD – 固定所有系统调用

新 syscall 固定的范围

• 内核现在更严格地约束 syscalls：
  • 以前：syscalls 只允许从进程的 libc 代码区域发起。
  • 现在：固定到特定的 libc syscall stub。
  • 对静态二进制：只允许二进制里实际引用到的 syscalls；其他 syscalls 实际上被禁用。
• 程序的 .text 现在不能再直接执行 syscalls；必须通过 libc（或启动期间的 ld.so）来调用。
• 语言运行时通常会调用 libc，因此仍然可用；那些会在运行时动态合成原始 syscalls 的“怪异”运行时或 JIT 可能会被阻止。

---

安全影响与利用技术

• 固定化减少了一些 ROP/JOP 的自由度：
  • 你不再能把任何可达的 syscall 指令变成任意 syscall；只允许记录过的 syscall 号。
  • 你仍然可以滥用被允许的 syscall 参数（例如，如果程序本来就会调用 execve，你仍然可以调用它）。
• 对静态二进制来说，攻击者不能通过 ROP 跳到程序从未使用过的 syscalls（例如不存在的 execve）；这被认为有助于限制攻击面。
• JIT 仍然可以跳入允许的 syscall thunk；浏览器 JavaScript 通常也不会直接 syscall。
• 另一个缓解效果：将 syscalls 限制在 libc 内，会让某些 ASLR 绕过更复杂——因为攻击者可能只知道主二进制的布局，并在代码段里寻找 syscall 字节模式。

---

关于效果与威胁建模的争论

• 支持观点：
  • 如果这个缓解措施代价低、又不会增加攻击面，那就值得发布。
  • OpenBSD 历史上经常在某类攻击公开之前就部署缓解措施（例如在 Spectre/Meltdown 之前关闭超线程；以及后来阻止 DNS 缓存攻击的“看似多余”的随机化）。
  • 低 CVE 数量，以及能预先阻止漏洞的缓解措施，被用来证明其安全直觉是可靠的。
• 怀疑观点：
  • 没有把缓解措施明确对应到真实世界利用/CVE 和经过测试的 exploit 链，就会被批评为“模糊不清”，甚至是“安全表演”。
  • 每一项缓解都会增加复杂度和长期维护成本；如果没有清晰的威胁模型，这反而可能降低整体安全性。
  • 有人认为，如果一个缓解措施并不能清楚地阻止当前在野技术，那它大多只是学术练习。
  • 也有人反驳说，过于关注“修复了多少 CVE”会奖励过去的失误，并低估那些被预先阻止的 bug。

---

发现的实现 bug

• 新代码里发现了一个看似简单但真实存在的 bug：
  • MAX 宏里有有符号/无符号混用，导致攻击者可以把内部计数（npins）拉成负数，从而引发分配不足，并在堆上发生越界写；写入位置由攻击者控制的 syscall 号索引决定。
  • 一个示例利用草图是使用精心构造的“已固定 syscall”表项先污染内存，再强行把 npins 设成 -1，而后它在分配前被钳制成一个较小的正值。
• 关于工具的讨论：
  • 有人指出，Rust 风格的整数/类型检查本可以阻止这类 bug。
  • 也有人指出，C 编译器其实已经有相关选项（例如符号比较警告、sanitizer、溢出陷阱）本可以发现它，只是并非普遍启用。

---

C vs. Rust 与 OpenBSD 的限制

• Rust 因其更安全的整数语义和类型检查而受到赞赏，但：
  • OpenBSD 约有数千万行 C、很多平台，而且人力极其有限。
  • 将核心 OS 代码重写或深度集成 Rust，被认为风险高、资源消耗大。
• 有人认为新的安全导向 OS 应该从 Rust 开始；也有人强调 Rust 并不是银弹，成熟的 C 代码加上谨慎的工具仍然可以继续可用。

---

元话题：OpenBSD 的安全姿态与生态

• 一些参与者表示，OpenBSD 的用户基数太小，因此不存在一个丰富、经验上已知的“利用元(meta)”；所以很多讨论只是从其他平台外推。
• 这里面存在张力：
  • 一类人认为 OpenBSD 的口号和声誉被夸大或误导。
  • 另一类人认为，持续的加固工作和相对较少的严重漏洞已经足以证明其价值，并且对那些积极劝阻他人使用它的做法感到困惑。