[dandersch]

Before knowing about binfmt, I always wondered how wine is able is able to execute .exe files directly, i.e. ./prog.exe instead of wine ./prog.exe. Turns out the wine package (at least on Arch) comes with a handler for them and the Arch wiki mentions that you may want to remove it for security reasons.

[thayne]

It can also be used to automatically execute jar files with "java -jar". I don't think arch is set up to do that automatically, but it is fairly easy to do[1].

[1]: https://wiki.archlinux.org/title/Binfmt_misc_for_Java

[mbreese]

I'm a bit late to this thread, but for posterity...

FYI - Because JAR files are specially formatted ZIP files, you can also prepend a shell script stub to the front of the file. Java reads JAR files and doesn't start processing them until it sees the ZIP magic bytes (PK\x03\x04). So long as your shell script doesn't contain those bytes, you can add whatever you want.

This is about the minimal stub script you can get away with.

    #!/bin/bash
    exec java -jar $0 "$@"
    exit 1

Using this, you don't even need binfmt to execute JARs. IMHO, the better example for binfmt and Java is executing class files directly... which is also covered in your linked Arch docs.

[WhyNotHugo]

binfmt can also be used to register qemu for binaries for foreign architectures. This allows running programs compiled for another architecture, and makes it really simply to run podman/docker containers with images for other architectures.

[mamikk]

The qemu and container case is a little interesting because if for example /usr/bin/qemu-system-aarch64 or similar is registered as a binfmt_misc handler for AArch64 ELF binaries; the kernel will execute qemu for AArch64 ELF binaries.

But inside a container (with its own mount namespace) or inside a chroot then the qemu binaries does not necessarily exist. But the binfmt_misc handler will still work in this case because of two features.

1. The kernel will open the qemu binaries in the original mount namespace when the binfmt_misc handler is registered with the F-flag (Fix binary) so the kernel will always have an open file reference to the qemu binary independent of mount namespace.

2. Distributions (at least Debian) ships statically linked qemu binaries so that qemu does not need to load any shared libraries inside the target namespace/chroot.

[nicman23]

also chroot into ie raspi sd cards.

[ktm5j]

WSL also uses binfmt so that you can run windows executables from inside whatever distro you have running. I thought that was pretty neat.