Skip to content

Latest commit

 

History

History
170 lines (121 loc) · 5.3 KB

kpatch.adoc

File metadata and controls

170 lines (121 loc) · 5.3 KB

Kernel Live Patching - Plan your reboots!

⚠️
This unit requires an active entitlement for RHEL and registration with the Red Hat CDN (subscription-manager). If connected to a Red Hat Satellite server, the Satellite must also have synchronized content to match the release of RHEL used for this workshop. So, besides overall functionality being impacted …​ some variations in the output can also be expected.

1. Overview

Red Hat Enterprise Linux offers kernel live patching, a solution to patch your running kernel without rebooting or restarting any processes. In this lab, we’ll explore this solution, which ships in the form of "kpatches" that can be managed with the "kpatch" tool.

2. Getting Started

For these exercises, you will be using the host node2 as user root.

From host bastion, ssh to node2.

ssh node2

Use sudo to elevate your priviledges.

sudo -i

Verify that you are on the right host for these exercises.

workshop-kpatch-checkhost.sh

You are now ready to proceed with these exercises.

3. Installing a kpatch

Let’s start by looking at the current kernel version:

rpm -q kernel
kernel-4.18.0-305.el8.x86_64
uname -r
4.18.0-305.el8.x86_64

Here we can see that we are running the 4.18.0-305 kernel. Now we install all kpatches for our kernel:

# yum install "kpatch-patch = $(uname -r)" -y
Updating Subscription Management repositories.
...

Note that kpatches are cumulative, so you cannot pick and choose a specific set of patches. You must take all fixes shipped by kpatches. At this time, kpatches are limited to security vulnerabilities. For a list of which kpatches are available and which vulnerabilities they address by CVE, please see: https://access.redhat.com/articles/4499631

Further, if you’d like to look at which CVEs are included by the kpatch installed on the system, you can do:

# rpm -qi --changelog kpatch-patch-4_18_0-305
Name        : kpatch-patch-4_18_0-305
Version     : 1
Release     : 1.el8
Architecture: x86_64
Install Date: Sun 15 Aug 2021 04:45:35 PM UTC
Group       : System Environment/Kernel
....
* Tue May 11 2021 Artem Savkov <[email protected]> [1-1.el8]
- serspace applications can misuse the KVM API to cause a write of 16 bytes at an offset up to 32 GB from vcpu->run [1954230] {CVE-2021-3501}

* Mon May 03 2021 Joe Lawrence <[email protected]> [0-0.el8]
- An empty patch to subscribe to kpatch stream for kernel-4.18.0-305.el8 [1956393]

This tells us that we are now protected against CVE-2021-3501. Let’s check kpatch list:

kpatch list
Loaded patch modules:
kpatch_4_18_0_305_1_1 [enabled]

Installed patch modules:
kpatch_4_18_0_305_1_1 (4.18.0-305.el8.x86_64)

We can see that we have kpatch_4_18_0_305_1_1 now installed and loaded. We have these protections effective immediately and without having to reboot. We can now schedule a reboot for a time that is convenient for us.

4. Taking that Scheduled Reboot

Kernel live patching is all about letting you schedule your reboots and not having to take downtime. We aren’t actually going to reboot our lab machines, but I’d like to spend a moment discussing what happens when you reboot.

If you reboot without installing a new kernel, you will boot back into the default kernel and if that one has kpatches, they will get loaded. Effectively, this means that your kpatch stack will persist.

If you do update the kernel prior to rebooting, on the next reboot, you’ll boot into the default kernel (which is now the new one) and thus your regularly running kernel should have the needed fixes without having any kpatches enabled.

At that point, kpatch list would look something like this:

kpatch list
Loaded patch modules:

Installed patch modules:
kpatch_4_18_0_305_1_1 (4.18.0-305.el8.x86_64)

Note that while we have installed patch modules, none of them are actually loaded.

5. Additional Resources