Automated patching for the Linux kernel

To start securely and efficiently, Linux systems follow a carefully orchestrated sequence of steps to initialize firmware and manage services. Applying security patches to the software responsible for some of these early steps of Linux startup often requires a full system reboot. Frequent reboots driven by unplanned critical patching is disruptive and man-power intensive, especially in high availability environments and for organizations that pride themselves in the number of 9’s in their uptime averages. Livepatch is Canonical’s solution to cut through this inefficiency in a way that shrinks vulnerability exploit windows and reduces unplanned strain on system administrators. Canonical Livepatch provides live kernel patches that are built and tested with the same machinery and rigor as the factory-installed kernel. Whether you’re running a single server or a high-availability cluster, Livepatch ensures your systems stay protected against critical and high CVEs, and the unplanned interruptions associated with remediating them. Let’s explore how Livepatch works and why it’s a game-changer for Linux security.

How Linux machines boot up

When booting up a Linux machine, a series of processes must successfully complete for the machine to be ready.

1. The BIOS (the firmware software for the motherboard) is initialized and loads the bootloader. The BIOS applies the default CPU microcode from the motherboard firmware.
2. Ubuntu’s GRUB bootloader is initialized. It is aware of Windows partitions on installed disk drives, and also aware of installed Linux kernels. If the OS has a newer CPU microcode, it is applied at this time via initrd. /dev/initrd is a  read-only block device owned by root:disk, with mode 0400 (read access by root only), and assigned major number 1 and minor number 250.
3. By default, the latest installed kernel is used to initialize the system hardware, mount the root filesystem, and start the init system.
4. The init system on Ubuntu, systemd, looks for glibc on the disk. systemd runs with Process ID 1 (PID 1), and loads before user-space applications and services start running. glibc is dynamically linked to systemd, and is essential for systemd’s operation.

Security patching automations with and without service and system restarts

All security patches can be installed using security patching automations, some require services to be restarted, and others require a complete reboot to be fully applied. Even though glibc can be security patched without having to recompile systemd, glibc security updates require a system reboot. This is because packages like systemd which are run using a vulnerable version of glibc could potentially be exploited. Any security patches for glibc, libc, CPU microcode, the GRUB bootloader, and security vulnerabilities in the Linux kernel rated medium and below all require an upgrade and a reboot to apply. The needrestart package can be configured to auto-restart services when possible, to ensure the security patches are applied when Landscape, unattended-upgrades, or manually triggered apt upgrades are applied.

In contrast, critical and high security vulnerabilities in the Linux kernel do not require a system reboot. 

Rebootless security patching automations for the Linux kernel

Livepatch is a security patching automation solution for the Linux kernel, designed to secure your Ubuntu instances against critical or high Common Vulnerabilities and Exploits (CVEs), until the next security patching and reboot window. Livepatch eliminates the need for a reboot, and it achieves this in 2 ways:

1. Livepatch can perform “per-CPU patching”, which is an efficient means to apply a kernel security patch in memory with minimal latency
2. Livepatch supports function-level patching, and replaces vulnerable functions in memory by integrating with the kernel’s ftrace infrastructure

Without Livepatch, in the event of a critical CVE, system administrators have to prepare environments for a reboot event. For high availability (HA) deployments, this means demoting a machine from the HA cluster, installing the update and applying it with a reboot, and promoting the machine back into the HA cluster. The HA cluster is vulnerable to exploits for the entire time it takes the system administrator to complete this security patching task.

Livepatch eliminates unplanned security patching related reboots. Livepatch applies available critical and high security patches as soon as Livepatch Client downloads the update, before any manual security patching intervention occurs. System administrators that want granular control over when Livepatch downloads and applies these patches have the ability to specify patching cut-off times, and also patching delays.

Shrink your security vulnerability exposure window exponentially with Livepatch, without sacrificing any 9’s in your uptime records. Livepatch is available with all free and paid Ubuntu Pro subscriptions. Learn more about Canonical’s release cadence and how it should influence your security patching maintenance calendar:

Learn more about Ubuntu Pro

Get started with a free trial

Learn more

• What is patching automation?
• An overview of Live Kernel Patching
• How often do you apply security patches on Linux?
• 3 ways to apply security patching in Linux