Linux Kernel Gains $ORIGIN Support via eBPF and binfmt_misc
Linux kernel will support $ORIGIN, sort of
I proposed adding $ORIGIN support to the Linux kernel for relocatable Nix binaries, expecting rejection. Instead, maintainer Christian Brauner collaborated on a solution using eBPF and binfmt_misc. This breakthrough allows dynamic interpreter selection and transparent execution, enabling powerful new use cases for tools like Nix, Buck, and Bazel while maintaining full backwards compatibility.
A ship in harbor is safe, but that is not what ships are built for.
- nextaccountic
I was confused on what $ORIGIN means, so, macroexpanding the article a bit
https://fzakaria.com/2026/06/21/nix-needs-relocatable-binari...
> The loader in Linux however natively supports the variable $ORIGIN which translates to “the directory containing the executable.”
https://man7.org/linux/man-pages/man8/ld.so.8.html
But, if ld.so supports $ORIGIN already, why does the kernel needs to support it also? Or rather, why can't the kernel leverage ld.so and do this entirely on userspace?
- wzdd
My reaction was negative when I read the title (policy!), but the actual outcome was very reasonable. "Hey, can we add $ORIGIN to the VFS layer to support relocatable interpreters?" "You can already do that with binfmt_misc and ebpf, here's an example."
Then, later, a couple of patches to make binfmt_misc more ergonomic. Seems like a good outcome.
- stabbles
Nice, PT_INTERP is the only non-relocatable thing of ELF files and typically requires wrapper scripts/executables.
Regarding shebangs, I've never understood why the kernel cannot resolve e.g. `#!sh` relative to PATH instead of CWD. Posix prescribes that you should look for `sh` in PATH and don't expect it to be in `/bin/sh`. And using `/usr/bin/env sh` has the same issue: what if coreutils is installed elsewhere.