Live kernel patching на VPS: стоит ли избегать

Как работает live kernel patching на VPS

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

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

Live patching часто предлагается как функция управляемых тарифов (managed). На неуправляемом сервере (unmanaged) вы можете включить его самостоятельно с помощью двух команд, что полезно знать до того, как вы решите доплатить за разницу между управляемым и неуправляемым 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 kernel patching

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

• Изменения структур данных. Если исправление от разработчиков ядра добавляет поле в структуру или меняет смысл существующего поля, не существует безопасного способа переписать объекты, которые уже выделены в памяти и используются. Проект kpatch прямо указывает на этот случай: «Патчи, изменяющие статически выделенные данные, напрямую не поддерживаются». В качестве обходного пути существуют теневые переменные и обратные вызовы, но они пишутся вручную для каждого патча, а не автоматически.
• Исправления, затрагивающие сразу несколько функций. Исправление, меняющее порядок блокировок в группе функций, требует одновременного изменения всех этих функций, а модель согласованности переключает задачи, вместо того чтобы замораживать всю машину в один момент времени.
• Код инициализации. Функции, помеченные __init, уже выполнились и были выгружены из памяти к моменту запуска сервера, поэтому перенаправлять уже нечего.
• Новые версии ядра и новые функции. Live patching позволяет перемещаться между уровнями патчей внутри одной серии ядра. Он никогда не переводит вас с одной серии на другую и не добавляет новые функции. Если вам нужно что-то из более новой серии, например изменения, вошедшие в 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 — это присвоенная ей оценка. CVE ядра со средним рейтингом исправляется в пакете на диске и не применяется через live patching, поэтому изменения вступят в силу только после следующей перезагрузки, но не раньше.

Какие существуют варианты «живого» обновления ядра (live patching)?

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

Canonical Livepatch поставляется через Ubuntu Pro. Ubuntu Pro бесплатен для личного использования; согласно формулировкам Canonical, он «есть и всегда будет бесплатным для личного использования на 5 физических машинах», а для официальных участников сообщества Ubuntu Community лимит составляет 50 машин. Это задокументированный предел по состоянию на август 2026 года. Для коммерческого использования требуется платная подписка. Покрытие предоставляется для каждой серии и версии ядра, включая ядра general availability (GA) поддерживаемых релизов long term support (LTS), а также их ядра hardware enablement (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 перестаёт отображать данные о покрытии, и единственным решением становится обновление ядра. Это требует перезагрузки. В LTS-релизах новая серия обычно доставляется в виде hardware enablement ядра, включённого в точечный релиз, например 26.04.1, поэтому замена уже находится в архиве, и всё, что требуется — это запланировать перезагрузку.

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