The 2021 Deep Dive to Linux Kernel Updates

Reliable, efficient IT depends on repeatable processes that run like clockwork – it doesn’t make sense to change practices all the time, but key policies still need to be refreshed every now and again to keep up with changes in the technology – and the cybersecurity landscape.

Kernel patching is one of these processes – and often organizations will decide not to mess with a patching policy that looks like it works. Worse, sometimes kernel patching is seen as an arcane sysadmin job – never given much thought by anyone outside of the Linux geeks in the company.

Yet kernel patching really matters, given how Linux kernel vulnerabilities keep emerging every month. Just one unpatched kernel vulnerability can lead to disaster as malicious actors take advantage of an inefficient or ineffective patching regime.

For example, patches often require a reboot to be effective, and the waiting periods between reboot cycles can give malicious actors an opportunity to exploit a vulnerability. Rather than leave patching open to scheduled gaps, tech teams should consider adapting a different route to patching.

In this article we outline what kernel patching is, why kernel patching is so important – and explain why live Linux kernel patching is critical to boosting your cybersecurity efforts.

Content:

1. Understanding what a kernel is
2. What is a kernel update – and why is it so important?
3. Looking back at Linux kernel patching
4. Understanding the difference between updating and upgrading
5. How frequently are Linux updates released?
6. Do updates get applied automatically to Linux?
7. Five poor reasons to update your Linux kernel
8. A good reason to update your Linux kernel
9. How you can update without a reboot
10. Type of live patching tools
11. You need to patch – and live patching is the realistic option

Understanding what a kernel is

A kernel sits at the core of any modern operating system (OS), acting as a bridge between the physical computer hardware and the applications that run on the operating system. Applications typically do not control computer hardware directly – instead, the operating system facilitates this communication.

The kernel is the core part of the operating system that loads at bootup and manages low-level operations such as memory management and scheduling of processor tasks. Any higher level functions in the operating system are always managed and actioned by the OS kernel.

Every OS kernel has a slightly different role, and kernels can be divided roughly into five different types:

• A monolithic kernel where a large chunk of OS functionality is packaged inside a single unit – including device drivers, memory management, task schedulers and so forth. Monolithic kernels are used in environments using large servers, or where a server is dedicated to a specific job.
• Microkernels are much slimmer in nature, and only consist of the absolute minimum code to enable memory management, scheduling and the communications amongst processes. It minimizes the amount of memory needed by the kernel – and this type of kernel is typical in a real-time system.
• A hybrid kernel blends features of the monolithic kernel and the microkernel – it is larger in footprint and in memory consumption than a microkernel, but it is essentially a slimmed down version of a monolithic kernel – say with device drivers removed, but still keeping key OS services within the kernel. It’s typical of modern day desktop kernels such as Windows and OS X, as well as versatile server kernels including Linux.
• Nanokernels are extremely stripped down version of kernels, essentially only offering hardware abstraction through a minimal kernel space – think about a virtualization hypervisor, for example.
• Exo kernels are essentially academic in nature, offering resource protection alone and mostly used where very specific access is required to hardware.

No matter what type of kernel is in use – kernels are always at the core of an OS, and as such a kernel offers malicious actors a unique, attractive target. An attacker that can compromise an OS kernel can gain wide access to systems.

What is a kernel update – and why is it so important?

So it’s clear that the Linux kernel is central to the Linux operating system – and, by consequence, central to many of the most common server operating systems used every day. Think everything from Red Hat Enterprise Linux to free Linux distros such as Ubuntu and Debian.

These Linux-based operating systems support enterprise workloads around the globe – all dependent on a secure, reliable, and up to date Linux kernel. Over time Linux developers expand the kernel by adding new features. But another important role of Linux kernel developers is the patching of security vulnerabilities.

These patches are released at regular intervals, but patching procedures that allow for – say – delays in reboots will mean that patches are not applied as soon as a patch is released for a vulnerability. In other words, a lacking patching regime will imply that workloads are at more risk for longer than they need to be.

Looking back at Linux kernel patching

While Linux started as a project by a single individual, it has evolved into one of the most important OS kernels – serving everyone from desktop users right through to critical enterprise applications.

After thirty years of development, Linux has reached the point where it is an extremely stable OS kernel, but it nonetheless contains bugs and vulnerabilities. After all, with twenty million lines of code there will be some human errors in there.

Many of these vulnerabilities will rapidly become public simply because the Linux kernel is open-source, in other words, the public has full access to the Linux kernel source code. By consequence, malicious actors also have access to Linux kernel source code – and the visible flaws and vulnerabilities. In turn, breaching a single Linux server can lead to countless opportunities – leaving hundreds of enterprise clients vulnerable to an attack.

It’s not hard to see then that Linux OS vendors are always trying to keep abreast of the latest discoveries of vulnerabilities, and one of the ways to respond to a newly discovered vulnerability is of course through patching that vulnerability.

The trouble is that the flaws keep coming: month in, month out new flaws are discovered – sometimes in very old Linux kernel code. In fact, hundreds of Linux kernel vulnerabilities are discovered every year, and these all need patches – and every patch needs to be installed.

From a sysadmin perspective the sheer workload can become infuriating – with patch after patch surfacing. Worse, many patches require a server reboot. Constantly disrupting services to install a patch is simply not a realistic prospect.

Systems administrators therefore often take the view that patching can simply wait until there is a sufficient number of outstanding patches to warrant a disruptive server reboot – but this leaves a wide window of vulnerability as some patches are left unapplied for an extended period.

Understanding the difference between updating and upgrading

One point that’s worth clarifying is the difference between updating the Linux kernel – and upgrading the Linux kernel.

Let’s look at upgrades first. We know that technology moves forward – new capabilities are rolled out all the time, with new features and benefits. Often these new features are wrapped in a package that constitutes a major move forward – and that would be called an OS upgrade.

In contrast, an OS update is intended to fix issues – either there is a broken feature or the developer of the OS discovered a security vulnerability that needed remediation. The more urgent – and more compact – nature of updates means that these are released more frequently than upgrades.

However, updates can still be disruptive to install and are therefore not always installed upon release.

How frequently are Linux updates released?

Linux kernel updates are released at high frequency – in part due to the fact that Linux kernel vulnerabilities are continuously discovered, right through the year. It’s not a matter of quarterly or annual updates – it’s more frequent than that.

Where a vulnerability is discovered, a Linux kernel update – or patch – will likely be released almost immediately. In other words, Linux updates are issued at unpredictable intervals. It makes it difficult to plan for system updates – and the associated disruption.

Nonetheless, updates need to be applied sooner rather than later as often regular patching is required by compliance obligations – and by service level agreements.

Do updates get applied automatically to Linux?

Many operating systems self-update – think about those regular, frustrating Windows restarts for example. Linux does not automatically update – but you can set a scheduler to ensure that Linux is automatically updated using your Linux OS platform maintainer – some Linux vendors have packages that facilitate unattended updates.

Without automatic updates, a Linux-based OS such as Ubuntu or CentOS can quickly become outdated – with key vulnerabilities left unpatched. Again, sysadmins can install updates at a regular schedule – but often fail to do so due to a lack of time and resources, or simply because they want to avoid the associated disruption.

There is an alternative in terms of automated patching – and particular, automated patching that is completed without reboots. It’s called live patching, but we will cover this in a later section.

Five poor reasons to update your Linux kernel

So we know that kernel updates are resource intensive, and disruptive. Not every kernel update is the same however – and so it’s worth considering whether a kernel update is really necessary. Some of the reasons that have limited validity include:

• Purely to improve stability as the Linux kernel is already incredibly stable and you should closely evaluate any promised stability improvements before installing an update that promises a small increase in stability – or an increase in stability in an edge case.
• Driver updates are also not a good reason to update the kernel as you may well find that the driver update is not applied to hardware in use in your installation of Linux, or doesn’t provide enough of a tangible benefit to offset the downtime for installation.
• Additional functionality is another reason why you may want to think twice about a kernel update. It’s worth considering whether that functionality is really necessary – and whether the software you use will really require that functionality anytime soon.
• Faster performance while always useful is not necessarily a reason to upgrade your kernel, particularly where these performance enhancements are really incremental in nature.
• Where downtime is significant you should also pause on non-critical kernel upgrades and think twice whether the upgrade will really bring benefits to your workload.

In other words, kernel upgrades are not universally desirable – or universally urgent. But there is a type of kernel upgrade that is far more urgent – and which is almost always a good reason to update your Linux instance.

A good reason to update your Linux kernel

Security vulnerabilities are without a shadow of a doubt a good reason to update your Linux kernel. These flaws can be exploited at great cost to you – each unpatched, unfixed vulnerability acts as an open door to hackers who can take advantage to disrupt and steal from you. Furthermore, unpatched vulnerabilities will leave you non-compliant and potentially in breach of contract.

So you need to keep your Linux servers secure by updating, but it can be challenging to do so both in terms of resources – and in terms of the disruption associated with server updates. Thankfully there is a solution – live, rebootless updates.

How you can update without a reboot

Updating the Linux kernel can be time consuming and tedious and even more so given the frequency of updates that the ever growing number of Linux kernel vulnerabilities implies. But live kernel patching takes away the frustrating aspects of updating the Linux kernel – by removing the need to update manually, and by removing the requirement to reboot a server once the kernel update is applied.

In other words, live rebootless patching means that you can update your Linux servers automatically without manual intervention. And you can do so without stopping and restarting a live, active server – no need to interrupt your workload to apply an update.

Type of live patching tools

Live patching comes in a few different guises. First, you can use administered live patching where you apply the live patching yourself. Fully automatic live patching implies that patches are applied upon release – and done so automatically, without the need for you to intervene.

Ideally, you want fully automatic live patching with multi-platform capability to ensure that you patch broadly – and across your technology estate. This is what TuxCare’s KernelCare delivers – an end to end live patching solution that doesn’t require reboots, and which covers a lot of territory.

This more persistent way of patching ensures not just that your servers remain secure, but also keeps your Linux server running in optimal shape.

You need to patch – and live patching is the realistic option

A lack of consistent patching is something that may never catch you out – after all, it’s easy to say that you’ve never been hacked and therefore don’t need to worry too much about patching. But this can change rapidly through just one successful attack.

Patching is critical in today’s cybersecurity environment – the automated, persistent attacks by today’s hackers mean that any unpatched vulnerability is open season. Linux won’t patch itself, and manual patching is resource-intensive.

Instead, consider effortless, rebootless automated patching from TuxCare – and ensure that your Linux kernels are always protected against known vulnerabilities.

Get a FREE 7-Day Supported Trial of KernelCare