ELF Relocations and Kernel Modules

What is it?

This roadmap plans loadable code: an ELF relocation engine, a .kmod kernel module format with a loader, EXPORT_SYMBOL so modules can call the kernel, dlopen() and dlsym() for Linux programs, lazy binding through the GOT and PLT, module hot-swap, and the lsmod, insmod, rmmod and modprobe commands. None of it has shipped. The kernel image is linked as one static ELF file today, and a second roadmap already plans the same module loader under other names.

How does it work?

Today. The ELF loader in elf.c accepts executables (ET_EXEC) and position-independent executables (ET_DYN) and maps their program segments. It applies no relocations and has no dynamic linker, so a program must be fully linked before it runs. elf.h defines the file and program headers, not the section, symbol and relocation records a relocatable object needs.

The kernel image registry already reserves an image type for modules: KIMAGE_TYPE_KMOD in kimage.h, described as an ELF relocatable kernel module. Nothing produces or loads one yet.

Planned design.

Relocation engine. Parse section headers, the symbol table and .rela sections of an ET_REL object and apply the x86-64 relocation types a module needs.
Module format and loader. A .kmod is an ET_REL object carrying a kmod_info descriptor; the loader allocates the image with pmm_alloc_contiguous(), relocates it, resolves its imports and calls its init function.
Symbol export. An EXPORT_SYMBOL table in its own linker section that the loader searches by name.
User-space dynamic loading. dlopen(), dlsym() and lazy GOT and PLT binding for the Linux compatibility layer.
Tooling. Module hot-swap as a stretch goal, and shell commands to list, load and unload modules.

flowchart LR
    K[.kmod ET_REL file] --> R[relocation engine]
    R --> S[resolve against exported symbols]
    S --> I[call module init]
    I --> T[kernel image registry]

What are its interfaces?

Interface	Status
ELF loader for `ET_EXEC` and `ET_DYN`	Shipped, no relocations
`KIMAGE_TYPE_KMOD` image type	Shipped (reserved; unused)
`elf_apply_rela()` and the relocation engine	Planned in section 1
`kmod_load()`, `kmod_unload()`	Planned in section 3
`EXPORT_SYMBOL`, `ksym_lookup()`	Planned in section 4
`dlopen()`, `dlsym()`, `dlclose()`	Planned in section 5
`lsmod`, `insmod`, `rmmod`, `modprobe`	Planned in section 8

How do I use it?

Nothing in this roadmap can be used yet. The ELF loader it builds on is covered by the executable tests:

bash scripts/test.sh SUITE=exec

Who owns what?

The Kernel Module System roadmap (04-drivers-hardware/TODO-05) plans a kernel symbol table and EXPORT_SYMBOL in its section 1 and an ELF relocatable module loader in its section 4, using module_load(), include/kernel/ksymtab.h and a .ksymtab section. This file plans the same pieces as kmod_load(), ksym_lookup() and src/kernel/kmod.c. Only one design can ship, so a reconcile item is filed in section 1 here and in section 1 of that file; neither side has been chosen. The user-space half (sections 5 and 6) has no competing owner and belongs with the Linux ELF Compatibility layer.

What is not implemented yet?

How does it compare with Windows 11 and Linux?

Windows loads drivers as PE .sys files and resolves them against the ntoskrnl.exe export table; it has no ELF path at all. Linux loads .ko files, which are ET_REL objects relocated by arch/x86/kernel/module.c, resolves them against EXPORT_SYMBOL and kallsyms, and manages them with lsmod, insmod and modprobe. The Impossible OS plan follows the Linux module model for native modules while the kernel image itself stays ELF permanently; PE drivers are a separate loader in the module system roadmap.