• 2024-02-23


KLP (Kernel Live Patching) makes it possible to apply the latest security updates to Linux kernels without rebooting. This maximizes system uptime and availability, which is especially important for mission-critical systems. 

Live patches contain only critical fixes, and they do not replace regular kernel updates that require a reboot. Consider live patches as temporary measures that protect the kernel until a proper kernel update and a reboot are performed.


Kernel live patches are delivered as packages with modified code that are separate from the main kernel package. The live patches are cumulative, so the latest patch contains all fixes from the previous ones for the kernel package. Each kernel live package is tied to the exact kernel revision for which it is issued. The live patch package version number increases with every addition of fixes.

The diagram below illustrates the overall relationship between live patches and kernel updates. The list of Common Vulnerabilities and Exposures (CVEs) and defect reports addressed by the currently active live patch can be viewed using the klp -v patches command. 

It is possible to have multiple versions of the kernel package installed along with their live patches. These packages do not conflict. You can install updated kernel packages along with live patches for the running kernel. In this case, you may be prompted to reboot the system. Users with SLE Live Patching subscriptions are eligible for technical support as long as there are live patch updates for the running kernel. 

With KLP activated, every kernel update comes with a live patch package. This live patch does not contain any fixes and serves as a seed for future live patches for the corresponding kernel. These empty seed patches are called initial patches.


KLP offers several benefits. 

a) Keeping a large number of servers automatically up to date is essential for organizations obtaining or maintaining certain compliance certifications. KLP can help achieve compliance, while reducing the need for costly maintenance windows. 

b) Companies that work with service-level agreement contracts must guarantee a specific level of their system accessibility and uptime. Live patching makes it possible to patch systems without incurring downtime. 

c) Since KLP is part of the standard system update mechanism,there is no need for specialized training or introduction of complicated maintenance routines. 


If you are using any tool for patching like SUSE Manager, then you can directly map SUSE kernel-live patch repositories to your server from that tool. 

And if you have SUSE subscription or your server is running on cloud then you can directly enable it by as below: - 


Or you can install it by installing kernel-livepatch-tools packages. 


4. Now we have enabled kernel live patch,and you can verify by below command: -

Ready means now you are ready to use it and you can patch your system with klp. Livepatch1 gets applied when we install kernel-livepatch . 

See below: livepatch_1 is active for this running kernel.

You can check if something is blocking to klp to get complete.


Make sure you have at least root volume backup for your instance/server before going forward for OS Patching. You can apply all patches except kernel so make sure you have locked kernel package before going forward for it. After patching you don’t need to reboot your host and therefore you can push your host’s maintenance to max. 1 yr. from the first patch. 

Make sure you have lock kernel-default packages if the system is directly registered with suse/aws. If you are using SUSE Manager, then apply the filter to exclude kernel-default package or make kernel-livepatch template and apply the patches. 

You can see there are now two livepatches are showing post patch the system.

As SUSE releases kernel patches every month therefore we can assume that we can apply max 12 livepatches.  


If you find the latest live patch problematic, you can downgrade the currently installed live patch back to its previous version by below command:

If you have multiple versions of livepatch available, and want to roll back to the n-2 or n-3 version then simply execute below command:-  

zypper in --oldpackage kernel-livepatch-RUNNING_KERNEL_VERSION -  default=DESIRED_VERSION

In the above case our DESIRED_VERSION is 1 because we want to roll back just to previous version that’s why its showing as 1. 

You can see again Livepatch1 is in use, and we have roll back live patches to the previous version.

NOTE: - We can roll back kernel livepatch package only with the help of above process but if you want to restore back all patches then go for root volume back restoration. 



You can simply uninstall the kernel-livepatch-tools package from the system. No need to reboot the host.


Important Notes: 

Kernel live patches are installed as part of regular system updates. However, there are several things you should be aware of. 

a) When kernel-default package is installed, the update manager prompts you to reboot the system. To prevent this message from appearing, you can filter out kernel updates from the patching operation. This can be done by adding package locks with zypper. SUSE Manager also makes it possible to filter channel contents.

b) You can check patching status using the klp status command. To examine installed patches, run the klp -v patches command.

c) Keep in mind that while there may be multiple kernel packages installed on the system, only one of them is running at any given time. Similarly, there may be multiple live patch packages installed, but only one live patch is loaded into the kernel.

d)The active live patch is included in the initrd. This means that in case of an unexpected reboot, the system comes up with live patch fixes applied, so there is no need to perform patching again.

e) Not all security issues can be fixed by applying a live patch. Some security issues can only be fixed by applying a full kernel update and require a reboot. The assigned CVE numbers for these issues are not included in live patches. A CVE audit displays this requirement.


Thank you!

Author's name: Mohit Kumar