17.3. カーネルの主な変更点
64k ページサイズのカーネル
4k ページをサポートする RHEL 9 for ARM カーネルに加えて、Red Hat は 64k ページをサポートするオプションのカーネルパッケージ kernel-64k を提供するようになりました。
64k ページサイズのカーネルは、ARM プラットフォーム上の大規模なデータセットに便利なオプションです。これにより、メモリーや CPU を大量に消費する一部の操作のパフォーマンスが向上します。
64 ビット ARM アーキテクチャーシステムでは、インストール時にページサイズを選択する必要があります。kernel-64k パッケージを Kickstart ファイルのパッケージリストに追加すると、Kickstart のみで kernel-64k をインストールできます。
kernel-64k のインストールの詳細は、ARM への Kernel-64k のインストール を参照してください。
RHEL 9 では、TPM 1.2 セキュア暗号プロセッサーはサポートされなくなりました。
TPM (Trusted Platform Module) セキュア暗号プロセッサーバージョン 1.2 が削除され、RHEL 9 以降のバージョンではサポートされなくなりました。TPM 2.0 は、TPM 1.2 に代わるもので、TPM 1.2 よりも改善されています。TPM 2.0 は以前のバージョンとは互換性がありません。
TPM 1.2 のサポートを必要とするアプリケーションの場合は、RHEL 8 を使用してください。
tpm2-tools および関連する TPM 2.0 コンポーネントを更新しました。
Red Hat Enterprise Linux 9 では、Trusted Platform Module (TPM) 2.0 ツールが、最新のハードウェア要件とセキュリティー対策に合わせて進化を続けています。Lenovo 64 ビット x86 プラットフォームで Red Hat Enterprise Linux 8 から Red Hat Enterprise Linux 9 へのアップグレードを計画する際は、tpm2-tools パッケージおよび関連する TPM ベースのワークフローへの依存関係を確認してください。
デプロイメントでセキュアブートの測定、シールキーの保存、アテステーション、またはプラットフォームの整合性チェックに TPM 2.0 を使用している場合は、自動化、スクリプト、および運用手順が Red Hat Enterprise Linux 9 に含まれる TPM ツールと互換性があることを確認してください。特に、大規模展開の前に、コマンドラインオプション、出力形式、プロビジョニングパイプラインやコンプライアンスパイプラインとの統合などの動作を検証してください。これにより、TPM(サードパーティープラットフォーム管理) による信頼性をプラットフォームの完全性とコンプライアンスストラテジーの重要な要素として捉えている環境において、予期せぬリグレッションが発生するリスクが軽減されます。
Venice プラットフォーム向け AMD CCP ドライバーのサポート変更
AMD Venice ベースのシステムでは、Red Hat Enterprise Linux 9.8 の AMD 暗号化コプロセッサー (CCP) ドライバーが更新され、追加の Venice PCI デバイス ID を認識するようになりました。その結果、これらのシステム上の CCP ハードウェアは、カーネルによって正しく検出され、初期化されるようになった。
この変更は、Venice プラットフォーム上で暗号化アクセラレーションに CCP エンジンを使用する環境 (たとえば、IPsec や dm-crypt ワークロード) に影響を与える可能性があります。
- これまで Venice ハードウェア上で CCP ベースのアクセラレーションを公開していなかったシステムでも、Red Hat Enterprise Linux 9.8 にアップグレードすると、暗号化ワークロードのパフォーマンス特性が変化する可能性があるため、この機能が利用できるようになる可能性があります。
- 暗号化処理の一部が CCP デバイスにオフロードされるようになったため、監視ツールや容量計画ツールによって CPU 使用率のプロファイルが異なる場合があります。
特定のパフォーマンス基準、ハードウェアオフロード動作、または FIPS 準拠の暗号化設定に依存している場合は、Venice ベースのシステムを Red Hat Enterprise Linux 9.8 にアップグレードした後、ワークロードのパフォーマンスとセキュリティーポリシーを見直して検証してください。
Wildcat Lake プラットフォームにおける Intel In-Memory Analytics Accelerator のサポート
Intel Wildcat Lake プラットフォームをベースとしたシステムにおいて、Red Hat Enterprise Linux 9 は、Intel In-Memory Analytics Accelerator (IAA) デバイスの PCI デバイス ID を認識するようになりました。従来、これらの IAA デバイスは正しく検出されず、オペレーティングシステムで使用できない可能性がありました。
その結果、IAA ハードウェアを搭載したサポート対象の Wildcat Lake システムで Red Hat Enterprise Linux 9 を実行すると、カーネルが圧縮や分析オフロードなどのサポート対象ワークロード向けにアクセラレーターデバイスを検出して公開できるようになります。
Wildcat Lake システムで Red Hat Enterprise Linux 9 にアップグレードした後、これらのアクセラレーターを使用するには:
- システムファームウェアと BIOS がベンダー推奨バージョンに更新されていること、およびファームウェア設定でアクセラレーター機能が有効になっていることを確認してください。
- Wildcat Lake プラットフォームに、Intel IAA をサポートする Red Hat Enterprise Linux 9 カーネルおよび関連パッケージをインストールします。
- ご使用のハードウェアベンダーのドキュメントおよび Red Hat Enterprise Linux のハードウェア有効化に関するドキュメントに従って、環境におけるアクセラレーターの使用状況を設定および検証してください。
Intel DMR CPU 向け Intel QuickAssist Technology (QAT) ドライバーのアップデート
Red Hat Enterprise Linux 9.8 では、Intel QuickAssist Technology (QAT) カーネルドライバーが、アップストリームの 6.18 をベースとしたバージョンに更新されています。このアップデートにより、最新の Intel Data Center Max Raise (DMR) ファミリー CPU における QAT の高速化が可能になり、サポートされているすべての QAT デバイスに適用されるバグ修正が含まれています。
これらの変更により、記載されているプロセッサーを搭載したシステムにおけるハードウェアアクセラレーションによる暗号化およびデータ圧縮のパフォーマンスが向上する可能性があります。このドライバーには複数の機能修正が含まれているため、既存のプラットフォームにおける QAT の動作は、以前の Red Hat Enterprise Linux 9 のマイナーリリースと比較して変更される可能性があります。
Intel QAT を使用しているシステムで Red Hat Enterprise Linux 9.8 へのアップグレードを計画する場合:
- アップグレード後、カーネルが QAT デバイスを認識し、QAT ベースのワークロードが正常に完了することを確認してください。
- QAT アクセラレーションに依存する、パフォーマンスに敏感な暗号化および圧縮ワークロードを再評価します。
- QAT デバイスまたはドライバー情報を報告する監視ツールやトラブルシューティングツールを確認してください。識別子やバージョン情報は、以前の Red Hat Enterprise Linux 9 リリースと異なる可能性があります。
RHEL 9 では、デフォルトで有効になっている cgroup-v2
コントロールグループバージョン 2 (cgroup-v2) 機能は、制御グループの管理を簡素化する 1 つの階層モデルを実装します。また、プロセスが、一度に 1 つのコントロールグループのメンバーにのみなれるようにします。systemd との深い統合により、RHEL システムでリソース制御を設定する際のエンドユーザーエクスペリエンスが改善されます。
新機能の開発は、主に cgroup-v2 向けに行われます。これには、cgroup-v1 に欠けている機能がいくつかあります。同様に、cgroup-v1 には、cgroup-v2 に欠けている従来の機能がいくつか含まれています。また、制御インターフェイスも異なります。したがって、cgroup-v1 に直接依存するサードパーティーソフトウェアは、cgroup-v2 では適切に実行されない可能性があります。
cgroup-v1 を使用するには、以下のパラメーターをカーネルコマンドラインに追加する必要があります。
systemd.unified_cgroup_hierarchy=0
systemd.legacy_systemd_cgroup_controller
cgroup-v1 と cgroup-v2 の両方がカーネルで完全に有効になっている。カーネルから見た場合、デフォルトのコントロールグループバージョンはありません。また、システムの起動時にマウントするかどうかは、systemd により決定します。
サードパーティーのカーネルモジュールに影響を与える可能性のあるカーネル変更
5.9 以前のカーネルバージョンを持つ Linux ディストリビューションは、GPL 以外の機能としての GPL 機能のエクスポートに対応していました。これにより、ユーザーは shim メカニズムを介して、独自の機能を GPL カーネル機能にリンクできます。今回のリリースで、RHEL カーネルにアップストリームの変更が組み込まれました。これにより、RHEL の機能が強化され、shim の再バフィングにより GPL が適用されるようになりました。
パートナーおよび独立したソフトウェアベンダー (ISV) は、初期バージョンの RHEL 9 でカーネルモジュールをテストして、GPL への準拠を確認する必要があります。
コアスケジューリングは RHEL 9 でサポートされている
コアスケジューリング機能を使用すると、相互に信頼できないタスクが同じ CPU コアを共有するのを防ぐことができます。同様に、ユーザーは CPU コアを共有できるタスクのグループを定義できます。
以下のグループを指定できます。
- SMT (Cross-Symmetric Multithreading) 攻撃を軽減することでセキュリティーを改善するには、以下の手順を行います。
- コア全体を必要とするタスクを分離するには、以下を行います。たとえば、リアルタイム環境のタスク、または SIMD (Multiple Data) 処理や Single Instruction などの特定のプロセッサー機能に依存するタスクなど。
詳細は コアスケジューリング を参照してください。
perf はlibbpf に静的にリンクするようになりました
Red Hat Enterprise Linux 9 では、perf プロファイリングツールは、libbpf ランタイムパッケージの libbpf 共有ライブラリーを使用する代わりに、カーネルソースツリーに含まれる libbpf ライブラリーに静的にリンクするようになりました。
この変更により、次の利点が得られます。
-
perf は常に、対応するカーネルビルドとともにテストされたバージョンのlibbpfを使用します。 -
perfに必要なlibbpfの API および ABI の変更は、対応するlibbpfパッケージの更新を必要とせずに、単一のカーネル更新で提供できます。 -
カーネルソース RPM が再構築されると、
perf も対応するインツリーlibbpfコードを使用して再構築されます。
ほとんどのユーザーにとって、この変更は意識することなく行われ、手動での操作は必要ありません。既存の perf ワークフローとコマンドラインオプションは、これまで通り引き続き動作します。
ただし、トラブルシューティングや特定のパッケージバージョンに対する動作検証などのために、perf バイナリーがシステムの libbpf 共有ライブラリーに動的にリンクすることに依存している場合、libbpf ランタイムパッケージのみを更新しても perf の 動作は変更されなくなります。このような場合は、目的の libbpf バージョンが組み込まれたカーネルビルドに含まれる perf ツールを使用する必要があります。
kernelopts 環境変数は RHEL 9 で削除された
RHEL 8 では、GRUB ブートローダーを使用するシステムのカーネルコマンドラインパラメーターが kernelopts 環境変数で定義されていました。変数は、カーネルブートエントリーごとに /boot/grub2/grubenv ファイルに保存されました。ただし、kernelopts を使用してカーネルコマンドラインパラメーターを保存することは堅牢ではありませんでした。そのため、Red Hat は kernelopts を削除し、カーネルコマンドラインパラメーターは、/boot/loader/entries/<KERNEL_BOOT_ENTRY>.conf ファイルではなく、ブートローダー仕様 (BLS) スニペットに保存されるようになりました。
64 ビット x86 での LUKS 暗号化 kdump のサポート
Red Hat Enterprise Linux 9 では、LUKS 暗号化ブロックデバイスを使用するシステムにおいて、kdump 機能がパスフレーズを手動で入力することなく、クラッシュダンプを自動的に実行できるようになりました。従来、ルートファイルシステムまたは kdump ターゲットデバイスが LUKS 暗号化を使用している場合、管理者がコンソールでパスフレーズを入力するか、暗号化されていない別の kdump ターゲットを設定しない限り、クラッシュカーネルは暗号化されたデバイスにアクセスできませんでした。
Red Hat Enterprise Linux 9 では、実行中のカーネルが kexec を使用して kdump カーネルをロードする際に、LUKS ボリュームキーを kdump カーネルに渡すことができます。kdump ユーティリティーのアップデートと合わせて、この変更により以下のことが可能になります。
- LUKS 暗号化システムにおける無人クラッシュダンプ (ヘッドレス環境およびリモートデプロイメントを含む)
- サポートされている場合、ルートファイルシステムと kdump ターゲットの両方に同じ LUKS 暗号化デバイスを使用する
- 暗号化されたインストールと暗号化されていないインストールの間で、より一貫性のある動作を実現
この機能を使用するには、システムがこの変更を含む Red Hat Enterprise Linux 9 カーネルを実行していること、kdump が設定され有効になっていること、および kdump のターゲットデバイスがクラッシュカーネル環境からアクセス可能であることを確認してください。設定の詳細およびサポートされているシナリオについては、Red Hat Enterprise Linux 9 の kdump 設定に関するドキュメントを参照してください。
カーネルのライブパッチによってのみ修正された CVE を特定する
kpatch ツールは、実行中のカーネルに適用されたライブパッチによって解決された脆弱性のリストを報告できます。この報告書には、ディスク上のカーネルパッケージではなく、ライブパッチによってのみ対処される CVE(共通脆弱性識別子) が記載されています。その結果、セキュリティーおよびコンプライアンスチームは、uname によって報告されるカーネルバージョンが外部のアドバイザリーやスキャナーによると脆弱であるように見える場合でも、システムが保護されていることを検証できます。
この変更は、厳格な稼働時間要件に依存する環境、特に新しいカーネルへの再起動が遅延したり、複数のシステム間で調整されたりする環境において、特に重要です。Red Hat Enterprise Linux 9 では、どの CVE がライブパッチでカバーされているかが表示されるため、カーネルのライブパッチのステータスをセキュリティーレポート、リスク評価、自動スキャンワークフローに容易に統合できます。
Red Hat Enterprise Linux 8 から Red Hat Enterprise Linux 9 へのアップグレードを計画する際は、既存の脆弱性管理およびコンプライアンスプロセスでこの kpatch レポートをどのように活用できるかを確認してください。カーネルパッケージのバージョンに修正が含まれていない場合でも、一部の CVE は現在実行中のカーネルのライブパッチによってのみ修正されることを認識するために、内部ドキュメント、ダッシュボード、またはスキャナーの設定を更新する必要があるかもしれません。
Red Hat は、マイナーリリースに対してのみカーネルシンボルを保護します。
Red Hat は、保護されたカーネルシンボルを使用してカーネルモジュールをコンパイルする場合にのみ、カーネルモジュールが Extended Update Support (EUS) リリース内の将来のすべての更新でロードされ続けることを保証します。RHEL 9 のマイナーリリース間では、カーネルアプリケーションバイナリーインターフェイス (ABI) の保証はありません。
POSIX_FADV_NOREUSE アドバイスのサポートが削除されました
RHEL 9.5 より前は、カーネルは POSIX_FADV_NOREUSE のアドバイスを無視していました。RHEL 9.5 以降、このアドバイスに対するサポートが導入されました。しかし、このアドバイスを実装すると、MADV_RANDOM アドバイスを使用するアプリケーションのパフォーマンスに大きな影響を与えました。その結果、MADV_RANDOM の RHEL 9 における期待される動作を維持するため、POSIX_FADV_NOREUSE の実装が元に戻されました。
RHEL 9.6 以降、アプリケーションの動作は以下のとおり変更されています。
-
MADV_RANDOMを使用するアプリケーションは、以前のバージョンの RHEL と同様に正常に動作します。 -
POSIX_FADV_NOREUSEを使用するアプリケーションは機能的な変更を受けませんが、POSIX_FADV_NOREUSEはカーネルに実装されていません。
mce カーネルブートパラメーターは非推奨になりました
RHEL 9.3 では、アップストリームのリベースにより、mce カーネルブートパラメーターの動作が変更されました。そのため、許容レベル制御機能は非推奨となり、今後のメジャーリリースで削除される予定です。