Chapter 16. Kernel

In RHEL 10, with sched_ext you can create custom process scheduling code in extended Berkeley Packet Filter (eBPF) at runtime. The sched_ext scheduler allows you to replace the standard kernel scheduler with your own scheduling logic to control process prioritization, resource allocation, and execution behavior.

Please note that Red Hat does not provide support for a custom scheduler.

The Completely Fair Scheduler (CFS) is replaced with a new scheduler, Enhanced Earliest Deadline First (EEVDF). This includes the following changes:

CFS and EEVDF deliver similar workload results in most cases. However, minor variations in performance might be observed because the logic of each task selection is different.

In Red Hat Enterprise Linux 10, the kdump feature on systems that use LUKS-encrypted block devices supports automatic crash dumping without manual passphrase entry. Previously, when the root file system or kdump target device used LUKS encryption, the crash kernel could not access the encrypted device unless an administrator entered the passphrase on the console or configured a separate unencrypted kdump target.

With Red Hat Enterprise Linux 10, the running kernel can pass the LUKS volume key to the kdump kernel when loading it with kexec. Together with updates in kdump utilities, this change enables:

To use this capability, ensure that the system runs a Red Hat Enterprise Linux 10 kernel that includes this change, that kdump is configured and enabled, and that the kdump target device is reachable in the crash kernel environment. For configuration details and supported scenarios, see the Red Hat Enterprise Linux 10 kdump documentation.

The kpatch tooling can report a list of vulnerabilities that are currently fixed by live patches applied to the running kernel. The report focuses on CVEs that are patched only by live patches, not by the on-disk kernel packages. As a result, security and compliance teams can verify that a system is protected even if the kernel version reported by uname appears vulnerable according to external advisories or scanners.

This change is especially important in environments that rely on strict uptime requirements, where rebooting into a new kernel is delayed or coordinated across many systems. By exposing which CVEs are covered by live patches, Red Hat Enterprise Linux 10 makes it easier to integrate kernel live patch status into security reporting, risk assessments, and automated scanning workflows.

When planning an upgrade from RHEL 9 to Red Hat Enterprise Linux 10, consider how your existing vulnerability management and compliance processes can take advantage of this kpatch reporting. You might need to update internal documentation, dashboards, or scanner configuration to recognize that some CVEs are remediated only through live patches on the currently running kernel, even if the kernel package version does not yet include the fix.

The kernel live patch build tool (klp-build) is now available in Red Hat Enterprise Linux 10 and is used to generate live patches from input kernel patches. As part of this change, the kernel build system uses additional objtool processing when building kernel modules.

Because of these changes, kernel modules can now have non-zero section load addresses (for example, non-zero sh_addr values for .text and related sections). This is different from earlier Red Hat Enterprise Linux releases, where many tools assumed that kernel module sections start at address 0.

This change can affect debugging and tracing tools that parse kernel module ELF metadata directly, such as tools based on elfutils or SystemTap, if they rely on the previous zero-based section address layout. To avoid unexpected failures or incorrect symbol resolution:

If you rely on live patching workflows or custom tooling that processes kernel modules, test your scenarios on Red Hat Enterprise Linux 10 before upgrading production systems from earlier Red Hat Enterprise Linux versions.

In Red Hat Enterprise Linux 10.2, the user-space perf tooling is synchronized with the upstream Linux 6.17 perf codebase. This change affects system administrators and developers who use perf for performance analysis, profiling, and hardware event sampling on Red Hat Enterprise Linux systems.

The rebase brings support for new and updated Performance Monitoring Units (PMUs) and events across several hardware platforms, including recent Intel uncore PMUs, new IBM Z CPU-MF counters, and additional vendor-specific platforms such as Fujitsu Monaka. As a result, the set of available events, metrics, and reporting options in perf can differ from earlier Red Hat Enterprise Linux major versions.

Because of these changes, some existing perf workflows might require adjustment:

Before upgrading to Red Hat Enterprise Linux 10.2, review and test your perf-based tooling and scripts in a non-production environment. After upgrading, verify available events and metrics with the perf list and perf help commands, and update any automation that relies on older event names or behaviors.

In Red Hat Enterprise Linux 10.2, the perf userspace tool is rebased to the upstream Linux 6.18 version. This rebase aligns the Red Hat Enterprise Linux performance monitoring stack with newer hardware support and upstream behavior.

When upgrading to Red Hat Enterprise Linux 10.2, note the following changes:

Before upgrading performance-sensitive environments or CI jobs that rely on perf, test your existing workflows on Red Hat Enterprise Linux 10.2 with the kernel-6.12.0-177.el10 build and re-baseline key measurements, because updated events and metric definitions can influence how results are reported.

In Red Hat Enterprise Linux 10, the perf profiling tool now links statically to the libbpf library that is included in the kernel source tree, instead of using the libbpf shared library from the libbpf runtime package.

This change provides the following benefits:

For most users, this change is transparent and does not require any manual action. Existing perf workflows and command-line options continue to work as before.

However, if you relied on the perf binary dynamically linking against the system libbpf shared library—for example, for troubleshooting or for validating behavior against a specific libbpf package version—you can no longer change perf’s `libbpf behavior by updating only the libbpf runtime package. In such cases, you must use the perf tool from the kernel build that includes the desired in-tree libbpf version.

In Red Hat Enterprise Linux 10, the Berkeley Packet Filter (BPF) subsystem is rebased to the upstream Linux kernel 6.17 level. This update adds new BPF features, a verifier, and performance improvements, which can change how existing BPF programs and tools behave after an upgrade from earlier Red Hat Enterprise Linux major versions.

Compared to previous Red Hat Enterprise Linux releases, the BPF rebase to 6.17 introduces:

After upgrading to Red Hat Enterprise Linux 10:

Before upgrading, test your existing BPF programs and workflows on a non-production Red Hat Enterprise Linux 10 system and rebuild BPF user-space components against the Red Hat Enterprise Linux 10 toolchain and kernel headers.

On AMD Venice-based systems, the AMD Cryptographic Co-processor (CCP) driver in Red Hat Enterprise Linux 10.2 is updated to recognize additional Venice PCI device IDs. As a result, CCP hardware on these systems is now correctly detected and initialized by the kernel.

This change can affect environments that use the CCP engine for cryptographic acceleration (for example, IPsec or dm-crypt workloads) on Venice platforms:

If you rely on specific performance baselines, hardware offload behavior, or FIPS-compliant crypto configurations, review and validate your workload performance and security policies after upgrading Venice-based systems to Red Hat Enterprise Linux 10.2.

On systems based on the Intel Wildcat Lake platform, Red Hat Enterprise Linux 10 now recognizes the PCI device IDs for the Intel In-Memory Analytics Accelerator (IAA) devices. Previously, these IAA devices might not have been detected correctly and could not be used by the operating system.

As a result, when you run Red Hat Enterprise Linux 10 on supported Wildcat Lake systems with IAA hardware, the kernel can now discover and expose the accelerator devices for supported workloads such as compression and analytics offload.

To use these accelerators after upgrading to Red Hat Enterprise Linux 10 on Wildcat Lake systems:

In Red Hat Enterprise Linux 10.2, the Intel QuickAssist Technology (QAT) kernel driver is updated to a version based on upstream 6.18. This update enables QAT acceleration on recent Intel DMR-family CPUs and includes bug fixes that apply to all supported QAT devices.

These changes can improve hardware-accelerated cryptography and data compression performance on systems with the listed processors. Because the driver includes multiple functional fixes, QAT behavior on existing platforms can change compared to earlier Red Hat Enterprise Linux 10 minor releases.

When planning an upgrade to Red Hat Enterprise Linux 10.2 on systems that use Intel QAT:

In Red Hat Enterprise Linux 10, Trusted Platform Module (TPM) 2.0 tooling continues to evolve to match current hardware requirements and security practices. When planning an upgrade from RHEL 9 to RHEL 10 on Lenovo 64-bit x86 platforms, review any dependencies on the tpm2-tools package and associated TPM-based workflows.

If your deployments rely on TPM 2.0 for secure boot measurements, sealed key storage, attestation, or platform integrity checks, validate that your automation, scripts, and operating procedures remain compatible with the TPM tooling included in RHEL 10. In particular, verify behavior such as command-line options, output formats, and integration with provisioning or compliance pipelines before large-scale rollout. This reduces the risk of unexpected regressions in environments that treat TPM-backed trust as a critical part of their platform integrity and compliance strategy.

Red Hat Enterprise Linux uses the shim boot loader as the first component in the UEFI Secure Boot chain. The shim binary must be signed with keys that the platform firmware trusts, and shim must trust the keys that sign later boot components such as grub2 and the kernel.

In RHEL 10.2, the shim binaries are signed with three keys, in this order:

For a shim binary to load under Secure Boot, at least one of the corresponding certificates must be enrolled in the system firmware trust store. Earlier shim builds were signed only with the Microsoft Windows UEFI Driver Publisher (2011) key.

For more information about these signatures and their impact on Red Hat Enterprise Linux Secure Boot, see the Secure Boot Certificate Changes in 2026: Guidance for Red Hat Enterprise Linux Environments.

Starting with RHEL 10.1, the grub2 and kernel binaries are signed with longer, more secure keys. To load these components, shim must trust both Red Hat Certificate Authority (CA) 5 and CA 8. As a result, systems that upgrade to RHEL 10.2 must have a sufficiently recent shim in the existing installation before attempting the upgrade.

The minimum supported shim levels for upgrade are:

If the existing RHEL 8 or RHEL 9 deployments use older shim builds that do not trust both CA 5 and CA 8, shim cannot verify the newer grub2 and kernel signatures. In such cases, systems with Secure Boot enabled will fail to start the updated boot chain.

Microsoft will no longer use the current Secure Boot signing key after June 2026. However, shim binaries that are signed only with the Microsoft Windows UEFI Driver Publisher (2011) key continue to boot after June 2026, provided that the corresponding 2011 certificate remains enrolled in firmware. The RHEL 10.2 shim binaries are also signed with the Microsoft UEFI CA 2023 certificate and the Red Hat UEFI Publisher 2024 key, which enables them to work with updated Secure Boot trust configurations.

When planning upgrades to RHEL 10.2 on systems with Secure Boot enabled, perform all of the following actions:

Failure to meet these conditions might cause RHEL 10.2 systems to fail to boot under Secure Boot and might require firmware configuration changes or rework of the Secure Boot chain of trust before deployment.