Documentation/livepatch/module-elf-format.rst

Source file repositories/reference/linux-study-clean/Documentation/livepatch/module-elf-format.rst

File Facts

System
Linux kernel
Corpus path
Documentation/livepatch/module-elf-format.rst
Extension
.rst
Size
13681 bytes
Lines
306
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

===========================
Livepatch module ELF format
===========================

This document outlines the ELF format requirements that livepatch modules must follow.


.. Table of Contents

.. contents:: :local:


1. 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.

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().

2. 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:**

Annotation

Implementation Notes