Re: Questions and concerns about BPF-selected interpreter

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

On Tue Jul 21, 2026 at 5:26 PM PDT, Cole Faust wrote:
> Correcting Farid's email.
>
> On Tue, Jul 21, 2026 at 5:24 PM Cole Faust <colefaust@google.com> wrote:
>>
>> Hi Christian, Farid,
>>
>> My name is Cole, I work on the android build system. We have similar
>> goals for creating hermetic and relocatable builds in our build system
>> (a custom, android-specific one). I was very excited when I saw Farid
>> working on $ORIGIN support, but then somewhat disappointed when I saw
>> the new BPF-based solution.
>>
>> Our usecase is mostly to decouple the glibc version used in the
>> android build from the host machine. We've had several instances where
>> our CI machines are running old glibc versions that cause problems,
>> and they're not trivial to update. Ideally you should be able to
>> download the android source and build it on a modern linux kernel,
>> regardless of the userspace.
>>
>> To register a binfmt_misc handler, you need either root + modifying
>> global state on the host, or to make a user+mount namespace. But if we
>> use a mount namespace, couldn't we just mount the interpreter we want
>> to use at a fixed path? I thought one of the main goals of this
>> features was to avoid the use of namespaces because they don't always
>> nest well; Farid called this out as a problem with buck2's sandboxing.
>> In android, we don't yet have any nested sandboxing but there have
>> been conversations about increasing security of the build using
>> something like gvisor to isolate the build from the kernel, in wake of
>> the recent AI-discovered local privilege escalations, after which
>> these complicated kernel features are likely to stop working. And
>> requiring root is definitely out of the question.
>>
>> I also wanted to ask about the security of this bpf solution. I
>> understand there are some security concerns about $ORIGIN. Why is this
>> new binfmt_misc + bpf solution better? An attacker will still have
>> more opportunity to place a malicious loader relative to the
>> executable. With the binfmt_misc solution, you will be able to only
>> have it active for certain things, like a build, but that's only if
>> you use the user+mount namespace to scope it. From what I understand,
>> Farid plans on registering the handler globally and persistently on
>> NixOS systems that want relocatable builds, does that not make those
>> systems susceptible to these concerns? (correct me if that's not your
>> plan, Farid)
>>
>> I can't really think of a better solution than the originally-proposed
>> $ORIGIN support for build systems to use. I don't care about setuid or
>> complicated filesystems like memfd, so I would hope it would be
>> straightforward to just error out if AT_SECURE is set or if any issue
>> arises like not being able to determine the directory of the
>> executable. IMO it's fine if it only works in simple, known-safe
>> cases.
>>
>> Thanks to both of you for working on this, please let me know what you think.
>>  - Cole