Livepatch

Differences between revisions 49 and 50
Revision 49 as of 2021-07-13 09:43:58
Size: 8966
Comment:
Revision 50 as of 2021-08-25 15:41:05
Size: 10295
Editor: bromer
Comment:
Deletions are marked like this. Additions are marked like this.
Line 36: Line 36:
Livepatches are released at the same time as each kernel SRU, and contain a subset of the CVEs fixed by that kernel SRU. Livepatches are cumulative, so when a new livepatch is released, it contains both the new CVE fixes, as well as all of the CVE fixes from the previous release of that livepatch. Livepatches are developed and released based on kernel SRU releases, and contain a subset of the CVEs fixed by that kernel SRU. Livepatches are cumulative, so when a new livepatch is released, it contains both the new CVE fixes, as well as all of the CVE fixes from the previous release of that livepatch.
Line 58: Line 58:
=== When should I expect updates? ===

Livepatches are related to and are ''usually'' derived from, but are not the same as, the kernel SRU updates for CVEs. While the vulnerabilities being addressed by both kernel SRU updates and livepatches are the same, the process for development and testing are not. A livepatch for a vulnerability can be significantly more complex than an ordinary kernel patch, and due to the additional complexity, can take more time to develop and test.

Canonical is committed to livepatching every high or critical rated CVE possible as quickly as we can, and in ideal circumstances, a livepatch will be available at the same time as the corresponding kernel SRU update.

If we determine that we cannot livepatch a high or critical CVE, we will inform our livepatch users at the same time an SRU kernel update that does fix the issue becomes available, in two ways:
 * The livepatch client will indicate that the system must be rebooted by reporting a state of "reboot required." This will be accompanied by a notification in the desktop, on desktop systems, and a notification in the MOTD on the terminal.
 * A LSN will be released containing instructions to reboot into a new SRU kernel that contains a fix for the CVE. LSNs are released on both the security website and via email.

Kernel Livepatch

This is a collection of notes and FAQs for the Canonical Livepatch Service. That page has a general introduction, data sheet and the ability to sign up for the service.

https://snapcraft.io/canonical-livepatch

System Requirements

Ubuntu release

Arch

Kernel Version

Kernel Variants

Ubuntu 20.04 LTS

64-bit x86

5.4 (GA)

generic, lowlatency, aws, azure, oem, gcp, gke, gkeop

Ubuntu 18.04 LTS

64-bit x86

5.4 (HWE)

generic, lowlatency, gke, gkeop

Ubuntu 18.04 LTS

64-bit x86

4.15 (GA)

generic, lowlatency, aws, oem, fips, azure-fips, gke

Ubuntu 16.04 LTS

64-bit x86

4.15 (HWE)

generic, lowlatency, azure, fips

Ubuntu 16.04 LTS

64-bit x86

4.4 (GA)

generic, lowlatency, aws, fips

Ubuntu 14.04 ESM

64-bit x86

4.4 (HWE)

generic, lowlatency

GA is the kernel a release launched with while HWE or Hardware Enablement is what has been added per that process. A rolling HWE kernel means that it will require major kernel upgrades per that LTS's specific plan.

Additionally, network access to the Canonical Livepatch Service (https://livepatch.canonical.com:443) and the latest version of snapd (at least 2.15) are needed.

Security Notices

The Livepatch Security Notices (LSN) are notifications issued for kernel vulnerabilities. They can be accessed by following our Security notices or by subscribing to the Ubuntu Security Announcements mailing list. LSNs are released for every high or critical kernel vulnerability. They are released for:

  • Announcing a new livepatch addressing a vulnerability.
  • Communicating an alert if a livepatch cannot be released describing the reason and possible mitigation. In that case
    • a standard Ubuntu security notice (USN) will be released with packages along side it to fix the issue.

    • the livepatch client will issue a warning that an update and reboot is necessary.

FAQ

What kinds of updates will be provided by the Canonical Livepatch Service?

The Livepatch Service intends to address high and critical severity Linux kernel security vulnerabilities, as identified by Ubuntu Security Notices and the CVE tracker. Since there are limitations to the kernel livepatch technology, some Linux kernel code paths cannot be safely patched while running. There may be occasions when the traditional kernel upgrade and reboot might still be necessary.

Livepatches are developed and released based on kernel SRU releases, and contain a subset of the CVEs fixed by that kernel SRU. Livepatches are cumulative, so when a new livepatch is released, it contains both the new CVE fixes, as well as all of the CVE fixes from the previous release of that livepatch.

What kinds of updates are not provided by the Livepatch service?

The livepatch service provides patches exclusively for Canonical-released kernels, addressing security issues that have been assigned a CVE and are rated as high or critical priority.

Livepatches are intended to address significant security issues in the kernel, and provide customers with protection from serious vulnerabilities until they can schedule a reboot. All CVEs that are rated as either a high or critical issue will always be livepatched if possible, and, if it is not possible, a notification that a reboot is required will be issued by the Livepatch client.

There are frequently patches included in kernel updates that are not included in the Livepatch service, such as:

  • bug fixes that are not security issues
  • performance improvements
  • driver updates
  • new features

To receive these updates, it is necessary to upgrade the kernel package using the package manager for the system (apt for Ubuntu desktop or server, or snapd if running on Ubuntu Core) and then reboot into the upgraded kernel.

When should I expect updates?

Livepatches are related to and are usually derived from, but are not the same as, the kernel SRU updates for CVEs. While the vulnerabilities being addressed by both kernel SRU updates and livepatches are the same, the process for development and testing are not. A livepatch for a vulnerability can be significantly more complex than an ordinary kernel patch, and due to the additional complexity, can take more time to develop and test.

Canonical is committed to livepatching every high or critical rated CVE possible as quickly as we can, and in ideal circumstances, a livepatch will be available at the same time as the corresponding kernel SRU update.

If we determine that we cannot livepatch a high or critical CVE, we will inform our livepatch users at the same time an SRU kernel update that does fix the issue becomes available, in two ways:

  • The livepatch client will indicate that the system must be rebooted by reporting a state of "reboot required." This will be accompanied by a notification in the desktop, on desktop systems, and a notification in the MOTD on the terminal.
  • A LSN will be released containing instructions to reboot into a new SRU kernel that contains a fix for the CVE. LSNs are released on both the security website and via email.

How do you rate a CVE?

We do not use an external rating system, but rate based on these qualifications:

negligible

Something that is technically a security problem, but is only theoretical in nature, requires a very special situation, has almost no install base, or does no real damage. These tend not to get backport from upstreams, and will likely not be included in security updates unless there is an easy fix and some other issue causes an update.

low

Something that is a security problem, but is hard to exploit due to environment, requires a user-assisted attack, a small install base, or does very little damage. These tend to be included in security updates only when higher priority issues require an update, or if many low priority issues have built up.

medium

Something is a real security problem, and is exploitable for many people. Includes network daemon denial of service attacks, cross-site scripting, and gaining user privileges. Updates should be made soon for this priority of issue.

high

A real problem, exploitable for many people in a default installation. Includes serious remote denial of services, local root privilege escalations, or data loss.

critical

A world-burning problem, exploitable for nearly all people in a default installation of Ubuntu. Includes remote root privilege escalations, or massive data loss.

What happens when a problem occurs that can't be patched?

When an un-patchable security issue occurs, users must upgrade to a version of the kernel that is fixed, and reboot. Problems of this type are announced on the mailing list via LSN. Kernels prior to the levels named in that announcement will no longer be livepatched.

The Livepatch client will report a state of "kernel-upgrade-required" if you are running a kernel that is no longer livepatched due to an earlier un-patchable kernel security issue.

Why isn't Livepatch working on my machine?

UNSUPPORTED KERNELS

Livepatch supports only kernels that have been released by the kernel team to the updates pocket, i.e. officially-released kernels acquired through APT using Canonical's repository for system updates, or Snap-based kernels released by Canonical to stable Snap channels.

While a livepatch *might* successfully apply to a kernel acquired from other sources, only kernels released by Canonical are supported. Kernels from other sources are not supported, including but not limited to:

  • kernels acquired from the development (proposed) kernel PPA
  • kernels acquired from the kernel team's build PPA
  • test kernels acquired from the kernel team's development PPAs
  • personally-rebuilt kernels using the source debian package
  • personally-rebuilt kernels using snapcraft
  • kernels acquired from a Ubuntu-derived distribution

Please be aware that while it may be possible to build a kernel with the same version markings as an officially-supported kernel, and to attempt to load a Canonical-generated livepatch into that kernel, it will likely not work, and can potentially crash your system or corrupt your data.

SECUREBOOT

If you are using secure boot, you will also need to import the livepatch public keys into your keyring.

This can be done with the following command:

sudo mokutil --import /snap/canonical-livepatch/current/keys/livepatch-kmod.x509

After this enter a password if necessary for MOK, then reboot. Your BIOS will then guide you through enrolling a new key in MOK. At this point you will be able to verify the module signatures.

How do I get more help?

For support questions see: https://www.ubuntu.com/management/ubuntu-advantage

Ubuntu Advantage customers may file support tickets at: https://support.canonical.com

Bugs

Please file bugs using the following URL: https://bugs.launchpad.net/canonical-livepatch-client/+filebug

When you open a bug, please provide the output from the following commands, so that we can troubleshoot your issue:

  • snap info canonical-livepatch
  • canonical-livepatch status
  • lsb_release -a
  • uname -a
  • journalctl -u snap.canonical-livepatch.canonical-livepatchd (this can be long, so maybe | tail -100 for recent issues)

Recommend marking the bug as private if any of the above contains personal information that you do not want publicly available and searchable.

Kernel/Livepatch (last edited 2021-10-21 19:14:00 by nmavrogiannopoulos)