12 User space live patching #
This chapter 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 them. Every time a security fix is available as a live patch, customer services will be secured after applying the live patch without restarting the processes.
Live patching operations are performed using the
ulp
tool that is part of
libpulp
. libpulp
is a
framework that consists of the libpulp.so
library and the ulp
binary that makes libraries live
patchable and applies live patches.
You can run the ulp
command either as a normal user
or a privileged user via the sudo
mechanism. The difference is that
running ulp
via sudo
lets you view information of
processes or patch processes that are running by root
.
Since SUSE Linux Enterprise Server SP6, the libpulp-load-default is
available that automates the requirements and manual steps mentioned in
Section 12.1.1, “Prerequisites” and Section 12.1.3, “Using libpulp
”.
If you install the package, you can skip those sections.
12.1.1 Prerequisites #
For ULP to work, two requirements must be met.
Install the ULP on your system by running:
>
sudo
zypper in libpulp0 libpulp-toolsApplications with desired live patch support must be launched preloading the
libpulp.so.0
library. See Section 12.1.3, “Usinglibpulp
” for more details.
12.1.2 Supported libraries #
Currently, only glibc
and
openssl
(openssl1_1
and openssl-3
)
are supported. Additional packages will be available after they are
prepared for live patching. To receive glibc
and openssl
live patches, install both
glibc-livepatches and
openssl-livepatches packages:
>
zypper install glibc-livepatches openssl-livepatches
12.1.3 Using libpulp
#
To enable live patching on an application, you need to preload the
libpulp.so.0
library when starting the
application:
>
LD_PRELOAD=/usr/lib64/libpulp.so.0 APPLICATION_CMD
12.1.3.1 Checking if a library is live patchable #
To check whether a library is live patchable, use the following command:
>
ulp livepatchable PATH_TO_LIBRARY
12.1.3.2 Checking if a .so
file is a live patch container #
A shared object (.so
) is a live patch 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 live patch container.
12.1.3.3 Applying live patches #
Live patches are applied using the ulp trigger
command, for example:
>
ulp trigger -p PID LIVEPATCH.so
Replace PID
with the process ID of the running
process that uses the library to be patched and
LIVEPATCH.so
with the actual live patch file. The
command returns one of the following status messages:
- SUCCESS
The live patching operation was successful.
- SKIPPED
The patch was skipped because it was not designed for any library that is loaded in the process.
- ERROR
An error occurred, and you can retrieve more information by inspecting the
libpulp
internal message buffer. See Section 12.1.3.6, “View internal message queue” for more information.
It is also possible to apply multiple live patches by using wildcards, for example:
>
ulp trigger '*.so'
The command tries to apply every patch in the current folder to every
process that have the libpulp
library
loaded. If the patch is not suitable for the process, it is
automatically skipped. In the end, the tool shows how many patches it
successfully applied to how many processes.
12.1.3.4 Reverting live patches #
You can use the ulp trigger
command 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 live patch 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, LIBRARY refers to the
actual library, such as 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 while the target application is still running a secure code, for example:
>
ulp trigger -p PID --revert-all=libcrypto.so.1.1 new_livepatch2.so
12.1.3.5 View applied patches #
It is possible to verify which applications have live patches applied by running:
>
ulp patches
The output shows which libraries are live patchable and patches loaded in programs, as well which bugs the patch addresses:
PID: 10636, name: test Livepatchable libraries: in /lib64/libc.so.6: livepatch: libc_livepatch1.so bug labels: jsc#SLE-0000 in /usr/lib64/libpulp.so.0:
It is also possible to see which functions are patched by the live patch:
>
ulp dump LIVEPATCH.so
12.1.3.6 View internal message queue #
Log messages from libpulp.so
are stored in a
buffer inside the library and are not displayed unless requested by
the user. To show these messages, run:
>
ulp messages -p PID
12.2 More information #
Further information about libpulp
is available
in the project's Git
repository.