Lines Matching full:module

2 Livepatch module ELF format
18 exists in the module loader, so this former approach produced redundant
19 code. So, instead of duplicating code and re-implementing what the module
20 loader can already do, livepatch leverages existing code in the module
22 livepatch reuses the apply_relocate_add() function in the module loader to
23 write relocations. The patch module ELF format described in this document
29 Since apply_relocate_add() requires access to a module's section header
38 A typical livepatch module contains patched versions of functions that can
41 since the kernel module loader cannot resolve them and will therefore
42 reject the livepatch module. Furthermore, we cannot apply relocations that
43 affect modules not yet loaded at patch module load time (e.g. a patch to a
46 module ELF output. Using these dynrela sections, livepatch could resolve
47 symbols while taking into account its scope and what module the symbol
60 See the sample livepatch module in samples/livepatch/ for how this is done.
64 used by the kernel module loader to identify livepatch modules.
83 A livepatch module manages its own ELF relocation sections to apply
85 appropriate time. For example, if a patch module patches a driver that is
89 Each "object" (e.g. vmlinux, or a module) within a patch module may have
94 also possible for a livepatch module to have no livepatch relocation
95 sections, as in the case of the sample livepatch module (see
111 section flag. See include/uapi/linux/elf.h for the definition. The module
113 at patch module load time. These sections must also be marked with SHF_ALLOC,
114 so that the module loader doesn't discard them on module load (i.e. they will
129   The name of the object (i.e. "vmlinux" or name of module) to
146 module that patches vmlinux and modules 9p, btrfs, ext4:**
167   not be discarded when the module is loaded into memory, as well as with the
170 **`readelf --relocs` output for a patch module:**
192 objects, whose addresses cannot be resolved by the module loader (because
193 they are local or unexported global syms). Since the module loader only
197 a patch module loads. For example, this is the case when livepatch patches
198 a module that is not loaded yet. In this case, the relevant livepatch
199 symbols are resolved simply when the target module loads. In any case, for
204 Livepatch symbols must be marked with SHN_LIVEPATCH so that the module
207 module->symtab.
209 4.1 A livepatch module's symbol table
211 Normally, a stripped down copy of a module's symbol table (containing only
212 "core" symbols) is made available through module->symtab (See layout_symtab()
213 in kernel/module/kallsyms.c). For livepatch modules, the symbol table copied
214 into memory on module load must be exactly the same as the symbol table produced
215 when the patch module was compiled. This is because the relocations in each
220 For example, take this particular rela from a livepatch module:::
229   And in this patch module's corresponding symbol table, symbol index 94 refers to that very symbol:
238 that the module loader can identify them and not attempt to resolve them.
252   The name of the object (i.e. "vmlinux" or name of module) to
275 **`readelf --symbols` output for a patch module:**
296 A livepatch module's symbol table is accessible through module->symtab.
298 Since apply_relocate_add() requires access to a module's section headers,
300 livepatch modules and is made accessible by the module loader through
301 module->klp_info, which is a :c:type:`klp_modinfo` struct. When a livepatch module
302 loads, this struct is filled in by the module loader.