Three Ways To Patch A Linux Kernel
Patching the Linux kernel is an essential part of web server security, as anyone in IT knows. How is it done? In three main ways:
- By running the upgrade command
- Through the system call kexec
- With a live patching system
Let’s review how each kernel patching method works, examine their pros and cons, and determine which one might work best for you.
Upgrading, Then Rebooting
The easiest way to patch Linux kernels is to run the upgrade command. You run sudo apt-get upgrade, and a new kernel with patches is installed.
Different distributions require slightly different commands. For example, on Ubuntu the command would be:
sudo apt-get upgrade linux-image-generic
sudo reboot
On Debian:
sudo apt-get upgrade kernel
sudo reboot
And on CentOS or RHEL:
sudo yum update kernel
sudo reboot
Once the server reboots, the patches included with the new kernel will take effect.
Running the upgrade command is an easy way to do kernel patching, but if you’re running servers that require maximum uptime, not an effective one. That’s because it involves shutting down processes — and shutting out users — while the server is rebooted.
This method is also the least secure, because it leaves servers open to attack between reboots. If you plan to reboot a server every month, for instance, new kinds of attacks can be devised and launched in that interval.
Rebooting More Quickly With Kexec
Using the kexec system call also involves a reboot, but a faster, more efficient one. It speeds up the reboot process by skipping the boot loader and hardware initialization, which enables you to install a new kernel more quickly.
To use kexec, first install kexec-tools. To do this on Ubuntu and Debian, you run the command:
sudo apt-get install kexec-tools
On CentOS and RHEL, the command is:
sudo yum install kexec-tools
Then you install the new kernel:
sudo yum update kernel
or
sudo rpm -qa kernel
Then you boot into the new kernel with commands such as:
sudo kexec -l /boot/vmlinuz-3.10.0–862.3.2.el7.x86_64 \
-initrd=/boot/initramfs-3.10.0–862.3.2.el7.x86_64.img \
-reuse-cmdline
sudo sync; sudo umount -a; sudo kexec -e
Using kexec to patch kernels is faster than a simple upgrade, but it’s also more involved, obviously, and still presents all the problems that come with reboots: downtime, interruptions, and user inconvenience.
The No-Reboots Method: Live Patching
For organizations that require constant uptime for their servers, live patching is an excellent option. That is, patching the kernel while a server is still running, without the need for a reboot.
Because it works while a server is running, live patching eliminates downtime and user inconvenience. It also reduces support costs, by automating many of the patching operations that formerly required support staff to perform.
The greatest advantage of live patching, however, is that it provides tighter security. It enables patches to be applied as soon as they’re available, in response to emerging threats. This, in turn, helps companies comply with security standards that customers trust, such as SOC2 and HIPAA.
Are there any drawbacks to live patching? Kind of, but not really. It involves additional licensing fees, but these fees are offset by reduced support costs. For companies that consider uptime and security to be critical concerns, live patching is the best way to patch Linux kernels.
How Does Live Patching Work?
KernelCare, a live patching system created by CloudLinux, provides a good example of how these systems typically work. It has three main components that perform the essential functions involved in patching:
- Patch Server
A patch server stores patches for each kernel version and architecture type. This can be a dedicated central server, or an in-house server. - Agent Program
A small agent program installed on a web server runs in the background, checking the patch server for patches at specified intervals. - Kernel Module
When instructed by the agent, a kernel module handles the patching, pausing and restarting the kernel’s processes to perform the patch.
During the live patching process, changes happen so quickly that users and applications can’t detect them while they’re being made. From the perspective of a user or a server process, the kernel never stops.
Choosing A Live Patching System
There are several live patching systems available: Oracle’s Ksplice, Ubuntu’s Livepatch, Red Hat’s Kpatch, SUSE’s Kgraft, and KernelCare from CloudLinux. Each vendor’s live patching system works best with their particular Linux distribution, and is integrated with their support packages.
Except for KernelCare, that is. It works with all major Linux distributions, including Amazon Linux, CentOS, Red Hat, Debian, Oracle Linux, and Ubuntu. It’s also the least expensive of all the live patching systems.
If integration is paramount for your organization, and you’re running one of the Linux distributions mentioned above, you’ll want to look at its corresponding patching system. If cost and support are your priorities, you’ll want to check out KernelCare. Its new KernelCare+ variant includes OpenSSL and glibc patching, and KernelCare Enterprise includes even more.
To try KernelCare free for 30 days, and evaluate a state-of-the-art live patching system firsthand, go to https://www.kernelcare.com/free-trial/.
