[DominoTree]

Traditionally I've seen these adapters primarily used to pass binaries for other architectures to QEMU and similar.

Years ago on FreeBSD I created a "Volkswagen mode" by using the similar `imgact_binmisc` kernel module to register a handler for binaries with the system's native ELF headers. It took a bit of hacking to make it all work with the native architecture, but when it was done, the handler would simply execute the binary, drop its return code, and return 0 instead - effectively making the system think that every command was "successful"

The system failed to boot when I finally got it all working (which was expected) but it was a fun adventure to do something so pointless and silly.

It would be a similarly clever place to maintain persistence and transparently inject bytecode or do other rude things on FreeBSD as well

[Twirrim]

Yup, using this approach it's possible to build/use aarch64 containers on an x86 machine. This technique means that a much smaller set of operations are being emulated (doesn't have to emulate the entire kernel etc)

For something I was building, it enabled me to get a full aarch64 compilation done, with a native toolkit, without having to run a full emulation layer. The time savings of doing it this way vs full emulation were huge. Off the top of my head, emulated it was taking over an hour to do the full build, whereas within a container it was only about 10-15 minutes.

[jeroenhd]

> effectively making the system think that every command was "successful"

I can only imagine the havoc this would wreak on shell scripts that call out to the test/[/[[ binaries on a system.

[porridgeraisin]

nit: while test and [ are binaries, [[ is a bash keyword.