Is a registered custom executable format also described by an object of type `linux_binfmt`?

Question

Understanding the Linux Kernel says

An executable format is described by an object of type linux_binfmt, which essentially provides three methods: load_binary, load_shlib, and core_dump.

and

Linux allows users to register their own custom executable formats. To register a new format, the user writes into the register file of the binfmt_misc special filesystem (usually mounted on /proc/sys/fs/binfmt_misc) a string with the following format:

:name:type:offset:string:mask:interpreter:flags

When the kernel determines that the executable file has a custom format, it starts the proper interpreter program. The interpreter program runs in User Mode, receives as its parameter the pathname of the executable file, and carries on the computation. As an example, an executable file containing a Java program is dealt by a java virtual machine such as /usr/lib/java/bin/java.

Although it doesn't mention this, is a registered custom executable format also described by an object of type linux_binfmt?

If yes, registering the custom executable format doesn't require us to explicitly provide load_binary, load_shlib, and core_dump methods. Are the three methods created implicitly from the registration?

Without load_binary method, what method does the kernel call to execute executable files of a registered executable format, via the corresponding interpreter?

Answer 1

In binfmt-misc’s case, the linux_binfmt object corresponds to the binfmt-misc module itself. Modules don’t have to provide implementations of all the functions; binfmt-misc only declares an implementation of load_binary:

static struct linux_binfmt misc_format = {
    .module = THIS_MODULE,
    .load_binary = load_misc_binary,
};

(binfmt_script, which implements support for shebang-based scripts, has a similar declaration.)

load_misc_binary deals with the specifics of all the registered executable types when the kernel invokes it. The kernel calls load_misc_binary, and then that function finds a matching registered executable type, if any, loads the corresponding interpreter, and sets the execution environment up as appropriate.