カーネルの管理、監視、および更新

手順

1. パッケージの利用可能なバージョンをリスト表示します。

   $ dnf repoquery <package_name>

   たとえば、kernel-core パッケージの利用可能なバージョンをリスト表示します。

   $ dnf repoquery kernel-core
   kernel-core-0:5.14.0-162.12.1.el9_1.x86_64
   kernel-core-0:5.14.0-162.18.1.el9_1.x86_64
   kernel-core-0:5.14.0-162.22.2.el9_1.x86_64
   kernel-core-0:5.14.0-162.23.1.el9_1.x86_64
   ...

2. パッケージ内のファイルをリスト表示します。

   $ dnf repoquery -l <package_name>

   たとえば、kernel-core-0:5.14.0-162.23.1.el9_1.x86_64 パッケージ内のファイルをリスト表示します。

   $ dnf repoquery -l kernel-core-0:5.14.0-162.23.1.el9_1.x86_64
   /boot/System.map-5.14.0-162.23.1.el9_1.x86_64
   /boot/config-5.14.0-162.23.1.el9_1.x86_64
   /boot/initramfs-5.14.0-162.23.1.el9_1.x86_64.img
   /boot/symvers-5.14.0-162.23.1.el9_1.x86_64.gz
   /boot/vmlinuz-5.14.0-162.23.1.el9_1.x86_64
   /lib/modules
   /lib/modules/5.14.0-162.23.1.el9_1.x86_64
   /lib/modules/5.14.0-162.23.1.el9_1.x86_64/.vmlinuz.hmac
   /lib/modules/5.14.0-162.23.1.el9_1.x86_64/System.map
   ...

手順

1. カーネルを更新するには、次のコマンドを入力します。

   # dnf update kernel

   このコマンドは、カーネルと、利用可能な最新バージョンへのすべての依存関係を更新します。

2. システムを再起動して、変更を有効にします。

手順

1. 読み込むカーネルモジュールを選択します。

   モジュールは /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ ディレクトリーにあります。

2. 関連するカーネルモジュールを読み込みます。

   # modprobe <MODULE_NAME>

   注記

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

手順

1. ロード済みの全カーネルモジュールをリスト表示します。

   # lsmod

2. アンロードするカーネルモジュールを選択します。

   カーネルモジュールに依存関係がある場合は、カーネルモジュールをアンロードする前に、これらをアンロードします。依存関係のあるモジュールを特定する方法は、Listing currently loaded kernel modules および Kernel module dependencies を参照してください。

3. 関連するカーネルモジュールをアンロードします。

   # modprobe -r <MODULE_NAME>

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

手順

1. システムをブートローダーで起動します。
2. カーソルキーを使用して、関連するブートローダーエントリーを強調表示します。

3. e キーを押してエントリーを編集します。

   図3.1 カーネルブートメニュー

   
4. カーソルキーを使用して、linux で始まる行に移動します。

5. modprobe.blacklist=module_name を行末に追加します。

   図3.2 カーネルブートエントリー

   

   serio_raw カーネルモジュールは、起動プロセスの初期段階でアンロードする不正なモジュールを示しています。

6. Ctrl+X を押して、変更した設定を使用して起動します。

手順

1. 起動プロセス中に読み込むカーネルモジュールを選択します。

   モジュールは /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/ ディレクトリーにあります。

2. モジュールの設定ファイルを作成します。

   # echo <MODULE_NAME> > /etc/modules-load.d/<MODULE_NAME>.conf

   注記

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

検証

1. 再起動後、関連するモジュールがロードされたことを確認します。

   $ lsmod | grep <MODULE_NAME>

   上記のコマンド例は成功し、関連するカーネルモジュールを表示します。

手順

1. lsmod コマンドを使用して、現在実行中のカーネルに読み込まれているモジュールを一覧表示します。

   $ lsmod
   Module                  Size  Used by
   tls                   131072  0
   uinput                 20480  1
   snd_seq_dummy          16384  0
   snd_hrtimer            16384  1
   …

   出力で、読み込みを阻止するモジュールを特定します。

   • または、/lib/modules/<KERNEL-VERSION>/kernel/<SUBSYSTEM>/ ディレクトリーに読み込まれないようにするアンロードしたカーネルモジュールを特定します。以下に例を示します。

     $ ls /lib/modules/4.18.0-477.20.1.el8_8.x86_64/kernel/crypto/
     ansi_cprng.ko.xz        chacha20poly1305.ko.xz  md4.ko.xz               serpent_generic.ko.xz
     anubis.ko.xz            cmac.ko.xz…

2. 拒否リストとして機能する設定ファイルを作成します。

   # touch /etc/modprobe.d/denylist.conf

3. 任意のテキストエディターで、カーネルへの自動読み込みから除外するモジュール名を blacklist 設定コマンドと組み合わせます。以下に例を示します。

   # Prevents <KERNEL-MODULE-1> from being loaded
   blacklist <MODULE-NAME-1>
   install <MODULE-NAME-1> /bin/false
   
   # Prevents <KERNEL-MODULE-2> from being loaded
   blacklist <MODULE-NAME-2>
   install <MODULE-NAME-2> /bin/false
   …

   blacklist コマンドは、モジュールが、拒否リストにない別のカーネルモジュールの依存関係として読み込まれることを阻止しないため、install 行も定義する必要があります。この場合、システムはモジュールをインストールする代わりに /bin/false を実行します。ハッシュ記号で始まる行は、ファイルをより読みやすくするために使用可能なコメントです。

   注記

   カーネルモジュールの名前を入力する際には、.ko.xz 拡張子は名前の末尾に追加しないでください。カーネルモジュール名には拡張子はありません。ただし、対応するファイルには拡張子があります。

4. 再構築を行う前に、現在の初期 RAM ディスクイメージのバックアップコピーを作成します。

   # cp /boot/initramfs-$(uname -r).img /boot/initramfs-$(uname -r).bak.$(date +%m-%d-%H%M%S).img

   • または、カーネルモジュールの自動読み込みを阻止するカーネルバージョンに対応する初期 RAM ディスクイメージのバックアップコピーを作成します。

     # cp /boot/initramfs-<VERSION>.img /boot/initramfs-<VERSION>.img.bak.$(date +%m-%d-%H%M%S)

5. 新しい初期 RAM ディスクイメージを生成して、変更を適用します。

   # dracut -f -v

   • システムで現在使用中のものとは異なるカーネルバージョンの初期 RAM ディスクイメージを構築する場合は、ターゲット initramfs とカーネルバージョンの両方を指定します。

     # dracut -f -v /boot/initramfs-<TARGET-VERSION>.img <CORRESPONDING-TARGET-KERNEL-VERSION>

6. システムを再起動します。

   $ reboot

手順

1. 以下の内容で /root/testmodule/test.c を作成します。

   #include <linux/module.h>
   #include <linux/kernel.h>
   
   int init_module(void)
       { printk("Hello World\n This is a test\n"); return 0; }
   
   void cleanup_module(void)
       { printk("Good Bye World"); }
   
   MODULE_LICENSE("GPL");

   test.c ファイルは、カーネルモジュールに主な機能を提供するソースファイルです。このファイルは、組織的な目的で、専用の /root/testmodule/ ディレクトリーに作成されています。モジュールをコンパイルすると、/root/testmodule/ ディレクトリーには複数のファイルが含まれます。

   test.c ファイルには、システムライブラリーから次のものが含まれます。

   • サンプルコードの printk() 機能には、linux/kernel.h ヘッダーファイルが必要です。
   • linux/module.h ファイルには、C 言語で記述した複数のソースファイルで共有する関数宣言とマクロ定義が含まれています。
2. 次に、init_module() 関数および cleanup_module() 関数に従い、テキストを出力するカーネルロギング機能 printk() を起動および終了します。

3. 以下の内容で /root/testmodule/Makefile を作成します。

   obj-m := test.o

   Makefile には、コンパイラーが、test.o という名前のオブジェクトファイルを作成する必要がある指示が含まれています。obj-m ディレクティブは、生成される test.ko ファイルを、読み込み可能なカーネルモジュールとしてコンパイルすることを指定します。もしくは、obj-y ディレクティブは、組み込みカーネルモジュールとして test.ko をビルドするように指示します。

4. カーネルモジュールをコンパイルします。

   # make -C /lib/modules/$(uname -r)/build M=/root/testmodule modules
   make: Entering directory '/usr/src/kernels/5.14.0-70.17.1.el9_0.x86_64'
     CC [M]  /root/testmodule/test.o
     MODPOST /root/testmodule/Module.symvers
     CC [M]  /root/testmodule/test.mod.o
     LD [M]  /root/testmodule/test.ko
     BTF [M] /root/testmodule/test.ko
   Skipping BTF generation for /root/testmodule/test.ko due to unavailability of vmlinux
   make: Leaving directory '/usr/src/kernels/5.14.0-70.17.1.el9_0.x86_64'

   コンパイラーは、各ソースファイル (test.c) のオブジェクトファイル (test.o) を中間手順として作成してから、それらを最終カーネルモジュール (test.ko) にリンクします。

   コンパイルが成功すると、/root/testmodule/ には、コンパイル済みカスタムカーネルモジュールに関連する追加ファイルが含まれます。コンパイル済みモジュール自身は、test.ko ファイルで表されます。

検証

1. 必要に応じて、/root/testmodule/ ディレクトリーのコンテンツを確認します。

   # ls -l /root/testmodule/
   total 152
   -rw-r—​r--. 1 root root    16 Jul 26 08:19 Makefile
   -rw-r—​r--. 1 root root    25 Jul 26 08:20 modules.order
   -rw-r—​r--. 1 root root     0 Jul 26 08:20 Module.symvers
   -rw-r—​r--. 1 root root   224 Jul 26 08:18 test.c
   -rw-r—​r--. 1 root root 62176 Jul 26 08:20 test.ko
   -rw-r—​r--. 1 root root    25 Jul 26 08:20 test.mod
   -rw-r—​r--. 1 root root   849 Jul 26 08:20 test.mod.c
   -rw-r—​r--. 1 root root 50936 Jul 26 08:20 test.mod.o
   -rw-r—​r--. 1 root root 12912 Jul 26 08:20 test.o

2. カーネルモジュールを /lib/modules/$(uname -r)/ ディレクトリーにコピーします。

   # cp /root/testmodule/test.ko /lib/modules/$(uname -r)/

3. モジュールの依存関係のリストを更新します。

   # depmod -a

4. カーネルモジュールを読み込みます。

   # modprobe -v test
   insmod /lib/modules/5.14.0-1.el9.x86_64/test.ko

5. カーネルモジュールが正常に読み込まれたことを確認します。

   # lsmod | grep test
   test                   16384  0

6. カーネルリングバッファーから最新のメッセージを読み込みます。

   # dmesg
   [74422.545004] Hello World
                   This is a test

手順

1. GRUB 2 ブートメニューを起動します。
2. 起動するカーネルを選択します。
3. e キーを押してカーネルパラメーターを編集します。
4. カーソルを下に移動してカーネルコマンドラインを見つけます。カーネルコマンドラインは、64 ビット IBM Power シリーズおよび x86-64 BIOS ベースのシステムの場合は linux で始まり、UEFI システムの場合は linuxefi で始まります。

5. カーソルを行の最後に移動します。

   注記

   行の最初に移動するには Ctrl+a を押します。行の最後に移動するには Ctrl+e を押します。システムによっては、Home キーおよび End キーも機能する場合があります。

6. 必要に応じてカーネルパラメーターを編集します。たとえば、緊急モードでシステムを実行するには、linux 行の最後に emergency パラメーターを追加します。

   linux   ($root)/vmlinuz-5.14.0-63.el9.x86_64 root=/dev/mapper/rhel-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet emergency

   システムメッセージを有効にするには、rhgb および quiet パラメーターを削除します。

7. Ctrl+x を押して、選択したカーネルと変更したコマンドラインパラメーターで起動します。

手順

1. /etc/default/grub ファイルに以下の 2 つの行を追加します。

   GRUB_TERMINAL="serial"
   GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1"

   最初の行は、グラフィカルターミナルを無効にします。GRUB_TERMINAL キーは、GRUB_TERMINAL_INPUT および GRUB_TERMINAL_OUTPUT の値を上書きします。

   2 行目は、ボーレート (--speed)、パリティー、および他の値を使用中の環境とハードウェアに適合するように調整します。以下のログファイルのようなタスクには、115200 のように非常に高いボーレートが推奨されます。

2. GRUB 設定ファイルを更新します。

   • BIOS ベースのマシンの場合:

     # grub2-mkconfig -o /boot/grub2/grub.cfg

   • UEFI ベースのマシンの場合:

     # grub2-mkconfig -o /boot/grub2/grub.cfg

3. システムを再起動して、変更を有効にします。

手順

1. grubby を使用して、インストール後のスクリプトで個々のカーネルのカーネルパラメーターを追加または削除します。

   # grubby --update-kernel <PATH_TO_KERNEL> --args "<NEW_ARGUMENTS>"

   たとえば、選択したカーネルに noapic パラメーターを追加します。

   # grubby --update-kernel /boot/vmlinuz-5.14.0-362.8.1.el9_3.x86_64 --args "noapic"

   パラメーターは BLS スニペットには伝播しますが、/etc/default/grub ファイルには伝播しません。

2. /etc/default/grub ファイルに存在する GRUB_CMDLINE_LINUX 値の内容で BLS スニペットを上書きします。

   # grub2-mkconfig -o /boot/grub2/grub.cfg --update-bls-cmdline
   Generating grub configuration file …​
   Adding boot menu entry for UEFI Firmware Settings …​
   done

   注記

   GRUB_TIMEOUT キー (/etc/default/grub GRUB 設定ファイルにも含まれています) に加えられた変更など、その他の変更は、デフォルトで新しい grub.cfg に伝搬します。

検証

1. オペレーティングシステムを再起動します。

2. パラメーターが /proc/cmdline ファイルに含まれていることを確認します。

   たとえば、/proc/cmdline には、noapic カーネルパラメーターが含まれています。

   BOOT_IMAGE=(hd0,gpt2)/vmlinuz-4.18.0-425.3.1.el8.x86_64 root=/dev/mapper/RHELCSB-Root ro vconsole.keymap=us crashkernel=auto rd.lvm.lv=RHELCSB/Root rd.luks.uuid=luks-d8a28c4c-96aa-4319-be26-96896272151d rhgb quiet noapic rd.luks.key=d8a28c4c-96aa-4319-be26-96896272151d=/keyfile:UUID=c47d962e-4be8-41d6-8216-8cf7a0d3b911 ipv6.disable=1

手順

1. すべてのパラメーターとその値をリストします。

   # sysctl -a

   注記

   # sysctl -a コマンドは、ランタイム時およびシステムの起動時に調整できるカーネルパラメーターを表示します。

2. パラメーターを一時的に設定するには、次のように入力します。

   # sysctl <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

   上記のサンプルコマンドは、システムの実行中にパラメーター値を変更します。この変更は、再起動なしですぐに適用されます。

   注記

   変更は、システムの再起動後にデフォルトに戻ります。

手順

1. すべてのパラメーターをリストします。

   # sysctl -a

   このコマンドは、ランタイム時に設定できるカーネルパラメーターをすべて表示します。

2. パラメーターを永続的に設定すします。

   # sysctl -w <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE> >> /etc/sysctl.conf

   サンプルコマンドは、調整可能な値を変更して、/etc/sysctl.conf ファイルに書き込みます。これにより、カーネルパラメーターのデフォルト値が上書きされます。変更は、再起動なしで即座に永続的に反映されます。

手順

1. /etc/sysctl.d/ に新しい設定ファイルを作成します。

   # vim /etc/sysctl.d/<some_file.conf>

2. カーネルパラメーターを 1 行に 1 つずつ含めます。

   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>
   <TUNABLE_CLASS>.<PARAMETER>=<TARGET_VALUE>

3. 設定ファイルを作成します。

4. マシンを再起動して、変更を有効にします。

   • また、再起動せずに変更を適用するには、以下を実行します。

     # sysctl -p /etc/sysctl.d/<some_file.conf>

     このコマンドにより、以前に作成した設定ファイルから値を読み取ることができます。

手順

1. 設定するカーネルパラメーターを特定します。

   # ls -l /proc/sys/<TUNABLE_CLASS>/

   コマンドが返した書き込み可能なファイルは、カーネルの設定に使用できます。読み取り専用権限を持つユーザーは、現在の設定についてフィードバックを提供します。

2. カーネルパラメーターにターゲットの値を割り当てます。

   # echo <TARGET_VALUE> > /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

   このコマンドでは、システムが再起動すると設定変更が消えます。

検証

1. 新しく設定したカーネルパラメーターの値を確認します。

   # cat /proc/sys/<TUNABLE_CLASS>/<PARAMETER>

手順

1. 次の内容を含む Playbook ファイル (例: ~/playbook.yml) を作成します。

   ---
   - name: Configure kernel settings
     hosts: managed-node-01.example.com
     roles:
       - rhel-system-roles.kernel_settings
     vars:
       kernel_settings_sysctl:
         - name: fs.file-max
           value: 400000
         - name: kernel.threads-max
           value: 65536
       kernel_settings_sysfs:
         - name: /sys/class/net/lo/mtu
           value: 65000
       kernel_settings_transparent_hugepages: madvise

   • name: 任意の文字列をラベルとしてプレイに関連付け、プレイの対象を特定するオプションのキー。
   • hosts: プレイを実行するホストを指定するプレイ内のキー。このキーの値または値は、マネージドホストの個別名または inventory ファイルで定義されているホストのグループとして指定できます。
   • vars: 選択したカーネルパラメーター名と、それらに対して設定する必要がある値を含む変数のリストを表す Playbook のセクション。

   • role: vars セクションで指定されたパラメーターと値を設定する RHEL システムロールを指定するキー。

     注記

     必要に応じて、Playbook のカーネルパラメーターとその値を変更することができます。

2. Playbook の構文を検証します。

   $ ansible-playbook --syntax-check ~/playbook.yml

   このコマンドは構文を検証するだけであり、有効だが不適切な設定から保護するものではないことに注意してください。

3. Playbook を実行します。

   $ ansible-playbook ~/playbook.yml

4. マネージドホストを再起動して、影響を受けるカーネルパラメーターをチェックし、変更が適用され、再起動後も維持されていることを確認します。

1. カーネルパッチモジュールは、/var/lib/kpatch/ ディレクトリーにコピーされ、次回の起動時に systemd を介して、カーネルへの再適用として登録されます。
2. 実行中のカーネルに kpatch モジュールがロードされ、新しいコードのメモリー内の場所を指定するポインターを使用して、新しい機能が ftrace メカニズムに登録されます。
3. パッチが当てられた機能にカーネルがアクセスすると、ftrace メカニズムにリダイレクトされます。これにより、元々の機能は回避され、パッチを当てたバージョンの機能にカーネルをリダイレクトします。

手順

1. オプション: カーネルのバージョンを確認します。

   # uname -r
   5.14.0-1.el9.x86_64

2. カーネルのバージョンに一致するライブパッチパッケージを検索します。

   # dnf search $(uname -r)

3. ライブパッチパッケージをインストールします。

   # dnf install "kpatch-patch = $(uname -r)"

   上記のコマンドでは、特定カーネルにのみに最新の累積パッチをインストールし、適用します。

   ライブパッチパッケージのバージョンが 1-1 以上である場合には、パッケージにパッチモジュールが含まれます。この場合、ライブパッチパッケージのインストール時に、カーネルにパッチが自動的に適用されます。

   カーネルパッチモジュールは、今後の再起動時に systemd システムおよびサービスマネージャーにより読み込まれる /var/lib/kpatch/ ディレクトリーにもインストールされます。

   注記

   指定のカーネルに利用可能なライブパッチがない場合は、空のライブパッチパッケージがインストールされます。空のライブパッチパッケージには、kpatch_version-kpatch_release 0-0 (例: kpatch-patch-5_14_0-1-0-0.x86_64.rpm) が含まれます。空の RPM のインストールを行うと、指定のカーネルの将来のすべてのライブパッチにシステムがサブスクライブされます。

手順

1. オプション: インストールされているすべてのカーネルと現在実行中のカーネルを確認します。

   # dnf list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64            5.14.0-1.el9              @beaker-BaseOS
   kernel-core.x86_64            5.14.0-2.el9              @@commandline
   ...
   
   # uname -r
   5.14.0-2.el9.x86_64

2. kpatch-dnf プラグインをインストールします。

   # dnf install kpatch-dnf

3. カーネルライブパッチの自動サブスクリプションを有効にします。

   # dnf kpatch auto
   Updating Subscription Management repositories.
   Last metadata expiration check: 1:38:21 ago on Fri 17 Sep 2021 07:29:53 AM EDT.
   Dependencies resolved.
   ==================================================
    Package                             Architecture
   ==================================================
   Installing:
    kpatch-patch-5_14_0-1               x86_64
    kpatch-patch-5_14_0-2               x86_64
   
   Transaction Summary
   ===================================================
   Install  2 Packages
   …​

   このコマンドは、現在インストールされているすべてのカーネルをサブスクライブして、カーネルライブパッチを受け取ります。このコマンドは、インストールされている全カーネルに、最新の累積パッチ (存在する場合) をインストールして適用します。

   今後、カーネルを更新すると、新しいカーネルのインストールプロセス中にライブパッチが自動的にインストールされます。

   カーネルパッチモジュールは、今後の再起動時に systemd システムおよびサービスマネージャーにより読み込まれる /var/lib/kpatch/ ディレクトリーにもインストールされます。

   注記

   指定のカーネルに利用可能なライブパッチがない場合は、空のライブパッチパッケージがインストールされます。空のライブパッチパッケージには、kpatch_version-kpatch_release 0-0 (例: kpatch-patch-5_14_0-1-0-0.el9.x86_64.rpm) が含まれます。空の RPM のインストールを行うと、指定のカーネルの将来のすべてのライブパッチにシステムがサブスクライブされます。

手順

1. オプション: インストールされているすべてのカーネルと現在実行中のカーネルを確認します。

   # dnf list installed | grep kernel
   Updating Subscription Management repositories.
   Installed Packages
   ...
   kernel-core.x86_64            5.14.0-1.el9              @beaker-BaseOS
   kernel-core.x86_64            5.14.0-2.el9              @@commandline
   ...
   
   # uname -r
   5.14.0-2.el9.x86_64

2. カーネルライブパッチへの自動サブスクリプションを無効にします。

   # dnf kpatch manual
   Updating Subscription Management repositories.

手順

1. ライブパッチパッケージを選択します。

   # dnf list installed | grep kpatch-patch
   kpatch-patch-5_14_0-1.x86_64        0-1.el9        @@commandline
   …​

   上記の出力例は、インストールしたライブパッチパッケージをリスト表示します。

2. ライブパッチパッケージを削除します。

   # dnf remove kpatch-patch-5_14_0-1.x86_64

   ライブパッチパッケージが削除されると、カーネルは次回の再起動までパッチが当てられたままになりますが、カーネルパッチモジュールはディスクから削除されます。今後の再起動では、対応するカーネルにはパッチが適用されなくなります。

3. システムを再起動します。

4. ライブパッチパッケージが削除されたことを確認します。

   # dnf list installed | grep kpatch-patch

   パッケージが正常に削除された場合、このコマンドでは何も出力されません。

検証

1. カーネルライブパッチソリューションが無効になっていることを確認します。

   # kpatch list
   Loaded patch modules:

   この出力例では、現在読み込まれているパッチモジュールがないため、カーネルにパッチが適用されておらず、ライブパッチソリューションがアクティブでないことが示されています。

手順

1. カーネルパッチモジュールを選択します。

   # kpatch list
   Loaded patch modules:
   kpatch_5_14_0_1_0_1 [enabled]
   
   Installed patch modules:
   kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)
   …​

2. 選択したカーネルパッチモジュールをアンインストールします。

   # kpatch uninstall kpatch_5_14_0_1_0_1
   uninstalling kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)

   • アンインストールしたカーネルモジュールが読み込まれていることに注意してください。

     # kpatch list
     Loaded patch modules:
     kpatch_5_14_0_1_0_1 [enabled]
     
     Installed patch modules:
     <NO_RESULT>

     選択したモジュールをアンインストールすると、カーネルは次回の再起動までパッチが当てられますが、カーネルパッチモジュールはディスクから削除されます。

3. システムを再起動します。

検証

1. カーネルパッチモジュールがアンインストールされたことを確認します。

   # kpatch list
   Loaded patch modules:
   …​

   上記の出力例では、ロードまたはインストールされたカーネルパッチモジュールが表示されていません。したがって、カーネルにパッチが適用されておらず、カーネルのライブパッチソリューションはアクティブではありません。

手順

1. kpatch.service が有効化されていることを確認します。

   # systemctl is-enabled kpatch.service
   enabled

2. kpatch.service を無効にします。

   # systemctl disable kpatch.service
   Removed /etc/systemd/system/multi-user.target.wants/kpatch.service.

   • 適用されたカーネルモジュールが依然としてロードされていることに注意してください。

     # kpatch list
     Loaded patch modules:
     kpatch_5_14_0_1_0_1 [enabled]
     
     Installed patch modules:
     kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)

3. システムを再起動します。

4. オプション: kpatch.service のステータスを確認します。

   # systemctl status kpatch.service
   ● kpatch.service - "Apply kpatch kernel patches"
      Loaded: loaded (/usr/lib/systemd/system/kpatch.service; disabled; vendor preset: disabled)
      Active: inactive (dead)

   この出力テストサンプルでは、kpatch.service が無効になっており、実行されていないことを証明しています。したがって、カーネルのライブパッチソリューションはアクティブではありません。

5. カーネルパッチモジュールがアンロードされたことを確認します。

   # kpatch list
   Loaded patch modules:
   
   Installed patch modules:
   kpatch_5_14_0_1_0_1 (5.14.0-1.el9.x86_64)

   上記の出力例では、カーネルパッチモジュールがインストールされていても、カーネルにパッチが適用されていないことを示しています。

1. コンソールログレベル。コンソールに出力されるメッセージの最低優先度を定義します。
2. 明示的なログレベルが付いていないメッセージのデフォルトのログレベル。
3. コンソールのログレベルに、可能な限り低いログレベル設定を設定します。

4. 起動時のコンソールのログレベルのデフォルト値を設定します。

   上記の各値は、エラーメッセージを処理するさまざまなルールを定義します。

手順

1. GRUB がインストールされているデバイスに GRUB を再インストールします。たとえば、sda がデバイスの場合は、以下のようになります。

   # grub2-install /dev/sda

2. システムを再起動して、変更を有効にします。

   # reboot

手順

1. grub2-efi および shim ブートローダーファイルを再インストールします。

   # yum reinstall grub2-efi shim

2. システムを再起動して、変更を有効にします。

   # reboot

手順

1. GRUB が格納されているディスクパーティションを特定します。

   # bootlist -m normal -o
   sda1

2. ディスクパーティションに GRUB を再インストールします。

   # grub2-install partition

   partition は、前のステップで特定した GRUB パーティション (/dev/sda1 など) に置き換えます。

3. システムを再起動して、変更を有効にします。

   # reboot

手順

1. 設定ファイルを削除します。

   # rm /etc/grub.d/*
   # rm /etc/sysconfig/grub

2. パッケージを再インストールします。

   • BIOS ベースのマシンで、次のように入力します。

     # yum reinstall grub2-tools

   • UEFI ベースのマシンでは、次のように入力します。

     # yum reinstall grub2-efi shim grub2-tools

3. 変更を有効にするために grub.cfg ファイルを再ビルドします。

   • BIOS ベースのマシンで、次のように入力します。

     # grub2-mkconfig -o /boot/grub2/grub.cfg

   • UEFI ベースのマシンでは、次のように入力します。

     # grub2-mkconfig -o /boot/grub2/grub.cfg

4. GRUB の再インストール 手順に従って、/boot/ パーティションに GRUB を復元します。

手順

1. KDUMP フィールドで、kdump がまだ有効になっていない場合は有効にします。

   
2. メモリー予約をカスタマイズする必要がある場合は、Kdump Memory Reservation で Manual を選択します。

3. KDUMP フィールドの Memory To Be Reserved (MB) で、kdump に必要なメモリー予約を設定します。

   

手順

1. kdump がシステムにインストールされているかどうかを確認します。

   # rpm -q kexec-tools

   このパッケージがインストールされている場合は以下を出力します。

   # kexec-tools-2.0.22-13.el9.x86_64

   このパッケージがインストールされていない場合は以下を出力します

   package kexec-tools is not installed

2. kdump および必要なパッケージをインストールします。

   # dnf install kexec-tools

手順

1. クラッシュカーネルのデフォルト値を設定します。

   # kdumpctl reset-crashkernel --kernel=ALL

   crashkernel= 値を設定する場合は、kdump を有効にして再起動し、設定をテストします。kdump カーネルの起動に失敗した場合は、メモリーサイズを徐々に増やして許容可能な値を設定します。

2. カスタムの crashkernel= 値を使用するには、以下を実行します。

   1. 必要なメモリー予約を設定します。

      crashkernel=192M

      あるいは、構文 crashkernel=<range1>:<size1>,<range2>:<size2> を使用して、予約メモリーの量を、インストールされているメモリーの合計量に応じて変動する値に設定することもできます。以下に例を示します。

      crashkernel=1G-4G:192M,2G-64G:256M

      この例では、システムメモリーの合計量が 1 GB 以上 4 GB 未満の場合、192 MB のメモリーが予約されます。メモリーの合計量が 4 GB を超える場合、256 MB が kdump 用に予約されます。

   2. オプション: 予約メモリーのオフセット。

      crashkernel 予約は非常に早いため、特定の固定オフセットでメモリーを予約する必要があるシステムもあります。また、特別な用途にいくつかの領域を予約したいシステムもあります。オフセットが設定されると、予約メモリーはそこから開始されます。予約メモリーをオフセットするには、以下の構文を使用します。

      crashkernel=192M@16M

      この例では、16 MB (物理アドレス 0x01000000) から始まる 192 MB のメモリーを予約します。オフセットを 0 に設定するか、値を指定しない場合、kdump は予約されたメモリーを自動的にオフセットします。オフセットを最後の値として指定することにより、変数メモリー予約を設定するときにメモリーをオフセットすることもできます。たとえば、crashkernel=1G-4G:192M,2G-64G:256M@16M です。

   3. ブートローダー設定を更新します。

      # grubby --update-kernel ALL --args "crashkernel=<custom-value>"

      <custom-value> には、クラッシュカーネル用に設定したカスタムの crashkernel= 値を含める必要があります。

3. 変更を有効にするために再起動します。

   # reboot

1. sysrq キーをアクティブ化して、kdump カーネルを起動します。

   # echo c > /proc/sysrq-trigger

   このコマンドによりカーネルがクラッシュし、必要に応じてカーネルが再起動されます。

2. /etc/kdump.conf ファイルを表示し、ターゲットの保存先に vmcore ファイルが保存されているかどうかを確認します。

手順

1. root で、/etc/kdump.conf 設定ファイルを編集し、#core_collector makedumpfile -l --message-level 1 -d 31 の行頭にあるハッシュ記号 ("#") を削除します。
2. クラッシュダンプファイルの圧縮を有効にするには、以下のコマンドを実行します。

手順

1. root で、/etc/kdump.conf 設定ファイルの #failure_action の行頭にあるハッシュ記号 (#) を削除します。

2. 値を任意のアクションに置き換えます。

   failure_action poweroff

手順

1. kdump サービスを有効にします。

   # kdumpctl restart

2. kdump サービスのステータスを確認します。kdumpctl コマンドを使用すると、出力をコンソールに出力できます。

   # kdumpctl status
     kdump:Kdump is operational

   あるいは、systemctl コマンドを使用すると、出力は systemd ジャーナルに出力されます。

3. カーネルクラッシュを開始して、kdump 設定をテストします。sysrq-trigger キーの組み合わせによりカーネルがクラッシュし、必要に応じてシステムが再起動します。

   # echo c > /proc/sysrq-trigger

   カーネルの再起動時に、/etc/kdump.conf ファイルで指定した場所に address-YYYY-MM-DD-HH:MM:SS/vmcore ファイルが作成されます。デフォルトは /var/crash/ です。

手順

1. 現在実行中のカーネルに読み込まれるモジュールのリストを表示します。読み込みをブロックするカーネルモジュールを選択します。

   $ lsmod
   
   Module                  Size  Used by
   fuse                  126976  3
   xt_CHECKSUM            16384  1
   ipt_MASQUERADE         16384  1
   uinput                 20480  1
   xt_conntrack           16384  1

2. /etc/sysconfig/kdump ファイルの KDUMP_COMMANDLINE_APPEND= 変数を更新します。以下に例を示します。

   KDUMP_COMMANDLINE_APPEND="rd.driver.blacklist=hv_vmbus,hv_storvsc,hv_utils,hv_netvsc,hid-hyperv"

   modprobe.blacklist=<modules> 設定オプションを使用した以下の例も検討してください。

   KDUMP_COMMANDLINE_APPEND="modprobe.blacklist=emcp modprobe.blacklist=bnx2fc modprobe.blacklist=libfcoe modprobe.blacklist=fcoe"

3. kdump サービスを再起動します。

   # systemctl restart kdump

手順

1. crashkernel= の推定値を出力します。

   # *kdumpctl estimate*
   
   Encrypted kdump target requires extra memory, assuming using the keyslot with minimum memory requirement
      Reserved crashkernel:    256M
      Recommended crashkernel: 652M
   
      Kernel image size:   47M
      Kernel modules size: 8M
      Initramfs size:      20M
      Runtime reservation: 64M
      LUKS required size:  512M
      Large modules: <none>
      WARNING: Current crashkernel size is lower than recommended size 652M.

2. crashkernel= の値を増やして、必要なメモリー量を設定します。
3. システムを再起動します。

手順

1. Web コンソールで、Kernel dump タブを開き、Kernel crash dump スイッチをオンに設定して kdump サービスを起動します。

2. ターミナルで kdump のメモリー使用量を設定します。以下に例を示します。

   $ sudo grubby --update-kernel ALL --args crashkernel=512M

   変更を適用するにはシステムを再起動します。

3. Kernel dump タブで、Crash dump location フィールドの末尾にある Edit をクリックします。

   

4. vmcore ダンプファイルを保存するターゲットディレクトリーを指定します。

   • ローカルファイルシステムの場合は、ドロップダウンメニューから Local Filesystem を選択します。

     

   • SSH プロトコルを使用したリモートシステムの場合は、ドロップダウンメニューから Remote over SSH を選択し、次のフィールドを指定します。

     • Server フィールドに、リモートサーバーのアドレスを入力します。
     • SSH key フィールドに、SSH キーの場所を入力します。
     • Directory フィールドに、ターゲットディレクトリーを入力します。

   • NFS プロトコルを使用したリモートシステムの場合は、ドロップダウンメニューから Remote over NFS を選択し、次のフィールドを指定します。

     • Server フィールドに、リモートサーバーのアドレスを入力します。
     • Export フィールドに、NFS サーバーの共有フォルダーの場所を入力します。

     • Directory フィールドに、ターゲットディレクトリーを入力します。

       注記

       Compression チェックボックスをオンにすると、vmcore ファイルのサイズを削減できます。

5. オプション: View automation script をクリックして自動化スクリプトを表示します。

   生成されたスクリプトを含むウィンドウが開きます。シェルスクリプトと Ansible Playbook の生成オプションタブ間を移動できます。

6. オプション: Copy to clipboard をクリックしてスクリプトをコピーします。

   このスクリプトを使用すると、複数のマシンに同じ設定を適用できます。

検証

1. Test configuration をクリックします。

   

2. Test kdump settings の下にある Crash system をクリックします。

   警告

   システムクラッシュを開始すると、カーネルの動作が停止し、システムがクラッシュしてデータが失われます。

手順

1. インストールしたすべてのカーネルに crashkernel= コマンドラインパラメーターを追加します。

   # grubby --update-kernel=ALL --args="crashkernel=xxM"

   xxM は必要なメモリー (メガバイト単位) です。

2. kdump を有効にします。

   # systemctl enable --now kdump.service

手順

1. マシンにインストールされているカーネルをリスト表示します。

   # ls -a /boot/vmlinuz-*
   /boot/vmlinuz-0-rescue-2930657cd0dc43c2b75db480e5e5b4a9
   /boot/vmlinuz-4.18.0-330.el8.x86_64
   /boot/vmlinuz-4.18.0-330.rt7.111.el8.x86_64

2. 特定の kdump カーネルを、システムの Grand Unified Bootloader (GRUB) 設定に追加します。

   以下に例を示します。

   # grubby --update-kernel=vmlinuz-4.18.0-330.el8.x86_64 --args="crashkernel=xxM"

   xxM は必要なメモリー予約 (メガバイト単位) です。

3. kdump を有効にします。

   # systemctl enable --now kdump.service

手順

1. 現在のセッションで kdump を停止するには、以下のコマンドを実行します。

   # systemctl stop kdump.service

2. kdump を無効にするには、以下を行います。

   # systemctl disable kdump.service

手順

1. final_action を設定するには、/etc/kdump.conf ファイルを編集して、次のいずれかのオプションを追加します。

   • final_action reboot
   • final_action halt
   • final_action poweroff

2. 変更を有効にするには、kdump サービスを再起動します。

   # kdumpctl restart

手順:

1. ダンプが失敗した場合に実行するアクションを設定するには、/etc/kdump.conf ファイルを編集して、failure_action オプションの 1 つを指定します。

   • failure_action reboot
   • failure_action halt
   • failure_action poweroff
   • failure_action shell
   • failure_action dump_to_rootfs

2. 変更を有効にするには、kdump サービスを再起動します。

   # kdumpctl restart

手順

1. kexec-tools パッケージをインストールします。

2. crashkernel のデフォルト値を設定します。

   # kdumpctl reset-crashkernel --fadump=on --kernel=ALL

3. オプション: デフォルト値の代わりにブートメモリーを予約します。

   # grubby --update-kernel ALL --args="fadump=on crashkernel=xxM"

   xxM は必要なメモリーサイズ (メガバイト単位) です。

   注記

   ブート設定オプションを指定するときは、kdump を有効にしてカーネルを再起動して設定をテストします。kdump カーネルの起動に失敗した場合は、crashkernel の値を徐々に増やして、適切な値を設定します。

4. 変更を有効にするために再起動します。

   # reboot

手順

1. sadump に対して kdump が予想どおりに起動するように /etc/sysctl.conf ファイルで以下の行を追加または編集します。

   kernel.panic=0
   kernel.unknown_nmi_panic=1

   警告

   特に、kdump の後にシステムが再起動しないようにする必要があります。kdump が vmcore ファイルの保存に失敗した後にシステムが再起動すると、sadump を呼び出すことができなくなります。

2. /etc/kdump.conf の failure_action パラメーターを halt または shell として適切に設定します。

   failure_action shell

手順

1. 関連するリポジトリーを有効にします。

   # subscription-manager repos --enable baseos repository

   # subscription-manager repos --enable appstream repository

   # subscription-manager repos --enable rhel-9-for-x86_64-baseos-debug-rpms

2. crash パッケージをインストールします。

   # dnf install crash

3. kernel-debuginfo パッケージをインストールします。

   # dnf install kernel-debuginfo

   パッケージ kernel-debuginfo は実行中のカーネルに対応し、ダンプ分析に必要なデータを提供します。

手順

1. crash ユーティリティーを起動するには、2 つの必要なパラメーターをコマンドに渡す必要があります。

   • debug-info (圧縮解除された vmlinuz イメージ) (特定の kernel-debuginfo パッケージに含まれる /usr/lib/debug/lib/modules/5.14.0-1.el9.x86_64/vmlinux など)

   • 実際の vmcore ファイル (例: /var/crash/127.0.0.1-2021-09-13-14:05:33/vmcore)

     その結果の crash コマンドの以下のようになります。

     # crash /usr/lib/debug/lib/modules/5.14.0-1.el9.x86_64/vmlinux /var/crash/127.0.0.1-2021-09-13-14:05:33/vmcore

     kdump で取得したのと同じ <kernel> のバージョンを使用します。

     例18.1 crash ユーティリティーの実行

     以下の例は、5.14.0-1.el9.x86_64 カーネルを使用して 2021 年 9 月 13 日の 14:05 PM に作成されたコアダンプを分析する方法を示しています。

     ...
     WARNING: kernel relocated [202MB]: patching 90160 gdb minimal_symbol values
     
           KERNEL: /usr/lib/debug/lib/modules/5.14.0-1.el9.x86_64/vmlinux
         DUMPFILE: /var/crash/127.0.0.1-2021-09-13-14:05:33/vmcore  [PARTIAL DUMP]
             CPUS: 2
             DATE: Mon Sep 13 14:05:16 2021
           UPTIME: 01:03:57
     LOAD AVERAGE: 0.00, 0.00, 0.00
            TASKS: 586
         NODENAME: localhost.localdomain
          RELEASE: 5.14.0-1.el9.x86_64
          VERSION: #1 SMP Wed Aug 29 11:51:55 UTC 2018
          MACHINE: x86_64  (2904 Mhz)
           MEMORY: 2.9 GB
            PANIC: "sysrq: SysRq : Trigger a crash"
              PID: 10635
          COMMAND: "bash"
             TASK: ffff8d6c84271800  [THREAD_INFO: ffff8d6c84271800]
              CPU: 1
            STATE: TASK_RUNNING (SYSRQ)
     
     crash>

2. 対話型プロンプトを終了して crash を停止するには、exit または q と入力します。

   例18.2 crash ユーティリティーの終了

   crash> exit
   ~]#

手順

1. Kernel Oops Analyzer ツールにアクセスします。

2. カーネルクラッシュの問題を診断するには、vmcore に生成されたカーネルの oops ログをアップロードします。

   • テキストメッセージまたは vmcore-dmesg.txt を入力として指定して、カーネルクラッシュの問題を診断することも可能です。

     
3. DETECT をクリックして、makedumpfile からの情報に基づいて既知のソリューションと oops メッセージを比較します。

手順

1. kdump サービスが有効でアクティブであることを確認します。

   # systemctl is-enabled kdump.service && systemctl is-active kdump.service
   enabled
   active

   kdump が有効ではなく、実行されていない場合は、必要な設定をすべて設定し、kdump サービスが有効化されていることを確認します。

2. 起動カーネルの initramfs イメージを、early kdump 機能で再構築します。

   # dracut -f --add earlykdump

3. rd.earlykdump カーネルコマンドラインパラメーターを追加します。

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="rd.earlykdump"

4. システムを再起動して、変更を反映させます。

   # reboot

手順

1. 公開鍵を sb_cert.cer ファイルにエクスポートします。

   # certutil -d /etc/pki/pesign \
              -n 'Custom Secure Boot key' \
              -Lr \
              > sb_cert.cer

2. 公開鍵を MOK リストにインポートします。

   # mokutil --import sb_cert.cer

3. この MOK 登録要求の新しいパスワードを入力してください。

4. マシンを再起動します。

   shim ブートローダーは、保留中の MOK キー登録要求を認識し、MokManager.efi を起動して、UEFI コンソールから登録を完了できるようにします。

5. Enroll MOK を選択し、プロンプトが表示されたら、この要求に関連付けたパスワードを入力し、登録を確認します。

   公開鍵が MOK リストに永続的に追加されます。

   キーが MOK リストに追加されると、UEFI セキュアブートが有効になっている場合は、このブートおよび後続のブートで .platform キーリングに自動的に伝達されます。

手順

1. 公開鍵を sb_cert.cer ファイルにエクスポートします。

   # certutil -d /etc/pki/pesign \
              -n 'Custom Secure Boot key' \
              -Lr \
              > sb_cert.cer

2. NSS データベースからキーを PKCS #12 ファイルとして抽出します。

   # pk12util -o sb_cert.p12 \
              -n 'Custom Secure Boot key' \
              -d /etc/pki/pesign

3. 前のコマンドでプロンプトが表示されたら、秘密鍵を暗号化する新しいパスワードを入力します。

4. 暗号化されていない秘密鍵をエクスポートします。

   # openssl pkcs12 \
            -in sb_cert.p12 \
            -out sb_cert.priv \
            -nocerts \
            -noenc

   重要

   暗号化されていない秘密鍵は慎重に取り扱ってください。

5. カーネルモジュールに署名します。次のコマンドは、カーネルモジュールファイル内の ELF イメージに署名を直接追加します。

   # /usr/src/kernels/$(uname -r)/scripts/sign-file \
             sha256 \
             sb_cert.priv \
             sb_cert.cer \
             my_module.ko

検証

1. カーネルモジュールの署名に関する情報を表示します。

   # modinfo my_module.ko | grep signer
     signer:         Your Name Key

   生成時に入力した名前が署名に記載されていることを確認します。

   注記

   この追加された署名は ELF イメージセクションには含まれず、また ELF イメージの正式な一部ではありません。したがって、readelf などのユーティリティーは、カーネルモジュールの署名を表示できません。

2. モジュールをロードします。

   # insmod my_module.ko

3. モジュールを削除 (アンロード) します。

   # modprobe -r my_module.ko

手順

1. 公開鍵がシステムキーリング上にあることを確認します。

   # keyctl list %:.platform

2. カーネルモジュールを必要なカーネルの extra/ ディレクトリーにコピーします。

   # cp my_module.ko /lib/modules/$(uname -r)/extra/

3. モジュールの依存関係のリストを更新します。

   # depmod -a

4. カーネルモジュールを読み込みます。

   # modprobe -v my_module

5. オプション: 起動時にモジュールをロードするには、/etc/modules-loaded.d/my_module.conf ファイルに追加します。

   # echo "my_module" > /etc/modules-load.d/my_module.conf

手順

1. 失効リストの現在のバージョンを確認します。

   # fwupdmgr get-devices

   UEFI dbx の下の Current version フィールドを確認します。

2. LVFS 失効リストリポジトリーを有効にします。

   # fwupdmgr enable-remote lvfs

3. リポジトリーのメタデータを更新します。

   # fwupdmgr refresh

4. 失効リストの更新を適用します。

   • コマンドラインの場合:

     # fwupdmgr update

   • グラフィカルインターフェイスの場合:

     1. Software アプリケーションを開きます。
     2. Updates タブに移動します。
     3. Secure Boot dbx Configuration Update エントリーを見つけます。
     4. Update をクリックします。
5. 更新の最後に、fwupdmgr または ソフトウェア がシステムの再起動を要求します。再起動を確認します。

手順

1. 失効リストの現在のバージョンを確認します。

   # fwupdmgr get-devices

   UEFI dbx の下の Current version フィールドを確認します。

2. RHEL から入手可能な更新をリストします。

   # ls /usr/share/dbxtool/

3. アーキテクチャーの最新の更新ファイルを選択します。ファイル名には次の形式が使用されます。

   DBXUpdate-date-architecture.cab

4. 選択した更新ファイルをインストールします。

   # fwupdmgr install /usr/share/dbxtool/DBXUpdate-date-architecture.cab

5. 更新の最後に、fwupdmgr がシステムの再起動を要求します。再起動を確認します。

手順

1. 次のユーティリティーのいずれかを使用して、永続ハンドル (たとえば、81000001) を持つ SHA-256 プライマリーストレージキーを使用して 2048 ビット RSA キーを作成します。

   1. tss2 パッケージを使用する場合:

      # TPM_DEVICE=/dev/tpm0 tsscreateprimary -hi o -st
      Handle 80000000
      # TPM_DEVICE=/dev/tpm0 tssevictcontrol -hi o -ho 80000000 -hp 81000001

   2. tpm2-tools パッケージを使用する場合:

      # tpm2_createprimary --key-algorithm=rsa2048 --key-context=key.ctxt
      name-alg:
        value: sha256
        raw: 0xb
      …
      sym-keybits: 128
      rsa: xxxxxx…
      
      # tpm2_evictcontrol -c key.ctxt 0x81000001
      persistentHandle: 0x81000001
      action: persisted

2. TPM 2.0 を使用し、keyctl add trusted <NAME> "new <KEY_LENGTH> keyhandle=<PERSISTENT-HANDLE> [options]" <KEYRING> という構文で信頼できる鍵を作成します。この例では、永続ハンドルは 81000001 です。

   # keyctl add trusted kmk "new 32 keyhandle=0x81000001" @u
   642500861

   このコマンドは、kmk という名前の信頼できる鍵を 32 バイト (256 ビット) の長さで作成し、ユーザーキーリング (@u) に配置します。鍵の長さは 32 から 128 バイト (256 から 1024 ビット) です。

3. カーネルキーリングの現在の構造を一覧表示します。

   # keyctl show
   Session Keyring
          -3 --alswrv    500   500  keyring: ses 97833714 --alswrv 500 -1 \ keyring: uid.1000 642500861 --alswrv 500 500 \ trusted: kmk

4. 信頼できる鍵のシリアル番号を使用して、鍵をユーザー空間のブロブにエクスポートします。

   # keyctl pipe 642500861 > kmk.blob

   このコマンドは、pipe サブコマンドと kmk のシリアル番号を使用します。

5. ユーザー空間のブロブから信頼できる鍵をロードします。

   # keyctl add trusted kmk "load `cat kmk.blob`" @u
   268728824

6. TPM で保護された信頼できる鍵 (kmk) を使用するセキュアな暗号化鍵を作成します。keyctl add encrypted <NAME> "new FORMAT <KEY_TYPE>:<PRIMARY_KEY_NAME> <KEY_LENGTH>" <KEYRING> という構文に従います。

   # keyctl add encrypted encr-key "new trusted:kmk 32" @u
   159771175

手順

1. 無作為な数列を使用してユーザーキーを生成します。

   # keyctl add user kmk-user "$(dd if=/dev/urandom bs=1 count=32 2>/dev/null)" @u
   427069434

   このコマンドは、kmk-user という名前のユーザーキーを生成し、プライマリーキー として動作させ、このユーザーキーを使用して実際の暗号化鍵を保護します。

2. 前の手順で取得したプライマリーキーを使用して、暗号化鍵を生成します。

   # keyctl add encrypted encr-key "new user:kmk-user 32" @u
   1012412758

検証

1. 指定したユーザーキーリングにあるすべての鍵をリスト表示します。

   # keyctl list @u
   2 keys in keyring:
   427069434: --alswrv  1000  1000 user: kmk-user
   1012412758: --alswrv  1000  1000 encrypted: encr-key

手順

1. 現在のブートエントリーの fix モードで IMA と EVM を有効にし、次のカーネルコマンドラインパラメーターを追加することで、ユーザーが IMA 測定値を収集および更新できるようにします。

   # grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="ima_policy=appraise_tcb ima_appraise=fix evm=fix"

   このコマンドは、現在のブートエントリーの fix モードで IMA および EVM を有効にしてユーザーが IMA 測定を収集し、更新できるようにします。

   ima_policy=appraise_tcb カーネルコマンドラインパラメーターにより、カーネルは、デフォルトの TCB (Trusted Computing Base) 測定ポリシーと評価手順を使用するようになります。評価手順では、以前の測定と現在の測定が一致しないファイルへのアクセスを禁止します。

2. 再起動して変更を適用します。

3. オプション: パラメーターがカーネルコマンドラインに追加されていることを確認します。

   # cat /proc/cmdline
   BOOT_IMAGE=(hd0,msdos1)/vmlinuz-5.14.0-1.el9.x86_64 root=/dev/mapper/rhel-root ro crashkernel=1G-4G:192M,4G-64G:256M,64G-:512M resume=/dev/mapper/rhel-swap rd.lvm.lv=rhel/root rd.lvm.lv=rhel/swap rhgb quiet ima_policy=appraise_tcb ima_appraise=fix evm=fix

4. カーネルマスターキーを作成して、EVM 鍵を保護します。

   # keyctl add user kmk "$(dd if=/dev/urandom bs=1 count=32 2> /dev/null)" @u
   748544121

   kmk は、すべてカーネル領域メモリー内に保持されます。kmk の 32 バイトの Long 値は、/dev/urandom ファイルの乱数バイト数から生成し、ユーザーの (@u) キーリングに配置します。鍵のシリアル番号は、前の出力の 1 行目にあります。

5. kmk に基づいて暗号化された EVM 鍵を作成します。

   # keyctl add encrypted evm-key "new user:kmk 64" @u
   641780271

   kmk を使用して 64 バイトの long 型ユーザーキー (evm-key) を生成してユーザー (@u) のキーリングに配置します。鍵のシリアル番号は、前の出力の 1 行目にあります。

   重要

   ユーザーキーの名前は evm-key (EVM サブシステムが想定して使用している名前) にする必要があります。

6. エクスポートする鍵のディレクトリーを作成します。

   # mkdir -p /etc/keys/

7. kmk を検索し、その暗号化されていない値を新しいディレクトリーにエクスポートします。

   # keyctl pipe $(keyctl search @u user kmk) > /etc/keys/kmk

8. evm-key を検索し、その暗号化された値を新しいディレクトリーにエクスポートします。

   # keyctl pipe $(keyctl search @u encrypted evm-key) > /etc/keys/evm-key

   evm-key は、すでにカーネルのマスターキーにより暗号化されています。

9. オプション: 新しく作成された鍵を表示します。

   # keyctl show
   Session Keyring
   974575405   --alswrv     0        0      keyring: ses 299489774 --alswrv 0 65534 \ keyring: uid.0 748544121 --alswrv 0 0 \ user: kmk
   641780271   --alswrv     0        0           \_ encrypted: evm-key
   
   # ls -l /etc/keys/
   total 8
   -rw-r--r--. 1 root root 246 Jun 24 12:44 evm-key
   -rw-r--r--. 1 root root  32 Jun 24 12:43 kmk

10. オプション: システムの再起動後など、鍵がキーリングから削除されている場合は、新しい kmk と evm-key を作成せずに、すでにエクスポートされているものをインポートできます。

    1. kmk をインポートします。

       # keyctl add user kmk "$(cat /etc/keys/kmk)" @u
       451342217

    2. evm-key をインポートします。

       # keyctl add encrypted evm-key "load $(cat /etc/keys/evm-key)" @u
       924537557

11. EVM をアクティブ化します。

    # echo 1 > /sys/kernel/security/evm

12. システム全体のラベルを付け直します。

    # find / -fstype xfs -type f -uid 0 -exec head -n 1 '{}' >/dev/null \;

    警告

    システムのラベルを変更せずに IMA と EVM を有効にすると、システム上のファイルの大部分にアクセスできなくなる可能性があります。

手順

1. テストファイルを作成します。

   # echo <Test_text> > test_file

   IMA と EVM は、test_file サンプルファイルにハッシュ値が割り当てられ、その拡張属性として格納されていることを確認します。

2. ファイルの拡張属性を検査します。

   # getfattr -m . -d test_file
   # file: test_file
   security.evm=0sAnDIy4VPA0HArpPO/EqiutnNyBql
   security.ima=0sAQOEDeuUnWzwwKYk+n66h/vby3eD

   出力例には、IMA および EVM ハッシュ値と SELinux コンテキストを含む拡張属性が示されています。EVM は、他の属性に関連する security.evm 拡張属性を追加します。この時点で、security.evm で evmctl ユーティリティーを使用して、RSA ベースのデジタル署名またはハッシュベースのメッセージ認証コード (HMAC-SHA1) を生成できます。

手順

1. rpm-plugin-ima プラグインをインストールするには、次を実行します。

   # dnf install rpm-plugin-ima -y

2. すべてのパッケージを再インストールするには、次を実行します。

   # dnf reinstall “*” -y

検証

1. 再インストールしたパッケージファイルに有効な IMA 署名があることを確認します。たとえば、/usr/bin/bash ファイルの IMA 署名を確認するには、次のコマンドを実行します。

   # getfattr -m security.ima -d /usr/bin/bash
   security.ima=0sAwIE0zIESQBnMGUCMFhf0iBeM7NjjhCCHVt4/ORx1eCegjrWSHzFbJMCsAhR9bYU2hNGjiWUYT2IIqWaaAIxALFGUkqGP5vDLuxQXibO9g7HFcfyZzRBY4rbKPsXcAIZRtDHVS5dQBZqM3hyS5v1MA==

2. 指定の証明書を使用してファイルの IMA 署名を検証します。IMA コード署名鍵には、/usr/share/doc/kernel-keys/$(uname -r)/ima.cer からアクセスできます。

   # evmctl ima_verify -k /usr/share/doc/kernel-keys/$(uname -r)/ima.cer /usr/bin/bash
   key 1: d3320449 /usr/share/doc/kernel-keys/5.14.0-359.el9.x86-64/ima.cer
   /usr/bin/bash: verification is OK

手順

1. Red Hat IMA コード署名鍵を /etc/ima/keys ファイルにコピーするには、次のコマンドを実行します。

   $ mkdir -p /etc/keys/ima
   $ cp /usr/share/doc/kernel-keys/$(uname -r)/ima.cer /etc/ima/keys

2. IMA コード署名鍵を .ima キーリングに追加するには、次のコマンドを実行します。

   # keyctl padd asymmetric RedHat-IMA %:.ima < /etc/ima/keys/ima.cer

3. 脅威モデルに応じて、/etc/sysconfig/ima-policy ファイルで IMA ポリシーを定義します。たとえば、次の IMA ポリシーは、実行可能ファイルと、関連するメモリーマッピングライブラリーファイルの両方の整合性をチェックします。

   # PROC_SUPER_MAGIC = 0x9fa0
   dont_appraise fsmagic=0x9fa0
   # SYSFS_MAGIC = 0x62656572
   dont_appraise fsmagic=0x62656572
   # DEBUGFS_MAGIC = 0x64626720
   dont_appraise fsmagic=0x64626720
   # TMPFS_MAGIC = 0x01021994
   dont_appraise fsmagic=0x1021994
   # RAMFS_MAGIC
   dont_appraise fsmagic=0x858458f6
   # DEVPTS_SUPER_MAGIC=0x1cd1
   dont_appraise fsmagic=0x1cd1
   # BINFMTFS_MAGIC=0x42494e4d
   dont_appraise fsmagic=0x42494e4d
   # SECURITYFS_MAGIC=0x73636673
   dont_appraise fsmagic=0x73636673
   # SELINUX_MAGIC=0xf97cff8c
   dont_appraise fsmagic=0xf97cff8c
   # SMACK_MAGIC=0x43415d53
   dont_appraise fsmagic=0x43415d53
   # NSFS_MAGIC=0x6e736673
   dont_appraise fsmagic=0x6e736673
   # EFIVARFS_MAGIC
   dont_appraise fsmagic=0xde5e81e4
   # CGROUP_SUPER_MAGIC=0x27e0eb
   dont_appraise fsmagic=0x27e0eb
   # CGROUP2_SUPER_MAGIC=0x63677270
   dont_appraise fsmagic=0x63677270
   appraise func=BPRM_CHECK
   appraise func=FILE_MMAP mask=MAY_EXEC

4. IMA ポリシーをロードしてカーネルがこの IMA ポリシーを受け入れるようにするには、次のコマンドを実行します。

   # echo /etc/sysconfig/ima-policy > /sys/kernel/security/ima/policy
   # echo $?
   0

5. dracut Integrity モジュールが IMA コード署名鍵と IMA ポリシーを自動的にロードできるようにするには、次のコマンドを実行します。

   # echo 'add_dracutmodules+=" integrity "' > /etc/dracut.conf.d/98-integrity.conf
   # dracut -f

手順

1. カスタム IMA CA キーペアを生成するには、次のコマンドを実行します。

   # openssl req -new -x509 -utf8 -sha256 -days 3650 -batch -config ima_ca.conf -outform DER -out custom_ima_ca.der -keyout custom_ima_ca.priv

2. オプション: ima_ca.conf ファイルの内容を確認するには、次のコマンドを実行します。

   # cat ima_ca.conf
   [ req ]
   default_bits = 2048
   distinguished_name = req_distinguished_name
   prompt = no
   string_mask = utf8only
   x509_extensions = ca
   
   [ req_distinguished_name ]
   O = YOUR_ORG
   CN =  YOUR_COMMON_NAME IMA CA
   emailAddress = YOUR_EMAIL
   
   [ ca ]
   basicConstraints=critical,CA:TRUE
   subjectKeyIdentifier=hash
   authorityKeyIdentifier=keyid:always,issuer
   keyUsage=critical,keyCertSign,cRLSign

3. 秘密鍵と IMA コード署名鍵の証明書署名要求 (CSR) を生成するには、次のコマンドを実行します。

   # openssl req -new -utf8 -sha256 -days 365 -batch -config ima.conf -out custom_ima.csr -keyout custom_ima.priv

4. オプション: ima.conf ファイルの内容を確認するには、次のコマンドを実行します。

   # cat ima.conf
   [ req ]
   default_bits = 2048
   distinguished_name = req_distinguished_name
   prompt = no
   string_mask = utf8only
   x509_extensions = code_signing
   
   [ req_distinguished_name ]
   O = YOUR_ORG
   CN = YOUR_COMMON_NAME IMA signing key
   emailAddress = YOUR_EMAIL
   
   [ code_signing ]
   basicConstraints=critical,CA:FALSE
   keyUsage=digitalSignature
   subjectKeyIdentifier=hash
   authorityKeyIdentifier=keyid:always,issuer

5. IMA CA 秘密鍵を使用して CSR に署名し、IMA コード署名証明書を作成します。

   # openssl x509 -req -in custom_ima.csr -days 365 -extfile ima.conf -extensions code_signing -CA custom_ima_ca.der -CAkey custom_ima_ca.priv -CAcreateserial -outform DER -out ima.der

手順

1. Secure Boot を有効にします。

2. ima_policy=secure_boot カーネルパラメーターを永続的に追加します。

   手順については、sysctl を使用したカーネルパラメーターの永続的な設定 を参照してください。

3. 次のコマンドを実行して、IMA ポリシーを準備します。

   # evmctl ima_sign /etc/sysconfig/ima-policy -k <PATH_TO_YOUR_CUSTOM_IMA_KEY>
   Place your public certificate under /etc/keys/ima/ and add it to the .ima keyring

4. 次のコマンドを実行して、カスタム IMA コード署名鍵を使用してポリシーに署名します。

   # keyctl padd asymmetric CUSTOM_IMA1 %:.ima < /etc/ima/keys/my_ima.cer

5. 次のコマンドを実行して、IMA ポリシーをロードします。

   # echo /etc/sysconfig/ima-policy > /sys/kernel/security/ima/policy
   # echo $?
   0

1. 選択したサービスに割り当てられた値を確認してください。

   # systemctl show --property <unit file option> <service name>

2. CPU 時間割り当てポリシーのオプションで必要な値を設定します。

   # systemctl set-property <service name> <unit file option>=<value>

手順

1. プロセスが属する cgroup を表示するには、# cat proc/<PID>/cgroup コマンドを実行します。

   # cat /proc/2467/cgroup
   0::/system.slice/example.service

   この出力例は、対象のプロセスに関するものです。今回の例では、example.service ユニットに属する PID 2467 で識別されるプロセスです。systemd ユニットファイルの仕様で定義されているように、適切なコントロールグループにプロセスが置かれているかどうかを判断できます。

2. cgroup が使用するコントローラーとそれぞれの設定ファイルを表示するには、cgroup ディレクトリーを確認します。

   # cat /sys/fs/cgroup/system.slice/example.service/cgroup.controllers
   memory pids
   
   # ls /sys/fs/cgroup/system.slice/example.service/
   cgroup.controllers
   cgroup.events
   …​
   cpu.pressure
   cpu.stat
   io.pressure
   memory.current
   memory.events
   …​
   pids.current
   pids.events
   pids.max

手順

1. systemd-cgtop コマンドを使用して、現在実行中の cgroups の動的アカウントを表示します。

   # systemd-cgtop
   Control Group                            Tasks   %CPU   Memory  Input/s Output/s
   /                                          607   29.8     1.5G        -        -
   /system.slice                              125      -   428.7M        -        -
   /system.slice/ModemManager.service           3      -     8.6M        -        -
   /system.slice/NetworkManager.service         3      -    12.8M        -        -
   /system.slice/accounts-daemon.service        3      -     1.8M        -        -
   /system.slice/boot.mount                     -      -    48.0K        -        -
   /system.slice/chronyd.service                1      -     2.0M        -        -
   /system.slice/cockpit.socket                 -      -     1.3M        -        -
   /system.slice/colord.service                 3      -     3.5M        -        -
   /system.slice/crond.service                  1      -     1.8M        -        -
   /system.slice/cups.service                   1      -     3.1M        -        -
   /system.slice/dev-hugepages.mount            -      -   244.0K        -        -
   /system.slice/dev-mapper-rhel\x2dswap.swap   -      -   912.0K        -        -
   /system.slice/dev-mqueue.mount               -      -    48.0K        -        -
   /system.slice/example.service                2      -     2.0M        -        -
   /system.slice/firewalld.service              2      -    28.8M        -        -
   ...

   この出力例では、現在実行中の cgroups が、リソースの使用状況 (CPU、メモリー、ディスク I/O 負荷) 別に表示されています。デフォルトでは 1 秒ごとにリストが更新されます。そのため、コントロールグループごとに、実際のリソースの使用状況について動的な見解が得られるようになります。

手順

1. /usr/lib/systemd/system/example.service ファイルを編集して、サービスのメモリー使用量を制限します。

   …​
   [Service]
   MemoryMax=1500K
   …​

   この設定により、コントロールグループ内のプロセスが超えることのできない最大メモリーの制限が設定されます。example.service サービスは、このようなコントロールグループの一部であり、制限を課せられています。測定単位のキロバイト、メガバイト、ギガバイト、またはテラバイトを指定するには、接尾辞 K、M、G、または T を使用できます。

2. すべてのユニット設定ファイルを再読み込みします。

   # systemctl daemon-reload

3. サービスを再起動します。

   # systemctl restart example.service

検証

1. 変更が有効になったことを確認します。

   # cat /sys/fs/cgroup/system.slice/example.service/memory.max
   1536000

   この出力例では、メモリー消費量が約 1,500 KB に制限されていることを示しています。

1. 選択したサービスで CPUAffinity ユニットファイルオプションの値を確認します。

   $ systemctl show --property <CPU affinity configuration option> <service name>

2. root ユーザーに切り替え、アフィニティーマスクとして使用する CPU 範囲に応じて、CPUAffinity ユニットファイルオプションの必要な値を設定します。

   # systemctl set-property <service name> CPUAffinity=<value>

3. サービスを再起動して変更を適用します。

   # systemctl restart <service name>

1. /etc/systemd/system.conf ファイルの [Manager] セクションの CPUAffinity= オプションに CPU 番号を設定します。

2. 編集したファイルを保存し、systemd サービスをリロードします。

   # systemctl daemon-reload

3. サーバーを再起動して、変更を適用します。

1. 選択したサービスで NUMAPolicy ユニットファイルオプションの値を確認します。

   $ systemctl show --property <NUMA policy configuration option> <service name>

2. root として、NUMAPolicy ユニットファイルオプションに必要なポリシータイプを設定します。

   # systemctl set-property <service name> NUMAPolicy=<value>

3. サービスを再起動して変更を適用します。

   # systemctl restart <service name>

1. /etc/systemd/system.conf ファイルで [Manager] セクションにある NUMAPolicy オプションを検索します。
2. ポリシータイプを編集してファイルを保存します。

3. systemd 設定をリロードします。

   # systemd daemon-reload

4. サーバーを再起動します。