€•~¶Œsphinx.addnodes”Œdocument”“”)”}”(Œ rawsource”Œ”Œchildren”]”(Œtranslations”Œ LanguagesNode”“”)”}”(hhh]”(hŒpending_xref”“”)”}”(hhh]”Œdocutils.nodes”ŒText”“”ŒChinese (Simplified)”…””}”Œparent”hsbaŒ attributes”}”(Œids”]”Œclasses”]”Œnames”]”Œdupnames”]”Œbackrefs”]”Œ refdomain”Œstd”Œreftype”Œdoc”Œ reftarget”Œ//translations/zh_CN/livepatch/module-elf-format”Œmodname”NŒ classname”NŒrefexplicit”ˆuŒtagname”hhhubh)”}”(hhh]”hŒChinese (Traditional)”…””}”hh2sbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ//translations/zh_TW/livepatch/module-elf-format”Œmodname”NŒ classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒItalian”…””}”hhFsbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ//translations/it_IT/livepatch/module-elf-format”Œmodname”NŒ classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒJapanese”…””}”hhZsbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ//translations/ja_JP/livepatch/module-elf-format”Œmodname”NŒ classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒKorean”…””}”hhnsbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ//translations/ko_KR/livepatch/module-elf-format”Œmodname”NŒ classname”NŒrefexplicit”ˆuh1hhhubh)”}”(hhh]”hŒSpanish”…””}”hh‚sbah}”(h]”h ]”h"]”h$]”h&]”Œ refdomain”h)Œreftype”h+Œ reftarget”Œ//translations/sp_SP/livepatch/module-elf-format”Œmodname”NŒ classname”NŒrefexplicit”ˆuh1hhhubeh}”(h]”h ]”h"]”h$]”h&]”Œcurrent_language”ŒEnglish”uh1h hhŒ _document”hŒsource”NŒline”NubhŒsection”“”)”}”(hhh]”(hŒtitle”“”)”}”(hŒLivepatch module ELF format”h]”hŒLivepatch module ELF format”…””}”(hh¨hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h¦hh£hžhhŸŒI/var/lib/git/docbuild/linux/Documentation/livepatch/module-elf-format.rst”h KubhŒ paragraph”“”)”}”(hŒVThis document outlines the ELF format requirements that livepatch modules must follow.”h]”hŒVThis document outlines the ELF format requirements that livepatch modules must follow.”…””}”(hh¹hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Khh£hžhubhŒcomment”“”)”}”(hŒTable of Contents”h]”hŒTable of Contents”…””}”hhÉsbah}”(h]”h ]”h"]”h$]”h&]”Œ xml:space”Œpreserve”uh1hÇhh£hžhhŸh¶h K ubhŒtopic”“”)”}”(hhh]”hŒbullet_list”“”)”}”(hhh]”(hŒ list_item”“”)”}”(hhh]”(h¸)”}”(hhh]”hŒ reference”“”)”}”(hhh]”hŒ1. Background and motivation”…””}”(hhíhžhhŸNh Nubah}”(h]”Œid2”ah ]”h"]”h$]”h&]”Œrefid”Œbackground-and-motivation”uh1hëhhèubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hhåubhß)”}”(hhh]”hä)”}”(hhh]”h¸)”}”(hhh]”hì)”}”(hhh]”hŒ5Why does livepatch need to write its own relocations?”…””}”(hjhžhhŸNh Nubah}”(h]”Œid3”ah ]”h"]”h$]”h&]”Œrefid”Œ4why-does-livepatch-need-to-write-its-own-relocations”uh1hëhj ubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hjubah}”(h]”h ]”h"]”h$]”h&]”uh1hãhjubah}”(h]”h ]”h"]”h$]”h&]”uh1hÞhhåubeh}”(h]”h ]”h"]”h$]”h&]”uh1hãhhàubhä)”}”(hhh]”(h¸)”}”(hhh]”hì)”}”(hhh]”hŒ2. Livepatch modinfo field”…””}”(hj:hžhhŸNh Nubah}”(h]”Œid4”ah ]”h"]”h$]”h&]”Œrefid”Œlivepatch-modinfo-field”uh1hëhj7ubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hj4ubhß)”}”(hhh]”hä)”}”(hhh]”h¸)”}”(hhh]”hì)”}”(hhh]”hŒExample:”…””}”(hjYhžhhŸNh Nubah}”(h]”Œid5”ah ]”h"]”h$]”h&]”Œrefid”Œexample”uh1hëhjVubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hjSubah}”(h]”h ]”h"]”h$]”h&]”uh1hãhjPubah}”(h]”h ]”h"]”h$]”h&]”uh1hÞhj4ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hãhhàubhä)”}”(hhh]”h¸)”}”(hhh]”hì)”}”(hhh]”hŒ 3. Livepatch relocation sections”…””}”(hj‡hžhhŸNh Nubah}”(h]”Œid6”ah ]”h"]”h$]”h&]”Œrefid”Œlivepatch-relocation-sections”uh1hëhj„ubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hjubah}”(h]”h ]”h"]”h$]”h&]”uh1hãhhàubhä)”}”(hhh]”(h¸)”}”(hhh]”hì)”}”(hhh]”hŒ'3.1 Livepatch relocation section format”…””}”(hj©hžhhŸNh Nubah}”(h]”Œid7”ah ]”h"]”h$]”h&]”Œrefid”Œ#livepatch-relocation-section-format”uh1hëhj¦ubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hj£ubhß)”}”(hhh]”hä)”}”(hhh]”h¸)”}”(hhh]”hì)”}”(hhh]”hŒ Examples:”…””}”(hjÈhžhhŸNh Nubah}”(h]”Œid8”ah ]”h"]”h$]”h&]”Œrefid”Œexamples”uh1hëhjÅubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hjÂubah}”(h]”h ]”h"]”h$]”h&]”uh1hãhj¿ubah}”(h]”h ]”h"]”h$]”h&]”uh1hÞhj£ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hãhhàubhä)”}”(hhh]”h¸)”}”(hhh]”hì)”}”(hhh]”hŒ4. Livepatch symbols”…””}”(hjöhžhhŸNh Nubah}”(h]”Œid9”ah ]”h"]”h$]”h&]”Œrefid”Œlivepatch-symbols”uh1hëhjóubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hjðubah}”(h]”h ]”h"]”h$]”h&]”uh1hãhhàubhä)”}”(hhh]”h¸)”}”(hhh]”hì)”}”(hhh]”hŒ'4.1 A livepatch moduleâ€™s symbol table”…””}”(hjhžhhŸNh Nubah}”(h]”Œid10”ah ]”h"]”h$]”h&]”Œrefid”Œ!a-livepatch-module-s-symbol-table”uh1hëhjubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hjubah}”(h]”h ]”h"]”h$]”h&]”uh1hãhhàubhä)”}”(hhh]”(h¸)”}”(hhh]”hì)”}”(hhh]”hŒ4.2 Livepatch symbol format”…””}”(hj:hžhhŸNh Nubah}”(h]”Œid11”ah ]”h"]”h$]”h&]”Œrefid”Œlivepatch-symbol-format”uh1hëhj7ubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hj4ubhß)”}”(hhh]”hä)”}”(hhh]”h¸)”}”(hhh]”hì)”}”(hhh]”hŒ Examples:”…””}”(hjYhžhhŸNh Nubah}”(h]”Œid12”ah ]”h"]”h$]”h&]”Œrefid”Œid1”uh1hëhjVubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hjSubah}”(h]”h ]”h"]”h$]”h&]”uh1hãhjPubah}”(h]”h ]”h"]”h$]”h&]”uh1hÞhj4ubeh}”(h]”h ]”h"]”h$]”h&]”uh1hãhhàubhä)”}”(hhh]”h¸)”}”(hhh]”hì)”}”(hhh]”hŒ&5. Symbol table and ELF section access”…””}”(hj‡hžhhŸNh Nubah}”(h]”Œid13”ah ]”h"]”h$]”h&]”Œrefid”Œ#symbol-table-and-elf-section-access”uh1hëhj„ubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hjubah}”(h]”h ]”h"]”h$]”h&]”uh1hãhhàubeh}”(h]”h ]”h"]”h$]”h&]”uh1hÞhhÛhžhhŸNh Nubah}”(h]”Œcontents”ah ]”(Œcontents”Œlocal”eh"]”Œcontents”ah$]”h&]”uh1hÙhŸh¶h Khh£hžhubh¢)”}”(hhh]”(h§)”}”(hŒ1. Background and motivation”h]”hŒ1. Background and motivation”…””}”(hj¶hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”Œrefid”höuh1h¦hj³hžhhŸh¶h Kubh¸)”}”(hX,Formerly, livepatch required separate architecture-specific code to write relocations. However, arch-specific code to write relocations already exists in the module loader, so this former approach produced redundant code. So, instead of duplicating code and re-implementing what the module loader can already do, livepatch leverages existing code in the module loader to perform the all the arch-specific relocation work. Specifically, livepatch reuses the apply_relocate_add() function in the module loader to write relocations. The patch module ELF format described in this document enables livepatch to be able to do this. The hope is that this will make livepatch more easily portable to other architectures and reduce the amount of arch-specific code required to port livepatch to a particular architecture.”h]”hX,Formerly, livepatch required separate architecture-specific code to write relocations. However, arch-specific code to write relocations already exists in the module loader, so this former approach produced redundant code. So, instead of duplicating code and re-implementing what the module loader can already do, livepatch leverages existing code in the module loader to perform the all the arch-specific relocation work. Specifically, livepatch reuses the apply_relocate_add() function in the module loader to write relocations. The patch module ELF format described in this document enables livepatch to be able to do this. The hope is that this will make livepatch more easily portable to other architectures and reduce the amount of arch-specific code required to port livepatch to a particular architecture.”…””}”(hjÅhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Khj³hžhubh¸)”}”(hX¹Since apply_relocate_add() requires access to a module's section header table, symbol table, and relocation section indices, ELF information is preserved for livepatch modules (see section 5). Livepatch manages its own relocation sections and symbols, which are described in this document. The ELF constants used to mark livepatch symbols and relocation sections were selected from OS-specific ranges according to the definitions from glibc.”h]”hX»Since apply_relocate_add() requires access to a moduleâ€™s section header table, symbol table, and relocation section indices, ELF information is preserved for livepatch modules (see section 5). Livepatch manages its own relocation sections and symbols, which are described in this document. The ELF constants used to mark livepatch symbols and relocation sections were selected from OS-specific ranges according to the definitions from glibc.”…””}”(hjÓhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Khj³hžhubh¢)”}”(hhh]”(h§)”}”(hŒ5Why does livepatch need to write its own relocations?”h]”hŒ5Why does livepatch need to write its own relocations?”…””}”(hjähžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”jÄjuh1h¦hjáhžhhŸh¶h K%ubh¸)”}”(hXžA typical livepatch module contains patched versions of functions that can reference non-exported global symbols and non-included local symbols. Relocations referencing these types of symbols cannot be left in as-is since the kernel module loader cannot resolve them and will therefore reject the livepatch module. Furthermore, we cannot apply relocations that affect modules not yet loaded at patch module load time (e.g. a patch to a driver that is not loaded). Formerly, livepatch solved this problem by embedding special "dynrela" (dynamic rela) sections in the resulting patch module ELF output. Using these dynrela sections, livepatch could resolve symbols while taking into account its scope and what module the symbol belongs to, and then manually apply the dynamic relocations. However this approach required livepatch to supply arch-specific code in order to write these relocations. In the new format, livepatch manages its own SHT_RELA relocation sections in place of dynrela sections, and the symbols that the relas reference are special livepatch symbols (see section 2 and 3). The arch-specific livepatch relocation code is replaced by a call to apply_relocate_add().”h]”hX¢A typical livepatch module contains patched versions of functions that can reference non-exported global symbols and non-included local symbols. Relocations referencing these types of symbols cannot be left in as-is since the kernel module loader cannot resolve them and will therefore reject the livepatch module. Furthermore, we cannot apply relocations that affect modules not yet loaded at patch module load time (e.g. a patch to a driver that is not loaded). Formerly, livepatch solved this problem by embedding special â€œdynrelaâ€ (dynamic rela) sections in the resulting patch module ELF output. Using these dynrela sections, livepatch could resolve symbols while taking into account its scope and what module the symbol belongs to, and then manually apply the dynamic relocations. However this approach required livepatch to supply arch-specific code in order to write these relocations. In the new format, livepatch manages its own SHT_RELA relocation sections in place of dynrela sections, and the symbols that the relas reference are special livepatch symbols (see section 2 and 3). The arch-specific livepatch relocation code is replaced by a call to apply_relocate_add().”…””}”(hjòhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K&hjáhžhubeh}”(h]”jah ]”h"]”Œ5why does livepatch need to write its own relocations?”ah$]”h&]”uh1h¡hj³hžhhŸh¶h K%ubeh}”(h]”hüah ]”h"]”Œ1. background and motivation”ah$]”h&]”uh1h¡hh£hžhhŸh¶h Kubh¢)”}”(hhh]”(h§)”}”(hŒ2. Livepatch modinfo field”h]”hŒ2. Livepatch modinfo field”…””}”(hjhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”jÄjCuh1h¦hjhžhhŸh¶h K9ubh¸)”}”(hŒ•Livepatch modules are required to have the "livepatch" modinfo attribute. See the sample livepatch module in samples/livepatch/ for how this is done.”h]”hŒ™Livepatch modules are required to have the â€œlivepatchâ€ modinfo attribute. See the sample livepatch module in samples/livepatch/ for how this is done.”…””}”(hjhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K;hjhžhubh¸)”}”(hŒÕLivepatch modules can be identified by users by using the 'modinfo' command and looking for the presence of the "livepatch" field. This field is also used by the kernel module loader to identify livepatch modules.”h]”hŒÝLivepatch modules can be identified by users by using the â€˜modinfoâ€™ command and looking for the presence of the â€œlivepatchâ€ field. This field is also used by the kernel module loader to identify livepatch modules.”…””}”(hj-hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K>hjhžhubh¢)”}”(hhh]”(h§)”}”(hŒExample:”h]”hŒExample:”…””}”(hj>hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”jÄjbuh1h¦hj;hžhhŸh¶h KCubh¸)”}”(hŒ**Modinfo output:**”h]”hŒstrong”“”)”}”(hjNh]”hŒModinfo output:”…””}”(hjRhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jPhjLubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KEhj;hžhubhŒ literal_block”“”)”}”(hŒ¸% modinfo livepatch-meminfo.ko filename: livepatch-meminfo.ko livepatch: Y license: GPL depends: vermagic: 4.3.0+ SMP mod_unload”h]”hŒ¸% modinfo livepatch-meminfo.ko filename: livepatch-meminfo.ko livepatch: Y license: GPL depends: vermagic: 4.3.0+ SMP mod_unload”…””}”hjgsbah}”(h]”h ]”h"]”h$]”h&]”h×hØuh1jehŸh¶h KIhj;hžhubeh}”(h]”jhah ]”h"]”Œexample:”ah$]”h&]”uh1h¡hjhžhhŸh¶h KCubeh}”(h]”jIah ]”h"]”Œ2. livepatch modinfo field”ah$]”h&]”uh1h¡hh£hžhhŸh¶h K9ubh¢)”}”(hhh]”(h§)”}”(hŒ 3. Livepatch relocation sections”h]”hŒ 3. Livepatch relocation sections”…””}”(hj†hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”jÄjuh1h¦hjƒhžhhŸh¶h KQubh¸)”}”(hXHA livepatch module manages its own ELF relocation sections to apply relocations to modules as well as to the kernel (vmlinux) at the appropriate time. For example, if a patch module patches a driver that is not currently loaded, livepatch will apply the corresponding livepatch relocation section(s) to the driver once it loads.”h]”hXHA livepatch module manages its own ELF relocation sections to apply relocations to modules as well as to the kernel (vmlinux) at the appropriate time. For example, if a patch module patches a driver that is not currently loaded, livepatch will apply the corresponding livepatch relocation section(s) to the driver once it loads.”…””}”(hj”hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KShjƒhžhubh¸)”}”(hXEach "object" (e.g. vmlinux, or a module) within a patch module may have multiple livepatch relocation sections associated with it (e.g. patches to multiple functions within the same object). There is a 1-1 correspondence between a livepatch relocation section and the target section (usually the text section of a function) to which the relocation(s) apply. It is also possible for a livepatch module to have no livepatch relocation sections, as in the case of the sample livepatch module (see samples/livepatch).”h]”hXEach â€œobjectâ€ (e.g. vmlinux, or a module) within a patch module may have multiple livepatch relocation sections associated with it (e.g. patches to multiple functions within the same object). There is a 1-1 correspondence between a livepatch relocation section and the target section (usually the text section of a function) to which the relocation(s) apply. It is also possible for a livepatch module to have no livepatch relocation sections, as in the case of the sample livepatch module (see samples/livepatch).”…””}”(hj¢hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KYhjƒhžhubh¸)”}”(hXSince ELF information is preserved for livepatch modules (see Section 5), a livepatch relocation section can be applied simply by passing in the appropriate section index to apply_relocate_add(), which then uses it to access the relocation section and apply the relocations.”h]”hXSince ELF information is preserved for livepatch modules (see Section 5), a livepatch relocation section can be applied simply by passing in the appropriate section index to apply_relocate_add(), which then uses it to access the relocation section and apply the relocations.”…””}”(hj°hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kbhjƒhžhubh¸)”}”(hŒÅEvery symbol referenced by a rela in a livepatch relocation section is a livepatch symbol. These must be resolved before livepatch can call apply_relocate_add(). See Section 3 for more information.”h]”hŒÅEvery symbol referenced by a rela in a livepatch relocation section is a livepatch symbol. These must be resolved before livepatch can call apply_relocate_add(). See Section 3 for more information.”…””}”(hj¾hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kghjƒhžhubeh}”(h]”j–ah ]”h"]”Œ 3. livepatch relocation sections”ah$]”h&]”uh1h¡hh£hžhhŸh¶h KQubh¢)”}”(hhh]”(h§)”}”(hŒ'3.1 Livepatch relocation section format”h]”hŒ'3.1 Livepatch relocation section format”…””}”(hjÖhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”jÄj²uh1h¦hjÓhžhhŸh¶h Klubh¸)”}”(hX¼Livepatch relocation sections must be marked with the SHF_RELA_LIVEPATCH section flag. See include/uapi/linux/elf.h for the definition. The module loader recognizes this flag and will avoid applying those relocation sections at patch module load time. These sections must also be marked with SHF_ALLOC, so that the module loader doesn't discard them on module load (i.e. they will be copied into memory along with the other SHF_ALLOC sections).”h]”hX¾Livepatch relocation sections must be marked with the SHF_RELA_LIVEPATCH section flag. See include/uapi/linux/elf.h for the definition. The module loader recognizes this flag and will avoid applying those relocation sections at patch module load time. These sections must also be marked with SHF_ALLOC, so that the module loader doesnâ€™t discard them on module load (i.e. they will be copied into memory along with the other SHF_ALLOC sections).”…””}”(hjähžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KnhjÓhžhubh¸)”}”(hŒQThe name of a livepatch relocation section must conform to the following format::”h]”hŒPThe name of a livepatch relocation section must conform to the following format:”…””}”(hjòhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KuhjÓhžhubjf)”}”(hŒw.klp.rela.objname.section_name ^ ^^ ^ ^ ^ |________||_____| |__________| [A] [B] [C]”h]”hŒw.klp.rela.objname.section_name ^ ^^ ^ ^ ^ |________||_____| |__________| [A] [B] [C]”…””}”hjsbah}”(h]”h ]”h"]”h$]”h&]”h×hØuh1jehŸh¶h KxhjÓhžhubhŒdefinition_list”“”)”}”(hhh]”(hŒdefinition_list_item”“”)”}”(hŒI[A] The relocation section name is prefixed with the string ".klp.rela." ”h]”(hŒterm”“”)”}”(hŒ[A]”h]”hŒ[A]”…””}”(hjhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jhŸh¶h K~hjubhŒ definition”“”)”}”(hhh]”h¸)”}”(hŒDThe relocation section name is prefixed with the string ".klp.rela."”h]”hŒHThe relocation section name is prefixed with the string â€œ.klp.rela.â€”…””}”(hj.hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K~hj+ubah}”(h]”h ]”h"]”h$]”h&]”uh1j)hjubeh}”(h]”h ]”h"]”h$]”h&]”uh1jhŸh¶h K~hjubj)”}”(hŒŒ[B] The name of the object (i.e. "vmlinux" or name of module) to which the relocation section belongs follows immediately after the prefix. ”h]”(j)”}”(hŒ[B]”h]”hŒ[B]”…””}”(hjLhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jhŸh¶h K‚hjHubj*)”}”(hhh]”h¸)”}”(hŒ‡The name of the object (i.e. "vmlinux" or name of module) to which the relocation section belongs follows immediately after the prefix.”h]”hŒ‹The name of the object (i.e. â€œvmlinuxâ€ or name of module) to which the relocation section belongs follows immediately after the prefix.”…””}”(hj]hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KhjZubah}”(h]”h ]”h"]”h$]”h&]”uh1j)hjHubeh}”(h]”h ]”h"]”h$]”h&]”uh1jhŸh¶h K‚hjhžhubj)”}”(hŒM[C] The actual name of the section to which this relocation section applies. ”h]”(j)”}”(hŒ[C]”h]”hŒ[C]”…””}”(hj{hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jhŸh¶h K…hjwubj*)”}”(hhh]”h¸)”}”(hŒHThe actual name of the section to which this relocation section applies.”h]”hŒHThe actual name of the section to which this relocation section applies.”…””}”(hjŒhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K…hj‰ubah}”(h]”h ]”h"]”h$]”h&]”uh1j)hjwubeh}”(h]”h ]”h"]”h$]”h&]”uh1jhŸh¶h K…hjhžhubeh}”(h]”h ]”h"]”h$]”h&]”uh1jhjÓhžhhŸh¶h Nubh¢)”}”(hhh]”(h§)”}”(hŒ Examples:”h]”hŒ Examples:”…””}”(hj¯hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”jÄjÑuh1h¦hj¬hžhhŸh¶h Kˆubh¸)”}”(hŒ'**Livepatch relocation section names:**”h]”jQ)”}”(hj¿h]”hŒ#Livepatch relocation section names:”…””}”(hjÁhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jPhj½ubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KŠhj¬hžhubjf)”}”(hŒL.klp.rela.ext4.text.ext4_attr_store .klp.rela.vmlinux.text.cmdline_proc_show”h]”hŒL.klp.rela.ext4.text.ext4_attr_store .klp.rela.vmlinux.text.cmdline_proc_show”…””}”hjÔsbah}”(h]”h ]”h"]”h$]”h&]”h×hØuh1jehŸh¶h KŽhj¬hžhubh¸)”}”(hŒd**`readelf --sections` output for a patch module that patches vmlinux and modules 9p, btrfs, ext4:**”h]”jQ)”}”(hjäh]”hŒ``readelf --sections` output for a patch module that patches vmlinux and modules 9p, btrfs, ext4:”…””}”(hjæhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jPhjâubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K‘hj¬hžhubjf)”}”(hX-Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ snip ] [29] .klp.rela.9p.text.caches.show RELA 0000000000000000 002d58 0000c0 18 AIo 64 9 8 [30] .klp.rela.btrfs.text.btrfs.feature.attr.show RELA 0000000000000000 002e18 000060 18 AIo 64 11 8 [ snip ] [34] .klp.rela.ext4.text.ext4.attr.store RELA 0000000000000000 002fd8 0000d8 18 AIo 64 13 8 [35] .klp.rela.ext4.text.ext4.attr.show RELA 0000000000000000 0030b0 000150 18 AIo 64 15 8 [36] .klp.rela.vmlinux.text.cmdline.proc.show RELA 0000000000000000 003200 000018 18 AIo 64 17 8 [37] .klp.rela.vmlinux.text.meminfo.proc.show RELA 0000000000000000 003218 0000f0 18 AIo 64 19 8 [ snip ] ^ ^ | | [*] [*]”h]”hX-Section Headers: [Nr] Name Type Address Off Size ES Flg Lk Inf Al [ snip ] [29] .klp.rela.9p.text.caches.show RELA 0000000000000000 002d58 0000c0 18 AIo 64 9 8 [30] .klp.rela.btrfs.text.btrfs.feature.attr.show RELA 0000000000000000 002e18 000060 18 AIo 64 11 8 [ snip ] [34] .klp.rela.ext4.text.ext4.attr.store RELA 0000000000000000 002fd8 0000d8 18 AIo 64 13 8 [35] .klp.rela.ext4.text.ext4.attr.show RELA 0000000000000000 0030b0 000150 18 AIo 64 15 8 [36] .klp.rela.vmlinux.text.cmdline.proc.show RELA 0000000000000000 003200 000018 18 AIo 64 17 8 [37] .klp.rela.vmlinux.text.meminfo.proc.show RELA 0000000000000000 003218 0000f0 18 AIo 64 19 8 [ snip ] ^ ^ | | [*] [*]”…””}”hjùsbah}”(h]”h ]”h"]”h$]”h&]”h×hØuh1jehŸh¶h K–hj¬hžhubj)”}”(hhh]”j)”}”(hX[*] Livepatch relocation sections are SHT_RELA sections but with a few special characteristics. Notice that they are marked SHF_ALLOC ("A") so that they will not be discarded when the module is loaded into memory, as well as with the SHF_RELA_LIVEPATCH flag ("o" - for OS-specific). ”h]”(j)”}”(hŒ[*]”h]”hŒ[*]”…””}”(hjhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jhŸh¶h K¨hj ubj*)”}”(hhh]”h¸)”}”(hXLivepatch relocation sections are SHT_RELA sections but with a few special characteristics. Notice that they are marked SHF_ALLOC ("A") so that they will not be discarded when the module is loaded into memory, as well as with the SHF_RELA_LIVEPATCH flag ("o" - for OS-specific).”h]”hXLivepatch relocation sections are SHT_RELA sections but with a few special characteristics. Notice that they are marked SHF_ALLOC (â€œAâ€) so that they will not be discarded when the module is loaded into memory, as well as with the SHF_RELA_LIVEPATCH flag (â€œoâ€ - for OS-specific).”…””}”(hjhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K¥hjubah}”(h]”h ]”h"]”h$]”h&]”uh1j)hj ubeh}”(h]”h ]”h"]”h$]”h&]”uh1jhŸh¶h K¨hjubah}”(h]”h ]”h"]”h$]”h&]”uh1jhj¬hžhhŸh¶h Nubh¸)”}”(hŒ1**`readelf --relocs` output for a patch module:**”h]”jQ)”}”(hjAh]”hŒ-`readelf --relocs` output for a patch module:”…””}”(hjChžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jPhj?ubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kªhj¬hžhubjf)”}”(hXjRelocation section '.klp.rela.btrfs.text.btrfs_feature_attr_show' at offset 0x2ba0 contains 4 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 000000000000001f 0000005e00000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.printk,0 - 4 0000000000000028 0000003d0000000b R_X86_64_32S 0000000000000000 .klp.sym.btrfs.btrfs_ktype,0 + 0 0000000000000036 0000003b00000002 R_X86_64_PC32 0000000000000000 .klp.sym.btrfs.can_modify_feature.isra.3,0 - 4 000000000000004c 0000004900000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.snprintf,0 - 4 [ snip ] ^ | [*]”h]”hXjRelocation section '.klp.rela.btrfs.text.btrfs_feature_attr_show' at offset 0x2ba0 contains 4 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 000000000000001f 0000005e00000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.printk,0 - 4 0000000000000028 0000003d0000000b R_X86_64_32S 0000000000000000 .klp.sym.btrfs.btrfs_ktype,0 + 0 0000000000000036 0000003b00000002 R_X86_64_PC32 0000000000000000 .klp.sym.btrfs.can_modify_feature.isra.3,0 - 4 000000000000004c 0000004900000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.snprintf,0 - 4 [ snip ] ^ | [*]”…””}”hjVsbah}”(h]”h ]”h"]”h$]”h&]”h×hØuh1jehŸh¶h K®hj¬hžhubj)”}”(hhh]”j)”}”(hŒC[*] Every symbol referenced by a relocation is a livepatch symbol. ”h]”(j)”}”(hŒ[*]”h]”hŒ[*]”…””}”(hjkhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1jhŸh¶h K¹hjgubj*)”}”(hhh]”h¸)”}”(hŒ>Every symbol referenced by a relocation is a livepatch symbol.”h]”hŒ>Every symbol referenced by a relocation is a livepatch symbol.”…””}”(hj|hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K¹hjyubah}”(h]”h ]”h"]”h$]”h&]”uh1j)hjgubeh}”(h]”h ]”h"]”h$]”h&]”uh1jhŸh¶h K¹hjdubah}”(h]”h ]”h"]”h$]”h&]”uh1jhj¬hžhhŸh¶h Nubeh}”(h]”j×ah ]”h"]”h$]”Œ examples:”ah&]”uh1h¡hjÓhžhhŸh¶h KˆŒ referenced”Kubeh}”(h]”j¸ah ]”h"]”Œ'3.1 livepatch relocation section format”ah$]”h&]”uh1h¡hh£hžhhŸh¶h Klubh¢)”}”(hhh]”(h§)”}”(hŒ4. Livepatch symbols”h]”hŒ4. Livepatch symbols”…””}”(hj®hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”jÄjÿuh1h¦hj«hžhhŸh¶h K¼ubh¸)”}”(hX‰Livepatch symbols are symbols referred to by livepatch relocation sections. These are symbols accessed from new versions of functions for patched objects, whose addresses cannot be resolved by the module loader (because they are local or unexported global syms). Since the module loader only resolves exported syms, and not every symbol referenced by the new patched functions is exported, livepatch symbols were introduced. They are used also in cases where we cannot immediately know the address of a symbol when a patch module loads. For example, this is the case when livepatch patches a module that is not loaded yet. In this case, the relevant livepatch symbols are resolved simply when the target module loads. In any case, for any livepatch relocation section, all livepatch symbols referenced by that section must be resolved before livepatch can call apply_relocate_add() for that reloc section.”h]”hX‰Livepatch symbols are symbols referred to by livepatch relocation sections. These are symbols accessed from new versions of functions for patched objects, whose addresses cannot be resolved by the module loader (because they are local or unexported global syms). Since the module loader only resolves exported syms, and not every symbol referenced by the new patched functions is exported, livepatch symbols were introduced. They are used also in cases where we cannot immediately know the address of a symbol when a patch module loads. For example, this is the case when livepatch patches a module that is not loaded yet. In this case, the relevant livepatch symbols are resolved simply when the target module loads. In any case, for any livepatch relocation section, all livepatch symbols referenced by that section must be resolved before livepatch can call apply_relocate_add() for that reloc section.”…””}”(hj¼hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h K¾hj«hžhubh¸)”}”(hŒèLivepatch symbols must be marked with SHN_LIVEPATCH so that the module loader can identify and ignore them. Livepatch modules keep these symbols in their symbol tables, and the symbol table is made accessible through module->symtab.”h]”hŒèLivepatch symbols must be marked with SHN_LIVEPATCH so that the module loader can identify and ignore them. Livepatch modules keep these symbols in their symbol tables, and the symbol table is made accessible through module->symtab.”…””}”(hjÊhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KÌhj«hžhubeh}”(h]”jah ]”h"]”Œ4. livepatch symbols”ah$]”h&]”uh1h¡hh£hžhhŸh¶h K¼ubh¢)”}”(hhh]”(h§)”}”(hŒ%4.1 A livepatch module's symbol table”h]”hŒ'4.1 A livepatch moduleâ€™s symbol table”…””}”(hjâhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”jÄj!uh1h¦hjßhžhhŸh¶h KÒubh¸)”}”(hXiNormally, a stripped down copy of a module's symbol table (containing only "core" symbols) is made available through module->symtab (See layout_symtab() in kernel/module/kallsyms.c). For livepatch modules, the symbol table copied into memory on module load must be exactly the same as the symbol table produced when the patch module was compiled. This is because the relocations in each livepatch relocation section refer to their respective symbols with their symbol indices, and the original symbol indices (and thus the symtab ordering) must be preserved in order for apply_relocate_add() to find the right symbol.”h]”hXoNormally, a stripped down copy of a moduleâ€™s symbol table (containing only â€œcoreâ€ symbols) is made available through module->symtab (See layout_symtab() in kernel/module/kallsyms.c). For livepatch modules, the symbol table copied into memory on module load must be exactly the same as the symbol table produced when the patch module was compiled. This is because the relocations in each livepatch relocation section refer to their respective symbols with their symbol indices, and the original symbol indices (and thus the symtab ordering) must be preserved in order for apply_relocate_add() to find the right symbol.”…””}”(hjðhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KÓhjßhžhubh¸)”}”(hŒ@For example, take this particular rela from a livepatch module::”h]”hŒ?For example, take this particular rela from a livepatch module:”…””}”(hjþhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KÜhjßhžhubjf)”}”(hX1Relocation section '.klp.rela.btrfs.text.btrfs_feature_attr_show' at offset 0x2ba0 contains 4 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 000000000000001f 0000005e00000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.printk,0 - 4”h]”hX1Relocation section '.klp.rela.btrfs.text.btrfs_feature_attr_show' at offset 0x2ba0 contains 4 entries: Offset Info Type Symbol's Value Symbol's Name + Addend 000000000000001f 0000005e00000002 R_X86_64_PC32 0000000000000000 .klp.sym.vmlinux.printk,0 - 4”…””}”hjsbah}”(h]”h ]”h"]”h$]”h&]”h×hØuh1jehŸh¶h KÞhjßhžhubh¸)”}”(hŒÂThis rela refers to the symbol '.klp.sym.vmlinux.printk,0', and the symbol index is encoded in 'Info'. Here its symbol index is 0x5e, which is 94 in decimal, which refers to the symbol index 94.”h]”hŒÊThis rela refers to the symbol â€˜.klp.sym.vmlinux.printk,0â€™, and the symbol index is encoded in â€˜Infoâ€™. Here its symbol index is 0x5e, which is 94 in decimal, which refers to the symbol index 94.”…””}”(hjhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kâhjßhžhubh¸)”}”(hŒcAnd in this patch module's corresponding symbol table, symbol index 94 refers to that very symbol::”h]”hŒdAnd in this patch moduleâ€™s corresponding symbol table, symbol index 94 refers to that very symbol:”…””}”(hj(hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h Kæhjßhžhubjf)”}”(hŒi[ snip ] 94: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.printk,0 [ snip ]”h]”hŒi[ snip ] 94: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.printk,0 [ snip ]”…””}”hj6sbah}”(h]”h ]”h"]”h$]”h&]”h×hØuh1jehŸh¶h Kéhjßhžhubeh}”(h]”j'ah ]”h"]”Œ%4.1 a livepatch module's symbol table”ah$]”h&]”uh1h¡hh£hžhhŸh¶h KÒubh¢)”}”(hhh]”(h§)”}”(hŒ4.2 Livepatch symbol format”h]”hŒ4.2 Livepatch symbol format”…””}”(hjNhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”jÄjCuh1h¦hjKhžhhŸh¶h Kîubh¸)”}”(hŒÎLivepatch symbols must have their section index marked as SHN_LIVEPATCH, so that the module loader can identify them and not attempt to resolve them. See include/uapi/linux/elf.h for the actual definitions.”h]”hŒÎLivepatch symbols must have their section index marked as SHN_LIVEPATCH, so that the module loader can identify them and not attempt to resolve them. See include/uapi/linux/elf.h for the actual definitions.”…””}”(hj\hžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h KðhjKhžhubh¸)”}”(hŒ=Livepatch symbol names must conform to the following format::”h]”hŒsymtab.”h]”hŒIA livepatch moduleâ€™s symbol table is accessible through module->symtab.”…””}”(hjühžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M+hjëhžhubh¸)”}”(hXgSince apply_relocate_add() requires access to a module's section headers, symbol table, and relocation section indices, ELF information is preserved for livepatch modules and is made accessible by the module loader through module->klp_info, which is a :c:type:`klp_modinfo` struct. When a livepatch module loads, this struct is filled in by the module loader.”h]”(hŒþSince apply_relocate_add() requires access to a moduleâ€™s section headers, symbol table, and relocation section indices, ELF information is preserved for livepatch modules and is made accessible by the module loader through module->klp_info, which is a ”…””}”(hj hžhhŸNh Nubh)”}”(hŒ:c:type:`klp_modinfo`”h]”hŒliteral”“”)”}”(hjh]”hŒklp_modinfo”…””}”(hjhžhhŸNh Nubah}”(h]”h ]”(Œxref”Œc”Œc-type”eh"]”h$]”h&]”uh1jhjubah}”(h]”h ]”h"]”h$]”h&]”Œrefdoc”Œlivepatch/module-elf-format”Œ refdomain”j#Œreftype”Œtype”Œrefexplicit”‰Œrefwarn”‰Œ reftarget”Œklp_modinfo”uh1hhŸh¶h M-hj ubhŒV struct. When a livepatch module loads, this struct is filled in by the module loader.”…””}”(hj hžhhŸNh Nubeh}”(h]”h ]”h"]”h$]”h&]”uh1h·hŸh¶h M-hjëhžhubeh}”(h]”j–ah ]”h"]”Œ&5. symbol table and elf section access”ah$]”h&]”uh1h¡hh£hžhhŸh¶h M*ubeh}”(h]”Œlivepatch-module-elf-format”ah ]”h"]”Œlivepatch module elf format”ah$]”h&]”uh1h¡hhhžhhŸh¶h Kubeh}”(h]”h ]”h"]”h$]”h&]”Œsource”h¶uh1hŒcurrent_source”NŒcurrent_line”NŒsettings”Œdocutils.frontend”ŒValues”“”)”}”(h¦NŒ generator”NŒ datestamp”NŒsource_link”NŒ source_url”NŒ toc_backlinks”Œentry”Œfootnote_backlinks”KŒ sectnum_xform”KŒstrip_comments”NŒstrip_elements_with_classes”NŒ strip_classes”NŒreport_level”KŒ halt_level”KŒexit_status_level”KŒdebug”NŒwarning_stream”NŒ traceback”ˆŒinput_encoding”Œ utf-8-sig”Œinput_encoding_error_handler”Œstrict”Œoutput_encoding”Œutf-8”Œoutput_encoding_error_handler”jsŒerror_encoding”Œutf-8”Œerror_encoding_error_handler”Œbackslashreplace”Œ language_code”Œen”Œrecord_dependencies”NŒconfig”NŒ id_prefix”hŒauto_id_prefix”Œid”Œ dump_settings”NŒdump_internals”NŒdump_transforms”NŒdump_pseudo_xml”NŒexpose_internals”NŒstrict_visitor”NŒ_disable_config”NŒ_source”h¶Œ_destination”NŒ _config_files”]”Œ7/var/lib/git/docbuild/linux/Documentation/docutils.conf”aŒfile_insertion_enabled”ˆŒraw_enabled”KŒline_length_limit”M'Œpep_references”NŒpep_base_url”Œhttps://peps.python.org/”Œpep_file_url_template”Œpep-%04d”Œrfc_references”NŒrfc_base_url”Œ&https://datatracker.ietf.org/doc/html/”Œ tab_width”KŒtrim_footnote_reference_space”‰Œsyntax_highlight”Œlong”Œsmart_quotes”ˆŒsmartquotes_locales”]”Œcharacter_level_inline_markup”‰Œdoctitle_xform”‰Œ docinfo_xform”KŒsectsubtitle_xform”‰Œ image_loading”Œlink”Œembed_stylesheet”‰Œcloak_email_addresses”ˆŒsection_self_link”‰Œenv”NubŒreporter”NŒindirect_targets”]”Œsubstitution_defs”}”Œsubstitution_names”}”Œrefnames”}”Œrefids”}”Œnameids”}”(jMjJj°j«jhüjjj€jIjyjhjÐj–j¨j¸Œ examples:”NjÜjjHj'jèjIjEj–uŒ nametypes”}”(jM‰j°‰j‰j‰j€‰jy‰jÐ‰j¨‰j·‰jÜ‰jH‰jè‰jE‰uh}”(jJh£j«hÛhüj³jjájIjjhj;j–jƒj¸jÓj×j¬jj«j'jßjIjKjhjKj–jëhöhíjjjCj:jbjYjj‡j²j©jÑjÈjÿjöj!jjCj:jbjYjj‡uŒ footnote_refs”}”Œ citation_refs”}”Œ autofootnotes”]”Œautofootnote_refs”]”Œsymbol_footnotes”]”Œsymbol_footnote_refs”]”Œ footnotes”]”Œ citations”]”Œautofootnote_start”KŒsymbol_footnote_start”KŒ id_counter”Œcollections”ŒCounter”“”}”jK s…”R”Œparse_messages”]”hŒsystem_message”“”)”}”(hhh]”h¸)”}”(hŒ,Duplicate implicit target name: "examples:".”h]”hŒ0Duplicate implicit target name: â€œexamples:â€.”…””}”(hjÛhžhhŸNh Nubah}”(h]”h ]”h"]”h$]”h&]”uh1h·hjØubah}”(h]”h ]”h"]”h$]”h&]”jhaŒlevel”KŒtype”ŒINFO”Œsource”h¶Œline”Muh1jÖhjKhžhhŸh¶h MubaŒtransform_messages”]”Œtransformer”NŒinclude_log”]”Œ decoration”Nhžhub.