Живое обновление ядра Linux на VPS: стоит ли переплачивать

Как работает «живое» обновление ядра на VPS

«Живое» обновление ядра (live kernel patching) применяет исправления безопасности к работающей системе без перезагрузки и разрыва соединений. Исправленная копия функции загружается как модуль ядра, а все вызовы старой функции перенаправляются на новую, пока сервер продолжает обрабатывать трафик. Этот механизм объясняет как преимущества «живого» обновления, так и его ограничения.

Оно позволяет выиграть время. Оно не отменяет необходимость перезагрузки. Сервер, который получал «живые» обновления в течение 6 месяцев, всё ещё работает на старом образе ядра с диска, а все патчи существуют только в оперативной памяти.

«Живое» обновление часто продаётся как функция управляемого тарифа (managed plan). На неуправляемом сервере вы можете включить его самостоятельно с помощью двух команд, что стоит знать, прежде чем переплачивать за разницу между управляемым и неуправляемым VPS.

Как работает «живое» обновление ядра (live patching)?

В ядре имеется встроенное ядро системы «живого» обновления, которое компилируется с параметром CONFIG_LIVEPATCH. Проверьте текущее ядро на наличие этой функции:

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

Строка с CONFIG_LIVEPATCH=y означает, что используемое ядро было собрано с поддержкой этого механизма. Без него ни одна служба «живого» обновления не сможет работать на данном сервере.

Перенаправление вызовов использует ftrace — встроенный в ядро инструмент трассировки функций. Большинство функций ядра компилируются с инструкцией вызова в самом начале, до обработки аргументов или стека. Ftrace использует эту точку вызова как перехватчик (hook). При применении патча ядро регистрирует обработчик ftrace для целевой функции, и этот обработчик перенаправляет выполнение на новую версию функции. В документации ядра это описано прямо: «Livepatching обычно требует перенаправления кода в самом начале входа в функцию, до того как параметры функции или стек будут каким-либо образом изменены».

Из этого утверждения следуют два важных вывода. Патчить можно только те функции, которые может перехватить ftrace; функции, скомпилированные без этой инструкции вызова, обновить невозможно. Единицей патчинга является вся функция целиком, а не отдельные строки внутри неё.

Более сложная задача — безопасное переключение работающей системы. Если старый код всё ещё выполняется в стеке какого-либо процессора в момент подмены функции, возникнет конфликт старого и нового поведения. В основной ветке Linux это решается с помощью модели согласованности для каждой задачи (per-task consistency model), которая в документации ядра описывается как гибридная: «она использует согласованность kGraft для каждой задачи и переключение через барьеры системных вызовов в сочетании с переключением через трассировку стека kpatch». Задачи переходят на новый код по одной, только когда ядро может подтвердить, что задача в данный момент не находится внутри патчируемой функции. Пока все задачи не перейдут на новый код, патч находится в переходном состоянии.

Результат можно увидеть самостоятельно. Применённые патчи отображаются в /sys/kernel/livepatch, где для каждого патча создаётся отдельный каталог со списком пропатченных функций.

ls /sys/kernel/livepatch/

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

Что нельзя исправить с помощью live-патчинга ядра

Исправляются только тела функций. Всё остальное — нет.

• Измененные структуры данных. Если исправление от разработчиков добавляет поле в структуру или меняет смысл существующего поля, не существует безопасного способа переписать объекты, которые уже выделены в памяти и используются. Проект kpatch прямо указывает на этот случай: «Патчи, изменяющие статически выделенные данные, напрямую не поддерживаются». В качестве обходного пути существуют теневые переменные (shadow variables) и обратные вызовы (callbacks), но они пишутся вручную для каждого патча, а не автоматически.
• Исправления, затрагивающие сразу несколько функций. Исправление, которое меняет порядок блокировок в группе функций, требует одновременного изменения всех этих функций, а модель согласованности переключает задачи, вместо того чтобы замораживать всю машину в один момент времени.
• Код инициализации. Функции, помеченные __init, уже выполнились и были выгружены из памяти к моменту запуска сервера, поэтому перенаправлять уже нечего.
• Новые версии ядра и новые функции. Live-патчинг позволяет перемещаться по уровням патчей внутри одной серии ядра. Он никогда не переводит вас из одной серии в другую и не добавляет новые функции. Если вам нужно что-то из более новой серии, например изменения, вошедшие в Linux 7.1, вы устанавливаете это ядро и загружаетесь с ним.
• Пользовательское пространство (userspace). Canonical четко определяет границы: «Canonical Livepatch не патчит библиотеки пользовательского пространства, такие как OpenSSL или glibc, поскольку это задача unattended-upgrades или инструментов управления системами». Ядро с примененными «на лету» патчами рядом с устаревшей версией OpenSSL не означает, что сервер защищен, поэтому используйте unattended-upgrades для обработки пакетов пользовательского пространства на том же узле.

В сервисе от Ubuntu также есть ограничение по уровню критичности. Canonical заявляет, что «патчит уязвимости ядра с критическим и высоким рейтингом по шкале CVSS (Common Vulnerability Scoring System) и приоритетом Ubuntu». Идентификатор CVE (common vulnerabilities and exposures) обозначает конкретную уязвимость, а CVSS — это присвоенная ей оценка. Уязвимости ядра со средним рейтингом исправляются в пакете на диске и не патчатся «на лету», поэтому они попадут в работающее ядро только после следующей перезагрузки, но не раньше.

Какие существуют варианты «живого» патчинга ядра?

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

Canonical Livepatch поставляется через Ubuntu Pro. Ubuntu Pro бесплатен для личного использования; согласно формулировкам Canonical, он «есть и всегда будет бесплатным для личного использования на 5 физических машинах», а для официальных участников сообщества Ubuntu лимит составляет 50 машин. Это задокументированный предел по состоянию на август 2026 года. Для коммерческого использования требуется платная подписка. Покрытие предоставляется для каждой серии и версии ядра, включая ядра общего доступа (GA) поддерживаемых релизов с долгосрочной поддержкой (LTS), а также ядра с поддержкой оборудования (HWE) для таких версий, как generic, aws, azure, gcp, oracle, ibm и lowlatency. Перед использованием проверьте свое ядро по опубликованному списку Canonical.

KernelCare от TuxCare — это коммерческий агент, поддерживающий множество дистрибуций, включая те, для которых нет официального сервиса от вендора. Установка, согласно документации, выполняется через скрипт поставщика curl -s -L https://kernelcare.com/installer | bash, после чего следует /usr/bin/kcarectl --register KEY для активации лицензии по ключу. Агент самостоятельно проверяет наличие новых патчей по расписанию, а команда /usr/bin/kcarectl --update принудительно запускает проверку. Изучите содержимое установщика, прежде чем передавать его на выполнение в оболочку на важном для вас сервере.

kpatch и kGraft — это предшественники современных решений. kGraft был разработан в SUSE, kpatch — в Red Hat, а текущий механизм «живого» патчинга в основном ядре Linux представляет собой объединение идей обоих проектов. Разработка kpatch сворачивается: в файле README указано, что начиная с Linux 6.19 «проект kpatch признан устаревшим и переведен в режим сопровождения», а kpatch-build заменяется на klp-build в основном ядре. В RHEL и производных от него дистрибутивах следует использовать штатный сервис дистрибутива, а не собирать патчи вручную.

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

Как включить Canonical Livepatch в Ubuntu

Сначала получите токен на странице вашей учетной записи Ubuntu Pro. Для выполнения обеих приведенных ниже команд требуется работающий исходящий доступ к сети, так как клиент связывается с серверами Canonical для привязки и загрузки патчей.

sudo pro attach TOKEN
sudo pro status

Запуск sudo pro attach без токена инициирует процесс авторизации через браузер и выводит код, который нужно ввести на сайте Canonical. Привязка автоматически включает рекомендуемые сервисы, в число которых в текущем LTS-релизе входит Livepatch. Используйте sudo pro attach --no-auto-enable, если хотите выбрать сервисы самостоятельно.

Если Livepatch еще не включен:

sudo pro enable livepatch
sudo canonical-livepatch status

Сервис работает из снапа canonical-livepatch, поэтому для завершения этапа включения необходимо, чтобы работал snapd. pro status выводит таблицу сервисов с указанием прав доступа и статуса. canonical-livepatch status выводит подробную информацию по каждому ядру, и документация Canonical показывает вывод в таком виде:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

Ответ содержится в двух строках. kernel state указывает, поддерживается ли используемая вами серия ядер данным сервисом; эта строка меняется на негативную, если вы загружаете ядро, которое Livepatch не поддерживает. patch state показывает, применены ли патчи, предназначенные для этого ядра. Если ядро поддерживается, но патчи не применены — это проблема клиента. Если ядро не поддерживается — это проблема самого ядра, и никакие настройки клиента её не исправят.

Как определить, требуется ли перезагрузка?

Live patching устраняет критичность ситуации, поэтому необходимость перезагрузки становится неочевидной. Её нужно проверять принудительно.

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

Менеджер пакетов создает /var/run/reboot-required, когда установленный пакет требует перезапуска для применения изменений, а новый пакет linux-image создает его всегда. Файл .pkgs содержит список пакетов, запросивших перезагрузку. Если первая команда возвращает No such file or directory, значит, с момента последней загрузки системы запросов на перезагрузку не поступало. В актуальных версиях Ubuntu /var/run является символической ссылкой на /run, поэтому оба пути ведут к одному и тому же файлу.

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

uname -r
dpkg -l 'linux-image-*' | grep ^ii

uname -r выводит версию ядра, которая работает в данный момент. Вторая команда выводит список пакетов ядер, установленных на диске. Если в этом списке есть linux-image новее того, что сообщает uname -r, значит, машина работает на старом ядре, независимо от статуса Livepatch. Это ключевая проверка, так как Livepatch предназначен для обеспечения безопасности работающего ядра, а не для его обновления до последней версии.

Для проверки пользовательского пространства (userspace) по тому же вопросу по умолчанию в Ubuntu Server установлена утилита needrestart, которая выводит список запущенных сервисов, использующих удаленные файлы библиотек.

sudo needrestart -r l

Пара флагов -r l означает «только список», поэтому команда ничего не меняет, а лишь выводит отчет.

Почему перезагрузка всё равно необходима

Ядро на диске остаётся неизменным. Live-патчи загружаются в работающее ядро и никогда не записываются в загрузочный образ, поэтому после перезагрузки система запускается с тем linux-image, который выбирает загрузчик, а затем клиент Livepatch повторно применяет актуальные патчи. В промежутке между этими двумя событиями вы работаете на неисправленном коде, что является ещё одной причиной загружать актуальное ядро, а не устаревшее.

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

Исправления для ядра средней и низкой степени критичности никогда не применяются через live-патчи. Они остаются в пакете на диске и вступают в силу только после перезагрузки.

Ядра, работающие длительное время, также накапливают состояние, которое патчи не очищают. Стоит процитировать официальную позицию Canonical, так как она наиболее честна: Livepatch «не является заменой перезагрузке. Это инструмент, который даёт вам больше контроля, предотвращая внеплановые перезагрузки». Ключевое слово здесь — внеплановые. Вы всё равно выполняете перезагрузку. Вы просто сами выбираете время.

Как запланировать перезагрузку с гарантией восстановления доступа

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

• Убедитесь, что ваш провайдер предоставляет доступ к последовательной консоли или VNC (virtual network computing) через панель управления, и откройте её заранее, а не во время простоя.
• Проверьте свободное место с помощью df -h /boot. Заполнение /boot приводит к сбою при записи initramfs (initial RAM filesystem) во время обновления ядра, из-за чего загрузчик может указывать на незавершенный образ.
• Сохраняйте как минимум одно старое, заведомо рабочее ядро. GRUB отображает его в разделе "Advanced options for Ubuntu", и загрузка через него — самый быстрый способ восстановления при сбое нового ядра.
• Найдите информацию о режиме восстановления (rescue mode) у вашего провайдера до того, как он вам понадобится. Если после перезагрузки консоль выдает приглашение initramfs, именно там выполняется ремонт системы.

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

sudo shutdown -r +5 "Kernel update, back in a moment"

Эта команда планирует перезагрузку через пять минут и отправляет уведомление вошедшим в систему пользователям. sudo shutdown -c отменяет её. Когда машина вернется в строй, проверьте оба параметра:

uname -r
sudo canonical-livepatch status

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

Почему старые ядра необходимо удалять

Live patching усугубляет эту проблему, так как снимает необходимость в перезагрузке, в то время как пакеты linux-image продолжают устанавливаться. Каждое ядро устанавливает загрузочный образ, initramfs, дерево модулей и, как правило, пакет заголовков. На небольшом VPS с отдельным разделом /boot размером в несколько сотен мегабайт три или четыре таких ядра полностью его заполняют.

Переполнение /boot приводит к сбою при установке следующего ядра, из-за чего система теряет возможность получать критически важные обновления. Команда apt autoremove удаляет старые ядра, как только они становятся не нужны, но на сервере, который никогда не перезагружается, они не всегда считаются лишними, так как менеджер пакетов не удаляет ядро, которое может быть запущено в данный момент.

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

FAQ

Означает ли live kernel patching, что мне никогда не придётся перезагружать VPS?

Нет. «Живые» патчи загружаются в работающее ядро и не записываются в загрузочный образ, поэтому linux-image на диске остаётся той версии, с которой вы загрузились. Canonical прямо заявляет: Livepatch «не заменяет перезагрузку. Это инструмент, который даёт больше контроля, позволяя избежать внеплановых перезагрузок». Поддержка также прекращается, когда серия вашего ядра выводится из эксплуатации, а исправления среднего уровня критичности для ядра вообще не выпускаются в виде «живых» патчей. Планируйте техническую перезагрузку с удобной вам периодичностью, вместо того чтобы ждать принудительной.

Как проверить, применяются ли патчи через live kernel patching?

Выполните sudo canonical-livepatch status и изучите две строки вывода. kernel state сообщает, поддерживается ли ваша текущая серия ядра сервисом, а patch state показывает, загружены ли патчи для этого ядра. Вы также можете проверить состояние ядра напрямую с помощью ls /sys/kernel/livepatch/, которая выводит по одному каталогу на каждый загруженный патч. Пустой список означает, что в данный момент в памяти ничего не пропатчено, независимо от того, что сообщает клиент.

Бесплатен ли Ubuntu Pro на личном VPS?

Да, в рамках установленных ограничений. Согласно формулировке Canonical, Ubuntu Pro «есть и всегда будет бесплатным для личного использования на 5 физических машинах», а для официальных участников сообщества Ubuntu этот лимит составляет 50 машин (по состоянию на август 2026 года). Для коммерческого использования требуется платная подписка. Вы подключаете машину с помощью sudo pro attach TOKEN, используя токен со страницы вашей учётной записи Ubuntu Pro, а затем активируете сервис командой sudo pro enable livepatch.

Почему CVE ядра всё ещё числится неисправленным после работы Livepatch?

Обычно есть две причины. Исправление может находиться ниже порога критичности, так как Canonical выпускает «живые» патчи только для «уязвимостей ядра с критическим и высоким рейтингом по шкале CVSS и приоритетом Ubuntu», оставляя остальные исправления для пакета на диске. Либо исправление невозможно реализовать как изменение тела функции, например, если разработчики ядра изменили структуру данных, что нельзя безопасно сделать «на лету» для уже выделенных объектов. В обоих случаях решение одно: установите обновлённый пакет ядра и загрузитесь с ним.

Что вообще не покрывает live kernel patching?

Пользовательское пространство (userspace). Canonical прямо указывает, что Livepatch «не патчит библиотеки пользовательского пространства, такие как OpenSSL или glibc, поскольку это зона ответственности unattended-upgrades или систем управления конфигурациями». Он также не может доставить новую версию ядра или новую функциональность, так как только заменяет тела функций внутри серии, которая уже запущена. Кроме того, он не может пропатчить функции __init, которые уже выполнились и были выгружены из памяти к моменту завершения загрузки сервера.