Ядро SberLinux#

Ядро — это основная часть операционной системы SberLinux OS Server, которая управляет системными ресурсами и обеспечивает взаимодействие между аппаратным и программным обеспечением. Ядра упакованы в формате RPM, поэтому они легко обновляются и проверяются менеджером пакетов dnf.

RPM-пакет#

RPM-пакет - это файл, содержащий архив файлов и метаданные, используемые для установки и удаления этих файлов. RPM-пакет включает в себя:

• подпись GPG - используется для проверки целостности пакета;

• заголовок RPM (метаданные пакета) - используется диспетчером RPM-пакетов для определения зависимостей пакетов, места для установки файлов и др.;

• cpio-архив - содержит файлы для установки в систему.

Существует два типа RPM-пакетов. Оба имеют общий формат файла и инструменты, но разное содержимое и служат разным целям:

• RPM-пакеты с исходным кодом (Source RPM – SRPM) - содержат исходный код и файл спецификации, в котором описывается, как встроить исходный код в двоичный RPM. Могут также содержать исправления исходного кода;

• бинарные RPM-пакеты – содержат бинарные файлы, созданные из исходников и исправлений.

Обзор kernel RPM-пакета ядра SberLinux#

RPM-пакет kernel – это метапакет ядра, который не содержит в себе файлов, а обеспечивает правильную установку следующих необходимых подпакетов:

• kernel-core – содержит бинарный образ ядра SberLinux;

• kernel-modules-core – содержит базовые модули ядра для обеспечения основной функциональности; включает в себя модули, необходимые для правильного функционирования часто используемого оборудования;

• kernel-modules – содержит остальные модули ядра, которых нет в kernel-core.

Подпакеты kernel-core и kernel-modules-core могут вместе использоваться в виртуализированных и облачных средах, чтобы обеспечить ядро SberLinux быстрой загрузкой и небольшим размером занимаемого пространства на диске. Подпакет kernel-modules в таких случаях обычно не используется.

Существуют также дополнительные пакеты ядра, например:

• kernel-modules-extra – содержит модули ядра для редкого оборудования и модули, загрузка которых отключена по умолчанию;

• kernel-debug – содержит вариант ядра с многочисленными опциями отладки для диагностики ядра за счет снижения производительности;

• kernel-tools – содержит инструменты для работы с ядром SberLinux и сопроводительную документацию;

• kernel-abi-stablelists – содержит информацию, относящуюся к ABI ядра SberLinux, включая список символов ядра, необходимых внешним модулям ядра, и dnf-плагин для обеспечения исполнения.

Отображение содержимого пакета ядра#

Следующий сценарий описывает, как отобразить содержимое пакета ядра, список его файлов без загрузки или установки пакетов, запросив репозиторий с помощью команды.

• Для отображения доступных версий пакета используйте команду:

  dnf repoquery <имя_пакета>
  

  Например, для отображения доступных версий пакета 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
  ...
  

• Для отображения списка файлов пакета используйте команду:

  dnf repoquery -l <имя_пакета>
  

  Например, для отображения списка файлов пакета 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
  ...
  

Установка определенных версий ядра#

Следующий сценарий описывает, как установить новые ядра с помощью dnf менеджера пакетов.

Для установки определенной версии ядра используйте команду:

dnf install kernel-<version>

Где <version> - номер версии.

Обновление ядра#

Для обновления ядра с помощью менеджера пакетов dnf выполните следующие шаги:

1. Для обновления ядра введите команду:

   dnf update kernel
   

   Эта команда обновляет ядро вместе со всеми зависимостями до последней доступной версии.

2. Перезагрузите систему, чтобы изменения вступили в силу.

Настройка ядра по умолчанию#

Настройте конкретное ядро по умолчанию, используя средство командной строки grubby и GRUB:

• Для настройки ядра по умолчанию при помощи grubby введите команду:

  grubby --set-default $kernel_path
  

  Где $kernel_path - это абсолютный путь файла ядра.

  Данная команда использует ID машины без суффикса .conf в качестве аргумента. ID машины при этом находится в каталоге /boot/loader/entries/.

• Для настройки ядра по умолчанию с помощью аргумента id выполните следующие шаги:

  1. Для получения списка загрузочных записей с использованием аргумента id введите команду:

     grubby --info ALL | grep id
     

  2. Для настройки ядра по умолчанию используйте команду:

     grubby --set-default /boot/vmlinuz-<version>.<arh>
     

  Примечание

  Для получения списка загрузочных записей можно также использовать title аргумент, выполнив команду grubby --info=ALL | grep title.

• Для настройки ядра по умолчанию только для следующей загрузки используйте команду:

  grub2-reboot <index|title|id>
  

  Где <index|title|id> - идентификационные данные записи в меню загрузчика GRUB2.

  Внимание

  Настройку ядра по умолчанию только для следующей загрузки выполняйте с осторожностью - установка новых RPM-ядер, ядер собственной сборки и добавление записей вручную в каталог /boot/loader/entries/ могут изменить значения индекса.

Управление модулями ядра#

Данный раздел содержит информацию о модулях ядра, способах отображения информации о них и выполнении основных административных задач с ними.

Ядро SberLinux может быть расширено дополнительными функциональными элементами, называемыми модулями ядра, без необходимости перезагрузки системы. В SberLinux OS Server модули ядра представляют собой дополнительный код ядра, встроенный в сжатые объектные файлы <name_module_kernel>.ko.xz.

Наиболее распространенные функции, предоставляемые модулями ядра:

• драйвер устройства, добавляющий поддержку нового оборудования;

• поддержка файловой системы, такой как GFS2 или NFS;

• системные вызовы.

В современных системах модули ядра загружаются автоматически по мере необходимости. Однако в некоторых случаях необходимо загружать или выгружать модули вручную.

Как и само ядро, модули могут принимать параметры, которые при необходимости настраивают их поведение.

В параграфах ниже описывается инструментарий для проверки: какие модули запущены в данный момент, какие модули доступны для загрузки в ядро и какие параметры принимает модуль. Также представлен механизм для загрузки и выгрузки модулей ядра в работающее ядро.

Некоторые модули ядра иногда зависят от одного или нескольких других модулей. Файл зависимостей /lib/modules/<версия_ядра>/modules.dep содержит полный список зависимостей модулей для соответствующей версии ядра.

Утилита depmod#

Файл зависимостей генерируется утилитой depmod, входящей в состав пакета kmod. Многие из предоставляемых пакетом kmod утилит учитывают зависимости модулей при выполнении операций, поэтому ручное отслеживание зависимостей требуется редко.

Скрипт weak-modules#

В дополнение к утилите depmod SberLinux OS Server предоставляет скрипт weak-modules, также поставляемый с пакетом kmod. weak-modules определяет, какие модули kABI-совместимы с установленными ядрами. При проверке совместимости модулей с ядром weak-modules обрабатывает зависимости спецификаций модулей от более высоких до более низких версий ядра, для которых они были созданы. Каждый модуль обрабатывается независимо от версий ядра.

Список установленных модулей ядра#

Для отображения списка установленных ядер и их индексов используйте команду:

grubby --info=ALL | grep title

Результат выполнения команды содержит в себе версии всех установленных ядер, а также путь к ним.

Список загруженных в данный момент модулей ядра#

Для получения списка всех загруженных в данный момент модулей ядра введите команду lsmod.

lsmod

Пример вывода команды:

Module                  Size  Used by
fuse                  126976  3
uinput                 20480  1
xt_CHECKSUM            16384  1
ipt_MASQUERADE         16384  1
xt_conntrack           16384  1
ipt_REJECT             16384  1
nft_counter            16384  16
nf_nat_tftp            16384  0
nf_conntrack_tftp      16384  1 nf_nat_tftp
tun                    49152  1
bridge                192512  0
stp                    16384  1 bridge
llc                    16384  2 bridge,stp
nf_tables_set          32768  5
nft_fib_inet           16384  1
...

В приведенном примере:

• первый столбец — имена загруженных в данный момент модулей;

• второй столбец — объем памяти для каждого модуля в КБ;

• третий столбец — количество и (необязательно) имена модулей, которые зависят от конкретного модуля.

Отображение информации о модулях ядра#

Используйте команду modinfo для отображения дополнительной информации о модулях ядра.

Для отображения дополнительной информации о конкретном модуле введите:

modinfo <name_module>

Где <name_module> - имя модуля ядра.

Например, для отображения подробной информации о модуле virtio_net введите команду:

modinfo virtio_net

Пример результата выполнения команды:

filename:       /lib/modules/.../kernel/drivers/net/virtio_net.ko.xz
license:        GPL
description:    Virtio network driver
sloversion:     9.3
srcversion:     F51C55A01C77BBC38330BCF
alias:          virtio:d00000001v*
depends:        net_failover
retpoline       Y
intree:         Y
name:           virtio_net
...
parm:           napi_weight:int
parm:           csum:bool
parm:           gso:bool
parm:           napi_tx:bool

При помощи команды modinfo можно запросить информацию обо всех доступных модулях, независимо от того, загружены они или нет. Записи parm в выводе команды показывают параметры, которые можно установить для модуля, и их ожидаемые значения.

Загрузка модулей ядра во время работы системы#

Оптимальным способом расширения функциональности ядра является загрузка дополнительных модулей ядра. Используйте команду modprobe для поиска и загрузки конкретного модуля в работающее в данный момент ядро.

Для загрузки модулей ядра во время работы системы выполните следующие шаги:

1. Выберите модуль ядра, который необходимо загрузить. Модули находятся в каталоге /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/.

2. Для загрузки модуля ядра используйте команду:

   modprobe <name_module>
   

   Где <name_module> – имя модуля.

   Примечание

   При вводе имени модуля ядра не добавляйте расширение .ko.xz в конец имени. Имена модулей ядра не имеют расширений, их имеют соответствующие файлы.

3. Для того чтобы убедиться, что соответствующий модуль был загружен, используйте команду:

   lsmod | grep <name_module>
   

   Если модуль был загружен правильно, эта команда отобразит соответствующий модуль ядра.

   Например, для проверки корректности загрузки модуля serio_raw введите команду:

   lsmod | grep serio_raw
   

   Пример результата выполнения команды:

   serio_raw              16384  0
   

Выгрузка модулей ядра во время работы системы#

Используйте команду modprobe для поиска и выгрузки модуля ядра во время работы системы из загруженного в данный момент ядра.

Для выгрузки модулей ядра во время работы системы выполните следующие шаги:

1. Для отображения списка всех загруженных модулей ядра введите команду lsmod.

2. Выберите модуль ядра, который необходимо выгрузить.

3. Для выгрузки выбранного модуля ядра используйте команду:

   modprobe -r <name_module>
   

   Примечание

   При вводе имени модуля ядра не добавляйте расширение .ko.xz в конец имени. Имена модулей ядра не имеют расширений, их имеют соответствующие файлы.

4. Для того чтобы убедиться, что соответствующий модуль был выгружен, используйте команду:

   lsmod | grep <name_module>
   

   Если модуль был успешно выгружен, эта команда ничего не выведет.

Выгрузка модулей ядра на ранних этапах процесса загрузки#

Иногда возникает необходимость выгрузить модуль ядра в начале процесса загрузки. Например, если модуль ядра содержит код, приводящий к отказу системы отвечать на запросы, и пользователь не может перейти к этапу окончательного отключения вредоносного модуля ядра. В этом случае можно временно заблокировать загрузку модуля ядра с помощью загрузчика.

Для редактирования соответствующей записи загрузчика с целью выгрузки модуля ядра до продолжения загрузки системы выполните следующие шаги:

1. Для вызова меню GRUB при загрузке системы нажмите клавишу Esc.

Рисунок. Пример меню GRUB

2. Для выделения соответствующей записи и выбора необходимого ядра используйте клавиши ↑ и ↓.

3. Для редактирования выбранной записи нажмите клавишу e.

4. С помощью клавиш ↑, ↓, ← и → перейдите к строке, начинающейся с linux ....

5. В конце указанной строки добавьте modprobe.blacklist=<name_module>.

Рисунок. Пример редактирования записи

В качестве примера выгружаемого модуля использован модуль serio_raw.

6. Для загрузки с измененной конфигурацией нажмите Ctrl+x или F10.

7. Для проверки того, что соответствующий модуль ядра не загружен, используйте команду:

   lsmod | grep <name_module>
   

   Если модуль был успешно выгружен, команда ничего не выведет.

Автоматическая загрузка модулей ядра во время загрузки системы#

Для настройки автоматической загрузки модуля ядра во время загрузки системы выполните следующий сценарий:

1. Выберите модуль ядра, который необходимо загрузить в процессе загрузки системы.

   Модули находятся в каталоге /lib/modules/$(uname -r)/kernel/<SUBSYSTEM>/.

2. Для создания конфигурационного файла для выбранного модуля используйте команду:

   echo <name_module> > /etc/modules-load.d/<name_module>.conf
   

   Где <name_module> - имя модуля.

   Примечание

   При вводе имени модуля ядра не добавляйте расширение .ko.xz в конец имени. Имена модулей ядра не имеют расширений, их имеют соответствующие файлы.

3. Для того чтобы убедиться, что соответствующий модуль был загружен, используйте команду:

   lsmod | grep <name_module>
   

   Результатом успешного выполнения команды является отображение соответствующего модуля.

Предотвращение автоматической загрузки модулей ядра во время загрузки системы#

В данном разделе описан процесс добавления модуля ядра в список запрещенных, чтобы он не загружался автоматически в процессе загрузки системы.

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. Выберите модуль ядра, загрузку которого необходимо предотвратить.

   Для определения незагруженного модуля ядра, который необходимо предотвратить от потенциальной загрузки, отобразите содержание каталога /lib/modules/<version_kernel>/kernel/<subsystem>/, выполнив команду ls с указанием соответствующего каталога.

3. Для создания конфигурационного файла, выполняющего функции списка запрещенных модулей, введите команду:

   touch /etc/modprobe.d/denylist.conf
   

4. В текстовом редакторе скомбинируйте имена модулей, которые необходимо исключить из автоматической загрузки в ядро, с помощью команды конфигурации blacklist.

   Например:

   # Prevents <module-kernel_1> from being loaded
   blacklist <name_module_1>
   install <name_module_1> /bin/false
   
   # Prevents <module-kernel-2> from being loaded
   blacklist <name_module_2>
   install <name_module_2> /bin/false
   ...
   

   Где <module-kernel_1> и <module-kernel_2> - имена модулей.

   Поскольку команда blacklist не препятствует загрузке модуля в качестве зависимости для другого модуля ядра, не находящегося в списке запрещенных, необходимо также определить строку install. В этом случае система запустится с использованием параметра /bin/false вместо установки модуля. Строки, начинающиеся с #, являются комментариями, которые используются, чтобы сделать файл более читабельным.

   Примечание

   При вводе имени модуля ядра не добавляйте расширение .ko.xz в конец имени. Имена модулей ядра не имеют расширений, их имеют соответствующие файлы.

5. Для создания резервной копии текущего исходного образа 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)
   

6. Для того чтобы изменения вступили в силу, сгенерируйте новый исходный образ RAM-диска, выполнив команду:

   dracut -f -v
   

   В случае, если создается первоначальный образ RAM-диска для версии ядра, отличной от используемой системой в данный момент, укажите целевую версию initramfs и версию ядра, выполнив команду:

   dracut -f -v /boot/initramfs-<version>.img
   

7. Перезагрузите систему:

   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 включает в себя файлы из системных библиотек:

   • заголовочный файл linux/kernel.h - необходим для функции printk() в примере кода;

   • файл linux/module.h - содержит определения функций и макросов, которые будут совместно использоваться несколькими исходными файлами, написанными на языке программирования C.

2. Для запуска и завершения работы функции ведения журнала ядра printk(), выводящей текст, используйте функции init_module() и cleanup_module().

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.o) для каждого исходного файла (test.c) в качестве промежуточного шага перед объединением их в окончательный модуль ядра (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
   

Настройка параметров командной строки ядра#

С помощью параметров командной строки ядра можно изменять поведение некоторых компонентов ядра SberLinux во время загрузки. Системный администратор имеет полный контроль над тем, какие параметры поведения ядра устанавливаются при загрузке; некоторые из них настраиваются только во время загрузки.

Введение в параметры командной строки ядра#

С помощью параметров командной строки ядра доступна перезапись значения по умолчанию и установка определенных аппаратных настроек.

Во время загрузки системы доступна настройка:

• ядра SberLinux;

• начального RAM-диска;

• функции пользовательского пространства.

По умолчанию параметры командной строки ядра для систем, использующих загрузчик GRUB, определены в конфигурационном файле загрузочной записи для каждой загрузочной записи ядра.

Для изменения файлов конфигурации загрузчика можно использовать утилиту grubby (подробнее в разделе «База знаний» → «Утилита grubby»). С помощью grubby возможно выполнение следующих действий:

• изменение записи загрузки, установленной по умолчанию;

• добавление/удаление аргументов из меню GRUB.

Загрузочные записи#

Загрузочная запись — это набор параметров, которые хранятся в файле конфигурации и привязаны к конкретной версии ядра. Количество загрузочных записей как минимум совпадает с количеством ядер, установленных в системе. Файл конфигурации загрузочной записи находится в каталоге /boot/loader/entries/.

Рисунок. Пример файла конфигурации загрузочной записи

Приведенное выше имя файла состоит из идентификатора машины, хранящегося в файле /etc/machine-id, и версии ядра.

Файл конфигурации загрузочной записи содержит информацию о версии ядра, изначальном образе RAM-диска и параметрах командной строки ядра.

Пример содержимого конфигурации загрузочной записи:

Рисунок. Пример содержимого конфигурации загрузочной записи

Изменение параметров командной строки ядра для всех загрузочных записей#

Для изменения параметров командной строки ядра для всех загрузочных записей в системе выполните следующие действия:

• Для добавления параметра используйте команду:

  grubby --update-kernel=ALL --args="<new_parameter>"
  

  Для систем, использующих загрузчик GRUB, данная команда добавляет новый параметр ядра в каждый файл /boot/loader/entries/<note>.conf.

• Для удаления параметра используйте команду:

  grubby --update-kernel=ALL --remove-args="<delete_parameter>"
  

Изменение параметров командной строки ядра для одной загрузочной записи#

Для изменения параметров командной строки ядра для одной загрузочной записи в системе выполните следующие действия:

• Для добавления параметра используйте команду:

  grubby --update-kernel=/boot/vmlinuz-$(uname -r) --args="<new_parameter>"
  

• Для удаления параметра используйте команду:

  grubby --update-kernel=/boot/vmlinuz-$(uname -r) --remove-args="<delete_parameter>"
  

Временное изменение параметров командной строки ядра во время загрузки#

Для внесения временных изменений в запись меню ядра при помощи параметров на время одной загрузки выполните следующий сценарий:

1. Войдите в меню загрузки GRUB2, нажав клавишу Esc при запуске системы.

2. Выберите ядро, которое необходимо запустить.

3. Нажмите клавишу e, чтобы отредактировать параметры ядра.

4. Найдите командную строку ядра, переместив курсор вниз. Командная строка ядра начинается с linux....

5. Переместите курсор в конец строки.

   Примечание

   Для перехода к началу строки нажмите Ctrl+a, для перехода к концу строки - Ctrl+e.

6. Отредактируйте необходимые параметры ядра. Например:

   • Для запуска системы в аварийном режиме добавьте параметр emergency в конец строки linux...

Рисунок. Пример корректировки параметра ядра

• Для включения системных сообщений удалите параметры rhgb и quiet.

7. Для загрузки системы с выбранным ядром и измененными параметрами командной строки нажмите Ctrl+x.

Настройка параметров GRUB для подключения последовательного консольного соединения#

Последовательная консоль полезна, когда нужно подключиться к headless-серверу или встроенной системе при неработающей сети. Или, например, в случае необходимости обхода правил безопасности и получения доступа для входа в другую систему.

Для использования последовательного консольного соединения необходимо настроить некоторые параметры GRUB, используемые по умолчанию:

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, контроль четности --parity и другие значения в соответствии со средой и оборудованием.

   Примечание

   Гораздо более высокая скорость передачи данных, например 115200, предпочтительнее для таких задач, как просмотр файлов журнала.

2. Обновите файл конфигурации GRUB.

   • На машинах на базе BIOS:

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

   • На машинах на базе UEFI:

     grub2-mkconfig -o /boot/efi/EFI/sberlinux/grub.cfg
     

3. Для того чтобы изменения вступили в силу, перезагрузите систему.

Настройка параметров ядра во время выполнения#

Системный администратор может настраивать многие аспекты поведения ядра SberLinux во время выполнения. Настраивайте параметры ядра во время выполнения с помощью команды sysctl и путем изменения файлов конфигурации в каталогах /etc/sysctl.d/ и /proc/sys/.

Параметры ядра#

Параметры ядра — это значения, которые доступны для настройки во время работы системы. Для вступления изменений в силу нет необходимости перезагружать или перекомпилировать ядро.

К параметрам ядра можно обратиться через:

• команду sysctl;

• виртуальную файловую систему, скомпонованную в каталоге /proc/sys/;

• файлы конфигурации в каталоге /etc/sysctl.d/.

Настраиваемые объекты разделены подсистемой ядра на классы. Настраиваемые классы SberLinux OS Server представлены в таблице ниже.

Временная настройка параметров ядра с помощью sysctl#

Следующий сценарий описывает, как использовать команду sysctl для временной установки параметров ядра во время выполнения. Команда также полезна для вывода списка и фильтрации настраиваемых параметров.

1. Для перечисления всех параметров и их значений введите команду:

   sysctl -a
   

   Примечание

   Команда sysctl -a отображает параметры ядра, настраиваемые во время выполнения и во время загрузки.

2. Для временной настройки параметра используйте команду:

   sysctl <custom_class>.<parameter>=<target_value>
   

   Приведенный выше пример команды изменяет значение параметра во время работы системы. Изменения вступают в силу немедленно, без перезагрузки.

Постоянная настройка параметров ядра с помощью sysctl#

Для постоянной настройки параметров ядра выполните следующие шаги:

1. Для перечисления всех параметров и их значений введите команду:

   sysctl -a
   

   Команда отображает все параметры ядра, которые можно настроить во время выполнения и во время загрузки.

2. Для настройки параметра на постоянной основе используйте команду:

   sysctl -w <custom_class>.<parameter>=<target_value> >> /etc/sysctl.conf
   

   Данный пример команды изменяет настраиваемое значение и записывает его в файл /etc/sysctl.conf, переопределяющий значения параметров ядра по умолчанию. Изменения вступают в силу немедленно и на постоянной основе, без необходимости перезагрузки.

Использование файлов конфигурации в /etc/sysctl.d/ для настройки параметров ядра#

Чтобы вручную изменить файлы конфигурации в каталоге /etc/sysctl.d/ для установки постоянных параметров ядра, выполните следующий сценарий:

1. Для создания нового файла конфигурации в каталоге /etc/sysctl.d/ используйте команду:

   vim /etc/sysctl.d/<имя_файла.conf>
   

2. Добавьте необходимые параметры ядра, по одному в строке, следующим образом:

   <custom_class>.<parameter>=<target_value>
   ...
   

3. Сохраните файл конфигурации.

4. Перезагрузите машину, чтобы изменения вступили в силу.

   В качестве альтернативного способа применения изменений, без перезагрузки, можно использовать команду:

   sysctl -p /etc/sysctl.d/<имя_файла.conf>
   

   Данная команда позволяет прочитать значения из файла конфигурации, созданного ранее.

Временная настройка параметров ядра с помощью /proc/sys/#

Чтобы временно установить параметры ядра с помощью файлов в каталоге виртуальной файловой системы /proc/sys/, выполните следующие действия:

1. Для определения параметра ядра, который необходимо настроить, используйте команду:

   ls -l /proc/sys/<настраиваемый_класс>/
   

   Результат выполнения команды — доступные для записи файлы — можно использовать для настройки ядра. Файлы с правами только на чтение предоставляют информацию о текущих настройках.

2. Для присвоения целевого значения параметру ядра используйте команду:

   echo <target_value> > /proc/sys/<custom_class>/<parameter>
   

   Команда вносит изменения в конфигурацию, которые исчезнут после перезапуска системы.

3. Опционально. Для проверки значения вновь установленного параметра ядра используйте команду:

   cat /proc/sys/<custom_class>/<parameter>
   

Начало работы с ведением журнала ядра#

Файлы журналов (лог-файлы) — это файлы, содержащие сообщения о системе, включая ядро, службы и приложения, запущенные в ней. Система ведения журналов в SberLinux OS Server основана на встроенном протоколе системного журнала. Различные утилиты используют эту систему для записи событий и организации их в log-файлы. Эти файлы полезны при проверке операционной системы или устранении неполадок.

Кольцевой буфер ядра#

В процессе загрузки консоль предоставляет много важной информации о начальном этапе запуска системы. Чтобы избежать потери ранних сообщений, ядро использует так называемый кольцевой буфер. В этом буфере хранятся все сообщения, включая загрузочные, сгенерированные функцией printk() в коде ядра. Сообщения из кольцевого буфера ядра затем считываются и сохраняются в лог-файлах на постоянном запоминающем устройстве (ПЗУ).

Кольцевой буфер ядра представляет собой циклическую структуру данных фиксированного размера, жестко запрограммированную в ядре. Пользователи могут отображать данные, хранящиеся в кольцевом буфере ядра, с помощью команды dmesg или файла /var/log/boot.log. Когда кольцевой буфер заполнен, новые данные перезаписывают старые.

Роль printk в ведении журнала ядра и его уровнях#

Каждое сообщение ядра связано с соответствующим уровнем журнала, определяющим важность сообщения. Кольцевой буфер ядра собирает сообщения всех уровней журнала. Параметр, определяющий, какие сообщения из буфера выводятся на консоль, — kernel.printk.

Значения уровней журнала ядра:

• 0 — Аварийная ситуация в ядре. Система непригодна для использования.

• 1 — Тревога. Необходимо немедленно принять меры.

• 2 — Состояние ядра считается критическим.

• 3 — Общая ошибка ядра.

• 4 — Общее предупреждение.

• 5 — Уведомление о нормальном, но требующем внимания состоянии.

• 6 — Информационное сообщение.

• 7 — Сообщение уровня отладки.

По умолчанию kernel.printk в SberLinux OS Server содержит четыре значения. Для отображения данных значений введите команду:

sysctl kernel.printk

Результат выполнения команды:

kernel.printk = 7 4 1 7

Приведенные четыре значения определяют следующее, в порядке перечисления:

1. Уровень журнала консоли — определяет самый низкий приоритет сообщений, выводимых на консоль.

2. Уровень журнала по умолчанию — для сообщений, за которыми явно не закреплен уровень журнала.

3. Устанавливает минимально возможную конфигурацию для уровня журнала консоли.

4. Устанавливает значение по умолчанию для уровня журнала консоли во время загрузки.

Каждое из данных значений определяет отдельное правило обработки сообщений об ошибках.

Установка kdump#

kdump — это служба, предоставляющая механизм аварийного дампа для ядра. Сервис позволяет сохранять содержимое системной памяти для анализа. Служба использует системный вызов kexec для загрузки второго ядра («ядро захвата») без перезагрузки; а затем захватывает содержимое памяти сбойного ядра (аварийный дамп или vmcore) и сохраняет его в файл. Второе ядро находится в зарезервированной части системной памяти.

kdump может включаться для всех установленных ядер на машине или только для определенных. Это полезно, когда используется несколько ядер.

При установке kdump по умолчанию создается файл /etc/kdump.conf. Он включает минимальную конфигурацию kdump. Можно отредактировать этот файл, чтобы настроить kdump, но это не обязательно.

Установка kdump с помощью Anaconda#

Программа установки Anaconda предоставляет экран графического интерфейса для настройки kdump во время интерактивной установки. Экран установщика называется KDUMP и доступен на главном экране установки. Включение kdump требует зарезервировать необходимый объем памяти.

Для установки kdump выполните следующий сценарий:

1. Перейдите в поле KDUMP.

2. Включите kdump, если служба еще не включена.

   

   Рисунок. Включение kdump

3. Определите, сколько памяти должно быть зарезервировано для файлов kdump.

   

   Рисунок. Память для файлов kdump

Установка kdump из командной строки#

Некоторые параметры установки, такие как выборочная установка Kickstart, в некоторых случаях не устанавливаются или не включаются в kdump по умолчанию. В данном случае выполните описанный ниже сценарий.

Чтобы установить kdump из командной строки, используйте следующий сценарий:

1. Проверьте, установлен ли kdump в системе:

   rpm -q kexec-tools
   

   Вывод, если пакет установлен:

   kexec-tools-2.0.17-11.el8.x86_64
   

   Вывод, если пакет не установлен:

   package kexec-tools is not installed
   

2. Установите kdump и другие необходимые пакеты:

   dnf install kexec-tools
   

Настройка kdump в командной строке#

При планировании и создании kdump среды важно знать, сколько места требуется для файла аварийного дампа.

Команда makedumpfile --mem-usage оценивает, сколько места требуется для файла аварийного дампа. Создает отчет об использовании памяти. Отчет поможет определить уровень дампа и какие страницы можно безопасно исключить.

Выполните следующую команду, чтобы создать отчет об использовании памяти:

# makedumpfile --mem-usage /proc/kcore

TYPE        PAGES    EXCLUDABLE    DESCRIPTION
-------------------------------------------------------------
ZERO                    501635      yes        Pages filled with zero
CACHE                  51657       yes        Cache pages
CACHE_PRIVATE 5442        yes        Cache pages + private
USER                    16301       yes        User process pages
FREE                     77738211    yes        Free pages
KERN_DATA.        1333192     no         Dumpable kernel data

Настройка использования памяти kdump#

Память для kdump резервируется во время загрузки системы. Размер настраивается в системном файле конфигурации Grand Unified Bootloader (GRUB). Размер памяти зависит от значения опции crashkernel=, указанной в файле конфигурации, и размера физической памяти системы.

Опция crashkernel= может быть определена несколькими способами. Можно указать значение crashkernel= или настроить параметр auto. Параметр crashkernel=auto резервирует память автоматически, исходя из общего объема физической памяти в системе. При настройке ядро автоматически резервирует соответствующий объем необходимой памяти для «ядра захвата». Это помогает предотвратить ошибки нехватки памяти (OOM).

Чтобы настроить использования памяти kdump, выполните следующие шаги:

1. Отредактируйте файл /etc/default/grub.

2. Установите опцию crashkernel=:

   Например, чтобы зарезервировать 128 МБ памяти, используйте следующее:

   crashkernel=128M
   

   Кроме того, можно установить объем зарезервированной памяти переменной в зависимости от общего объема установленной памяти. Синтаксис резервирования памяти в переменную: crashkernel=<range1>:<size1>,<range2>:<size2>. Например:

   crashkernel=512M-2G:64M,2G-:128M
   

   В приведенном примере резервируется 64 МБ памяти, если общий объем системной памяти составляет от 512 МБ до 2 ГБ. Если общий объем памяти превышает 2 ГБ, резервируется 128 МБ.

   Смещение зарезервированной памяти: некоторым системам требуется резервировать память с определенным фиксированным смещением, поскольку резервирование crashkernel происходит очень рано, и требуется зарезервировать некоторую область для специального использования. Если установлено смещение, зарезервированная память начинается там. Чтобы компенсировать зарезервированную память, используйте следующий синтаксис:

   crashkernel=128M@16M
   

   В приведенном выше примере kdump резервируется 128 МБ памяти, начиная с 16 МБ (физический адрес 0x01000000). Если параметр смещения установлен на 0 или отсутствует, kdump автоматически смещается зарезервированная память. Также можно использовать этот синтаксис при настройке резервирования переменной памяти. В этом случае смещение всегда указывается последним (например, crashkernel=512M-2G:64M,2G-:128M@16M).

3. Используйте следующую команду для обновления файла конфигурации GRUB:

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

   Примечание

   Альтернативный способ настроить память для kdump — добавить опцию crashkernel=<SOME_VALUE> к переменной kernelopts с помощью команды grub2-editenv, которая обновит все загрузочные записи. Или можно использовать утилиту grubby для обновления одной загрузочной записи, нескольких загрузочных записей или всех загрузочных записей.

kdump с использованием системных ролей#

Параметры, используемые для системных ролей SberLinux OS Server дампа ядра, следующие:

Установите основные параметры дампа ядра на нескольких системах, используя системную роль dump, запустив Ansible playbook.

Настройка kdump с использованием Ansible playbook#

1. Создайте новый файл playbook.yml со следующим содержимым:

   --- - hosts: kdump-test
   vars:
   kdump_path: /var/crash
   roles:
   - sberlinux-system-roles.kdump
   

2. При необходимости проверьте синтаксис playbook:

   ansible-playbook --syntax-check playbook.yml
   

3. Запустите playbook в файле inventory:

   ansible-playbook -i inventory_file /path/to/file/playbook.yml
   

Настройка цели kdump#

Аварийный дамп обычно хранится в виде файла в локальной файловой системе и записывается непосредственно на устройство. Кроме того, можно настроить отправку аварийного дампа по сети с использованием протоколов NFS или SSH. Одновременно устанавливается только один из этих параметров для сохранения файла аварийного дампа. Поведение по умолчанию — хранение в каталоге /var/crash/ локальной файловой системы.

Чтобы сохранить файл аварийного дампа в каталоге /var/crash/ локальной файловой системы, отредактируйте файл /etc/kdump.conf и укажите путь:

path /var/crash

Параметр path /var/crash представляет собой путь к файловой системе, в которой kdump сохраняет файл аварийного дампа. Когда указана цель в /etc/kdump.conf, то path относится к указанной цели дампа.

Если цель не указана в файле /etc/kdump.conf, то path представляет собой абсолютный путь от корневого каталога. В зависимости от того, что смонтировано в текущей системе, цель дампа и скорректированный путь выбираются автоматически.

kdump сохраняет файл аварийного дампа в каталоге /var/crash/var/crash, когда цель смонтирована в /var/crash и параметр path установлен как /var/crash в файле /etc/kdump.conf.

В данном примере файловая система ext4 уже смонтирована в /var/crash и path установлен как /var/crash:

# grep -v ^# /etc/kdump.conf | grep -v ^$
ext4 /dev/mapper/vg00-varcrashvol
path /var/crash
core_collector makedumpfile -c --message-level 1 -d 31

Эти результаты в /var/crash/var/crash пути. Чтобы решить эту проблему, используйте опцию path / вместо path /var/crash.

• Чтобы изменить локальный каталог, в котором должен быть сохранен аварийный дамп, от имени пользователя с административными полномочиями отредактируйте файл конфигурации /etc/kdump.conf, как описано ниже:

  1. Удалите символ решетки («#») в начале строки #path /var/crash.

  2. Замените значение предполагаемым путем к каталогу. Например:

  path /usr/local/cores
  

  Примечание

  Каталог, определенный как цель kdump с помощью директивы пути, должен существовать при запуске службы kdump systemd, иначе служба не работает.

• Чтобы записать файл в другой раздел, от имени пользователя с административными полномочиями, отредактируйте файл конфигурации /etc/kdump.conf, как описано ниже.

  • Удалите символ решетки (#) в начале строки #ext4, в зависимости от выбора:

    • имени устройства (строка #ext4 /dev/vg/lv_kdump)

    • метки файловой системы (строка #ext4 LABEL=/boot)

    • UUID (строка #ext4 UUID=03138356-5e61-4ab3-b58e-27507ac41937)

    • записи аварийного дампа непосредственно на устройство, для этого отредактируйте /etc/kdump.conf файл конфигурации:

      • Удалите символ решетки (#) в начале строки #raw /dev/vg/lv_kdump.

      • Замените значение предполагаемым именем устройства. Например:

      raw /dev/sdb1
      

• Чтобы сохранить аварийный дамп на удаленной машине с использованием протокола NFS, отредактируйте /etc/kdump.conf файл конфигурации:

  • Удалите символ решетки (#) в начале строки #nfs my.server.com:/export/tmp.

  • Замените значение допустимым именем хоста и путем к каталогу. Например:

  nfs penguin.example.ru:/export/cores
  

• Чтобы сохранить аварийный дамп на удаленной машине с использованием SSH-протокола, отредактируйте /etc/kdump.conf файл конфигурации:

  • Удалите символ решетки (»#») в начале строки #ssh user@my.server.com.

  • Замените значение допустимым именем пользователя и именем хоста.

  • Включите свой ssh-ключ в конфигурацию.

• Удалите символ решетки с начала строки #sshkey /root/.ssh/kdump_id_rsa.

  • Измените значение на расположение ключа, действительного на сервере, на который выполняется дамп. Например:

  ssh john@penguin.example.ru
  sshkey /root/.ssh/mykey
  

Настройка сборщика ядер kdump#

Служба kdump использует core_collector программу для захвата образа аварийного дампа. В SberLinux OS Server утилита makedumpfile является основным сборщиком по умолчанию. Это помогает уменьшить файл дампа:

• сжатие размера файла аварийного дампа и копирование только необходимых страниц с использованием различных уровней;

• исключение ненужных страниц аварийного дампа;

• фильтрация типов страниц для включения в аварийный дамп.

Синтаксис core_collector:

core_collector makedumpfile -l --message-level 1 -d 31

Опции core_collector указаны в таблице ниже.

Для настройки core_collector выполните следующие шаги:

1. От имени пользователя с административными полномочиями отредактируйте файл конфигурации /etc/kdump.conf. Удалите символ решетки (#) в начале файла #core_collector makedumpfile -l --message-level 1 -d 31.

2. Чтобы включить сжатие файла аварийного дампа, выполните:

   core_collector makedumpfile -l --message-level 1 -d 31
   

   Параметр -l указывает формат сжатого файла. Параметр -d указывает уровень дампа как 31.

   Параметр --message-level указывает уровень сообщения как 1.

Кроме того, доступны следующие примеры с опциями -c и -p:

• Чтобы сжать файл аварийного дампа, используйте -c:

core_collector makedumpfile -c -d 31 --message-level 1

• Чтобы сжать файл аварийного дампа, используйте -p:

core_collector makedumpfile -p -d 31 --message-level 1

Настройка реакции kdump на сбой по умолчанию#

По умолчанию, если kdump не удается создать файл аварийного дампа в настроенном целевом расположении, система перезагружается, и дамп при этом теряется. Чтобы изменить это поведение, выполните описанную ниже процедуру.

Для настройки реакции kdump на сбой выполните следующий сценарий:

1. От имени пользователя с административным полномочиями удалите символ решетки (» #») в начале строки #failure_action в файле конфигурации /etc/kdump.conf:

2. Замените значение желаемым действием.

   failure_action poweroff
   

Файл конфигурации для kdump#

Файл конфигурации /etc/sysconfig/kdump управляет параметрами командной строки ядра kdump.

Для большинства настроек используйте параметры по умолчанию. Однако в некоторых сценариях может потребоваться изменить определенные параметры для управления kdump. Например, изменение для добавления командной строки ядра kdump для получения подробного вывода отладки.

В данном разделе содержится информация об изменении параметров KDUMP_COMMANDLINE_REMOVE и KDUMP_COMMANDLINE_APPEND. Информацию о дополнительных параметрах конфигурации см. в файле /etc/sysconfig/kdump.

KDUMP_COMMANDLINE_REMOVE удаляет аргументы из текущей командной строки kdump. Опция удаляет параметры, которые могут вызвать ошибки или сбои при загрузке ядра. Эти параметры могут передаваться из предыдущего процесса KDUMP_COMMANDLINE или унаследованы от файла /proc/cmdline. Когда данная переменная не настроена, она наследует все значения из файла /proc/cmdline. Настройка параметра также предоставляет информацию, полезную при отладке проблемы.

Тестирование конфигурации kdump#

Чтобы проверить, что процесс аварийного дампа работает и действителен, выполните следующий сценарий:

1. Перезагрузите систему с включенным kdump.

2. Убедитесь, что kdump запущен:

   **# systemctl is-active kdump**
   active
   

3. Вызовите принудительный сбой ядра:

   echo 1 > /proc/sys/kernel/sysrq
   
   echo c > /proc/sysrq-trigger
   

   Примечание

   После сбоя ядра потребуется перезагрузка.

После повторной загрузки файл с адресом address-YYYY-MM-DD-HH:MM:SS/vmcore создается в месте, которое указано в файле /etc/kdump.conf (по умолчанию /var/crash/).

Включение kdump#

Чтобы включить и запустить службу kdump для всех ядер, установленных на машине, выполните следующие действия:

1. Добавьте параметр командной строки crashkernel=auto ко всем установленным ядрам:

   grubby --update-kernel=ALL --args="crashkernel=auto"
   

2. Включите службу kdump:

   systemctl enable --now kdump.service
   

3. Опционально. Убедитесь, что служба kdump запущена:

   systemctl status kdump.service
   
   ○ kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled)
   Active: active (live)
   

Включение kdump для определенного установленного ядра#

Чтобы включить службу kdump для определенного ядра на машине, выполните следующие шаги:

1. Выведите список ядер, установленных на машине:

   ls -a /boot/vmlinuz-
   
   /boot/vmlinuz-0-rescue-<hash>/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=auto"
   

3. Включите службу kdump:

   systemctl enable --now kdump.service
   

4. Опционально. Убедитесь, что служба kdump запущена:

   systemctl status kdump.service
   
   ○ kdump.service - Crash recovery kernel arming
   Loaded: loaded (/usr/lib/systemd/system/kdump.service; enabled; vendor preset: disabled)
   Active: active (live)
   

Отключение службы kdump#

Чтобы отключить службу kdump во время загрузки, выполните процедуру описанную ниже:

1. Чтобы остановить службу kdump в текущем сеансе, введите команду:

   systemctl stop kdump.service
   

2. Чтобы отключить службу kdump, используйте:

   systemctl disable kdump.service
   

Устранение неполадок#

Если для kptr_restrict не установлено значение (1) и если KASLR включен, содержимое файла /proc/kcore генерируется как нулевые значения. Следовательно, служба kdumpctl не может получить доступ к /proc/kcore и загрузить аварийное ядро.

Чтобы обойти проблему, в файле /usr/share/doc/kexec-tools/kexec-kdump-howto.txt отображается предупреждающее сообщение, в котором рекомендуется параметр kptr_restrict=1.

Чтобы убедиться, что служба kdumpctl загружает аварийное ядро, убедитесь, что в файле sysctl.conf указано значение kernel.kptr_restrict = 1.

Поддерживаемые конфигурации и цели kdump#

Чтобы kdump мог захватить дамп сбоя ядра и сохранить его для дальнейшего анализа, часть системной памяти должна быть постоянно зарезервирована для «ядра захвата». Зарезервированная часть системной памяти недоступна основному ядру.

В таблице ниже перечислены минимальные требования к памяти для автоматического резервирования объема памяти kdump. Размер изменяется в зависимости от общего объема доступной физической памяти.

На многих системах kdump умеет оценивать объем требуемой памяти и автоматически резервировать ее. Таоке поведение включено по умолчанию, но работает только в системах с более чем определенным объемом доступной памяти.

Минимальный порог для автоматического резервирования памяти#

В некоторых системах возможно автоматическое выделение памяти kdump с помощью параметра crashkernel=auto в файле конфигурации загрузчика, либо путем включения этой опции в графической утилите настройки. Чтобы автоматическое резервирование работало, в системе должен быть доступен определенный объем общей памяти.

Для архитектуры x86_64 пороговое значение автоматического выделения памяти - 2 ГБ. Если в системе память меньше указанного порогового значения, необходимо настроить память вручную.

Поддерживаемые цели kdump#

Когда фиксируется сбой ядра, файл vmcore может быть записан непосредственно на устройство, сохранен в виде файла в локальной файловой системе или отправлен по сети. В приведенной ниже таблице содержится полный список целей, которые в настоящее время поддерживаются или явно не поддерживаются kdump.

Поддерживаемые уровни фильтрации kdump#

Чтобы уменьшить размер файла дампа, kdump использует основной сборщик makedumpfile для сжатия данных и, при необходимости, для исключения нежелательной информации. В приведенной ниже таблице содержится полный список уровней фильтрации, которые в настоящее время поддерживаются утилитой makedumpfile.

Поддерживаемые ответы на ошибки по умолчанию#

По умолчанию, когда kdump не может создать дамп ядра, операционная система перезагружается. Однако можно настроить kdump на выполнение другой операции в случае, если ему не удастся сохранить дамп ядра в первичную цель. В таблицах ниже перечислены все действия по умолчанию, которые в настоящее время поддерживаются.

Использование параметра final_action#

Final_action позволяет использовать некоторые дополнительные операции, такие как reboot, halt и poweroff после успешного kdump или после завершения вызванного механизма failure_response с использованием shell или dump_to_rootfs. Если параметр не указан, по умолчанию используется reboot.

Для использования параметра выполните следующий сценарий:

1. Отредактируйте файл /etc/kdump.conf и добавьте параметр final_action:

   final_action <reboot | halt | poweroff>
   

2. Перезапустите службу kdump:

   kdumpctl restart
   

Установка лимитов для приложений#

Используйте функциональные возможности ядра групп управления (cgroups) для установки ограничений, определения приоритетов или изоляции аппаратных ресурсов процессов. Это позволяет детально контролировать использование ресурсов приложениями, чтобы использовать их более эффективно.

Общие сведения о контрольных группах#

Группы управления — это функция ядра, которая позволяет организовывать процессы в иерархически упорядоченные группы — cgroups. Иерархия (дерево групп управления) определяется путем предоставления структуры виртуальной файловой системе cgroups, смонтированной по умолчанию в каталоге /sys/fs/cgroup/. Диспетчер систем и служб systemd использует cgroups для организации всех модулей и служб, которыми он управляет. Кроме того, можно вручную управлять иерархиями cgroups, создавая и удаляя подкаталоги в каталоге /sys/fs/cgroup/.

Контроллеры ресурсов (компонент ядра) затем изменяют поведение процессов в cgroups, ограничивая, расставляя приоритеты или распределяя системные ресурсы (такие, как процессорное время, память, пропускная способность сети или различные комбинации) этих процессов.

Дополнительным преимуществом cgroups является объединение процессов, позволяющее разделить аппаратные ресурсы между приложениями и пользователями. Тем самым может быть достигнуто повышение общей эффективности, стабильности и безопасности пользовательской среды.

Группы управления версии 1 (cgroups-v1) обеспечивают иерархию контроллеров для каждого ресурса. Это означает, что каждый ресурс, такой как ЦП, память, ввод-вывод и т.д., имеет свою собственную иерархию групп управления. Можно комбинировать различные иерархии групп управления таким образом, чтобы один контроллер мог координировать свои действия с другим при управлении соответствующими ресурсами. Однако два контроллера могут принадлежать к разным иерархиям процессов, что не позволяет обеспечить их надлежащую координацию. Контроллеры cgroups-v1 разрабатывались в течение большого промежутка времени, и в результате поведение и имена их управляющих файлов неодинаковы.

Проблемы с координацией контроллеров, возникшие из-за гибкости иерархии, привели к разработке групп управления версии 2. Группа управления версии 2 (cgroups-v2) обеспечивает единую иерархию группы управления, в которой монтируются все контроллеры ресурсов. Поведение управляющего файла и его наименование одинаковы для разных контроллеров.

Формат вывода cgroups и irqs для обеспечения лучшей читаемости выводом команд tuna show_threads для утилиты cgroup структурирован в зависимости от размера терминала. Также можно настроить дополнительные интервалы между выводимыми данными cgroups, добавив параметр -z в команду new --spaced или show_threads. В результате можно просматривать выходные данные cgroups в удобочитаемом формате, который можно адаптировать к размеру терминала.

Контроллеры ресурсов ядра#

Функциональность контрольных групп обеспечивается контроллерами ресурсов ядра. SberLinux OS Server поддерживает различные контроллеры для контрольных групп версии 1 (cgroups-v1) и контрольных групп версии 2 (cgroups-v2).

Контроллер ресурсов, также называемый подсистемой группы управления, представляет собой подсистему ядра, представляющую один ресурс, такой как процессорное время, память, пропускная способность сети или дисковый ввод-вывод. Ядро предоставляет ряд контроллеров ресурсов, которые автоматически монтируются системой systemd и диспетчером служб. Найдите список смонтированных в данный момент контроллеров ресурсов в /proc/cgroups файле.

Доступны следующие контроллеры cgroups-v1:

• blkio - устанавливает ограничения на доступ ввода/вывода к блочным устройствам и от них.

• cpu- настраивает параметры планировщика Completely Fair Scheduler (CFS) для задач контрольной группы. Монтируется вместе со cpuacct контроллером на одном креплении.

• cpuacct - создает автоматические отчеты по ресурсам процессора, используемым задачами в контрольной группе. Монтируется вместе со cpu контроллером на одном креплении.

• cpuset - использует ограничения задач группы управления только на указанном подмножестве ЦП и указания задачам использовать память только на указанных узлах памяти.

• devices - контролирует доступ к устройствам для задач в группе управления.

• freezer - используется для приостановки или возобновления задач в контрольной группе.

• memory - используется для установки ограничений на использование памяти задачами в контрольной группе и генерирует автоматические отчеты о ресурсах памяти, используемых этими задачами.

• net_cls - помечает сетевые пакеты идентификатором класса (classid), что позволяет контроллеру трафика Linux (tc команде) идентифицировать пакеты, исходящие от конкретной задачи группы управления. Подсистема net_cls.

• net_filter iptables - использует тег для выполнения действий с пакетами. Сетевые сокеты net_filter помечаются идентификатором межсетевого экрана (fwid), который позволяет межсетевому экрану Linux (через iptables команду) идентифицировать пакеты, исходящие от конкретной задачи группы управления.

• net_prio - устанавливает приоритет сетевого трафика.

• pids - устанавливает лимиты на количество процессов и их потомков в контрольной группе.

• perf_event - группирует задачи для мониторинга с помощью perf утилиты мониторинга производительности и создания отчетов.

• rdma - устанавливает ограничения на определенные ресурсы Remote Direct Memory Access/InfiniBand в контрольной группе.

• hugetlb - использует для ограничения использования страниц виртуальной памяти большого размера задачами в контрольной группе.

Доступны следующие контроллеры cgroups-v2:

• io - продолжение blkio из cgroups-v1;

• memory - продолжение memory из cgroups-v1;

• pids - аналог pids из cgroups-v1;

• rdma - аналог rdma из cgroups-v1;

• cpu - продолжение cpu и cpuacct из cgroups-v1;

• cpuset - поддержка основных функций (cpus{,.effective}, mems{,.effective}) с новой функцией разделов;

• perf_event - встроенная поддержка, нет явного управляющего файла. Указывает v2 cgroup в качестве параметра команды perf, которая будет профилировать все задачи в этом файле cgroup.

Пространства имен#

Пространства имен — один из наиболее важных методов организации и идентификации программных объектов.

Пространство имен заключает глобальный системный ресурс (например, точку монтирования, сетевое устройство или имя хоста) в абстракцию, благодаря которой для процессов внутри пространства имен кажется, что у них есть собственный изолированный экземпляр глобального ресурса. Одной из наиболее распространенных технологий, использующих пространства имен, являются контейнеры.

Изменения конкретного глобального ресурса видны только процессам в этом пространстве имен и не влияют на остальную часть системы или другие пространства имен.

Чтобы проверить, членом каких пространств имен является процесс, проверьте символические ссылки в каталоге /proc/<PID>/ns/.

В таблице ниже представлены поддерживаемые пространства имен и ресурсы, которые они изолируют.

Установка ограничений ЦП для приложений с помощью cgroups-v1#

Иногда приложение потребляет много процессорного времени, что может негативно сказаться на общем состоянии среды. Используйте виртуальную файловую систему /sys/fs/, чтобы настроить ограничения ЦП для приложения с помощью контрольных групп версии 1 (cgroups-v1).

# mount -l | grep cgroup
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,seclabel,mode=755)
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,cpu,cpuacct)
cgroup on /sys/fs/cgroup/perf_event type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,perf_event)
cgroup on /sys/fs/cgroup/pids type cgroup (rw,nosuid,nodev,noexec,relatime,seclabel,pids)
...

Для установки ограничений ЦП приложений выполните следующие действия:

1. Определите идентификатор процесса (PID) приложения, которое необходимо ограничить потреблением ЦП:

   top
   top - 12:28:42 up  1:06,  1 user,  load average: 1.02, 1.02, 1.00
   Tasks: 266 total,   6 running, 260 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 11.0 us,  1.2 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.2 st
   MiB Mem :   1826.8 total,    287.1 free,   1054.4 used,    485.3 buff/cache
   MiB Swap:   1536.0 total,   1396.7 free,    139.2 used.    608.3 avail Mem
   
       PID USER      PR  NI        VIRT        RES     SHR   S  %CPU  %MEM      TIME+    COMMAND
    6955   root      20   0   228440       1752     1472  R     20.6          0.1  47:11.43    sha1sum
    5760   jdoe      20   0 3604956 208832   65316 R        2.3        11.2   0:43.50    gnome-shell
    6448  jdoe      20   0    743836     31736  19488 S        0.7          1.7   0:08.25    gnome-terminal-
      505   root      20   0               0             0          0   I        0.3          0.0   0:03.39    kworker/u4:4-events_unbound
    4217   root      20   0       74192        1612    1320  S       0.3           0.1   0:01.19     spice-vdagentd
   ...
   

   Пример вывода программы top показывает, что PID 6955 (иллюстративное приложение sha1sum) потребляет много ресурсов ЦП.

2. Создайте подкаталог в каталоге контроллера ресурсов cpu:

   mkdir /sys/fs/cgroup/cpu/Example/
   

   Вышеупомянутый каталог представляет собой группу управления, в которую нужно поместить определенные процессы и применить к ним определенные ограничения ЦП. В то же время в каталоге будут созданы некоторые файлы интерфейса cgroups-v1 и файлы, относящиеся к контроллеру cpu.

3. Настройте лимиты cpu для контрольной группы:

   ll /sys/fs/cgroup/cpu/Example/
   
   -rw-r—r--. 1 root root 0 Mar 11 11:42 cgroup.clone_children
   -rw-r—r--. 1 root root 0 Mar 11 11:42 cgroup.procs
   -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.stat
   -rw-r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage
   -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_all
   -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu
   -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_sys
   -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_percpu_user
   -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_sys
   -r—r—r--. 1 root root 0 Mar 11 11:42 cpuacct.usage_user
   -rw-r—r--. 1 root root 0 Mar 11 11:42 cpu.cfs_period_us
   -rw-r—r--. 1 root root 0 Mar 11 11:42 cpu.cfs_quota_us
   -rw-r—r--. 1 root root 0 Mar 11 11:42 cpu.rt_period_us
   -rw-r—r--. 1 root root 0 Mar 11 11:42 cpu.rt_runtime_us
   -rw-r—r--. 1 root root 0 Mar 11 11:42 cpu.shares
   -r—r—r--. 1 root root 0 Mar 11 11:42 cpu.stat
   -rw-r—r--. 1 root root 0 Mar 11 11:42 notify_on_release
   -rw-r—r--. 1 root root 0 Mar 11 11:42 tasks
   

   Где:

   • cpu.cfs_period_us – период времени в микросекундах (мкс, представленный здесь как нас), в рамках которого производится контроль и перераспределение доступа контрольной группы к ЦП. Верхний предел составляет 1 секунду, а нижний предел — 1000 микросекунд.

   • cpu.cfs_quota_us – общее количество времени в микросекундах, в течение которого все процессы в группе управления выполняются продолжительностью в один период (как определено параметром cpu.cfs_period_us). Как только процессы в контрольной группе в течение одного периода израсходуют все время, указанное в квоте, они будут регулироваться на оставшуюся часть периода, и им не разрешается выполняться до следующего периода. Нижний предел составляет 1000 микросекунд.

   Приведенные выше примеры команд устанавливают ограничения времени ЦП, чтобы все процессы в совокупности в Example могли работать только в течение 0,2 секунды (определяется cpu.cfs_quota_us) из каждой 1 секунды (определяется cpu.cfs_period_us).

4. Добавьте PID приложения в группу управления Example:

   echo "6955" > /sys/fs/cgroup/cpu/Example/cgroup.procs
   

   или

   echo "6955" > /sys/fs/cgroup/cpu/Example/tasks
   

   Предыдущая команда гарантирует, что желаемое приложение станет членом контрольной группы Example и, следовательно, не превысит ограничения ЦП. PID должен представлять существующий процесс в системе. Здесь PID 6955 был назначен процессу sha1sum /dev/zero & для иллюстрации варианта использования cpu контроллера.

5. Убедитесь, что приложение работает в указанной группе управления:

   # cat /proc/6955/cgroup
   
   12:cpuset:/
   11:hugetlb:/
   10:net_cls,net_prio:/
   9:memory:/user.slice/user-1000.slice/user@1000.service
   8:devices:/user.slice
   7:blkio:/
   6:freezer:/
   5:rdma:/
   4:pids:/user.slice/user-1000.slice/user@1000.service
   3:perf_event:/
   2:cpu,cpuacct:/Example
   1:name=systemd:/user.slice/user-1000.slice/user@1000.service/terminal-server.service
   

   В приведенном выше примере выходных данных показано, что процесс нужного приложения выполняется в группе управления Example, которая применяет ограничения cpu к процессу приложения.

6. Определите текущее потребление регулируемым приложением cpu:

   # top
   top - 12:28:42 up  1:06,  1 user,  load average: 1.02, 1.02, 1.00
   Tasks: 266 total,   6 running, 260 sleeping,   0 stopped,   0 zombie
   %Cpu(s): 11.0 us,  1.2 sy,  0.0 ni, 87.5 id,  0.0 wa,  0.2 hi,  0.0 si,  0.2 st
   MiB Mem :   1826.8 total,    287.1 free,   1054.4 used,    485.3 buff/cache
   MiB Swap:   1536.0 total,   1396.7 free,    139.2 used.    608.3 avail Mem
   
       PID USER      PR  NI        VIRT        RES     SHR   S  %CPU  %MEM      TIME+    COMMAND
    6955   root      20   0   228440       1752     1472  R     20.6          0.1  47:11.43    sha1sum
    5760   jdoe      20   0 3604956 208832   65316 R        2.3        11.2   0:43.50    gnome-shell
    6448  jdoe      20   0    743836     31736  19488 S        0.7          1.7   0:08.25    gnome-terminal-
      505   root      20   0               0             0          0   I        0.3          0.0   0:03.39    kworker/u4:4-events_unbound
    4217   root      20   0       74192        1612    1320  S       0.3           0.1   0:01.19     spice-vdagentd
   ...
   

   Обратите внимание, что потребление ЦП PID 6955 уменьшилось с 99% до 20%.

   Примечание

   Аналогом cgroups-v2 для cpu.cfs_period_us и cpu.cfs_quota_us является cpu.max файл. Файл cpu.max доступен через cpu контроллер.

Команда rteval#

Команда rteval отображает сводный отчет с количеством загрузок программы, потоков измерения и соответствующим процессором, который запускал эти потоки. Эта информация помогает оценить производительность ядра реального времени под нагрузкой на определенных аппаратных платформах.

Отчет rteval записывается в XML-файл вместе с журналом загрузки системы и сохраняется в сжатом файле rteval-<date>-N-tar.bz2. Где date указывает дату создания отчета и N является счетчиком для N-го запуска.

Чтобы сгенерировать отчет rteval, введите следующую команду:

# rteval --summarize rteval-<date>-N.tar.bz2

Настройка политик CPU Affinity и NUMA с помощью systemd#

Параметры управления ЦП, управления памятью и пропускной способности ввода-вывода связаны с разделением доступных ресурсов.

Настройка привязки ЦП с помощью systemd#

Настройки привязки ЦП помогают ограничить доступ определенного процесса к некоторым ЦП. По сути, планировщик ЦП никогда не планирует выполнение процесса на ЦП, который не находится в маске сходства процесса.

Маска привязки ЦП по умолчанию применяется ко всем службам, управляемым systemd.

Чтобы настроить маску соответствия ЦП для конкретной службы systemd, systemd предоставляет CPUAffinity= как параметр файла модуля, так и параметр конфигурации менеджера в файле /etc/systemd/system.conf.

Параметр файла модуля CPUAffinity= задает список ЦП или диапазонов ЦП, которые объединяются и используются в качестве маски сходства. Параметр CPUAffinity в файле /etc/systemd/system.conf определяет маску сходства для процесса с идентификационным номером (PID) 1 и всех процессов, ответвленных от PID1. Затем нужно переопределить CPUAffinity для каждой службы.

Чтобы установить маску привязки ЦП для конкретной службы systemd, используйте параметр файла модуля CPUAffinity:

1. Проверьте значения параметра файла модуля CPUAffinity в выбранном сервисе:

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

2. В качестве пользователя с административными полномочиями установите требуемое значение параметра файла модуля CPUAffinity для диапазонов ЦП, используемых в качестве маски сходства:

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

3. Перезапустите службу, чтобы применить изменения:

   systemctl restart <service name>
   

Чтобы установить маску соответствия ЦП для конкретной службы systemd, используйте параметр конфигурации менеджера:

1. Отредактируйте файл /etc/systemd/system.conf:

   vi /etc/systemd/system.conf
   

2. Найдите параметр CPUAffinity= и установите номера процессоров.

3. Сохраните отредактированный файл и перезапустите сервер, чтобы изменения вступили в силу.

Настройка политик NUMA с помощью systemd#

Non-uniform memory access (NUMA) — это конструкция подсистемы памяти компьютера, в которой время доступа к памяти зависит от расположения физической памяти относительно процессора.

Память, близкая к ЦП, имеет меньшую задержку (локальная память), чем память, локальная для другого ЦП (внешняя память) или совместно используемая набором ЦП. Политика NUMA определяет, из какого узла памяти ядро выделяет страницы физической памяти для процесса.

systemd предоставляет параметры файла модуля NUMAPolicy и NUMAMask для управления политиками выделения памяти для служб.

Чтобы установить политику памяти NUMA с помощью параметра файла модуля NUMAPolicy, выполните следующие шаги:

1. Проверьте значения параметра файла модуля NUMAPolicy:

   systemctl show --property <NUMA_policy_configuration_option> <service_name>
   

   Где:

   • <NUMA_policy_configuration_option> - значения параметра файла модуля;

   • <service_name> - имя службы.

2. В качестве пользователя с административными полномочиями установите требуемый тип политики в параметре модуля NUMAPolicy:

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

3. Перезапустите службу, чтобы применить изменения.

   systemctl restart <service name>
   

Чтобы установить глобальный параметр NUMAPolicy с помощью параметра конфигурации менеджера:

1. Найдите в файле /etc/systemd/system.conf параметр NUMAPolicy.

2. Измените тип политики, сохраните файл.

3. Перезагрузите конфигурацию systemd службы:

   systemd daemon-reload
   

4. Перезагрузите сервер.

При настройке строгой политики NUMA, например bind, убедитесь, что также правильно установлен параметр файла модуля CPUAffinity=.

Параметры конфигурации политики NUMA для systemd#

Systemd предоставляет следующие параметры для настройки политики NUMA:

NUMAPolicy - управляет политикой памяти NUMA исполняемых процессов. Возможны следующие типы политик:

• default;

• preferred;

• bind;

• interleave;

• local.

NUMAMask - управляет списком узлов NUMA, связанным с выбранной политикой NUMA.

Обратите внимание, что параметр NUMAMask не требуется указывать для следующих политик:

• default;

• local.

Для предпочтительной политики в списке указан только один узел NUMA.

Повышение безопасности с помощью подсистемы целостности ядра#

Усильте защиту своей системы, используя компоненты подсистемы целостности ядра. В следующих разделах представлены соответствующие компоненты и даны рекомендации по их настройке.

Подсистема целостности ядра#

Подсистема целостности — это часть ядра, отвечающая за поддержание целостности данных всей системы. Данная подсистема помогает сохранить состояние определенной системы неизменным с момента ее создания и, таким образом, предотвращает нежелательное изменение определенных системных файлов.

Подсистема целостности ядра может использовать доверенный платформенный модуль (TPM), чтобы повысить безопасность системы. TPM — это спецификация Trusted Computing Group (TCG) для важных криптографических функций. Модули TPM обычно представляют собой специальное аппаратное обеспечение, которое подключается к материнской плате платформы и предотвращает программные атаки, предоставляя криптографические функции из защищенной и защищенной от несанкционированного доступа области аппаратного чипа. Некоторые из функций TPM:

• генератор случайных чисел;

• генератор и безопасное хранилище криптографических ключей;

• хеш-генератор;

• удаленная аттестация.

Доверенные и зашифрованные ключи#

В следующем разделе представлены доверенные и зашифрованные ключи как важная часть повышения безопасности системы.

Надежные и зашифрованные ключи — это симметричные ключи переменной длины, сгенерированные ядром, которые используют службу набора ключей ядра. Тот факт, что этот тип ключей никогда не появляется в пользовательском пространстве в незашифрованном виде, означает, что их целостность может быть проверена. Программы пользовательского уровня могут получить доступ к ключам только в виде зашифрованных больших двоичных объектов.

Для доверенных ключей требуется аппаратный компонент: микросхема доверенного платформенного модуля (Trusted Platform Module (TPM)), которая используется как для создания, так и для шифрования (запечатывания) ключей. Доверенный платформенный модуль запечатывает ключи с помощью 2048-битного ключа RSA, называемого корневым ключом хранилища (storage root key (SRK)).

Кроме того, пользователь может запечатать доверенные ключи с помощью набора значений для регистра конфигурации платформы (platform configuration register (PCR)) TPM. PCR содержит набор значений управления целостностью, которые отражают встроенное ПО, загрузчик и операционную систему. Это означает, что ключи, запечатанные PCR, могут быть расшифрованы доверенным платформенным модулем только в той же системе, в которой они были зашифрованы. Однако как только доверенный ключ, запечатанный PCR, загружен (добавлен в связку ключей) и, таким образом, проверены связанные с ним значения PCR, он может быть обновлен новыми (или будущими) значениями PCR, так что новое ядро, например, может быть загруженным. Один ключ также можно сохранить в виде нескольких больших двоичных объектов, каждый из которых имеет разные значения PCR.

Зашифрованные ключи не требуют доверенного платформенного модуля, поскольку они используют расширенный стандарт шифрования ядра (Advanced Encryption Standard (AES)), что делает их быстрее, чем доверенные ключи. Зашифрованные ключи создаются с использованием случайных чисел, сгенерированных ядром, и шифруются главным ключом при экспорте в большие двоичные объекты пользовательского пространства. Главный ключ — это либо доверенный ключ, либо пользовательский ключ. Если мастер-ключ не является доверенным, зашифрованный ключ безопасен настолько, насколько безопасен пользовательский ключ, используемый для его шифрования.

Работа с доверенными ключами#

В следующем разделе описывается, как создавать, экспортировать, загружать или обновлять доверенные ключи с помощью утилиты keyctl для повышения безопасности системы.

Чтобы создать доверенный ключ с помощью TPM, выполните:

keyctl **Add** trusted <name> "new <key_length> [options]" <key_ring>

• На основе синтаксиса создайте пример команды следующим образом:

# keyctl **Add** trusted kmk "new 32" @u

642500861

Команда создает доверенный ключ kmk длиной 32 байта (256 бит) и помещает его в связку ключей пользователя (@u). Ключи могут иметь длину от 32 до 128 байт (от 256 до 1024 бит).

• Чтобы просмотреть текущую структуру связок ключей ядра:

keyctl show

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

• Чтобы экспортировать ключ в большой двоичный объект пользовательского пространства, выполните:

keyctl pipe 642500861 > kmk.blob

Команда использует pipe подкоманду и серийный номер файла kmk.

• Чтобы загрузить доверенный ключ из большого двоичного объекта пользовательского пространства, используйте add подкоманду с большим двоичным объектом в качестве аргумента:

# keyctl **Add** trusted kmk "load `cat kmk.blob`" @u

268728824

• Создайте безопасные зашифрованные ключи на основе доверенного ключа, запечатанного TPM:

# keyctl **Add** encrypted <pass:quotes[name]> "new [format] <pass:quotes[key_type]>:<pass:quotes[primary_key_name]> <pass:quotes[keylength]>" <pass:quotes[key_ring]>

• На основе синтаксиса сгенерируйте зашифрованный ключ, используя уже созданный доверенный ключ:

# keyctl **Add** encrypted encr-key "new trusted:kmk 32" @u

159771175

Команда использует доверенный ключ, запечатанный TPM (kmk), созданный на предыдущем шаге, в качестве первичного ключа для создания зашифрованных ключей.

Работа с зашифрованными ключами#

Для управления зашифрованными ключами в целях повышения безопасности систем, в которых недоступен доверенный платформенный модуль (TPM), выполните следующий сценарий.

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