On 2026-07-06 09:47:53-07:00, Farid Zakaria wrote: > On Mon, Jul 6, 2026 at 9:01 AM Christian Brauner <[email protected]> wrote: > > > 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?
Always start a new thread and bump the version number. So we're at v3 now, if I'm counting correctly. Fwiw, if you have access to an LLM you can try and setup b4 to manage patch series. It's quite easy once you get the hang of it. > > 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. Right, bpf tokens exist to delegate bpf access to containers. Not always ideal but it works for such cases. My main point was to communicate that containers are able to disconnect themselves from being able to execute binaries by mounting an empty binfmt_misc instance, iirc. I should remember that as I did that work but I kinda don't exactly. :) In any case, I think it wouldn't be crazy to allow registering "default" handlers that appear in all binfmt_misc instances if needed so containers with separate binfmt_misc always have the bpf program available. Just thinking out loud...
