Live kernel patching чи перезавантаження VPS

Що робить live kernel patching на VPS

Live kernel patching застосовує виправлення безпеки ядра до запущеної системи без перезавантаження та розриву з’єднань.

Виправлена копія функції завантажується як kernel module. Кожен виклик старої функції перенаправляється до нової копії, поки сервер продовжує обробляти network traffic. Цей механізм пояснює, для чого потрібен live patching і чого він не може зробити.

Це дає час. Але не скасовує перезавантаження. Сервер, який отримував live patching протягом шести місяців, усе ще завантажений зі старого kernel image на диску. Усі ці виправлення існують лише в пам’яті.

Live patching часто подають як функцію managed plan. На unmanaged server його можна ввімкнути самостійно двома командами. Це варто знати, перш ніж платити за різницю між керованим і некерованим VPS.

Як працює live kernel patching?

У ядрі є вбудоване ядро live patching, скомпільоване з параметром CONFIG_LIVEPATCH. Перевірте його на запущеному ядрі:

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

Рядок CONFIG_LIVEPATCH=y означає, що запущене ядро зібране з цим компонентом. Без нього жоден сервіс live patching не зможе нічого зробити на цій машині.

Для перенаправлення використовується ftrace — трасувальник функцій ядра. Більшість функцій ядра компілюються з інструкцією виклику на самому початку функції, до обробки аргументів або зміни стека. ftrace використовує цю точку виклику як hook. Коли застосовується patch, ядро live patching реєструє обробник ftrace для цільової функції, а обробник перенаправляє виконання до функції-замінника. У документації ядра це сформульовано прямо: "Livepatching typically needs to redirect the code at the very beginning of the function entry before the function parameters or the stack are in any way modified."

З цього речення випливають два наслідки, і надалі обидва мають значення. Можна patch лише функцію, до якої може підключитися ftrace. Функцію, скомпільовану без цього виклику на вході, patch застосувати взагалі неможливо. Одиницею patching є ціла функція, а не окремий рядок усередині неї.

Складніша частина — безпечно перемикнути запущену систему. Якщо старий код ще виконується на стеку якогось CPU під час заміни функції, ви отримаєте поєднання старої та нової поведінки. Upstream Linux вирішує це за допомогою моделі узгодженості для кожного task. У документації ядра її описано як гібрид: "it uses kGraft's per-task consistency and syscall barrier switching combined with kpatch's stack trace switching." Task переходять на новий код по одному, лише коли ядро може підтвердити, що відповідний task наразі не перебуває всередині patched-функції. Поки не перейшли всі task, patch перебуває в стані переходу.

Результат можна перевірити самостійно. Застосовані patch відображаються в /sys/kernel/livepatch: для кожного patch створюється окремий каталог, усередині якого перелічено patched-функції.

ls /sys/kernel/livepatch/

Порожній список означає, що в пам’яті не завантажено жодного live patch. Для нового сервера це нормальний початковий стан.

Що live kernel patching не може виправити

Патчаться тіла функцій. Усе інше — ні.

• Змінені структури даних. Якщо upstream-виправлення додає поле до struct або змінює значення наявного поля, безпечного способу переписати об’єкти, які вже виділені та використовуються, немає. Проєкт kpatch прямо описує аналогічний випадок: "Patches which modify statically allocated data are not directly supported." Shadow variables і callback-функції можна використовувати як обхідний шлях, але для кожного патча їх потрібно писати вручну; автоматично це не виконується.
• Виправлення, що одночасно охоплюють кілька функцій. Якщо виправлення змінює порядок блокувань у групі функцій, усі вони мають змінитися разом. Модель узгодженості перемикає задачі, а не заморожує всю систему в один момент.
• Код ініціалізації. Функції, позначені __init, уже виконалися та були вивільнені до моменту запуску сервера, тому перенаправляти вже нічого.
• Нові версії ядра та нові функції. Live patching переміщує вас між рівнями патчів у межах однієї серії ядра. Він не переводить систему з однієї серії на іншу й не додає нових функцій. Якщо вам потрібна можливість із новішої серії, наприклад зміни, що з’явилися в Linux 7.1, встановіть це ядро та завантажте його.
• Userspace. Canonical прямо визначає цю межу: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." Ядро з live patching у системі зі застарілим OpenSSL — це не пропатчений сервер. Тому залиште обробку пакетів userspace через unattended upgrades на тому самому сервері.

Для сервісу Ubuntu також існує межа за рівнем критичності. Canonical зазначає, що він "patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings." Ідентифікатор CVE (common vulnerabilities and exposures) позначає одну вразливість, а CVSS — це присвоєна їй оцінка. Kernel CVE із середнім рівнем критичності виправляється в пакеті на диску, але не патчиться в запущеному ядрі. Воно отримає це виправлення під час наступного перезавантаження, але не раніше.

Які існують варіанти live kernel patching?

У поширеному використанні є три основні напрями. Усі вони задіюють той самий механізм ядра.

Canonical Livepatch постачається через Ubuntu Pro. Ubuntu Pro безкоштовний для особистого використання. Canonical зазначає, що він «є і завжди буде безкоштовним для особистого використання на щонайбільше 5 фізичних машинах». Для офіційних учасників Ubuntu Community ліміт зростає до 50 машин. Станом на August 2026 це задокументований ліміт. Для комерційного використання потрібна платна підписка. Покриття надається для кожної серії ядра та кожного варіанта. Воно охоплює ядра general availability (GA) підтримуваних long term support (LTS) releases і їхні hardware enablement (HWE) kernels, зокрема варіанти generic, aws, azure, gcp, oracle, ibm і lowlatency. Перед використанням перевірте своє ядро за опублікованим Canonical списком ядер.

KernelCare від TuxCare — це комерційний агент, який підтримує багато дистрибутивів, зокрема дистрибутиви без власного сервісу live patching. У документації для встановлення передбачено vendor script curl -s -L https://kernelcare.com/installer | bash, а потім /usr/bin/kcarectl --register KEY для ліцензії на основі ключа. Після цього агент самостійно перевіряє наявність нових patch за власним розкладом, а /usr/bin/kcarectl --update примусово запускає перевірку. Перед передаванням скрипта до shell на важливому сервері прочитайте його вміст.

kpatch і kGraft — це попередники сучасних рішень. kGraft створила SUSE, а kpatch — Red Hat. Сьогоднішнє ядро live patching в upstream Linux є результатом об’єднання обох підходів. Сам kpatch поступово припиняють розвивати: у README зазначено, що починаючи з Linux 6.19 «проєкт kpatch оголошено застарілим і переведено в режим супроводу», а kpatch-build в upstream kernel замінюється на klp-build. У RHEL і його rebuilds використовуйте власний сервіс дистрибутива, а не створюйте patch вручну.

Обирайте рішення з урахуванням підтримки вашого дистрибутива та умов ліцензії. Результат на рівні ядра в усіх випадках однаковий.

Як увімкнути 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

Сервіс працює з snap-пакета 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 показує, чи справді завантажено виправлення, які застосовуються до цього ядра. Якщо ядро підтримується, але виправлення не застосовано, проблема на боці клієнта. Якщо ядро не підтримується, проблема в ядрі, і жодне налаштування клієнта її не усуне.

Як визначити, чи очікується перезавантаження?

Livepatching усуває аварійну потребу в перезавантаженні, тому його необхідність стає менш очевидною. Це потрібно перевіряти окремо.

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. Саме ця перевірка має значення, оскільки live patching призначений для захисту запущеного ядра, а не для підтримання його актуальності.

Для простору користувача в межах цієї самої перевірки needrestart встановлюється за замовчуванням в Ubuntu Server і виводить запущені служби, які все ще утримують видалені файли бібліотек.

sudo needrestart -r l

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

Чому перезавантаження нікуди не зникає

Ядро на диску не змінюється. Live patches завантажуються в запущене ядро й ніколи не записуються в boot image, тому після перезавантаження система запускається з того linux-image, яке вибере bootloader, а клієнт Livepatch повторно застосовує патчі, які ще сумісні з цим ядром. У проміжку між цими двома моментами система працює з непатченим кодом. Це ще одна причина завантажувати актуальне ядро, а не старе.

Покриття надається для окремих серій ядер, а підтримка серій завершується. Коли поточна серія зникає зі списку підтримуваних, рядок kernel state перестає повідомляти про покриття, і єдиним виправленням стає новіше ядро. Це означає перезавантаження. У LTS-релізі новіша серія зазвичай надходить як hardware enablement kernel, включене до точкового релізу, наприклад 26.04.1, тому заміна вже є в archive, а бракує лише запланованого завантаження.

Виправлення ядра із середнім і низьким рівнем критичності ніколи не застосовуються в режимі live patching. Вони містяться в пакеті на диску й стають доступними лише після завантаження цього ядра.

У ядрах, які працюють тривалий час, також накопичується стан, який patching не очищає. Позицію 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 продовжують установлюватися. Кожне ядро встановлює boot image, initramfs, дерево модулів і зазвичай пакет заголовків. На невеликому VPS з окремим розділом /boot обсягом у кілька сотень мегабайт три або чотири таких набори його заповнюють.

Повний /boot після цього перешкоджає встановленню наступного ядра. Через це система може не встановити саме те оновлення, якого потребує. apt autoremove видаляє старі ядра, коли вони стають придатними для видалення. Але на сервері, який ніколи не перезавантажується, вони не завжди вже придатні для видалення, оскільки менеджер пакетів не видалятиме ядро, яке ще може бути запущене.

Тому перевірте, які ядра встановлено, залиште запущене ядро та одну перевірену резервну версію, а решту видаліть за безпечною процедурою видалення старих ядер в Ubuntu. Ніколи не видаляйте ядро, яке наразі показує uname -r.

FAQ

Чи означає live kernel patching, що мені ніколи не доведеться перезавантажувати VPS?

Ні. Live-патчі завантажуються в запущене ядро, але не записуються в boot image, тому linux-image на диску залишається тієї версії, з якою ви завантажилися. Canonical прямо зазначає: Livepatch «не є заміною перезавантаженню. Це інструмент, який дає змогу краще контролювати перезавантаження, запобігаючи незапланованим перезавантаженням». Покриття також припиняється, коли вашу серію ядра знімають із підтримки, а виправлення вразливостей ядра із середнім рівнем критичності взагалі не застосовуються через live patching. Заплануйте технічне перезавантаження з періодичністю, яку ви оберете, замість того щоб чекати примусового перезавантаження.

Як перевірити, чи live kernel patching справді застосовує патчі?

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

Чи безкоштовний Ubuntu Pro на особистому VPS?

Так, у межах встановленого ліміту. За формулюванням Canonical, Ubuntu Pro «був і завжди буде безкоштовним для особистого використання на не більш ніж 5 фізичних машинах». Для офіційних учасників Ubuntu Community ліміт становить 50 машин. Це актуально станом на August 2026. Для комерційного використання потрібна платна підписка. Під’єднайте машину за допомогою sudo pro attach TOKEN, використовуючи токен зі сторінки свого облікового запису Ubuntu Pro, а потім увімкніть службу командою sudo pro enable livepatch.

Чому CVE для ядра все ще позначена як невиправлена після запуску Livepatch?

Зазвичай є одна з двох причин. Виправлення може не досягати порога критичності, оскільки Canonical застосовує live-патчі до «вразливостей ядра з критичними та високими оцінками Common Vulnerability Scoring System (CVSS) і Ubuntu Priority», а решту залишає для пакета на диску. Або виправлення може бути неможливо подати як зміну тіла функції, наприклад якщо upstream змінив структуру даних. Live patching не може безпечно виконати таку зміну для об’єктів, які вже виділені в пам’яті. В обох випадках потрібно встановити оновлений пакет ядра та завантажити систему з нього.

Що взагалі не охоплює live kernel patching?

Userspace. Canonical прямо зазначає, що Livepatch «не патчить userspace-бібліотеки, такі як OpenSSL або glibc, оскільки за це відповідають unattended-upgrades або інструмент керування системами». Livepatch також не може надати нову версію ядра або нову функцію, оскільки замінює лише тіла функцій усередині серії ядра, яка вже запущена. Крім того, він не може патчити функції __init, які на момент роботи сервера вже виконалися та були звільнені з пам’яті.