User space live patching | Administration Guide | SUSE Linux Enterprise Desktop 15 SP4

Applies to SUSE Linux Enterprise Desktop 15 SP4

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 the LD_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.