12 User space live patching #
This document describes the basic principles and usage of user space live patching.
12.1 About user space live patching #
User space live patching (ULP) refers to the process of applying patches
to the libraries used by a running process, without interrupting it. Live
patching operations are performed using the ulp
tool that is part of the libpulp
.
libpulp
is a framework that enables user space live patching. It
consists of the libpulp.so
library and tools for
making libraries live-patchable and applying live patches (the
ulp
binary).
12.1.1 Prerequisites #
For ULP to work, two requirements must be met.
To be live-patchable, a library must be compiled with the
-fpatchable-function-entry
GCC flag. No changes to the library source code are required.Processes must preload the
libpulp.so
library.
12.1.2 Using libpulp #
To use libpulp
with an application, you must
perform the following steps:
Make a library live-patchable.
When launching the application, preload
libpulp
with theLD_PRELOAD=/usr/lib64/libpulp.so ./APPLICATION
command.
12.1.2.1 Preparing a library to be live-patchable #
For a library to be live-patchable, it must contain a
NOP
prologue in all function calls. GCC version 8 and
higher, as well as the GCC version that ships with SUSE Linux Enterprise Server, provides the
-fpatchable-function-entry
specifically for that purpose.
Thus on the AMD64/Intel 64 architecture, compiling a library written in C with
-fpatchable-function-entry=16,14
flag is sufficient to
make it live-patchable.
The glibc, libssl.so.1.1, and libcrypto.so.1.1 libraries are already live-patchable on SUSE Linux Enterprise 15 SP4.
12.1.2.2 Checking if a library is live-patchable #
To check whether a library is live-patchable, use the following command:
ulp livepatchable LIBRARY
12.1.2.3 Checking if a .so
file is a livepatch container #
A shared object (.so
) is a livepatch container if it contains the ULP patch
description embedded into it. You can verify it with the
following command:
>
readelf -S SHARED_OBJECT | grep .ulp
If the output shows that there are both .ulp
and .ulp.rev
sections in the
shared object, then it is a livepatch container.
12.1.2.4 Applying live patches #
Live patches are applied using the ulp trigger
command, for example:
ulp trigger -p PID LIVEPATCH.so
In this example, PID
is the PID of the running process
that uses the library to be patched and LIVEPATCH.ulp
is the actual live patch file.
The live patching succeeded
message indicates that the
live-patching operation was successful.
It is also possible to apply multiple livepatches by using wildcards. For example:
>
ulp trigger -p PID '*.so'
This command will try to apply every patch in the current folder to the process holding
PID
. In the end, the tool will show how many patches it successfully applied.
12.1.2.5 Reverting live patches #
ulp trigger
can be used to revert live patches. There
are two ways to revert live patches. You can revert a live patch by
using the --revert
switch and passing the livepatch container:
>
ulp trigger -p PID --revert LIVEPATCH.so
Alternatively, it is possible to remove all patches associated with a particular library. For example:
ulp trigger -p PID --revert-all=LIBRARY
In the example above, LIBRARY refers to the
actual library, for example: libcrypto.so.1.1
.
The latter approach can be useful when the source code of the original live patch is not available, or you want to remove a specific old patch and apply a new one, without the target application running potentially unsecure code. For example:
>
ulp trigger -p PID --revert-all=libcrypto.so.1.1 new_livepatch2.so
12.2 More information #
Further information about libpulp
is available in
the project's Git
repository.