Re: [RFC PATCH] fs: binfmt_misc: introduce eBPF-based matching and interpreter selection

[Alessandro Di Federico]

On Wed, 22 Jul 2026 15:33:40 +0200
Christian Brauner <brauner@xxxxxxxxxx> wrote:

> I think this could even just be part of systemd. You ship the distro
> with a file for that in /etc/binfmt.d/ and systemd loads that bpf
> program for PT_INTERP_WITH_ORIGIN.

One could delegate the feature to user space, but that makes it much
harder to get adopted in a uniform way.

Will systemd, Android [1] and OpenWrt implement this? In the same way?
If so, at that point it could have just been a feature of the Linux ELF
extension. 

Of course the Android people could disable the feature even if it's
in the kernel, but if the convention is established by the kernel,
there's really no reason to deviate from it in the way it's implemented.

The whole point of the portability thing is to reduce the assumptions
you make about the target system. Ideally, you just want to use
features widely available in kernels in the wild.

But from what I understand from another thread, your intention is to
use userspace as testbench, correct?

> This is policy that the admin should decide

Agreed, but the admin is probably satisfied with enabling/disabling,
not deciding whether the program header type is `PT_INTERP_WITH_ORIGIN`
or `PT_ORIGIN_ENABLED_INTERP`. Same for the distro maintainers.

> not an arbitrary extension into elf core.

I think that, in order for this to be useful, it needs to be a ELF
feature, not something the admin/distro maintainer puts together in
eBPF.

Then, from a security perspective, AFAIU, implementing this in
eBPF does not solve the problems that have been discussed.

For instance, `selftests/exec: add binfmt_misc bpf-backed handler test`
does string manipulation (no `openat`).

I understand that's just an example and it's not the same as committing
to a new ABI feature, but still.

Overall, I feel like the current proposal pushes back on having a new
ELF feature for security reasons, but then delegates to distro
maintainers who want to use the feature to take those risks. But also,
distro maintainers don't really need this feature because they can just
write /nix.

I love binfmt_misc enabling you to do ./foreign-architecture-binary or
./notepad.exe and spawn qemu/wine (usually with your friendly sysadmin
approval) and extra flexibility in that area with eBPF is super cool.
However if we are thinking about portability, this make sense only if
it's a default-enabled ELF feature (implemented in eBPF or not).

I'd be happy to try to work on the example eBPF program using openat,
address the various security concerns that have been mentioned until it
looks right and then it could be loaded by default, but with an option
to disable it. But I'm not sure whether there's such a thing as "default
loaded eBPF program".

Alternatively, I could extend the ELF core as a parallel feature of
the eBPF-based mechanism, reviving some patches from previous
iterations.

What do you think?

-- 
Alessandro Di Federico
rev.ng Labs

[1] There's a flavor of nix for Android (using proot) which would
benefit from this:

    https://github.com/nix-community/nix-on-droid-app