On Mon, Jul 6, 2026 at 9:01 AM Christian Brauner <[email protected]> wrote: > > > Historically binfmt_misc has only matched binaries by magic bytes or file > > extension, and always redirects a match to a fixed interpreter recorded in > > the registration. This is insufficient when the match requires parsing the > > binary header (e.g. inspecting ELF program headers) or when the interpreter > > must be computed per-binary rather than hard-coded. > > > > Introduce a new 'B' (BPF) handler type. A pinned SOCKET_FILTER program is > > registered in place of the magic/mask, and no interpreter is recorded: > > > > echo ':name:B:<bpf_pinned_path>::::<flags>' \ > > > /proc/sys/fs/binfmt_misc/register > > > > When a binary is executed, binfmt_misc runs the program with the > > BINPRM_BUF_SIZE file-header buffer as context. Returning 1 selects the > > handler; returning 0 falls through to the remaining handlers. > > > > Unlike magic/extension handlers, a 'B' handler carries no interpreter of its > > own: the program chooses it via a new helper, bpf_binprm_set_interp(). This > > lets the program compute the interpreter path however it sees fit (for > > example > > relative to the binary). A 'B' handler is therefore a strict superset of the > > existing magic handlers -- any of them can be expressed as a program that > > matches on the header and sets a fixed interpreter. > > > > bpf_binprm_set_interp() is exposed to SOCKET_FILTER programs and stashes the > > chosen path on a per-CPU area that binfmt_misc reads back immediately after > > the run under migrate_disable(); only a match that set an interpreter > > allocates. > > > > Signed-off-by: Farid Zakaria <[email protected]> > > Ignoring the blatant bpf abuse here I think this is quite workable. So > this can be turned into an actual design and patch imho...
Glad to see you think this proposal is in the right direction. Just for my edification, when you say "balatant bpf abuse", you mean how it abuses the socket bpf type? If so, do you have any guidance on a new type or should I just take a stab at it. For the proper RFC patch unbastardized with tests, should I start a new thread or is the convention to keep attaching it to this same thread? > > Note that binfmt_misc is namespaced and can be mounted inside of user > namespace + mount namespaces fwiw. So a container mounting binfmt_misc > (a fresh instance - few do) would escape that bpf program. On the other > hand it would allow to register a custom bpf program per container if > needed... That makes sense -- but you will need CAP_BPF etc.. to load the new programs though if inside a userns. > > -- > Christian Brauner <[email protected]>
