Re: [PATCH v2 0/9] binfmt_misc: bpf-backed binary type handlers

["Farid Zakaria" <farid.m.zakaria@gmail.com>]

On Wed Jul 15, 2026 at 1:40 AM PDT, Christian Brauner wrote:
> On 2026-07-14 17:28 -0700, Farid Zakaria wrote:
>> On Tue, 14 Jul 2026 21:58:05 +0200, Christian Brauner <brauner@kernel.org> wrote:
>> > [...]
>> > 		.load = (void *)nix_load,
>> > 		.name = "nix",
>> > 	};
>> > 
>> > Farid, this should slot underneath your qemu demo from [4] with the
>> > program ported to struct_ops. Feel free to take it from here.
>> 
>> Thanks for the recent update.
>> Is it still "take it from here" or was this left-over from the previous
>> series.
>
> Leftover from the previous series. :) Sorry.
>

No problem -- just checking.

>> I think you've done the majority of the work here with the validation of
>> the few selftests and mentioning the gap for shebangs.
>
> It was a nice joint effort imo. I think this is in general an
> interesting idea. I'm also working on some glibc loader patches. One
> of the patches in this series allows for "transparent binary execution"
> if the loader supports it.
>
> In this mode you can pass AT_EXECFD to an interpreter and don't change
> the command line. An exec like this is indistinguishable from a "native"
> exec.
>

This sounds super interesting (orthogonal to binfmt_misc and BPF work right?)
but a neat feature nonetheless. I wonder if this makes it easier for
tools like perf to attribute the correct binary or they have already
handled interpreters in the cmdline well enough.

>> Please let me know what you would like me to do next. I just tested
>> reviewing the series with b4 + AI -- pretty cool. Was a little clunky to
>> get it to work but overall a good experience. (I need to tinker with it
>> a little for NixOS vim setup etc..)
>> 
>> I shared this patch series at my workplace as well. 
>> I think there is some interest in the work.
>> (If you are curious as to why, I can elaborate on that as well).
>
> Sure, happy to hear other use-cases. I have a plan to make it possible
> to pre-open a set of interpreters (pin them essentially) when
> registering the handler in binfmt_misc and then bpf would be able to
> select from a set of pre-opened interpreters but that's for the future.
>

This is assuming that in prior calls to the BPF it returned the path
string to be pinned?

As for the use case, we use buck2 --
a build system similar to Google's Bazel and does many things in spirit
to Nix by leveraging RUN_PATH to create links to the shared-libraries.

We have customized our interpreter however the lack of $ORIGIN means
that we've had to maintain a single glibc versioning across our machines as
a platform since glibc has tight coupling between the loader and the
libc.

This has been a pain point for upgrading. I think the ability for the
loader to now be relative to $ORIGIN meanst hat each binary could
diverge glibc/ld.so and not affect the rest of the machines.

tl;dr; ld.so from $ORIGIN itself is not only useful but since it's
intimately tied to glibc, it allows for more flexibililty across our
builds (very similar to NixOS in spirit).

>> I hope you are enjoying your vacation.
>
> Thanks!