On Thu, Jun 25, 2026, at 4:50 AM, Christian Brauner wrote: > Also, we change long-standing kernel behavior which will be very > surprising for any userspace that might implicitly rely on the fact > that the system loader is used. So even if we were to do something > like this it would very likely have to be configurable in some way.
Yes that's definitely something that worried me. > So I'm not enthusiastic about this. I want this to be consistent. For what it's worth, I somewhat wish the `PT_INTERP` field didn't exist at all. IMO the ELF spec is very weird for some parts of the same headers being for the kernel, and the other parts being for userspace. If there were separate data structures (think encapsulated packets) so it was crystal clear who was responsible for what, we wouldn't be in this situation. While I earlier complained that our <https://github.com/Mic92/wrap-buddy> work-around was likely to make some security analyses/policies go haywire, arguably it implements this behavior: from the kernel's perspective, everything is statically linked, and the program, entirely in userspace, takes responsibility for whatever loading it needs. Put that way, this is less of an ugly work-around than the way I wish things worked period in a world without `PT_INTERP`. Dynamic linking would be entirely a userspace concern and the kernel would not know or care. ---- What about shebangs? It's the same problem, with the same solutions and pitfalls. We can also make wrapper executables around them that do the right thing, but turning mere scripts into statically linked binaries is a bit heavier. I assume the answer is the same, but just want to double check before we close this off. Cheers, John
