History log of /linux/tools/testing/selftests/exec/.gitignore (Results 1 – 25 of 144)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
# b9cba7eb 17-Aug-2026 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'vfs-7.3-rc1.binfmt' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Pull binfmt updates from Christian Brauner:
"This contains a bunch of work for binfmt_misc. It fixes a bunch

Merge tag 'vfs-7.3-rc1.binfmt' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs

Pull binfmt updates from Christian Brauner:
"This contains a bunch of work for binfmt_misc. It fixes a bunch of
old bugs, reworks the locking, and then extends the format registry
so a binary type can be matched programmatically and its interpreter
computed per exec instead of being a fixed string recorded at
registration time.

This allows nixos and other to e.g., implement relocatable binaries
meaning the interpreter/dynamic loader can be determined
programatically, say found relative to the binary. The mechanism is
flexible and can support other policies:

- Handler lookup is now an rcu walk. An exec that matches no
binfmt_misc entry should now never write to a shared cacheline

- remove the VERBOSE_STATUS and USE_DEBUG compile time toggles

- convert the entry file to a seq_file which simplifies things quite
a bit and kills a lot of custom logic

- make flags proper enums

- rename struct Node to binfmt_misc_entry

- allow entries to be removed with unlink(2)

- Add the ability to attach bpf programs to binfmt_misc entries so
it's possible to dynamically choose the execution environment such
as the loader or interpreter on a per binary basis.

A handler is an instance of a binfmt_misc_ops struct_ops with a
->match() and a ->load() program. match() decides from the entry
lookup walk whether the handler applies under the same
registration-order. It can read file content as needed not only the
prefetched 256 bytes in bprm->buf.

load() then selects the interpreter and stages it through the new
bpf_binprm_set_interp(), bpf_binprm_set_interp_arg() and
bpf_binprm_set_flags() kfuncs.

Handlers are published in a registry keyed by the registering
task's user namespace and activated through the existing text
interface with a new 'B' type carrying the handler name:

echo ':origin:B::::nix:' > /proc/sys/fs/binfmt_misc/register

The permission and namespacing model is unchanged. Activating a
handler requires the same write access to an instance as any other
registration. A container mounting its own instance escapes the
host's entries exactly as before. The computed interpreter is
opened with open_exec() under the caller's credentials and goes
through full LSM vetting as the next binprm level. A program can
only ever redirect the caller to something the caller could exec
anyway.

- Two dispatch modes are added. So far the chosen interpreter owns
the whole process identity (argv[0], /proc/pid/cmdline,
/proc/self/exe all name interpreter information). So relocatable
find the dynamic linker instead. Also a binary passed to execveat()
as an inaccessible O_CLOEXEC fd cannot run at all and gdb trips
because AT_ENTRY and AT_PHDR do not match the exe file. So PIE
symbols are unrelocated.

This adds transparent dispatch which allows the interpreter to load
the binary through AT_EXECFD and leaves the argument vector exactly
as the caller built it and labels mm->exe_file and comm with the
binary. It also raises the AT_FLAGS_TRANSPARENT_INTERP aux vector
bit. The interpreter keeps control of mapping the binary.

The second mode is loader substitution. This allows a binary to be
executed natively and only the interpreter to be changed.

- Last, interpreters can be bound at registration time. Each
interpreter is opened by its own write with the credentials the
entry file was opened with. The program picks one per exec with
bpf_binprm_select_interp().

Ucounts are used to properly account for pre-opened interpreters
via /proc/sys/user/max_binfmt_misc_interpreters"

* tag 'vfs-7.3-rc1.binfmt' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: (63 commits)
binfmt_misc: document the pre-opened interpreter limit
selftests/exec: test the pre-opened interpreter limit
binfmt_misc: correctly account pre-opened interpreters
binfmt_misc: document interpreters bound by a 'B' entry
selftests/exec: test interpreters bound to a 'B' entry
binfmt_misc: let a 'B' entry bind its interpreters
binfmt_misc: carry pre-opened interpreters in struct binfmt_misc_interp
selftests/exec: share the bpf handler preconditions
binfmt_misc: document registering an entry disabled
selftests/exec: test registering an entry disabled
selftests/exec: let binfmt_flag_supported() return a bool
selftests/exec: check that a binfmt_misc instance cannot be pinned
binfmt_misc: let a register string create an entry disabled
binfmt_misc: document loader substitution
selftests/exec: test binfmt_misc loader substitution
binfmt_misc: let a bpf handler request loader substitution
binfmt_misc: add the 'L' loader substitution flag
binfmt_elf_fdpic: consume a stashed PT_INTERP substitute
binfmt_elf: consume a stashed PT_INTERP substitute
exec: carry a PT_INTERP substitute in struct linux_binprm
...

show more ...


Revision tags: v7.2, v7.2-rc7
# 68aabd01 03-Aug-2026 Christian Brauner <brauner@kernel.org>

Merge patch series "binfmt_misc: bound the interpreters an entry can pre-open"

Christian Brauner <brauner@kernel.org> says:

An 'F' entry opens its interpreter at registration and every exec runs a

Merge patch series "binfmt_misc: bound the interpreters an entry can pre-open"

Christian Brauner <brauner@kernel.org> says:

An 'F' entry opens its interpreter at registration and every exec runs a
clone of it. A 'B' entry does the same for each interpreter it binds. That
file stays open for as long as the entry lives. So it pins the file, its
inode, the mount it came from and that mount's superblock.

An entry binds at most 100 interpreters, but nothing caps the entries.
binfmt_misc is container mountable so all of this is reachable by
unprivileged users.

While the pins go away when the instance is unmounted, it's still weird
for an unprivileged namespace to be allowed to do this. And the fix is
simple.

Charge each binding to the user namespace and uid that makes it against
a new UCOUNT_BINFMT_MISC_INTERPRETERS and refuse with -ENOSPC when the
limit is hit.

A per-instance cap won't do. Instances are keyed on the user namespace, so
whatever constant I pick gets multiplied by however many namespaces the
caller cares to create. inc_ucount() charges the namespace and every one
of its ancestors, and a namespace can only ever raise its own limit, so
nesting buys nothing.

The knob is /proc/sys/user/max_binfmt_misc_interpreters, per namespace like
every other ucount. I left it at the max_threads/2 default that
fork_init() hands a new ucount type. Nothing anyone runs today comes
anywhere near that.

Selftests for all of it, including that a nested namespace can't buy
itself budget.

* patches from https://patch.msgid.link/20260803-work-binfmt_misc-interplimit-v1-0-4a2435500bd9@kernel.org:
binfmt_misc: document the pre-opened interpreter limit
selftests/exec: test the pre-opened interpreter limit
binfmt_misc: correctly account pre-opened interpreters

Link: https://patch.msgid.link/20260803-work-binfmt_misc-interplimit-v1-0-4a2435500bd9@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

show more ...


# f2b69ea2 03-Aug-2026 Christian Brauner <brauner@kernel.org>

selftests/exec: test the pre-opened interpreter limit

- an interpreter opened at registration is charged
- an interpreter a 'B' entry binds is charged too
- an entry that opens none is not
- removin

selftests/exec: test the pre-opened interpreter limit

- an interpreter opened at registration is charged
- an interpreter a 'B' entry binds is charged too
- an entry that opens none is not
- removing an entry gives the charge back
- a nested user namespace cannot buy itself budget by raising its own limit

Skips where the sysctl or binfmt_misc is missing. The 'B' case lives in
binfmt_misc_bpf.c because binding needs a handler. It binds from a child
in a user namespace of its own, through the fd the child inherited, so
the charge lands on the child while the interpreter is still opened with
the entry file's credentials, and nothing outside the child sees a
changed limit.

Link: https://patch.msgid.link/20260803-work-binfmt_misc-interplimit-v1-2-4a2435500bd9@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

show more ...


Revision tags: v7.2-rc6, v7.2-rc5
# b2a52381 25-Jul-2026 Christian Brauner <brauner@kernel.org>

Merge patch series "binfmt_misc: transparent interpreters and PT_INTERP loader substitution"

Christian Brauner <brauner@kernel.org> says:

binfmt_misc has exactly one execution model where the regis

Merge patch series "binfmt_misc: transparent interpreters and PT_INTERP loader substitution"

Christian Brauner <brauner@kernel.org> says:

binfmt_misc has exactly one execution model where the registered
interpreter becomes the executed program and the matched binary is
handed to it as an argument. For wine or qemu-user that is the point.
For a per-binary loader it is backwards. The interpreter is an
implementation detail of running the binary, yet it owns the entire
process identity:

- argv[0] and /proc/pid/cmdline show the interpreter invocation, not
what the caller executed.

- /proc/self/exe names the interpreter. Relocatable programs commonly
locate themselves through it and find the dynamic linker instead.

- A binary passed to execveat() as an inaccessible O_CLOEXEC fd
cannot run at all as the interpreter has no path to open it by.

- gdb cross-validates AT_ENTRY/AT_PHDR against the exe file and
discards the load displacement on mismatch leaving PIE symbols
unrelocated.

This series adds two dispatch modes that close the gap from opposite
ends:

(1) transparent dispatch

Registered with the 'T' flag or chosen per exec with
BPF_BINPRM_TRANSPARENT. The binary is sent to the interpreter through
AT_EXECFD, the argument vector stays exactly as the caller built it,
and the kernel labels mm->exe_file and comm with the binary. A new
AT_FLAGS_TRANSPARENT_INTERP aux vector bit is raised indicating that
nothing was spliced, argv belongs to the program, and to load it from
the descriptor.

The interpreter keeps control of mapping the binary, so the mode
covers foreign architectures and non-ELF payloads.

The exe label is not a new privilege. It names precisely the file the
caller passed to execve(), not a file of the process's choosing. That
file is permission-checked, write-denied while the process runs and
recorded by audit. Credential derivation does not change exactly as
today.

(2) loader substitution

The kernel executes the matched binary natively as the main image
and substitutes the registered interpreter for the binary's
PT_INTERP. binfmt_misc functions as a PT_INTERP override. There is
no contract and no identity to reconstruct. So a stock dynamic
loader works unchanged. Hence, 'L' is for native-arch ELF with
PT_INTERP.

The two modes compose. A bpf handler reads the ELF header from bprm->buf
and grades per binary, picking 'L' where it applies and 'T' or classic
dispatch for the rest. If userspace control over relocation is wanted
'T' is the way to go.

* patches from https://patch.msgid.link/20260721-work-bpf-binfmt_misc-ptinterp-v2-0-e57866e4ae0f@kernel.org: (21 commits)
binfmt_misc: document loader substitution
selftests/exec: test binfmt_misc loader substitution
binfmt_misc: let a bpf handler request loader substitution
binfmt_misc: add the 'L' loader substitution flag
binfmt_elf_fdpic: consume a stashed PT_INTERP substitute
binfmt_elf: consume a stashed PT_INTERP substitute
exec: carry a PT_INTERP substitute in struct linux_binprm
binfmt_misc: document the transparent identity contract
selftests/exec: test the transparent binfmt_misc mode
binfmt_misc: let a bpf handler run the interpreter transparently
binfmt_misc: add a static transparent flag 'T'
binfmt_misc: add transparent interpreter dispatch
exec: label mm->exe_file with the binary for a transparent dispatch
exec: add AT_FLAGS_TRANSPARENT_INTERP
selftests/exec: convert the binfmt_misc bpf test to the kselftest harness
exec: release the replaced file with do_close_execat()
binfmt_misc: split out entry_open_interpreter() and build_interp_argv()
binfmt_misc: normalize the per-exec invocation flags
binfmt_misc: table-drive the register string flags
docs, binfmt_misc: keep general usage out of the handler sections
...

Link: https://patch.msgid.link/20260721-work-bpf-binfmt_misc-ptinterp-v2-0-e57866e4ae0f@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

show more ...


# 87c50a58 21-Jul-2026 Christian Brauner <brauner@kernel.org>

selftests/exec: test binfmt_misc loader substitution

Exercise the 'L' flag end to end. The payload runs as the main image
with a copy of the system loader substituted for its PT_INTERP, and
asserts

selftests/exec: test binfmt_misc loader substitution

Exercise the 'L' flag end to end. The payload runs as the main image
with a copy of the system loader substituted for its PT_INTERP, and
asserts the native identity from inside:

- argv exactly as the caller built it
- no AT_EXECFD
- AT_FLAGS clear
- AT_BASE set but outside its own image
- AT_PHDR/AT_ENTRY inside it
- /proc/self/{exe,comm,stat} and AT_EXECFN all describing the binary
- ETXTBSY on the running binary
- the substituted loader visible in /proc/self/maps under its real path

Magic matching pokes a marker into the ELF header's e_ident padding
(EI_PAD, offset 9), which sits inside the match window and is ignored by
kernel and loader alike. the same binary is also matched by extension.

Two cases cover the paths where the substitution does not happen. A '#!'
file that matched an 'L' entry is claimed by binfmt_script rather than by
binfmt_elf, so the staged substitute has to be released when the
interpreter replaces the file; the test opens the loader for writing
afterwards, which fails with ETXTBSY if the write denial was leaked
instead. A relative interpreter path is rejected at registration for both
'L' and 'C', neither of which may resolve one against the working
directory of whoever runs the binary.

The bpf-side BPF_BINPRM_LOADER path shares all machinery past the flag
mapping. A harness case for it can join the bpf runtime coverage of
the transparent series.

Link: https://patch.msgid.link/20260721-work-bpf-binfmt_misc-ptinterp-v2-20-e57866e4ae0f@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

show more ...


# 7baee96f 21-Jul-2026 Christian Brauner <brauner@kernel.org>

selftests/exec: test the transparent binfmt_misc mode

Verify the identity a transparent dispatch constructs, from both
activation paths.

- binfmt_misc_transparent: registers a magic entry with the

selftests/exec: test the transparent binfmt_misc mode

Verify the identity a transparent dispatch constructs, from both
activation paths.

- binfmt_misc_transparent: registers a magic entry with the static 'T'
flag and execs a matched binary with arguments.

- binfmt_misc_bpf: a handler whose load program sets
BPF_BINPRM_TRANSPARENT.

Both dispatch to a shared asserting interpreter that runs in place of
the binary and checks the contract from the inside:

- AT_FLAGS carries AT_FLAGS_TRANSPARENT_INTERP
- AT_EXECFD refers to the very inode of the binary
- /proc/self/exe resolves to the binary
- argv and /proc/self/cmdline are exactly what the caller passed with
nothing spliced in
- comm is the binary's basename
- the binary is write-denied while it runs

The static test also validates the registration. 'T' combined with 'P'
must be rejected. A kernel that does not know 'T' turns the test into a
skip. The asserting interpreter and the static test build without the
bpf toolchain so the core transparent semantics stay covered on systems
where the bpf cases are skipped.

The flag support probe, the canonical payload argv with the
run_payload() helper that execs it, and the identity assertions (exe
link, comm, write denial) live in binfmt_misc_common.h; the loader
substitution test reuses all of them.

Link: https://patch.msgid.link/20260721-work-bpf-binfmt_misc-ptinterp-v2-13-e57866e4ae0f@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

show more ...


Revision tags: v7.2-rc4
# e566d062 17-Jul-2026 Christian Brauner <brauner@kernel.org>

Merge patch series "binfmt_misc: bpf-backed binary type handlers"

Christian Brauner <brauner@kernel.org> says:

binfmt_misc: bpf-backed binary type handlers

This is a POC for the nix people and Far

Merge patch series "binfmt_misc: bpf-backed binary type handlers"

Christian Brauner <brauner@kernel.org> says:

binfmt_misc: bpf-backed binary type handlers

This is a POC for the nix people and Farid and Eric in particular. I
would take my hands off the wheel now that I POCed this and hand it to
Farid if he likes to take it forward.

VL;MR (very long, must read):

For a while now Farid has been trying to make relocatable, hermetic
binaries (think Nix-style store layouts) work without patchelf tricks
or wrapper scripts. For such binaries the right dynamic loader can only
be determined relative to the location of the binary itself, which
neither PT_INTERP nor a fixed binfmt_misc interpreter string can
express.

The first attempt was $ORIGIN expansion in PT_INTERP [1]. I pushed back
on that. Userspace guards $ORIGIN behind AT_SECURE so the kernel would
have to make the used loader depend on the type of binary, LSMs would
need a say, it changes long-standing behavior in ways that are ripe for
loader injection attacks, and bprm->file may not have a usable path at
all (memfds, deleted files, unresolvable paths). Making the kernel
splice bprm->file back together with PT_INTERP is terrible. The second
attempt was a pluggable ELF interpreter loader registry [2] which would
mean actual kernel modules for custom binary formats. Also no.
binfmt_misc was invented to kill exactly this horrendous past.

What I suggested instead [3] was to put this where delegating binary
formats to userspace already lives: binfmt_misc. The only things
binfmt_misc cannot do today are matching programmatically and computing
the interpreter per binary instead of using a fixed string recorded at
registration time. Farid prototyped that with an eBPF program [4] and
it turned out quite workable, but the prototype ran a SOCKET_FILTER
program over bprm->buf, added a new helper to the frozen uapi helper
list, and returned the computed path through per-CPU memory.

This series is the proposal turned into what I think the bpf side
{c,sh}ould actually look like. It is a POC: it builds, the selftests
pass, and the design is what I want to discuss. The selftests are
Farid's from his v2 posting, adapted to the contract below.

A handler is an instance of the new binfmt_misc_ops struct_ops with a
name and two ops:

struct binfmt_misc_ops {
bool (*match)(struct linux_binprm *bprm);
int (*load)(struct linux_binprm *bprm);
char name[BINFMT_MISC_OPS_NAME_MAX];
};

Both programs receive the bprm as a trusted BTF pointer and both are
sleepable. The match program decides from the entry lookup walk whether
the handler applies, under the same rules as magic matching:
registration order, first match wins. It is not limited to the
prefetched 256 bytes in bprm->buf: it can read arbitrary file content
through bpf_dynptr_from_file(), e.g. to find an ELF interpreter
segment at whatever offset it sits. That is what makes multiple
independent handlers workable at all - a handler that cannot read the
file would have to match broadly and reject from its load program,
stealing the binaries of every handler registered after it. To make
this safe the entry walk becomes an SRCU read-side section. The load
program of the matched handler then selects the interpreter, reading
the file the same way and resolving the binary's location via
bpf_path_d_path() on &bprm->file->f_path. That also solves the
prototype's limitation of only seeing the first 256 bytes of the file.
Selecting is the load program's privilege: the verifier rejects the
selection kfuncs in match, keyed off the struct_ops member a program
attaches to. A match commits the exec to the handler: a failing load
fails the exec instead of falling through to later entries, with
-ENOEXEC handing over to the remaining binary formats, so the walk is
never left and re-entered.

The genuinely new piece of bpf surface is a small family of kfuncs:

int bpf_binprm_set_interp(struct linux_binprm *bprm,
const char *path, size_t path__sz);
int bpf_binprm_set_interp_arg(struct linux_binprm *bprm,
const char *arg, size_t arg__sz);
int bpf_binprm_set_flags(struct linux_binprm *bprm,
enum bpf_binprm_flags flags);

staging the selected interpreter, an optional single argument for it
(the slot the optional argument of a #! interpreter line has), and the
per-exec invocation flags - 'P', 'C' and 'O' equivalents. Selection
cannot go through bprm_change_interp() directly because
load_misc_binary() copies bprm->interp into argv[1] after the program
ran, hence the staging fields added in patch 1.

Registering (attaching) the struct_ops map publishes the handler under
its name in a registry keyed by the registering task's user namespace.
Activation reuses the existing text interface with a new 'B' type where
the interpreter field carries the handler name - it consistently names
whoever supplies the interpreter - and offset, magic, and mask must be
empty:

echo ':origin:B::::nix:' > /proc/sys/fs/binfmt_misc/register

This keeps the existing permission and namespacing model completely
intact. Activating a handler requires the same write access to a
binfmt_misc instance as any other registration, a container mounting
its own instance escapes the host's entries exactly as before, and
shadowing e.g. all ELF binaries takes the same privilege as a static
'M' entry matching \x7fELF does today.

The only novelty is that matching becomes programmable. Handler lookup
walks the user namespace hierarchy upwards, mirroring how binfmt_misc
instances themselves are resolved, so a handler registered on the host
can be activated from a container's own instance without being forced
upon it.

The computed interpreter is opened with open_exec() under the caller's
credentials and goes through the full LSM vetting as the next binprm
level, exactly like a statically registered interpreter, so the program
cannot widen access. It only ever redirects the caller to something the
caller could exec anyway.

A 'B' entry carries no flags in the register string: the load program
chooses the invocation flags per exec through bpf_binprm_set_flags()
instead. BPF_BINPRM_PRESERVE_ARGV0, BPF_BINPRM_CREDENTIALS and
BPF_BINPRM_EXECFD keep the static 'P', 'C' and 'O' semantics -
BPF_BINPRM_CREDENTIALS honors the matched binary's suid bits exactly
as a static 'C' entry does, with the setuid transition gated by
vfsuid_has_mapping() in the caller's user namespace either way, which
makes 'B' handlers usable for a per-binary loader over setuid
binaries. 'F' (pre-open a fixed interpreter) is rejected: a 'B' entry
has no fixed interpreter. AT_EXECVE_CHECK never invokes programs and
interpreter chains stay capped by the usual ELOOP depth.

A handler for the Nix case then looks roughly like:

SEC("struct_ops.s/match")
bool BPF_PROG(nix_match, struct linux_binprm *bprm)
{
return !bpf_strncmp(bprm->buf, 4, "\x7f" "ELF");
}

SEC("struct_ops.s/load")
int BPF_PROG(nix_load, struct linux_binprm *bprm)
{
char path[256];
long n;

n = bpf_path_d_path(&bprm->file->f_path, path, sizeof(path));
if (n < 0)
return n;

/* derive the loader location from the binary's path */

return bpf_binprm_set_interp(bprm, path, sizeof(path));
}

SEC(".struct_ops.link")
struct binfmt_misc_ops nix = {
.match = (void *)nix_match,
.load = (void *)nix_load,
.name = "nix",
};

Farid, this should slot underneath your qemu demo from [4] with the
program ported to struct_ops. Feel free to take it from here.

[1]: https://lore.kernel.org/20260622043934.179879-1-farid.m.zakaria@gmail.com
[2]: https://lore.kernel.org/20260702214247.1253741-1-farid.m.zakaria@gmail.com
[3]: https://lore.kernel.org/20260703-meditation-ratsuchende-moratorium-9ecdf1f3f8bb@brauner
[4]: https://lore.kernel.org/20260704211409.1978485-1-farid.m.zakaria@gmail.com

* patches from https://patch.msgid.link/20260714-work-bpf-binfmt_misc-v2-0-57b7529c002c@kernel.org:
selftests/exec: add binfmt_misc bpf-backed handler test
binfmt_misc: let a bpf handler choose the invocation flags per exec
binfmt_misc: let bpf handlers pass an argument to the interpreter
bpf: allow fs kfuncs for binfmt_misc_ops programs
binfmt_misc: wire up bpf-backed 'B' entries
binfmt_misc: let the entry lookup walk sleep
binfmt_misc: add binfmt_misc_ops bpf struct_ops
exec: stash bpf-selected interpreter state in struct linux_binprm

Link: https://patch.msgid.link/20260714-work-bpf-binfmt_misc-v2-0-57b7529c002c@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

show more ...


# 277d787f 14-Jul-2026 Farid Zakaria <farid.m.zakaria@gmail.com>

selftests/exec: add binfmt_misc bpf-backed handler test

Exercise the bpf-backed ('B') binfmt_misc handlers end to end. A handler
is a struct binfmt_misc_ops struct_ops map; the test loads and attach

selftests/exec: add binfmt_misc bpf-backed handler test

Exercise the bpf-backed ('B') binfmt_misc handlers end to end. A handler
is a struct binfmt_misc_ops struct_ops map; the test loads and attaches
it (which publishes it by name), activates it with a 'B' entry, and
checks that a matched binary is routed to the interpreter the program
selected via bpf_binprm_set_interp().

Two self-contained cases are covered:

- bpf_interp: the match program matches a synthetic aarch64 ELF header
from the prefetched bprm->buf and the load program routes it to a
fixed interpreter of its choosing.
- nix_origin: the match program parses the program headers to commit
only to a "$ORIGIN/..."-relative PT_INTERP and the load program
resolves it to an interpreter co-located with the binary -- the
relocatable-loader case the kernel ELF loader cannot express. The
relocatable binary is linked with PT_INTERP set to the literal
"$ORIGIN/binfmt_bpf_interp" (-Wl,--dynamic-linker), which the kernel
cannot resolve on its own.

Both route to a small test interpreter that prints a marker, proving the
program-selected interpreter actually ran.

The bpf objects are compiled against the running kernel's BTF: the
Makefile generates vmlinux.h with bpftool and the harness links libbpf.
Override CLANG/BPFTOOL/VMLINUX_BTF/LIBBPF_CFLAGS/LIBBPF_LDLIBS as needed.
The bpf pieces are only built when clang, bpftool, the vmlinux BTF and
libbpf are all present (HAVE_BPF_TOOLCHAIN=y forces them) so the other
exec selftests keep building without a bpf toolchain.

Christian Brauner (Amutable) <brauner@kernel.org> says:

Adapted to the two-op contract: 'B' entries carry the handler name in
the interpreter field, both programs are sleepable, the match programs
decide. nix_origin reads PT_INTERP from the match program and load
returns zero on success. Skip on kernels without binfmt_misc_ops in BTF.
Build the bpf pieces only when the toolchain is present and gitignore
the generated artifacts.

Signed-off-by: Farid Zakaria <farid.m.zakaria@gmail.com>
Link: https://patch.msgid.link/20260714-work-bpf-binfmt_misc-v2-9-57b7529c002c@kernel.org
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>

show more ...


Revision tags: v7.2-rc3, v7.2-rc2, v7.2-rc1, v7.1, v7.1-rc7, v7.1-rc6, v7.1-rc5, v7.1-rc4, v7.1-rc3, v7.1-rc2, v7.1-rc1, v7.0, v7.0-rc7, v7.0-rc6, v7.0-rc5, v7.0-rc4, v7.0-rc3, v7.0-rc2, v7.0-rc1, v6.19, v6.19-rc8, v6.19-rc7, v6.19-rc6, v6.19-rc5, v6.19-rc4, v6.19-rc3, v6.19-rc2, v6.19-rc1, v6.18, v6.18-rc7, v6.18-rc6, v6.18-rc5, v6.18-rc4, v6.18-rc3, v6.18-rc2, v6.18-rc1, v6.17, v6.17-rc7, v6.17-rc6, v6.17-rc5, v6.17-rc4, v6.17-rc3, v6.17-rc2, v6.17-rc1, v6.16, v6.16-rc7, v6.16-rc6, v6.16-rc5, v6.16-rc4, v6.16-rc3, v6.16-rc2, v6.16-rc1, v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2
# 1260ed77 08-Apr-2025 Thomas Zimmermann <tzimmermann@suse.de>

Merge drm/drm-fixes into drm-misc-fixes

Backmerging to get updates from v6.15-rc1.

Signed-off-by: Thomas Zimmermann <tzimmermann@suse.de>


Revision tags: v6.15-rc1
# 946661e3 05-Apr-2025 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge branch 'next' into for-linus

Prepare input updates for 6.15 merge window.


Revision tags: v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5
# 0b119045 26-Feb-2025 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge tag 'v6.14-rc4' into next

Sync up with the mainline.


Revision tags: v6.14-rc4, v6.14-rc3, v6.14-rc2
# 9e676a02 05-Feb-2025 Namhyung Kim <namhyung@kernel.org>

Merge tag 'v6.14-rc1' into perf-tools-next

To get the various fixes in the current master.

Signed-off-by: Namhyung Kim <namhyung@kernel.org>


# 0410c612 28-Feb-2025 Lucas De Marchi <lucas.demarchi@intel.com>

Merge drm/drm-next into drm-xe-next

Sync to fix conlicts between drm-xe-next and drm-intel-next.

Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>


# 93c7dd1b 06-Feb-2025 Maxime Ripard <mripard@kernel.org>

Merge drm/drm-next into drm-misc-next

Bring rc1 to start the new release dev.

Signed-off-by: Maxime Ripard <mripard@kernel.org>


# ea9f8f2b 05-Feb-2025 Jani Nikula <jani.nikula@intel.com>

Merge drm/drm-next into drm-intel-next

Sync with v6.14-rc1.

Signed-off-by: Jani Nikula <jani.nikula@intel.com>


# c771600c 05-Feb-2025 Tvrtko Ursulin <tursulin@ursulin.net>

Merge drm/drm-next into drm-intel-gt-next

We need
4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with a scope")
in order to land a i915 PMU simplification and a fix. That landed in 6.12
and

Merge drm/drm-next into drm-intel-gt-next

We need
4ba4f1afb6a9 ("perf: Generic hotplug support for a PMU with a scope")
in order to land a i915 PMU simplification and a fix. That landed in 6.12
and we are stuck at 6.9 so lets bump things forward.

Signed-off-by: Tvrtko Ursulin <tursulin@ursulin.net>

show more ...


# b3cc7428 26-Mar-2025 Jiri Kosina <jkosina@suse.com>

Merge branch 'for-6.15/amd_sfh' into for-linus

From: Mario Limonciello <mario.limonciello@amd.com>

Some platforms include a human presence detection (HPD) sensor. When
enabled and a user is detecte

Merge branch 'for-6.15/amd_sfh' into for-linus

From: Mario Limonciello <mario.limonciello@amd.com>

Some platforms include a human presence detection (HPD) sensor. When
enabled and a user is detected a wake event will be emitted from the
sensor fusion hub that software can react to.

Example use cases are "wake from suspend on approach" or to "lock
when leaving".

This is currently enabled by default on supported systems, but users
can't control it. This essentially means that wake on approach is
enabled which is a really surprising behavior to users that don't
expect it.

Instead of defaulting to enabled add a sysfs knob that users can
use to enable the feature if desirable and set it to disabled by
default.

show more ...


Revision tags: v6.14-rc1
# 21266b8d 23-Jan-2025 Linus Torvalds <torvalds@linux-foundation.org>

Merge tag 'AT_EXECVE_CHECK-v6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

Pull AT_EXECVE_CHECK from Kees Cook:

- Implement AT_EXECVE_CHECK flag to execveat(2) (Mickaël Sala

Merge tag 'AT_EXECVE_CHECK-v6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux

Pull AT_EXECVE_CHECK from Kees Cook:

- Implement AT_EXECVE_CHECK flag to execveat(2) (Mickaël Salaün)

- Implement EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
(Mickaël Salaün)

- Add selftests and samples for AT_EXECVE_CHECK (Mickaël Salaün)

* tag 'AT_EXECVE_CHECK-v6.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/kees/linux:
ima: instantiate the bprm_creds_for_exec() hook
samples/check-exec: Add an enlighten "inc" interpreter and 28 tests
selftests: ktap_helpers: Fix uninitialized variable
samples/check-exec: Add set-exec
selftests/landlock: Add tests for execveat + AT_EXECVE_CHECK
selftests/exec: Add 32 tests for AT_EXECVE_CHECK and exec securebits
security: Add EXEC_RESTRICT_FILE and EXEC_DENY_INTERACTIVE securebits
exec: Add a new AT_EXECVE_CHECK flag to execveat(2)

show more ...


Revision tags: v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3
# 2a69962b 12-Dec-2024 Mickaël Salaün <mic@digikod.net>

samples/check-exec: Add an enlighten "inc" interpreter and 28 tests

Add a very simple script interpreter called "inc" that can evaluate two
different commands (one per line):
- "?" to initialize a c

samples/check-exec: Add an enlighten "inc" interpreter and 28 tests

Add a very simple script interpreter called "inc" that can evaluate two
different commands (one per line):
- "?" to initialize a counter from user's input;
- "+" to increment the counter (which is set to 0 by default).

It is enlighten to only interpret executable files according to
AT_EXECVE_CHECK and the related securebits:

# Executing a script with RESTRICT_FILE is only allowed if the script
# is executable:
./set-exec -f -- ./inc script-exec.inc # Allowed
./set-exec -f -- ./inc script-noexec.inc # Denied

# Executing stdin with DENY_INTERACTIVE is only allowed if stdin is an
# executable regular file:
./set-exec -i -- ./inc -i < script-exec.inc # Allowed
./set-exec -i -- ./inc -i < script-noexec.inc # Denied

# However, a pipe is not executable and it is then denied:
cat script-noexec.inc | ./set-exec -i -- ./inc -i # Denied

# Executing raw data (e.g. command argument) with DENY_INTERACTIVE is
# always denied.
./set-exec -i -- ./inc -c "+" # Denied
./inc -c "$(<script-ask.inc)" # Allowed

# To directly execute a script, we can update $PATH (used by `env`):
PATH="${PATH}:." ./script-exec.inc

# To execute several commands passed as argument:

Add a complete test suite to check the script interpreter against all
possible execution cases:

make TARGETS=exec kselftest-install
./tools/testing/selftests/kselftest_install/run_kselftest.sh

Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20241212174223.389435-8-mic@digikod.net
Signed-off-by: Kees Cook <kees@kernel.org>

show more ...


# b083cc81 12-Dec-2024 Mickaël Salaün <mic@digikod.net>

selftests/exec: Add 32 tests for AT_EXECVE_CHECK and exec securebits

Test that checks performed by execveat(..., AT_EXECVE_CHECK) are
consistent with noexec mount points and file execute permissions

selftests/exec: Add 32 tests for AT_EXECVE_CHECK and exec securebits

Test that checks performed by execveat(..., AT_EXECVE_CHECK) are
consistent with noexec mount points and file execute permissions.

Test that SECBIT_EXEC_RESTRICT_FILE and SECBIT_EXEC_DENY_INTERACTIVE are
inherited by child processes and that they can be pinned with the
appropriate SECBIT_EXEC_RESTRICT_FILE_LOCKED and
SECBIT_EXEC_DENY_INTERACTIVE_LOCKED bits.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Kees Cook <keescook@chromium.org>
Cc: Paul Moore <paul@paul-moore.com>
Cc: Serge Hallyn <serge@hallyn.com>
Signed-off-by: Mickaël Salaün <mic@digikod.net>
Link: https://lore.kernel.org/r/20241212174223.389435-4-mic@digikod.net
Signed-off-by: Kees Cook <kees@kernel.org>

show more ...


# 25768de5 21-Jan-2025 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge branch 'next' into for-linus

Prepare input updates for 6.14 merge window.


# 6d4a0f4e 17-Dec-2024 Dmitry Torokhov <dmitry.torokhov@gmail.com>

Merge tag 'v6.13-rc3' into next

Sync up with the mainline.


Revision tags: v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7
# c787c290 04-Nov-2024 Thomas Hellström <thomas.hellstrom@linux.intel.com>

Merge drm/drm-next into drm-xe-next

Backmerging to get up-to-date and to bring in a fix that was
merged through drm-misc-fixes.

Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com>


Revision tags: v6.12-rc6, v6.12-rc5, v6.12-rc4
# 64f3b5a6 14-Oct-2024 Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge 6.12-rc3 into usb-next

We need the USB fixes in here as well.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>


Revision tags: v6.12-rc3
# 220c71da 12-Oct-2024 Jonathan Cameron <Jonathan.Cameron@huawei.com>

Merge tag 'v6.12-rc2' into test2

Linux 6.12-rc2

Resolved movement of asm/unaligned.h to linux/unaligned.h


123456