Bringing BPF to Binfmt_misc

Bringing BPF to binfmt_misc [LWN.net]

LWN .net News from the source

Content Weekly Edition Archives Search Kernel Security Events calendar Unread comments

LWN FAQ Write for us

User: Password: |

Bringing BPF to binfmt_misc

[LWN subscriber-only content]

LWN needs you

LWN counts on its subscribing readers to support its mission of creating relevant human-written news coverage of the Linux and free-software communities. Please subscribe to LWN and help to keep us on the net.

As a special offer, subscribe to LWN now for at least six months, and receive a 25% discount on your subscription.

[+] Proceed to the article

By Jonathan Corbet August 6, 2026

The kernel is able to run a few types of executable files, including native binaries in the ELF format and interpreted programs that begin with the #! marker. It also, however, has a mechanism, called binfmt_misc, that can be configured from user space to enable the transparent execution of programs in just about any format. This feature has been relatively static for years, but it seems likely to receive some significant updates in the near future, including the ability to load BPF programs that can decide how to run a given program.

binfmt_misc

In the beginning, Linux used the a.out format for binary executables. Support for the Executable and Linkable Format (ELF) was added to the 0.99.13 release in 1993, with distribution support (involving upgrades so painful that they still cause post-traumatic stress many years later) arriving around 1995. But, from the earliest days, there was interest in running programs in different formats as well. There were a number of Unix variants available for x86 systems, for example, each with its own binary format. There are languages, such as Java, that compile to their own virtual machines and need a separate interpreter. The kernel could gain support for all of these formats, but it was understood early on that a more general solution was called for.

That solution is binfmt_misc, which was added for the 2.1.43pre1 development release in 1997. In its current form, binfmt_misc presents a directory under /proc/sys/fs/binfmt_misc containing a file called register. Writing a string to that file registers a new format and tells the kernel how to recognize executables in that format; recognition can be based on a pattern in the first 256 bytes of the file itself, or on the file's name extension. For example, the documentation states that support for packed DOS applications can be had by writing this string to the register file:

:DEXE:M::\x0eDEX::/usr/bin/dosexec:

This line causes the kernel to recognized a packed DOS executable by the four-byte sequence \x0eDEX at the beginning of the file; it will invoke /usr/bin/dosexec to run that executable. As another example, any file with a .py extension and execute permission can be executed directly with:

:python:E::py::/usr/bin/python3:

After that has been done, .py files will be executed by the Python interpreter regardless of whether they contain a #! line. Multiple binfmt_misc entries can be made; the first matching entry is selected whenever an interpreter for a program must be found. In a delightful quirk, entries are checked in the opposite order that one might expect; the most recently added entries are checked first.

With binfmt_misc in place, the kernel developers allowed user space to set up whatever policy it needs for its own special executable formats; there was no longer a need to add dedicated support to the kernel for them. While this feature has seen a slow stream of improvements over the years, it has not seen many fundamental changes since its introduction nearly three decades ago.

Hermetic binaries

The formats defined with binfmt_misc all involve an interpreter that handles the actual execution of the program. Native binaries, instead, run directly on the CPU, but (unless they are statically linked) they still involve an interpreter; in that case, the interpreter is the dynamic linker, which is charged with loading the binary code into memory, loading libraries, and resolving references. The location of that interpreter is, for ELF files, found in the ELF binary itself, in the PT_INTERP segment; it is typically something like /lib64/ld-linux-x86-64.so.2. The kernel loads the interpreter, then lets it do the rest of the work in user space.

This scheme has worked well for many years, but there is always somebody who wants to do something different. Back in June, Farid Zakaria made the case that the Nix distribution needs relocatable binaries — binary programs that are fully self-contained (hermetic) and can run regardless of where they are placed in the filesystem hierarchy. A hermetic binary needs, among other things, a specific version of the dynamic linker, which may not be the default one installed on the system where the binary is expected to run. The PT_INTERP mechanism can allow for the specification of a...

Bringing BPF to Binfmt_misc

Related Articles

(no title)

Scientists reverse brain aging, with a nasal spray

NHS apologises and admits Palantir have access to identifiable patient data

AI has torched the market for junior programmers

Al Vigier: Canada's AI strategy shouldn't include secret Palantir bills