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

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

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

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

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

Як працює live patching ядра?

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

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

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

Для перенаправлення використовується ftrace — трасувальник функцій ядра. Більшість функцій ядра компілюються з інструкцією виклику на самому початку функції, до того як буде змінено аргументи або стек. ftrace використовує цю точку виклику як hook. Коли застосовується patch, ядро live patching реєструє обробник ftrace для цільової функції, а обробник натомість передає виконання функції-заміні. У документації ядра це сформульовано прямо: «Для livepatch зазвичай потрібно перенаправити код на самому початку входу у функцію, до того як параметри функції або стек буде будь-яким чином змінено».

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

Складніша частина — безпечно змінити код у запущеній системі. Якщо старий код усе ще виконується на стеку одного з CPU під час заміни функції, поведінка буде змішаною: частина старою, а частина новою. Upstream Linux розв’язує це за допомогою моделі узгодженості для окремих задач. У документації ядра її описано як гібридну: «вона поєднує узгодженість для окремих задач і перемикання через бар’єр системних викликів із kGraft із перемиканням за трасуванням стеку з kpatch». Задачі переходять на новий код по одній і лише тоді, коли ядро може підтвердити, що відповідна задача зараз не перебуває всередині patch-еної функції. Поки не буде переміщено всі задачі, patch перебуває в стані переходу.

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

ls /sys/kernel/livepatch/

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

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

Змінюються тіла функцій. Усе інше не змінюється.

• Змінені структури даних. Якщо виправлення з upstream додає поле до struct або змінює значення наявного поля, безпечного способу переписати об’єкти, які вже виділені та використовуються, немає. Проєкт kpatch прямо описує аналогічний випадок: «Patches which modify statically allocated data are not directly supported.» Shadow variables і callbacks можуть бути обхідним рішенням, але їх потрібно вручну реалізовувати для кожного patch; автоматично вони не працюють.
• Виправлення, що одночасно охоплюють кілька функцій. Якщо виправлення змінює порядок блокувань у групі функцій, усі ці функції потрібно змінити разом. При цьому модель узгодженості перемикає tasks, а не заморожує всю систему в один момент.
• Код ініціалізації. Функції, позначені __init, уже виконалися та були вивільнені до моменту запуску сервера, тому перенаправляти вже нічого.
• Нові версії kernel і нові функції. Live patching переміщує вас між рівнями patch в межах однієї серії kernel. Воно не переводить систему з однієї серії на іншу й не додає нових функцій. Якщо потрібна можливість із новішої серії, наприклад зміни, що увійшли до Linux 7.1, потрібно встановити цей kernel і завантажити його.
• 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.» Kernel із 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 patching, тому потрапляє до запущеного kernel під час наступного перезавантаження, а не раніше.

Які доступні варіанти динамічного виправлення ядра?

У загальному використанні є три напрями розвитку. Усі вони працюють через ті самі механізми ядра.

Canonical Livepatch постачається через Ubuntu Pro. Ubuntu Pro безкоштовний для особистого використання. Формулювання Canonical таке: сервіс «є і завжди буде безкоштовним для особистого використання на 5 фізичних машинах», а для офіційних учасників Ubuntu Community ліміт зростає до 50 машин. Станом на August 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 примусово запускає перевірку. Перед передаванням скрипту до shell на важливому сервері прочитайте його вміст.

kpatch і kGraft — це попередники сучасних рішень. kGraft розробила SUSE, а kpatch — Red Hat. Сьогодні ядро динамічного виправлення в upstream Linux є результатом об’єднання обох підходів. Сам kpatch поступово виводиться з використання: у README зазначено, що починаючи з Linux 6.19 «проєкт kpatch застарілий і перебуває в режимі обслуговування», а kpatch-build в upstream kernel замінюється на 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

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

Як визначити, чи потрібне перезавантаження?

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

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 означає «лише перелічити», тому команда тільки виводить інформацію і нічого не змінює.

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

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

Підтримка надається для кожної серії ядер окремо, а серії виводяться з підтримки. Коли серія запущеного ядра зникає зі списку підтримуваних, рядок kernel state перестає повідомляти про наявність покриття. Єдине рішення — новіше ядро. Це означає перезавантаження.

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

У ядрах, які працюють тривалий час, також накопичується стан, який Livepatch не очищає. Варто навести власну позицію 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 patches завантажуються в запущене ядро, але не записуються в 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, використавши token зі сторінки свого облікового запису Ubuntu Pro, а потім увімкніть сервіс за допомогою sudo pro enable livepatch.

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

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

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

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