Ubuntu kernel variants from Canonical

A kernel variant is a kernel that deviates from the General Availability (GA) kernel by changes to its configuration and/or by having modules added and/or removed. In short, a kernel variant is an Ubuntu kernel that reports a kernel version and flavour other than what is reported with an Ubuntu LTS -generic kernel when you run the $ uname -a command. It is possible to have kernel variants for multiple releases of a kernel, which is something that will happen naturally over time to a newly-released custom kernel.

Canonical’s Kernel Team strives to support all use cases from the generic kernel. Only where this is not possible are kernel variants created. Variants fall into four broad categories:

  • Version-specific, where the kernel base version differs
  • Configuration-specific, where desired kernel configurations are incompatible and the underlying features are not runtime selectable
  • Platform-specific, where a specific platform requires patches that are not currently applicable to the primary kernels
  • Project-specific, where project deadlines require expedited delivery

Version-specific kernels

It is not possible to sensibly combine kernels at different upstream versions. For any Ubuntu LTS release where we carry a General Availability (GA) kernel at one version, and a Hardware Enablement (HWE) kernel at another version, those are delivered as separate kernels. Version-specific kernels provide a consistent operating environment for Application Binary Interface (ABI)-sensitive workloads. It is not possible to combine kernels based on different upstream versions, which means maintaining a version-specific kernel is done through backporting fixes for serious/critical bugs and CVEs, which is the primary differentiator for this kernel variant. Version-specific kernels are just as rigorously maintained by Canonical as our generic kernels but Canonical ensures backport of critical/high CVE mitigation.

There is no significant additional technical consideration with a version-specific kernel variant since the work of backporting patches is a well-understood industry practice. However, there are business considerations regarding scope, cost and effort to maintain ABI compatibility over time as a version-specific kernel ages and gets further and further away from the latest upstream stable kernels, which makes backporting critical and high patches increasingly complicated and expensive.

Configuration-specific kernels

Our primary kernels are targeted to a general-purpose configuration with wide applicability. Where additional configuration combinations are needed, and cannot be runtime selected, we create use-case-specific kernels. For example, some memory management unit (MMU) page table code is build time selectable for performance reasons.

Platform-specific kernels

Some platforms exhibit a very large delta to the primary kernel code base. It is common for this delta to change platform-agnostic code in ways which create risk for other platforms and are not yet accepted upstream. In these cases it is desirable to create a separate kernel for this platform to contain the risk.

Project-specific kernels

For some projects it might be required to release kernels out of sync with the primary kernels, or to release fixes to those projects quicker than is possible to cycle a full suite of testing. In these cases it is desirable to create a separate kernel to release it from those constraints.

Current varient kernels

Name Type Description
Generic - The primary GA kernel, targeting a general-purpose configuration. It is the latest upstream kernel at the time of the release and remains on this version for the life of the release.
lowlatency configuration Targets latency sensitive applications such as sound processing.
generic-hwe version Targets a later version of the upstream kernel, and updates with respect to that every 6 months until it matches the GA kernel in the subsequent LTS release.
lowlatency-hwe version
configuration
Targets latency-sensitive applications such as sound processing at the same version as the generic-hwe kernel.
generic-hwe-edge version Provides early access to the next generic-hwe kernel.
lowlatency-hwe-edge version
configuration
Provides early access to the next lowlatency-hwe kernel.
kvm configuration Targeting KVM instance usage. This carries the minimum support required for a guest kernel.
aws configuration Targeting the AWS cloud.
azure configuration
version
Targeting the Azure cloud.
gcp/gke configuration Targeting the Google Compute Platform/Google Kubernetes Engine.
raspi2 platform For the Raspberry Pi 2 ARM board.
snapdragon platform For the Qualcomm Snapdragon ARM64 board.
oem project Targeting various OEM projects. This carries early access drivers for hardware enablement. This kernel is typically used in the early phases of a project release, with a view to “upstreaming” any delta into the GA or HWE kernels and once this delta is incorporated the final platform is moved over to those kernels.

Additional kernel variants

In addition to those kernel variants, Canonical offers FIPS/STIG kernels:

  • FIPS — Certified 16.04 GA kernel for Ubuntu 16.04
  • FIPS — compliant 16.04 GA kernel with critical security and patch updates for Ubuntu 16.04