第16章 カーネル

RHEL 10 では、sched_ext を使用して、Extended Berkeley Packet Filter (eBPF) でカスタムのプロセススケジューリングコードを実行時に作成できます。sched_ext スケジューラーを使用すると、標準のカーネルスケジューラーを独自のスケジューリングロジックに置き換えて、プロセスの優先度設定、リソースの割り当て、および実行動作を制御できます。

Red Hat はカスタムスケジューラーのサポートを提供していません。

Completely Fair Scheduler (CFS) は、新しいスケジューラーである Enhanced Earliest Deadline First (EEVDF) に置き換えられました。これには次の変更が含まれます。

CFS と EEVDF は、ほとんどの場合、ワークロードの面で同等の結果を提供します。ただし、各タスク選択のロジックが異なるため、パフォーマンスに若干の差が生じる可能性があります。

Red Hat Enterprise Linux 10 では、LUKS 暗号化ブロックデバイスを使用するシステムにおいて、パスフレーズを手動で入力することなく、kdump 機能がクラッシュダンプを自動的に実行できるようになりました。以前は、ルートファイルシステムまたは kdump ターゲットデバイスが LUKS 暗号化を使用している場合、管理者がコンソールでパスフレーズを入力するか、暗号化されていない別の kdump ターゲットを設定しない限り、クラッシュカーネルから暗号化されたデバイスにアクセスできませんでした。

Red Hat Enterprise Linux 10 では、実行中のカーネルが kexec を使用して kdump カーネルをロードする際に、LUKS ボリューム鍵を kdump カーネルに渡すことができます。kdump ユーティリティーの更新と合わせて、この変更により以下のことが可能になります。

この機能を使用するには、この変更が組み込まれた Red Hat Enterprise Linux 10 カーネルをシステムで実行していること、kdump が設定され有効になっていること、および kdump のターゲットデバイスがクラッシュカーネル環境からアクセス可能であることを確認してください。設定の詳細とサポートされているシナリオについては、Red Hat Enterprise Linux 10 の kdump ドキュメント を参照してください。

kpatch ツールでは、実行中のカーネルに適用されたライブパッチによって修正されている脆弱性のリストをレポートできます。このレポートは、ディスク上のカーネルパッケージによってではなく、ライブパッチによってのみ修正された CVE に焦点を当てたものです。そのため、外部のアドバイザリーやスキャナーによると、uname が報告するカーネルバージョンが脆弱であるように見える場合でも、セキュリティーおよびコンプライアンスチームはシステムが保護されていることを検証できます。

この変更は、厳格な稼働時間要件に依存する環境、特に新しいカーネルへの再起動が遅延したり、複数のシステム間で調整されたりする環境では、特に重要です。Red Hat Enterprise Linux 10 では、ライブパッチで対応済みの CVE が明らかです。そのため、カーネルのライブパッチのステータスを、セキュリティーレポート、リスク評価、および自動スキャンワークフローに容易に統合できます。

RHEL 9 から Red Hat Enterprise Linux 10 へのアップグレードを計画する際には、既存の脆弱性管理およびコンプライアンスプロセスで、この kpatch レポートをどのように活用できるかを検討してください。カーネルパッケージのバージョンにまだ修正が含まれていなくても、現在実行中のカーネルに適用されたライブパッチによってのみ修正された CVE があることを認識できるように、内部のドキュメント、ダッシュボード、またはスキャナーの設定を更新する必要がある可能性があります。

カーネルライブパッチビルドツール (klp-build) が、Red Hat Enterprise Linux 10 で利用可能になりました。これは、入力されたカーネルパッチからライブパッチを生成するために使用されます。この変更の一環として、カーネルビルドシステムが、カーネルモジュールをビルドする際に、追加の objtool 処理を使用するようになりました。

これらの変更により、カーネルモジュールがゼロ以外のセクションロードアドレスを持つことができるようになりました (たとえば、.text および関連セクションの sh_addr 値がゼロ以外になります)。これは、以前の Red Hat Enterprise Linux リリースとは異なります。以前のリリースでは、多くのツールが、カーネルモジュールセクションがアドレス 0 から始まることを前提としていました。

この変更の影響を受ける可能性があるのは、カーネルモジュールの ELF メタデータを直接解析するデバッグツールやトレースツール (elfutils や SystemTap に基づくツールなど) のうち、以前のゼロベースのセクションアドレスレイアウトに依存しているものです。予想外の障害や誤ったシンボル解決を避けるために、以下を実行してください。

ライブパッチ適用ワークフローやカーネルモジュールを処理するカスタムツールに依存している場合は、以前のバージョンの Red Hat Enterprise Linux から実稼働システムをアップグレードする前に、Red Hat Enterprise Linux 10 でシナリオをテストしてください。

Red Hat Enterprise Linux 10.2 では、ユーザー空間の perf ツールが、アップストリームの Linux 6.17 の perf コードベースと同期されました。この変更は、Red Hat Enterprise Linux システムで、パフォーマンス分析、プロファイリング、およびハードウェアイベントサンプリングに perf を使用するシステム管理者と開発者に影響します。

このリベースにより、最新の Intel アンコア PMU、新しい IBM Z CPU-MF カウンター、および Fujitsu Monaka などのベンダー固有のプラットフォームを含む、複数のハードウェアプラットフォームにわたる新規および更新された Performance Monitoring Unit (PMU) イベントがサポートされるようになります。そのため、perf で利用可能な一連のイベント、メトリクス、およびレポートオプションは、以前の Red Hat Enterprise Linux のメジャーバージョンとは異なる場合があります。

これらの変更により、既存の perf ワークフローの一部に調整が必要になる可能性があります。

Red Hat Enterprise Linux 10.2 にアップグレードする前に、非実稼働環境で perf ベースのツールとスクリプトを確認し、テストしてください。アップグレード後、perf list コマンドと perf help コマンドを使用して、利用可能なイベントとメトリクスを確認し、古いイベント名や動作に依存する自動化を更新してください。

Red Hat Enterprise Linux 10.2 では、perf ユーザー空間ツールが、アップストリームの Linux 6.18 バージョンにリベースされました。このリベースにより、Red Hat Enterprise Linux のパフォーマンスモニタリングスタックが、より新しいハードウェアサポートおよびアップストリームの動作と整合したものになります。

Red Hat Enterprise Linux 10.2 にアップグレードする際は、以下の変更点にご注意ください。

perf に依存するパフォーマンス重視の環境や CI ジョブをアップグレードする前に、Red Hat Enterprise Linux 10.2 上で既存のワークフローを kernel-6.12.0-177.el10 ビルドを使用してテストし、主要な測定値のベースラインを再設定してください。イベントやメトリクスの定義が更新されたことにより、結果の出力方法に影響が及ぶ可能性があるためです。

Red Hat Enterprise Linux 10 では、perf プロファイリングツールは、libbpf ランタイムパッケージの libbpf 共有ライブラリーを使用する代わりに、カーネルソースツリーに含まれる libbpf ライブラリーに静的にリンクするようになりました。

この変更により、次の利点が得られます。

ほとんどのユーザーにとって、この変更は透過的に行われ、手動での操作は必要ありません。既存の perf ワークフローとコマンドラインオプションは、これまでどおり引き続き動作します。

ただし、たとえばトラブルシューティングや、特定の libbpf パッケージバージョンでの動作を検証する目的などで、perf バイナリーがシステムの libbpf 共有ライブラリーに動的リンクする仕組みに依存していた場合、今後は libbpf ランタイムパッケージを更新するだけでは perf の libbpf に関する動作を変更できなくなります。このような場合は、目的の libbpf バージョンが組み込まれたカーネルビルドに含まれる perf ツールを使用する必要があります。

Red Hat Enterprise Linux 10 では、Berkeley Packet Filter (BPF) サブシステムが、アップストリームの Linux カーネル 6.17 レベルにリベースされました。今回のアップデートにより、新しい BPF 機能、ベリファイアー、およびパフォーマンスの改善が追加されました。これにより、以前の Red Hat Enterprise Linux メジャーバージョンからアップグレードした後、既存の BPF プログラムやツールの動作が変わる可能性があります。

6.17 への BPF のリベースにより、以前の Red Hat Enterprise Linux リリースと比較して、以下が導入されています。

Red Hat Enterprise Linux 10 にアップグレードすると、以下のことが起きる可能性があります。

アップグレードを行う前に、既存の BPF プログラムとワークフローを非実稼働環境の Red Hat Enterprise Linux 10 システムでテストしてください。また、Red Hat Enterprise Linux 10 のツールチェーンとカーネルヘッダーに合わせて BPF ユーザー空間コンポーネントを再ビルドしてください。

AMD Venice ベースのシステムでは、Red Hat Enterprise Linux 10.2 の AMD Cryptographic Co-processor (CCP) ドライバーが更新され、追加の Venice PCI デバイス ID を認識するようになりました。その結果、これらのシステムの CCP ハードウェアが、カーネルによって正しく検出され、初期化されるようになりました。

この変更は、Venice プラットフォーム上で暗号化アクセラレーションに CCP エンジンを使用する環境 (たとえば、IPsec や dm-crypt ワークロード) に、次のような影響を与える可能性があります。

特定のパフォーマンス基準、ハードウェアオフロード動作、または FIPS 準拠の暗号化設定に依存している場合は、Venice ベースのシステムを Red Hat Enterprise Linux 10.2 にアップグレードした後、ワークロードのパフォーマンスとセキュリティーポリシーを見直して検証してください。

Intel Wildcat Lake プラットフォームをベースとしたシステムでは、Red Hat Enterprise Linux 10 は、Intel In-Memory Analytics Accelerator (IAA) デバイスの PCI デバイス ID を認識するようになりました。以前は、これらの IAA デバイスは正しく検出されず、オペレーティングシステムで使用できない場合がありました。

その結果、IAA ハードウェアを搭載したサポート対象の Wildcat Lake システムで Red Hat Enterprise Linux 10 を実行すると、圧縮や分析オフロードなどのサポートされているワークロード向けに、カーネルがアクセラレーターデバイスを検出して公開できるようになりました。

Wildcat Lake システムで Red Hat Enterprise Linux 10 にアップグレードした後、このアクセラレーターを使用するには、以下を実行してください。

Red Hat Enterprise Linux 10.2 では、Intel QuickAssist Technology (QAT) カーネルドライバーが、アップストリームの 6.18 をベースとしたバージョンに更新されました。この更新により、最新の Intel DMR ファミリーの CPU で QAT アクセラレーションが可能になります。また、この更新には、サポートされているすべての QAT デバイスに適用されるバグ修正が含まれています。

これらの変更により、記載されているプロセッサーを搭載したシステムで、ハードウェアアクセラレーションによる暗号化およびデータ圧縮のパフォーマンスが向上する可能性があります。このドライバーには複数の機能修正が含まれています。そのため、既存のプラットフォームにおける QAT の動作が、以前の Red Hat Enterprise Linux 10 のマイナーリリースと比較して変わる可能性があります。

Intel QAT を使用しているシステムで Red Hat Enterprise Linux 10.2 へのアップグレードを計画する場合は、以下を実行してください。

Red Hat Enterprise Linux 10 では、Trusted Platform Module (TPM) 2.0 ツールが、最新のハードウェア要件とセキュリティープラクティスに合わせて進化を続けています。Lenovo の 64 ビット x86 プラットフォームで RHEL 9 から RHEL 10 へのアップグレードを計画する際は、tpm2-tools パッケージおよび関連する TPM ベースのワークフローへの依存関係を確認してください。

自社の環境で、セキュアブートの測定、シールされた鍵の保管、アテステーション、またはプラットフォームの完全性チェックのために TPM 2.0 を利用している場合は、自動化、スクリプト、および運用手順が、RHEL 10 に含まれる TPM ツールと引き続き互換性を保っていることを検証してください。特に、大規模なロールアウトの前には、コマンドラインオプション、出力形式、プロビジョニングパイプラインやコンプライアンスパイプラインとの統合などの動作を検証してください。これにより、TPM を基盤とする信頼を、プラットフォームの完全性およびコンプライアンス戦略の重要な要素とみなしている環境で、想定外のリグレッションが発生するリスクが軽減されます。