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 5:10 PM PDT, Farid Zakaria wrote:
> 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!

Ah one more thing!

What's next for this patch? Do we wait for BPF maintainers to comment?
Should I continue to add Reviewed-By trailers to the other patches?
(I have limited knowledge on some of the mutex stuff but the agent
review in b4 was helpful in understanding it enough to give a review.)

Sorry if it's obvious. I've never contributed to a patch this far
along or substantial to the point of having to understand the
merging/acceptance process in Linux.