transcript
show notes
为什么栈必须连续，而不能按需稀疏映射？Raymond Chen 从这一看似节省内存的设想出发，拆解了它如何绕过 guard page，演变为著名的 Stack Clash／guard-page hopping 风险：一次跨页的大型栈分配，可能让程序悄然读写本不属于栈的相邻内存。
本期对原文进行深度解析，串联 Sudo、su 等 SUID 程序曾遭受的本地提权实测案例，并进一步说明：稀疏栈不仅削弱边界防护，还会破坏 `alloca` “返回成功即代表内存可用”的关键错误处理契约。欢迎结合原文阅读。
原文链接：
https://devblogs.microsoft.com/oldnewthing/20260907-00/?p=112677
原文标题：Why don’t we allow stacks to be sparse, instead of forcing them to be contiguous?
主要内容：
• 连续栈通过逐页访问与 guard page，把栈扩张的边界检查嵌入实际访问路径。
• 大型 `alloca` 若跨越保护页而未触碰中间页面，就可能形成 Stack Clash，造成相邻映射与栈空间混淆。
• Qualys 曾展示针对 Sudo、su 等 SUID 程序的完整本地提权利用，证明这并非纯理论风险。
• 延迟到首次访问才提交页面，会让分配失败发生在 `alloca` 返回之后，打破既有异常处理与可用性契约。
• 真正可靠的方向不是取消探测，而是在栈实际扩张时高效地逐页探测，并确保编译器、旧二进制与手写汇编都获得覆盖。
推荐理由：
这篇文章把一个表面上的内存优化问题，推回到底层系统设计最关键的两条原则：安全检查必须无法被“跳过”，而接口成功的语义必须稳定可信。它既解释了 Stack Clash 为何危险，也揭示了性能、兼容性与安全契约之间常被忽视的牵连；对系统编程、编译器安全与操作系统机制感兴趣的读者尤其值得深入阅读原文。
---
「Andrej Karpathy的RSS订阅清单」为您精选全球最前沿的AI技术博客文章，深度剖析技术背后的核心洞察。
由 voieech.com 提供技术支持。
