LWN上那篇关于内核"支持"$ORIGIN的patch讨论，让我回想起做container seccomp时反复拉扯的一个问题：kernel到底该替用户空间做多少决策。这个补丁的答案是——更少，而不是更多。

它不是让内核在内核态完整展开$ORIGIN或做RPATH解析。实现方式更像一个轻量透传：加载器在map模块时把原始RPATH/Runpath信息保留下来，交给用户空间的ld.so去解。Greg Kroah-Hartman那派"don’t put policy in kernel"的传统又一次赢了。

这种克制的安全收益很直观。字符串拼接、路径归一化、环境变量展开这些复杂逻辑一旦塞进ring 0，就等于把攻击面直接喂给kernel exploit。想想近几年针对vfs和路径解析的LPE CVE数量，这个feature要是做成"内核自己算"，维护者大概会崩溃。所以保留最小钩子、把语义复杂性交还用户态，是Linux"minimal kernel"哲学在现代场景下的韧性延续。

更有意思的是它对构建工具链的连锁反应。glibc和musl对RPATH的处理从来就不一致，patchelf、chrpath这些工具以前基本靠约定和hack混过去。现在内核明确说"我只负责传，不保证语义"，那么cargo-audit、nix以及reproducible build的验证逻辑就必须更前置、更严格。这反而把安全性从运行时后移到构建时，对supply chain完整性是件好事。
嗯
这个patch代码量很小，但架构信号很强。它再一次说明，系统设计里最难的不是决定加什么，而是决定把什么拒之门外。值得后续跟进。

楼主对内核“克制”的梳理很清晰，尤其是把策略层推回用户态的论述。不过文中提到“维护者大概会崩溃”，这个归因值得商榷。从某种角度看，内核态处理这类逻辑的瓶颈更多在于ABI的向后兼容性，而非单纯规避CVE。以CVE-2021-3156为例，漏洞根源是权限边界模糊，而非路径解析本身。内核坚持minimal design，核心诉求是维持系统调用的确定性。我早年做安防巡检时，见过太多因核心逻辑过度耦合导致的级联故障，把复杂性留给用户态确实是更稳健的工程选择。你们在容器环境里测过musl下的$ORIGIN解析延迟吗？