11===========================
2- Livepatch module Elf format
2+ Livepatch module ELF format
33===========================
44
5- This document outlines the Elf format requirements that livepatch modules must follow.
5+ This document outlines the ELF format requirements that livepatch modules must follow.
66
77
88.. Table of Contents
@@ -20,17 +20,17 @@ code. So, instead of duplicating code and re-implementing what the module
2020loader can already do, livepatch leverages existing code in the module
2121loader to perform the all the arch-specific relocation work. Specifically,
2222livepatch reuses the apply_relocate_add() function in the module loader to
23- write relocations. The patch module Elf format described in this document
23+ write relocations. The patch module ELF format described in this document
2424enables livepatch to be able to do this. The hope is that this will make
2525livepatch more easily portable to other architectures and reduce the amount
2626of arch-specific code required to port livepatch to a particular
2727architecture.
2828
2929Since apply_relocate_add() requires access to a module's section header
30- table, symbol table, and relocation section indices, Elf information is
30+ table, symbol table, and relocation section indices, ELF information is
3131preserved for livepatch modules (see section 5). Livepatch manages its own
3232relocation sections and symbols, which are described in this document. The
33- Elf constants used to mark livepatch symbols and relocation sections were
33+ ELF constants used to mark livepatch symbols and relocation sections were
3434selected from OS-specific ranges according to the definitions from glibc.
3535
3636Why does livepatch need to write its own relocations?
@@ -43,7 +43,7 @@ reject the livepatch module. Furthermore, we cannot apply relocations that
4343affect modules not yet loaded at patch module load time (e.g. a patch to a
4444driver that is not loaded). Formerly, livepatch solved this problem by
4545embedding special "dynrela" (dynamic rela) sections in the resulting patch
46- module Elf output. Using these dynrela sections, livepatch could resolve
46+ module ELF output. Using these dynrela sections, livepatch could resolve
4747symbols while taking into account its scope and what module the symbol
4848belongs to, and then manually apply the dynamic relocations. However this
4949approach required livepatch to supply arch-specific code in order to write
@@ -80,7 +80,7 @@ Example:
80803. Livepatch relocation sections
8181================================
8282
83- A livepatch module manages its own Elf relocation sections to apply
83+ A livepatch module manages its own ELF relocation sections to apply
8484relocations to modules as well as to the kernel (vmlinux) at the
8585appropriate time. For example, if a patch module patches a driver that is
8686not currently loaded, livepatch will apply the corresponding livepatch
@@ -95,7 +95,7 @@ also possible for a livepatch module to have no livepatch relocation
9595sections, as in the case of the sample livepatch module (see
9696samples/livepatch).
9797
98- Since Elf information is preserved for livepatch modules (see Section 5), a
98+ Since ELF information is preserved for livepatch modules (see Section 5), a
9999livepatch relocation section can be applied simply by passing in the
100100appropriate section index to apply_relocate_add(), which then uses it to
101101access the relocation section and apply the relocations.
@@ -291,12 +291,12 @@ Examples:
291291 Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20).
292292 "OS" means OS-specific.
293293
294- 5. Symbol table and Elf section access
294+ 5. Symbol table and ELF section access
295295======================================
296296A livepatch module's symbol table is accessible through module->symtab.
297297
298298Since apply_relocate_add() requires access to a module's section headers,
299- symbol table, and relocation section indices, Elf information is preserved for
299+ symbol table, and relocation section indices, ELF information is preserved for
300300livepatch modules and is made accessible by the module loader through
301301module->klp_info, which is a :c:type: `klp_modinfo ` struct. When a livepatch module
302302loads, this struct is filled in by the module loader.
0 commit comments