步骤

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. 选择您要卸载的内核模块。

   如果内核模块有依赖项，请在卸载内核模块前卸载它们。有关识别使用依赖项的模块的详情，请参阅列出当前载入的内核模块和内核模块依赖项。

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 扩展附加到名称的末尾。内核模块名称没有扩展名，它们对应的文件有。

3. 另外，重启后，验证载入了相关模块：

   $ 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. 创建一个配置文件作为 denylist ：

   # 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 命令不会阻止将模块作为不在 denylist 中的另一个内核模块的依赖项加载，所以您还必须定义 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.ko)之前，会为每个源文件(test.c)创建一个对象文件(test.c)来作为中间步骤。

   成功编译后，/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 文件中：

   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 键的值。

   第二行调整了波特率(--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. 包括内核参数，一行一个。

   <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>

   命令进行配置更改，这些更改将在系统重启后消失。

3. （可选）验证新设置的内核参数的值。

   # 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

   • 名称 ：将任意字符串与 play 关联为标签的可选键，并确定该 play 的用途。
   • 在 play 中 主机: 键，用于指定运行该 play 的主机。此键的值或值可以作为被管理的主机的单独名称提供，也可以作为 inventory 文件中定义的一组主机提供。
   • playbook 的 vars: 部分，它表示包含所选内核参数名称和值的变量列表。

   • role: 键指定 RHEL 系统角色将配置 vars 部分中提到的参数和值。

     注意

     您可以修改 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. 安装实时补丁（live patching）软件包：

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

   以上命令只为特定内核安装并应用最新的实时补丁。

   如果实时补丁软件包的版本是 1-1 或更高版本，则软件包将包含补丁模块。在这种情况下，内核会在安装 live patching 软件包期间自动修补。

   内核补丁模块也安装到 /var/lib/kpatch/ 目录中，供 systemd 系统和服务管理器以后重启时载入。

   注意

   当给定内核没有可用的实时补丁时，将安装空的实时补丁软件包。空的 live patching 软件包会有一个 0-0 的 kpatch_version-kpatch_release，如 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
   …​

   这个命令订阅所有当前安装的内核，以接收内核实时补丁。命令还会为所有安装的内核安装并应用最新的累积实时补丁（如果有）。

   将来，当您更新内核时，将在新的内核安装过程中自动安装实时补丁。

   内核补丁模块也安装到 /var/lib/kpatch/ 目录中，供 systemd 系统和服务管理器以后重启时载入。

   注意

   当给定内核没有可用的实时补丁时，将安装空的实时补丁软件包。一个空的实时打补丁软件包将有一个 0-0 的 kpatch_version-kpatch_release，如 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

   如果软件包已被成功删除，命令不会显示任何输出。

5. （可选）验证内核实时补丁解决方案是否已禁用。

   # 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. 重启您的系统。

4. （可选）验证内核补丁模块是否已卸载。

   # 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。例如：如果 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

   使用您在上一步中找到的 GRUB 分区（如 /dev/sda1） 替换 partition。

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/efi/EFI/redhat/grub.cfg

4. 按照 重新安装 GRUB 流程来在 /boot/ 分区上恢复 GRUB。

流程

1. 在 KDUMP 字段中，如果 kdump 尚未启用，请启用它。

   
2. 在 Kdump Memory Reservation 下，如果必须自定义内存保留，请选择 Manual'。

3. 在 KDUMP 字段下，在 Memory To Beserved (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，则为 kdump 保留 256 MB。

   2. （可选）偏移保留的内存。

      有些系统需要保留内存并带有特定的固定偏移，因为崩溃内核保留非常早，并且希望保留一些区域供特殊使用。如果设置了偏移，则保留内存从此偏移开始。要偏移保留的内存，请使用以下语法：

      crashkernel=192M@16M

      示例保留从 16 MB 开始的 192 MB 内存（物理地址 0x01000000）。如果您偏移到 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 的开头删除 hash 符号("#")。
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

   在内核重启时，address-YYYY-MM-DD-HH:MM:SS/vmcore 文件在您在 /etc/kdump.conf 文件中指定的位置创建。默认值为 /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. 将 crashkernel= 命令行参数添加到所有安装的内核中。

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

   xxM 是所需的内存（以 MB 为单位）。

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. 向系统的 Grand Unified Bootloader (GRUB)配置中添加特定的 kdump 内核。

   例如：

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

   xxM 是所需的内存保留（以 MB 为单位）。

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 选项：

   • 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 是所需的内存大小（以 MB 为单位）。

   注意

   当指定引导选项时，请通过重启启用了 kdump 的内核来测试配置。如果 kdump 内核无法引导，请逐渐增加 crashkernel 值来设置适当的值。

4. 重启以使更改生效。

   # reboot

流程

1. 在 /etc/sysctl.conf 文件中添加或编辑以下行，以确保 sadump 的 kdump 按预期启动：

   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 工具程序，需要将两个必要的参数传递给该命令：

   • debug-info（解压缩的 vmlinuz 镜像），如 /usr/lib/debug/lib/modules/5.14.0-1.el9.x86_64/vmlinux，通过特定的 kernel-debuginfo 软件包提供。

   • 实际的 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> 版本。

     例 17.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。

   例 17.2. 退出 crash 工具

   crash> exit
   ~]#

流程

1. 访问内核 Oops 分析器工具.

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. 使用 早期 kdump 功能重建引导内核的 initramfs 镜像：

   # 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 Revocation List 存储库：

   # fwupdmgr enable-remote lvfs

3. 刷新存储库元数据：

   # fwupdmgr refresh

4. 应用撤销列表更新：

   • 在命令行上：

     # fwupdmgr update

   • 在图形界面中：

     1. 打开 Software 应用程序
     2. 进入 Updates 选项卡。
     3. 查找 Secure Boot dbx Configuration Update 条目。
     4. 点 Update。
5. 在更新结束时，fwupdmgr 或 Software 会要求您重启系统。确认重启。

流程

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. 使用具有持久句柄的 SHA-256 主存储密钥创建一个 2048 位 RSA 密钥，例如 81000001，使用以下工具之一：

   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. 使用可信密钥的序列号将密钥导出到用户空间 blob:

   # keyctl pipe 642500861 > kmk.blob

   命令使用 pipe 子命令和 kmk 的序列号。

5. 从用户空间 blob 加载可信密钥：

   # 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

3. 另外，还可列出指定用户密钥环中的所有密钥：

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

流程

1. 在 修复 模式下为当前引导条目启用 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)测量策略和评估步骤。评估步骤禁止访问之前和当前测量结果不匹配的文件。

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 字节长值是从 /dev/urandom 文件中的随机字节生成的，并放在用户(@u)密钥环中。密钥序列号位于前面输出的第一行。

5. 根据 kmk 创建加密的 EVM 密钥：

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

   命令使用 kmk 生成并加密 64 字节长用户密钥（名为 evm-key），并将其放在用户(@u)密钥环中。密钥序列号位于前面输出的第一行。

   重要

   用户密钥必须命名为 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. 要将红帽 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 keyring 中，请运行：

   # 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 完整性模块来自动载入 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. 启用安全引导.

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

   输出示例与关注进程相关。在这种情况下，它是由 PID 2467 来标识的进程，它属于 example.service 单元。您可以确定该过程是否放置在 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 命令显示当前正在运行的 cgroup 的动态帐户。

   # 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 将 Kilobyte、Megabyte、Gigabyte 或 Terabyte 作为一个测量单位。

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. 作为根目录，设置 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. 重启服务器。