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

Tip
Tip

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.

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.

  • Applications with desired live patch support must be launched preloading the libpulp.so.0 library. See Section 4.1.3, “Using libpulp” for more details.

4.1.2 Supported libraries

  

Currently, only glibc and openssl (openssl1_1) 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: 

> transactional-update pkg in glibc-livepatches openssl-livepatches

After successful installation, reboot your system.

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

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

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

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

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

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

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

4.2 More information

  

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