From: Alessandro Di Federico <ale@rev.ng>
To: Christian Brauner <brauner@kernel.org>,
Farid Zakaria <farid.m.zakaria@gmail.com>
Cc: david.laight.linux@gmail.com, jack@suse.cz, jannh@google.com,
kees@kernel.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
linux-mm@kvack.org, mail@johnericson.me, shuah@kernel.org,
viro@zeniv.linux.org.uk, Gemini <assistant@google.com>
Subject: Re: [RFC PATCH] fs: binfmt_misc: introduce eBPF-based matching and interpreter selection
Date: Wed, 22 Jul 2026 01:18:08 +0200 [thread overview]
Message-ID: <20260722011217.45e79a08@spawn> (raw)
In-Reply-To: <20260707-campieren-fingen-himbeeren-e4b682bd8e63@brauner>
On Tue, 07 Jul 2026 13:34:46 +0200
Christian Brauner <brauner@kernel.org> wrote:
> > 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.
Hi everyone, first post here.
tl;dr I think an $ORIGIN+PT_INTERP-like feature should be available by
default (no root) since portable software is most important when you're
an unprivileged user.
I've recently read about this patch and I'm super excited. An
ORIGIN-like feature for loaders is something I wanted for years. Let me
share our use case + some additional nix use cases.
We have a package/build system that makes heavy use of RPATH+ORIGIN to
make portable installation directories of our software, as in: extract
a plain .tar in ~/mysoftware, `./myexecutable` and it works [1]. No
root, no run-time patching, no namespaces.
Now, this means we need to ship all of our dependencies properly
RPATH'd (using $ORIGIN). The only exception is the libc, which we can't
ship, since we can't put $ORIGIN in PT_INTERP. This means we
need to link against an ancient libc in order to be compatible with
a wide range of host libcs. Needless to say, is a *huge* pain.
This patch could in theory solve our problems, except for the "no root"
part, which I think it's the most important one. After all, if you
assume your user is root (at least at install time), you don't have big
problems, just drop your software in /opt/mysoftware and ship your
loader in there.
But I think being able to use $ORIGIN from non-root users would be
useful also for nix, not when you are on NixOS (where I'd assume they'd
enable PT_INTERP_NIX by default), but when you're on a non-NixOS system.
There are several projects that aim at running nix without root:
https://github.com/davhau/nix-portable
https://github.com/nixie-dev/nixie
Currently they either use user namespaces or ptrace. However, the former
is restricted under Ubuntu (`apparmor_restrict_unprivileged_unconfined`)
and the latter is not ideal.
AFAIU it'd be possible to avoid all of this if $ORIGIN was available by
default in PT_INTERP, or at least the biggest roadblocker would go away.
I understand that enabling $ORIGIN in PT_INTERP can be problematic (I
should dig into that actually).
However, in whatever way this gets supported, I think that in order to
be actually useful in the most important use cases where portability is
important (i.e., no root, no user namespaces), having this feature
available *by default* is important.
> 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. [...]
Maybe we can have a "default eBPF program" loaded for
`PT_INTERP_WITH_ORIGIN`?
We toolchain people are happy to tamper with our binaries, but if these
features are not available by default, their use is going to be limited.
In any case, thanks for this work, I've been wanting this for a long
time.
--
Alessandro Di Federico
rev.ng Labs
[1] https://github.com/revng/orchestra
Note that this is soon going to be dismissed in favor of nix itself.
Example artifact:
wget 'https://rev.ng/downloads/revng-distributable/develop.tar.xz'
tar xaf develop.tar.xaf
$ ./revng-public-demo/root/lib64/llvm/llvm/bin/clang --version
clang version 16.0.1
prev parent reply other threads:[~2026-07-21 23:43 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-22 4:39 [PATCH 0/2] fs: support $ORIGIN in ELF interpreter paths Farid Zakaria
2026-06-22 4:39 ` [PATCH 1/2] " Farid Zakaria
2026-06-22 9:53 ` Jori Koolstra
2026-06-23 20:14 ` Kees Cook
2026-06-23 20:35 ` Farid Zakaria
2026-06-22 4:39 ` [PATCH 2/2] selftests/exec: add test suites for $ORIGIN interpreter resolution Farid Zakaria
2026-06-22 10:39 ` [PATCH 0/2] fs: support $ORIGIN in ELF interpreter paths Jan Kara
2026-06-22 17:15 ` Farid Zakaria
2026-06-22 21:08 ` John Ericson
2026-06-25 8:50 ` Christian Brauner
2026-06-25 19:34 ` John Ericson
2026-06-26 12:39 ` Jann Horn
2026-06-26 13:26 ` David Laight
2026-06-26 13:34 ` Jann Horn
2026-06-26 16:28 ` David Laight
2026-06-28 12:36 ` Christian Brauner
2026-06-28 13:20 ` Christian Brauner
2026-06-28 18:44 ` David Laight
2026-06-30 16:58 ` Farid Zakaria
2026-07-02 6:47 ` Christian Brauner
2026-06-30 17:59 ` David Laight
2026-07-02 21:42 ` [RFC PATCH] fs: introduce pluggable ELF interpreter loader registry Farid Zakaria
2026-07-03 9:22 ` Christian Brauner
2026-07-03 18:32 ` Farid Zakaria
2026-07-04 8:15 ` Christian Brauner
2026-07-04 21:14 ` [RFC PATCH] fs: binfmt_misc: introduce eBPF-based matching and interpreter selection Farid Zakaria
2026-07-06 16:01 ` Christian Brauner
2026-07-06 16:47 ` Farid Zakaria
2026-07-07 11:34 ` Christian Brauner
2026-07-07 19:45 ` Christian Brauner
2026-07-07 22:44 ` Farid Zakaria
2026-07-08 9:14 ` Christian Brauner
2026-07-08 16:47 ` Christian Brauner
2026-07-09 4:07 ` Farid Zakaria
2026-07-09 8:46 ` Christian Brauner
2026-07-21 23:18 ` Alessandro Di Federico [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260722011217.45e79a08@spawn \
--to=ale@rev.ng \
--cc=assistant@google.com \
--cc=brauner@kernel.org \
--cc=david.laight.linux@gmail.com \
--cc=farid.m.zakaria@gmail.com \
--cc=jack@suse.cz \
--cc=jannh@google.com \
--cc=kees@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mail@johnericson.me \
--cc=shuah@kernel.org \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox