Jump to contentJump to page navigation: previous page [access key p]/next page [access key n]
documentation.suse.com / SUSE Linux Enterprise Micro Documentation / Administration Guide / Common tasks / User space live patching
Applies to SUSE Linux Enterprise Micro 5.3

4 User space live patching

This chapter describes the basic principles and usage of user space live patching.

4.1 About user space live patching

Important
Important: user space live patching technical preview

On SLE Micro, ULP is a technical preview only.

Note
Note: Live patching on SLE Micro

Only the currently running processes are affected by the live patches. As the libraries are changed in the new snapshot and not in the current one, new processes started in the current snapshot still use the non-patched libraries until you reboot. After the reboot, the system switches to the new snapshot and all started processes will use the patched libraries.

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

4.1.1 Prerequisites

For ULP to work, two requirements must be met.

  • Install the ULP on your system by running:

    # transactional-update pkg in libpulp0 libpulp-tools

    After successful installation, reboot your system.

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

4.1.2 Using libpulp

To use libpulp with an application, you must perform the following steps:

  1. Make a library live-patchable.

  2. When launching the application, preload libpulp with the LD_PRELOAD=/usr/lib64/libpulp.so ./APPLICATION command.

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

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

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

4.1.2.4 Applying live patches

Live patches are applied using the ulp trigger command, for example:

ulp trigger -p PID LIVEPATCH.ulp

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 live patches 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.

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

4.2 More information

Further information about libpulp is available in the project's Git repository.