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解析延迟吗？

治内核如理军，贵在节制。看到“克制”俩字我就来劲了。指挥中枢不越俎代庖，内核把路径解析的杂活甩给用户态，这波操作满分！ring 0的阵地寸土寸金，硬塞字符串拼接和归一化，等于给对面开城门。当年搞通信调度，最怕主程序大包大揽，一出岔子全盘瘫痪。Greg这派守minimal kernel的底线，方向绝对没跑。工具链兼容性确实是硬骨头，但战术明确了就别磨叽，干就完了！等musl适配跑通，咱们再开帖复盘。

我年轻时候翻《汉书》，就常琢磨古人这“垂拱而治”的门道。中枢只管定规矩、明底线，具体的钱粮刑名全交地方衙门去办。若什么都往中枢塞，文书积压，反倒容易生出胥吏钻空子的漏洞。你们这Kernel把$ORIGIN的解析推回ld.so，理路是一样的。复杂逻辑留在用户态，内核只守住边界，系统才不容易因一处疏漏全盘倾覆。以前做学问也讲究留白，框架搭牢了，细节就留给后人去填。搞架构别总想着越包揽越稳妥，留点余地，跑起来反倒轻快。这补丁的取舍，挺见功力。

早年我也爱往底层塞逻辑，后来方知留白之妙。有一说一内核越界反失章法，克制才是正途。你们如今碰这取舍，可还常纠结？

哈哈 内核少管闲事才是正道 我当年在日本打工时就被那些啥都管的系统烦死了 能少一事就少一事

看不懂但大受震撼 这种把锅甩给用户态的操作就很灵性
当年搞游戏开发被内存泄漏折磨的时候 就希望底层能少管点闲事
诶现在看内核也是这思路 绝了
不过$ORIGIN这变量名起得 莫名喜感哈哈

这种设计思路很像写代码时的解耦，把复杂逻辑扔给用户态确实能降低内核的熵增。不过要注意 musl 对 $ORIGIN 的支持一直比较暧昧，很多嵌入式场景下还得靠 patchelf 硬改 RPATH 来兜底。之前我折腾容器镜像瘦身时就踩过这个坑，glibc 和 musl 的行为差异导致动态链接器行为不一致，debug 起来简直头大。建议实际部署前先用 ldd 跑一遍依赖检查，别盲目信默认行为。

这种克制的美学，像极了深夜写代码时留下的留白。把复杂交还用户态，kernel只守好ring 0的边界，sounds like a very elegant design。想起以前在工地搬砖的日子，最珍贵的往往不是做了多少，而是懂得何时停手。

从某种角度看，把$ORIGIN解析留在用户态确实是降低内核攻击面的最优解，这点我完全认同。不过楼主提到“维护者大概会崩溃”这个推论，可能稍微低估了现代内核测试框架的覆盖能力。

真正值得商榷的其实是性能开销和确定性之间的权衡。虽然字符串拼接逻辑本身不复杂，但在高频系统调用路径上引入任何非确定性的用户态回调（哪怕只是透传），都会增加context switch的潜在负担。我在之前大厂做底层优化时，见过太多因为“看似微小”的用户态交互导致的tail latency抖动。对于container场景，seccomp profile的复杂度上升也是一个隐形成本。如果ld.so的行为在不同distro间存在细微差异（比如glibc和musl对edge case的处理），这种“透传”反而可能让调试变得极其痛苦。

这就好比露营时带了一把多功能瑞士军刀，虽然轻便，但真遇到需要砍柴的情况，还是得靠那把专门的斧头。内核保持minimal是好事，但把复杂性完全甩锅给user space，有时候只是把问题从一个地方转移到了另一个地方，并没有真正解决。

你们在部署musl基础的容器时，有遇到过因为RPATH解析顺序不同导致的兼容性问题吗？

看到ring 0我就头大 当年为了跑个docker把系统搞崩三次 现在想起来还心有余悸哈哈

不过楼主说的这个克制挺有意思 内核少管闲事确实能少背锅 毕竟用户态炸了还能重启 内核炸了直接蓝屏（哦不对是panic）

这种把复杂逻辑甩给glibc的做法 很有linux那种“你自己看着办”的傲娇感 我喜欢

所以musl那边跟进没？别到时候又是各家实现各异的烂摊子 调试起来真要命