On 2026-07-13 08:19 -0700, Farid Zakaria wrote:
> On Mon Jul 13, 2026 at 1:20 AM PDT, Christian Brauner wrote:
> >> > - The single sleepable load op is split into two ops:
> >> >
> >> > struct binfmt_misc_ops {
> >> > bool (*match)(struct linux_binprm *bprm);
> >> > int (*load)(struct linux_binprm *bprm);
> >> > char name[BINFMT_MISC_OPS_NAME_MAX];
> >> > };
> >> >
> >> > The non-sleepable match program runs from the RCU entry lookup
> >> > walk itself, exactly like magic and extension matching: same
> >> > registration order, same first-match-wins semantics, and it can
> >> > only rely on the prefetched bprm->buf. It must be free of side
> >> > effects since the walk may be restarted.
> >> >
> >>
> >> Is relying on brpm->buf enough?
> >> Right now that's only 256 bytes I think, which is not enough to read
> >> segments we might care about. That worked fine when it was just a magic
> >> number but the idea with the eBPF program is to make decisions based on
> >> more data.
> >>
> >> In the selftest I provided, the `PT_INTERP` segment is already at file
> >> offset 0x318 (792). I was imaginging NixOS having to support
> >> `PT_INTERP_NIX` in order for the produced binaries to be backwards
> >> compatible with older kernels.
> >>
> >> The other idea would be to make the `match()` broad and select
> >> everything but then nearly all ELF64 binaries would match and then pay
> >> the price to `load()` and ultimately `-ENOEXEC`. Seems like it would
> >> make multiple BPF binfmt programs less useful.
> >
> > Ok, so your idea is to have multiple bpf programs that look for
> > different interpreters. Yeah, then you have to be able to sleep because
> > you need to be able to fault. It makes the code uglier but I can see how
> > that's useful. I'll see how nice I can make that.
> >
>
> I mean... I thought that's the intent to binfmt_misc, to have multiple
> handlers -- with the expressiveness of eBPF vs. the limited
I was thinking of having one bpf program per type (elf, python, etc) but
I can see how it's useful to have multiple elf bpf handlers...
> > Ah, fun. binfmt_misc wasn't able to express this at all. It's good to
> > close that gap. This can just be done by adding
> > bpf_binprm_set_interp_arg().
>
> What is "cool" about this is now it's also a net-new feature for shebags
> which the "old" binfmt_misc didn't support. Anyways, I was thining ahead
> about what I would need to support $ORIGIN fully and this was
> a remaining gap. We also explored this idea in a patch pre-BPF [1] but
> now that we've settled on this solution it seems much more natural.
>
>
> I was recently reached out by some Bazel people who are also interested
> in this $ORIGIN support. Interestingly they let me know that
Yeah, for build systemd it's very nice ofc.
> IllumOS/Solaris had support for it as well.
The whole $ORIGIN thing comes from Illumos/Solaris afair. So no big
surprise.
