Обновление ядра Linux: плановое обслуживание и live patching

Зачем вообще регулярно обновлять ядро

Ядро Linux — самый привилегированный слой операционной системы: оно управляет доступом к памяти, планирует выполнение процессов, обрабатывает сетевой стек и работает с оборудованием напрямую. Уязвимость в ядре потенциально даёт злоумышленнику возможности, недоступные через уязвимость в обычном приложении — вплоть до полного контроля над системой или выхода за пределы изоляции контейнера на хосте с несколькими арендаторами.

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

uname -r
cat /proc/version

Обратная сторона обновлений — риск: новое ядро иногда приносит собственные регрессии, несовместимость с конкретным драйвером стороннего производителя или проблему производительности, которая проявляется не сразу. Именно поэтому обновление ядра — не разовое действие "поставить и забыть", а процесс, требующий планирования, тестового окна и понимания, как быстро откатиться, если что-то пойдёт не так.

Работающее ядро и установленный пакет — не всегда одно и то же

Частое заблуждение — считать, что после команды обновления пакетов (apt upgrade или yum update) сервер уже работает на новом ядре. На деле обновление ядра устанавливает новые файлы на диск, но само ядро загружается в память только один раз при старте системы, поэтому до перезагрузки сервер продолжает выполняться на прежней, уже загруженной версии.

uname -r
dpkg --list | grep linux-image
rpm -qa | grep kernel | sort -V

Если версия из uname -r отличается от самой свежей версии в списке установленных пакетов, это верный признак того, что обновление ядра уже готово к применению, но перезагрузка ещё не выполнялась. На серверах без автоматической перезагрузки после обновлений такое расхождение может незаметно сохраняться неделями, оставляя систему технически уязвимой, несмотря на формально выполненное обновление пакетов.

ls -la /boot | grep vmlinuz

Полезно периодически удалять старые неиспользуемые версии ядра (apt autoremove в Debian/Ubuntu, package-cleanup --oldkernels в RHEL-подобных системах с соответствующим пакетом утилит) — раздел /boot часто ограничен по размеру, и накопление десятка старых версий ядра способно заполнить его полностью, из-за чего следующее обновление ядра завершится ошибкой нехватки места, причём в самый неподходящий момент.

Стандартный процесс: обновление пакета ядра и перезагрузка

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

apt update
apt list --upgradable | grep linux-image
apt install linux-image-generic
reboot

yum check-update kernel
yum update kernel
reboot

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

uname -r
systemctl --failed
systemctl status nginx mysql php8.3-fpm

Команда systemctl --failed особенно полезна сразу после перезагрузки — она мгновенно покажет список сервисов, которые не смогли корректно запуститься, что зачастую случается из-за изменившихся имён сетевых интерфейсов, несовместимости стороннего модуля ядра или зависимости, не пережившей обновление, и требует немедленного внимания, а не обнаружения через час по жалобам пользователей.

Планирование окна обслуживания для перезагрузки

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

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

systemctl list-unit-files --state=enabled | grep -v "static\|masked"

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

Live patching: обновление ядра без перезагрузки

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

kpatch list
kpatch-dnf status

kpatch — решение, интегрированное в экосистему Red Hat Enterprise Linux и его производных (CentOS Stream, AlmaLinux, Rocky Linux), позволяющее применять исправления критичных уязвимостей ядра в виде отдельных модулей, загружаемых поверх работающего ядра. Похожий по идее механизм для Ubuntu называется Canonical Livepatch и распространяется как отдельная служба, подключаемая через специальный токен.

canonical-livepatch enable <TOKEN>
canonical-livepatch status --verbose

Оба решения бесплатны в базовой конфигурации для ограниченного числа серверов на аккаунт (у Canonical Livepatch — до нескольких машин без оплаты для личного использования, у kpatch — как часть подписки Red Hat для соответствующих систем), что делает их доступным способом закрыть самые критичные уязвимости ядра без перезагрузки даже для не самых крупных проектов.

KernelCare: коммерческое решение для более широкого круга дистрибутивов

KernelCare — стороннее коммерческое решение для live patching, поддерживающее заметно более широкий список дистрибутивов и версий ядра, чем встроенные решения отдельных вендоров, включая многие популярные у хостинг-провайдеров сборки CentOS, CloudLinux, Debian, Ubuntu и Amazon Linux.

curl -s https://repo.cloudlinux.com/kernelcare/kernelcare_install.sh | bash
kcarectl --update
kcarectl --uname -a

Практическая ценность KernelCare для хостинг-инфраструктуры — единая система патчинга ядра для парка серверов на разных дистрибутивах без необходимости координировать окна обслуживания под каждый сервер отдельно: агент периодически проверяет доступность новых патчей и применяет их автоматически в фоне, а команда kcarectl --uname -a показывает эффективную версию защищённости ядра, даже если формально установленный пакет ядра остался прежним.

Выбор между kpatch, Canonical Livepatch и KernelCare обычно определяется используемым дистрибутивом и готовностью платить за расширенную поддержку: для чистого RHEL-совместимого дистрибутива достаточно встроенного kpatch, для Ubuntu — Canonical Livepatch, а KernelCare имеет смысл там, где парк серверов разнороден по дистрибутивам или нужна поддержка версий, не покрытых бесплатными вариантами.

Ограничения live patching: не всё можно исправить на лету

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

На практике это означает, что live patching эффективно закрывает подмножество наиболее критичных уязвимостей (обычно связанных с повышением привилегий или удалённым выполнением кода) в разумные сроки после публикации, но не отменяет необходимость в регулярных полноценных обновлениях ядра с перезагрузкой — их по-прежнему нужно планировать, просто с меньшим давлением экстренности, поскольку самые срочные проблемы безопасности уже закрыты live-патчем.

Поставщики live patching обычно явно публикуют список покрытых CVE для каждой версии ядра — стоит сверяться именно с этим списком, а не полагаться на общее ощущение защищённости: наличие активной подписки на live patching не означает автоматической защиты от абсолютно всех новых уязвимостей ядра, обнаруженных после последнего планового обновления.

Откат, если новое ядро сломало сервер

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

grep menuentry /boot/grub/grub.cfg | cut -d"'" -f2
grub2-reboot 1
reboot

Команда grub2-reboot (или grub-reboot в некоторых дистрибутивах) задаёт пункт меню GRUB, который будет использован только при следующей перезагрузке, без изменения загрузчика по умолчанию для всех последующих перезапусков, — это удобно для проверки, действительно ли откат на предыдущее ядро решает проблему, прежде чем менять настройку загрузчика окончательно.

Для серверов без прямого физического доступа откат через GRUB требует консоли управления — IPMI/KVM у выделенных серверов или консоль виртуализации у VPS — поскольку меню загрузчика недоступно через обычное SSH-соединение, которое устанавливается уже после того, как система полностью загрузилась. Именно поэтому перед плановым обновлением ядра стоит заранее убедиться, что доступ к такой консоли настроен и работает, а не выяснять это уже в момент, когда сервер не поднялся после перезагрузки.

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

Автоматизация рутинных обновлений безопасности

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

apt install unattended-upgrades
dpkg-reconfigure --priority=low unattended-upgrades

unattended-upgrades настраивается через файл /etc/apt/apt.conf.d/50unattended-upgrades, где можно указать, какие именно репозитории считать источником автоматически применяемых обновлений (обычно только репозиторий обновлений безопасности, а не все обновления подряд, чтобы не рисковать неожиданным обновлением версии PHP или другого критичного для приложения пакета), и включить опцию Unattended-Upgrade::Automatic-Reboot для автоматической перезагрузки в заданное время, если это допустимо для конкретного сервера.

dnf install dnf-automatic
systemctl enable --now dnf-automatic-install.timer

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

Тестовое окружение перед обновлением продакшн-серверов

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

Особое внимание стоит уделять серверам с нестандартными или сторонними модулями ядра — драйверами специфичного сетевого оборудования, модулями для аппаратного RAID-контроллера или VPN-решениями, работающими на уровне ядра. Такие модули пересобираются под новую версию ядра автоматически не всегда, и после обновления стоит явно проверить их наличие и работоспособность, а не полагаться на то, что раз ядро загрузилось, значит всё в порядке.

lsmod | grep -E "wireguard|zfs|nvidia"
modinfo wireguard | head -5

Если тестовое окружение по каким-то причинам недоступно, минимально достаточная альтернатива — обновлять сначала наименее критичный из имеющихся продакшн-серверов (например, staging-контур или один узел из нескольких за балансировщиком), выдерживать на нём небольшую паузу для наблюдения, и только затем распространять то же обновление на остальные серверы — это не заменяет полноценное тестовое окружение, но заметно снижает риск одновременного выхода из строя всей инфраструктуры из-за одного проблемного обновления ядра.

Итоги: обновление ядра как регулярный процесс, а не разовая задача

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

Live patching через kpatch, Canonical Livepatch или KernelCare заметно снижает давление срочности для критичных продакшн-серверов, позволяя закрыть самые опасные уязвимости без немедленной перезагрузки, но не отменяет необходимость в плановых полноценных обновлениях — обе практики дополняют друг друга, а не заменяют одна другую. Комбинация регулярных плановых окон обслуживания и live patching для промежутков между ними — рабочий баланс между безопасностью и стабильностью для большинства продакшн-инфраструктур.