Chapter 10. Kernel

This chapter lists the most notable changes to kernel between RHEL 8 and RHEL 9.

10.1. Notable changes to kdump memory allocation

A new crashkernel.default file for kdump memory allocation

A new crashkernel.default file is now available on the RHEL 9 version of kdump.

The crashkernel.default file is shipped with kernel and it contains the default crash kernel value for the corresponding kernel build. The default value is used by kdump to control the default crash kernel memory value of each kernel. The value forms a good reference for kdump memory reservation. Using this value as the base to estimate the required memory, you can configure the desired crashkernel= value.

This implementation improves the memory allocation for kdump when a system has less than 4 GB available memory.

Note that the crashkernel=auto option in the boot command line is no longer supported on RHEL 9 and later releases.

For more information, see the /usr/share/doc/kexec-tools/crashkernel-howto.txt file.

10.2. Notable changes to TPM 1.2 secure cryptoprocessor support on RHEL 9

The TPM 1.2 secure cryptoprocessor is no longer supported on RHEL 9

The Trusted Platform Module (TPM) secure cryptoprocessor version 1.2 has been removed and is no longer supported on RHEL 9 and later versions. TPM 2.0 replaces TPM 1.2 and provides many improvements over TPM 1.2. TPM 2.0 is not backward compatible.

Note that for applications that require support for TPM 1.2, Red Hat recommends that you use RHEL 8.

10.3. Notable changes to kernel

cgroup-v2 enabled by default in RHEL 9

The control groups version 2 (cgroup-v2) feature implements a single hierarchy model that simplifies the management of control groups. Also, it ensures that a process can only be a member of a single control group at a time. Deep integration with systemd improves the end-user experience when configuring resource control on a RHEL system.

Development of new features is mostly done for cgroup-v2, which has some features that are missing in cgroup-v1. Similarly, cgroup-v1 contains some legacy features that are missing in cgroup-v2. Also, the control interfaces are different. Therefore, third party software with direct dependency on cgroup-v1 may not run properly in the cgroup-v2 environment.

To use cgroup-v1, you need to add the following parameters to the kernel command-line:


Both cgroup-v1 and cgroup-v2 are fully enabled in the kernel. There is no default control group version from the kernel point of view, and is decided by systemd to mount at startup.

Kernel changes potentially affecting third party kernel modules

Linux distributions with a kernel version prior to 5.9 supported exporting GPL functions as non-GPL functions. As a result, users could link proprietary functions to GPL kernel functions through the shim mechanism. With this release, the RHEL kernel incorporates upstream changes that enhance the ability of RHEL to enforce GPL by rebuffing shim.


Partners and independent software vendors (ISVs) should test their kernel modules with RHEL 9 Alpha to ensure their compliance with GPL.

Core scheduling is supported in RHEL 9

With the core scheduling functionality users can prevent tasks that should not trust each other from sharing the same CPU core. Likewise, users can define groups of tasks that can share a CPU core.

These groups can be specified:

  • To improve security by mitigating some cross-Symmetric Multithreading (SMT) attacks
  • To isolate tasks that need a whole core. For example for tasks in real-time environments, or for tasks that rely on specific processor features such as Single Instruction, Multiple Data (SIMD) processing

For more information, see Core Scheduling.