mirror of
https://github.com/edk2-porting/linux-next.git
synced 2024-12-24 21:24:00 +08:00
5ad75fcdd7
Document usage of arch-specific elf sections in livepatch as well as implementation of arch-specific code. [jkosina@suse.cz: fix wording as suggested by Petr Mladek] Signed-off-by: Jessica Yu <jeyu@redhat.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
324 lines
16 KiB
Plaintext
324 lines
16 KiB
Plaintext
===========================
|
|
Livepatch module Elf format
|
|
===========================
|
|
|
|
This document outlines the Elf format requirements that livepatch modules must follow.
|
|
|
|
-----------------
|
|
Table of Contents
|
|
-----------------
|
|
0. Background and motivation
|
|
1. Livepatch modinfo field
|
|
2. Livepatch relocation sections
|
|
2.1 What are livepatch relocation sections?
|
|
2.2 Livepatch relocation section format
|
|
2.2.1 Required flags
|
|
2.2.2 Required name format
|
|
2.2.3 Example livepatch relocation section names
|
|
2.2.4 Example `readelf --sections` output
|
|
2.2.5 Example `readelf --relocs` output
|
|
3. Livepatch symbols
|
|
3.1 What are livepatch symbols?
|
|
3.2 A livepatch module's symbol table
|
|
3.3 Livepatch symbol format
|
|
3.3.1 Required flags
|
|
3.3.2 Required name format
|
|
3.3.3 Example livepatch symbol names
|
|
3.3.4 Example `readelf --symbols` output
|
|
4. Architecture-specific sections
|
|
5. Symbol table and Elf section access
|
|
|
|
----------------------------
|
|
0. Background and motivation
|
|
----------------------------
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
0.1 Why does livepatch need to write its own relocations?
|
|
---------------------------------------------------------
|
|
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().
|
|
|
|
================================
|
|
PATCH MODULE FORMAT REQUIREMENTS
|
|
================================
|
|
|
|
--------------------------
|
|
1. Livepatch modinfo field
|
|
--------------------------
|
|
|
|
Livepatch modules are required to have the "livepatch" modinfo attribute.
|
|
See the sample livepatch module in samples/livepatch/ for how this is done.
|
|
|
|
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.
|
|
|
|
Example modinfo output:
|
|
-----------------------
|
|
% modinfo livepatch-meminfo.ko
|
|
filename: livepatch-meminfo.ko
|
|
livepatch: Y
|
|
license: GPL
|
|
depends:
|
|
vermagic: 4.3.0+ SMP mod_unload
|
|
|
|
--------------------------------
|
|
2. Livepatch relocation sections
|
|
--------------------------------
|
|
|
|
-------------------------------------------
|
|
2.1 What are livepatch relocation sections?
|
|
-------------------------------------------
|
|
A 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.
|
|
|
|
Each "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).
|
|
|
|
Since 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.
|
|
|
|
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.
|
|
|
|
---------------------------------------
|
|
2.2 Livepatch relocation section format
|
|
---------------------------------------
|
|
|
|
2.2.1 Required flags
|
|
--------------------
|
|
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).
|
|
|
|
2.2.2 Required name format
|
|
--------------------------
|
|
The name of a livepatch relocation section must conform to the following format:
|
|
|
|
.klp.rela.objname.section_name
|
|
^ ^^ ^ ^ ^
|
|
|________||_____| |__________|
|
|
[A] [B] [C]
|
|
|
|
[A] The relocation section name is prefixed with the string ".klp.rela."
|
|
[B] The name of the object (i.e. "vmlinux" or name of module) to
|
|
which the relocation section belongs follows immediately after the prefix.
|
|
[C] The actual name of the section to which this relocation section applies.
|
|
|
|
2.2.3 Example livepatch relocation section names:
|
|
-------------------------------------------------
|
|
.klp.rela.ext4.text.ext4_attr_store
|
|
.klp.rela.vmlinux.text.cmdline_proc_show
|
|
|
|
2.2.4 Example `readelf --sections` output for a patch
|
|
module that patches vmlinux and modules 9p, btrfs, ext4:
|
|
--------------------------------------------------------
|
|
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 ] ^ ^
|
|
| |
|
|
[*] [*]
|
|
[*] 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).
|
|
|
|
2.2.5 Example `readelf --relocs` output for a patch module:
|
|
-----------------------------------------------------------
|
|
Relocation 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 ] ^
|
|
|
|
|
[*]
|
|
[*] Every symbol referenced by a relocation is a livepatch symbol.
|
|
|
|
--------------------
|
|
3. Livepatch symbols
|
|
--------------------
|
|
|
|
-------------------------------
|
|
3.1 What are livepatch symbols?
|
|
-------------------------------
|
|
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.
|
|
|
|
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.
|
|
|
|
-------------------------------------
|
|
3.2 A livepatch module's symbol table
|
|
-------------------------------------
|
|
Normally, 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.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.
|
|
|
|
For example, take this particular rela from a livepatch module:
|
|
Relocation 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
|
|
|
|
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.
|
|
And in this patch module's corresponding symbol table, symbol index 94 refers to that very symbol:
|
|
[ snip ]
|
|
94: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.printk,0
|
|
[ snip ]
|
|
|
|
---------------------------
|
|
3.3 Livepatch symbol format
|
|
---------------------------
|
|
|
|
3.3.1 Required flags
|
|
--------------------
|
|
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.
|
|
|
|
3.3.2 Required name format
|
|
--------------------------
|
|
Livepatch symbol names must conform to the following format:
|
|
|
|
.klp.sym.objname.symbol_name,sympos
|
|
^ ^^ ^ ^ ^ ^
|
|
|_______||_____| |_________| |
|
|
[A] [B] [C] [D]
|
|
|
|
[A] The symbol name is prefixed with the string ".klp.sym."
|
|
[B] The name of the object (i.e. "vmlinux" or name of module) to
|
|
which the symbol belongs follows immediately after the prefix.
|
|
[C] The actual name of the symbol.
|
|
[D] The position of the symbol in the object (as according to kallsyms)
|
|
This is used to differentiate duplicate symbols within the same
|
|
object. The symbol position is expressed numerically (0, 1, 2...).
|
|
The symbol position of a unique symbol is 0.
|
|
|
|
3.3.3 Example livepatch symbol names:
|
|
-------------------------------------
|
|
.klp.sym.vmlinux.snprintf,0
|
|
.klp.sym.vmlinux.printk,0
|
|
.klp.sym.btrfs.btrfs_ktype,0
|
|
|
|
3.3.4 Example `readelf --symbols` output for a patch module:
|
|
------------------------------------------------------------
|
|
Symbol table '.symtab' contains 127 entries:
|
|
Num: Value Size Type Bind Vis Ndx Name
|
|
[ snip ]
|
|
73: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.snprintf,0
|
|
74: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.capable,0
|
|
75: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.find_next_bit,0
|
|
76: 0000000000000000 0 NOTYPE GLOBAL DEFAULT OS [0xff20] .klp.sym.vmlinux.si_swapinfo,0
|
|
[ snip ] ^
|
|
|
|
|
[*]
|
|
[*] Note that the 'Ndx' (Section index) for these symbols is SHN_LIVEPATCH (0xff20).
|
|
"OS" means OS-specific.
|
|
|
|
---------------------------------
|
|
4. Architecture-specific sections
|
|
---------------------------------
|
|
Architectures may override arch_klp_init_object_loaded() to perform
|
|
additional arch-specific tasks when a target module loads, such as applying
|
|
arch-specific sections. On x86 for example, we must apply per-object
|
|
.altinstructions and .parainstructions sections when a target module loads.
|
|
These sections must be prefixed with ".klp.arch.$objname." so that they can
|
|
be easily identified when iterating through a patch module's Elf sections
|
|
(See arch/x86/kernel/livepatch.c for a complete example).
|
|
|
|
--------------------------------------
|
|
5. Symbol table and Elf section access
|
|
--------------------------------------
|
|
A livepatch module's symbol table is accessible through module->symtab.
|
|
|
|
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 klp_modinfo struct. When a livepatch module loads,
|
|
this struct is filled in by the module loader. Its fields are documented below:
|
|
|
|
struct klp_modinfo {
|
|
Elf_Ehdr hdr; /* Elf header */
|
|
Elf_Shdr *sechdrs; /* Section header table */
|
|
char *secstrings; /* String table for the section headers */
|
|
unsigned int symndx; /* The symbol table section index */
|
|
};
|