Live kernel patching a restart serwera VPS

Na czym polega live kernel patching na serwerze VPS

Live kernel patching pozwala na instalację poprawek bezpieczeństwa jądra systemu na działającej maszynie, bez konieczności restartu i przerywania połączeń. Poprawiona kopia funkcji jest ładowana jako moduł jądra, a każde wywołanie starej funkcji zostaje przekierowane do nowej wersji, podczas gdy serwer nieprzerwanie obsługuje ruch. Ten mechanizm wyjaśnia zarówno zalety, jak i ograniczenia live patchingu.

Rozwiązanie to pozwala zyskać czas. Nie eliminuje jednak potrzeby restartu. Serwer, który przez sześć miesięcy był aktualizowany za pomocą live patchingu, nadal korzysta z obrazu jądra zapisanego na dysku, a wszystkie poprawki istnieją wyłącznie w pamięci operacyjnej.

Live patching jest często oferowany jako funkcja planów zarządzanych. Na serwerze niezarządzanym można włączyć go samodzielnie za pomocą dwóch poleceń, co warto wiedzieć przed dopłatą za różnicę między serwerem VPS zarządzanym a niezarządzanym.

Jak działa mechanizm live kernel patching?

Jądro systemu posiada wbudowany rdzeń live patching, kompilowany z opcją CONFIG_LIVEPATCH. Sprawdź, czy uruchomione jądro go obsługuje:

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

Wiersz o treści CONFIG_LIVEPATCH=y oznacza, że używane jądro zostało skompilowane z aktywnym rdzeniem. Bez tego żadna usługa live patching nie zadziała na danej maszynie.

Samo przekierowanie wykorzystuje ftrace, czyli mechanizm śledzenia funkcji jądra. Większość funkcji jądra jest kompilowana z instrukcją wywołania na samym początku, jeszcze przed przetworzeniem argumentów lub stosu. Ftrace używa tego miejsca jako punktu zaczepienia (hook). Po zastosowaniu poprawki rdzeń live patching rejestruje procedurę obsługi ftrace dla docelowej funkcji, a ta przekierowuje wykonanie kodu do funkcji zastępczej. Dokumentacja jądra wyjaśnia to jasno: „Livepatching zazwyczaj wymaga przekierowania kodu na samym początku wejścia do funkcji, zanim parametry funkcji lub stos zostaną w jakikolwiek sposób zmodyfikowane”.

Z tego zdania wynikają dwie konsekwencje, obie istotne w dalszej pracy. Możliwe do załatania są tylko te funkcje, które ftrace może przechwycić, więc funkcji skompilowanych bez tego wywołania wejściowego nie da się załatać. Jednostką poprawki jest cała funkcja, nigdy pojedyncza linia wewnątrz niej.

Trudniejszym zadaniem jest bezpieczne przełączenie działającego systemu. Jeśli stary kod nadal wykonuje się na stosie procesora w momencie zamiany funkcji, powstaje mieszanka starego i nowego zachowania. Główna gałąź Linux rozwiązuje to za pomocą modelu spójności per-task, opisanego w dokumentacji jądra jako hybrydowy: „wykorzystuje spójność per-task z kGraft oraz przełączanie barier syscall w połączeniu z przełączaniem śladów stosu z kpatch”. Zadania przechodzą na nowy kod pojedynczo, tylko wtedy, gdy jądro może potwierdzić, że zadanie nie znajduje się obecnie wewnątrz łatanej funkcji. Dopóki wszystkie zadania nie zostaną przeniesione, poprawka znajduje się w stanie przejściowym.

Możesz samodzielnie sprawdzić wynik. Zastosowane poprawki pojawiają się w /sys/kernel/livepatch, po jednym katalogu na poprawkę, z listą załatanych funkcji wewnątrz.

ls /sys/kernel/livepatch/

Pusta lista oznacza, że w pamięci nie jest załadowana żadna poprawka live patch, co na świeżo zainstalowanym serwerze jest stanem domyślnym.

Czego nie naprawia aktualizacja jądra w czasie pracy (live patching)

Modyfikowane są jedynie treści funkcji. Wszystkie pozostałe elementy pozostają bez zmian.

• Zmiany w strukturach danych. Jeśli poprawka od dostawcy dodaje pole do struktury lub zmienia znaczenie istniejącego pola, nie istnieje bezpieczny sposób na nadpisanie obiektów, które zostały już zaalokowane i są w użyciu. Projekt kpatch wprost wskazuje na ten przypadek: „Poprawki modyfikujące statycznie zaalokowane dane nie są bezpośrednio wspierane”. Zmienne cieniujące (shadow variables) oraz wywołania zwrotne (callbacks) stanowią obejście, jednak wymagają ręcznego przygotowania dla każdej poprawki, nie są automatyczne.
• Poprawki rozproszone jednocześnie na wiele funkcji. Poprawka zmieniająca kolejność blokad (lock ordering) w grupie funkcji wymaga jednoczesnej zmiany wszystkich tych elementów, a model spójności przełącza zadania zamiast zamrażać cały system w jednym momencie.
• Kod inicjalizacyjny. Funkcje oznaczone jako __init zostały już wykonane i zwolnione w momencie, gdy serwer jest uruchomiony, więc nie ma czego przekierowywać.
• Nowe wersje jądra i nowe funkcje. Live patching pozwala na aktualizację poziomu poprawek wewnątrz jednej serii jądra. Nie umożliwia przejścia między seriami ani dodawania nowych funkcji. Jeśli wymagane są zmiany z nowszej serii, takie jak zmiany wprowadzone w Linux 7.1, należy zainstalować to jądro i uruchomić z niego system.
• Przestrzeń użytkownika (userspace). Canonical jasno wyznacza granicę: „Canonical Livepatch nie aktualizuje bibliotek przestrzeni użytkownika, takich jak OpenSSL czy glibc, ponieważ jest to zadanie narzędzi typu unattended-upgrades lub systemów zarządzania”. Jądro zaktualizowane w czasie pracy przy nieaktualnej bibliotece OpenSSL nie oznacza w pełni zabezpieczonego serwera, dlatego należy utrzymać obsługę pakietów przestrzeni użytkownika przez unattended-upgrades na tej samej maszynie.

Usługa Ubuntu posiada również ograniczenia dotyczące stopnia ważności poprawek. Canonical informuje, że „aktualizuje luki w jądrze o krytycznym i wysokim poziomie ważności w skali Common Vulnerability Scoring System (CVSS) oraz o priorytecie Ubuntu”. Identyfikator CVE (common vulnerabilities and exposures) wskazuje konkretną lukę, a CVSS to przypisana do niej ocena. Luka w jądrze o średnim priorytecie jest naprawiana w pakiecie na dysku i nie jest wdrażana przez live patching, więc trafi do działającego jądra dopiero przy następnym restarcie systemu.

Jakie są opcje stosowania poprawek jądra w czasie rzeczywistym?

W powszechnym użyciu znajdują się trzy linie rozwiązań, z których wszystkie wykorzystują ten sam mechanizm jądra.

Canonical Livepatch jest dostarczany w ramach Ubuntu Pro. Ubuntu Pro jest bezpłatny do użytku osobistego, a według deklaracji Canonical „jest i zawsze będzie bezpłatny do użytku osobistego na maksymalnie 5 maszynach fizycznych”, z limitem zwiększonym do 50 maszyn dla oficjalnych członków społeczności Ubuntu. Jest to udokumentowany limit na sierpień 2026. Użytek komercyjny wymaga płatnej subskrypcji. Zakres wsparcia jest przyznawany dla każdej serii i odmiany jądra, obejmując jądra typu general availability (GA) wspieranych wydań long term support (LTS) oraz ich odpowiedniki hardware enablement (HWE), w różnych odmianach, takich jak generic, aws, azure, gcp, oracle, ibm oraz lowlatency. Przed poleganiem na tym rozwiązaniu należy sprawdzić własne jądro względem opublikowanej przez Canonical listy wspieranych jąder.

KernelCare, od TuxCare, to komercyjny agent obsługujący wiele dystrybucji, w tym te, które nie posiadają własnych usług tego typu. Udokumentowana instalacja odbywa się za pomocą skryptu dostawcy, curl -s -L https://kernelcare.com/installer | bash, po którym następuje /usr/bin/kcarectl --register KEY w celu aktywacji licencji opartej na kluczu. Agent następnie sprawdza dostępność nowych poprawek zgodnie z własnym harmonogramem, a /usr/bin/kcarectl --update wymusza sprawdzenie ręczne. Przed przekazaniem skryptu instalacyjnego do powłoki na serwerze o znaczeniu krytycznym należy zapoznać się z jego treścią.

kpatch oraz kGraft to rozwiązania pierwotne. kGraft wywodzi się z SUSE, kpatch z Red Hat, a obecny mechanizm live patching w jądrze Linux jest połączeniem założeń obu tych projektów. Projekt kpatch jest wygaszany: jego plik README informuje, że od wersji Linux 6.19 „projekt kpatch jest przestarzały i znajduje się w trybie utrzymania”, a kpatch-build jest zastępowane przez klp-build w jądrze upstream. W systemach RHEL i ich odpowiednikach właściwym narzędziem jest usługa dostarczana przez dystrybutora, zamiast ręcznego tworzenia poprawek.

Wybór należy uzależnić od wsparcia dystrybucji oraz posiadanej licencji. Wynik na poziomie jądra jest w każdym przypadku identyczny.

Jak włączyć Canonical Livepatch w systemie Ubuntu

Najpierw należy pobrać token ze strony konta Ubuntu Pro. Obie poniższe komendy wymagają działającego połączenia z Internetem, ponieważ klient komunikuje się z serwerami Canonical w celu autoryzacji i pobrania poprawek.

sudo pro attach TOKEN
sudo pro status

Uruchomienie sudo pro attach bez podania tokena inicjuje proces w przeglądarce i wyświetla kod, który należy wprowadzić na stronie Canonical. Dołączenie do usługi automatycznie włącza zalecane komponenty, co w przypadku aktualnego wydania LTS obejmuje Livepatch. Należy użyć sudo pro attach --no-auto-enable, jeśli wymagany jest ręczny wybór usług.

Jeśli usługa Livepatch nie jest jeszcze aktywna:

sudo pro enable livepatch
sudo canonical-livepatch status

Usługa działa w ramach snap canonical-livepatch, więc do poprawnego zakończenia procesu włączania wymagane jest działanie snapd. pro status wyświetla tabelę usług wraz z ich uprawnieniami i statusem. canonical-livepatch status wyświetla szczegółowe informacje dla poszczególnych jąder, a dokumentacja Canonical przedstawia wynik w następującej formie:

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

Dwie linie zawierają kluczowe informacje. kernel state informuje, czy używana seria jądra jest w ogóle objęta wsparciem usługi; linia ta zmienia status na negatywny po uruchomieniu jądra, którego Livepatch nie obsługuje. patch state wskazuje, czy poprawki przeznaczone dla danego jądra zostały faktycznie załadowane. Jeśli jądro jest objęte wsparciem, a poprawki nie zostały załadowane, problem leży po stronie klienta. Jeśli jądro nie jest objęte wsparciem, jest to ograniczenie samego jądra, którego nie można rozwiązać zmianą ustawień klienta.

Jak sprawdzić, czy wymagany jest restart systemu?

Live patching usuwa sytuację awaryjną, więc konieczność restartu przestaje być oczywista. Należy ją aktywnie zweryfikować.

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

Menedżer pakietów tworzy /var/run/reboot-required, gdy zainstalowany pakiet wymaga restartu, aby zmiany weszły w życie; nowy pakiet linux-image zawsze go tworzy. Plik .pkgs zawiera listę pakietów, które zgłosiły taką potrzebę. Jeśli pierwsze polecenie zwraca No such file or directory, oznacza to, że od ostatniego uruchomienia systemu żaden pakiet nie wymusił restartu. W aktualnych wersjach Ubuntu /var/run jest dowiązaniem symbolicznym do /run, więc obie ścieżki prowadzą do tego samego pliku.

Ta flaga znajduje się w tmpfs i jest resetowana przy każdym uruchomieniu, dlatego należy zweryfikować stan bezpośrednio w jądrze:

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

uname -r wyświetla wersję aktualnie działającego jądra. Drugie polecenie wyświetla pakiety jąder zainstalowane na dysku. Jeśli na tej liście znajduje się linux-image nowsze niż to, które raportuje uname -r, oznacza to, że maszyna pracuje na starym jądrze, niezależnie od statusu Livepatch. Jest to kluczowa weryfikacja, ponieważ mechanizm Livepatch służy do zabezpieczania działającego jądra, a nie do aktualizacji jego wersji.

W odniesieniu do przestrzeni użytkownika, narzędzie needrestart jest domyślnie zainstalowane na Ubuntu Server i wyświetla listę uruchomionych usług, które nadal korzystają z usuniętych plików bibliotek.

sudo needrestart -r l

Para flag -r l oznacza "tylko lista", więc polecenie jedynie raportuje stan bez wprowadzania żadnych zmian.

Dlaczego restart jest zawsze konieczny

Jądro na dysku pozostaje niezmienione. Poprawki typu live patch są ładowane do działającego jądra i nigdy nie są zapisywane w obrazie startowym, więc restart uruchamia system z użyciem linux-image wybranego przez bootloader, a klient Livepatch ponownie nakłada poprawki, które nadal mają zastosowanie. W czasie między tymi dwoma momentami system działa na niepoprawionym kodzie, co stanowi kolejny powód, by uruchamiać aktualne jądro zamiast starego.

Zakres wsparcia dotyczy serii jądra, a serie te są wycofywane. Gdy używana seria wypada z listy wspieranych, linia kernel state przestaje raportować pokrycie poprawkami, a jedynym rozwiązaniem jest nowsze jądro. To wymaga restartu.

Poprawki jądra o średnim i niskim priorytecie nigdy nie są dostarczane przez live patching. Pozostają one w pakiecie na dysku i trafiają do systemu dopiero po restarcie.

Długo działające jądra gromadzą również stan, którego nakładanie poprawek nie czyści. Warto przytoczyć stanowisko firmy Canonical, ponieważ jest ono uczciwe: Livepatch „nie zastępuje restartu. Jest to narzędzie, które daje większą kontrolę poprzez zapobieganie nieplanowanym restartom”. Słowem kluczowym jest tutaj nieplanowanym. Restart nadal jest konieczny. Użytkownik decyduje jedynie o jego terminie.

Jak zaplanować restart z gwarancją powrotu systemu

Restart VPS jest jednostronny, jeśli nie masz dostępu do konsoli. Zanim wpiszesz reboot, upewnij się, że będziesz w stanie odzyskać dostęp, gdy maszyna nie wróci do pracy.

• Potwierdź, że dostawca udostępnia konsolę szeregową lub podgląd VNC (virtual network computing) w panelu sterowania i otwórz go teraz, zamiast czekać do momentu awarii.
• Sprawdź wolne miejsce za pomocą df -h /boot. Pełna partycja /boot powoduje błąd pakietu jądra podczas zapisu initramfs (initial RAM filesystem), co może pozostawić wpis w programie rozruchowym wskazujący na niedokończony obraz.
• Zachowaj przynajmniej jedno starsze, sprawne jądro. GRUB wyświetla je w sekcji "Advanced options for Ubuntu", a uruchomienie go jest najszybszą metodą odzyskiwania, gdy nowe jądro zawiedzie.
• Znajdź tryb ratunkowy (rescue mode) u swojego dostawcy, zanim będzie potrzebny. Jeśli po restarcie konsola wyświetla monit initramfs, to właśnie tam należy przeprowadzić naprawę.

Następnie zaplanuj restart na godzinę, w której będziesz aktywny:

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

To polecenie zaplanuje restart za pięć minut i wyśle komunikat do zalogowanych użytkowników. sudo shutdown -c anuluje to zadanie. Gdy maszyna wróci, potwierdź obie części:

uname -r
sudo canonical-livepatch status

uname -r powinno teraz wskazywać nowsze jądro, a wynik statusu powinien potwierdzać, że nowa seria jest obsługiwana. Jeśli maszyna w ogóle nie wraca do pracy, przyczyna prawie zawsze leży w ścieżce rozruchu, a nie w sieci, a ścieżka odzyskiwania znajduje się w przewodniku dla VPS, który nie uruchamia się po aktualizacji jądra.

Dlaczego stare jądra wymagają regularnego usuwania

Live patching pogarsza ten problem, ponieważ eliminuje potrzebę restartu, podczas gdy pakiety linux-image są stale instalowane. Każde jądro instaluje obraz rozruchowy, initramfs, drzewo modułów oraz zazwyczaj pakiet nagłówków. Na małym serwerze VPS z oddzielną partycją /boot o rozmiarze kilkuset megabajtów, trzy lub cztery takie zestawy zapełniają ją całkowicie.

Pełna partycja /boot uniemożliwia instalację kolejnego jądra, co prowadzi do sytuacji, w której maszyna nie może pobrać niezbędnej aktualizacji. Polecenie apt autoremove usuwa stare jądra, gdy stają się one zbędne, jednak na serwerze, który nigdy nie jest restartowany, nie zawsze są one kwalifikowane do usunięcia, ponieważ menedżer pakietów nie usunie jądra, na którym system może nadal pracować.

Należy zatem sprawdzić zainstalowane wersje, zachować aktualnie używane jądro oraz jedno sprawdzone zapasowe, a pozostałe usunąć, korzystając z bezpiecznej procedury usuwania starych jąder w systemie Ubuntu. Nigdy nie należy usuwać jądra, które jest zgłaszane przez uname -r.

FAQ

Czy live kernel patching oznacza, że nigdy nie muszę restartować mojego VPS?

Nie. Poprawki typu live są ładowane do działającego jądra i nie są zapisywane w obrazie startowym, więc linux-image na dysku pozostaje w wersji, z której uruchomiono system. Canonical stwierdza to wprost: Livepatch „nie zastępuje restartu. Jest to narzędzie zapewniające większą kontrolę poprzez zapobieganie nieplanowanym restartom”. Zakres ochrony kończy się również w momencie wycofania danej serii jądra, a poprawki jądra o średnim stopniu ważności nigdy nie są dostarczane w trybie live. Należy zaplanować restart serwisowy w wybranym przez siebie terminie, zamiast czekać na wymuszenie tej czynności.

Jak sprawdzić, czy live kernel patching faktycznie stosuje poprawki?

Uruchom sudo canonical-livepatch status i odczytaj dwie linie. kernel state informuje, czy używana seria jądra jest objęta usługą, a patch state wskazuje, czy poprawki dla tego jądra są załadowane. Można również sprawdzić stan jądra bezpośrednio za pomocą ls /sys/kernel/livepatch/, co wyświetli listę zawierającą jeden katalog na każdą załadowaną poprawkę. Pusta lista oznacza, że w pamięci nie ma obecnie żadnych poprawek, niezależnie od tego, co wskazuje klient.

Czy Ubuntu Pro jest darmowe na prywatnym VPS?

Tak, w określonym limicie. Według zapisów Canonical, Ubuntu Pro „jest i zawsze będzie darmowe do użytku osobistego na maksymalnie 5 maszynach fizycznych”, a dla oficjalnych członków Ubuntu Community limit ten wynosi 50 maszyn (stan na sierpień 2026). Użytek komercyjny wymaga płatnej subskrypcji. Maszynę podpina się za pomocą sudo pro attach TOKEN, używając tokena z panelu konta Ubuntu Pro, a następnie włącza usługę poleceniem sudo pro enable livepatch.

Dlaczego CVE jądra nadal widnieje jako niepoprawione po uruchomieniu Livepatch?

Zazwyczaj istnieją dwa powody. Poprawka może znajdować się poniżej progu ważności, ponieważ Canonical stosuje live patching tylko dla „podatności jądra o krytycznym i wysokim poziomie w skali Common Vulnerability Scoring System (CVSS) oraz priorytecie Ubuntu”, a resztę pozostawia pakietowi na dysku. Alternatywnie, poprawka może być niemożliwa do wyrażenia jako zmiana treści funkcji, na przykład gdy upstream zmienił strukturę danych, czego live patching nie może bezpiecznie wykonać na już zaalokowanych obiektach. W obu przypadkach rozwiązanie jest takie samo: zainstaluj zaktualizowany pakiet jądra i uruchom z niego system.

Czego live kernel patching w ogóle nie obejmuje?

Przestrzeni użytkownika (userspace). Canonical wyraźnie zaznacza, że Livepatch „nie poprawia bibliotek przestrzeni użytkownika, takich jak OpenSSL czy glibc, ponieważ jest to odpowiedzialność unattended-upgrades lub narzędzia do zarządzania systemem”. Nie może również dostarczyć nowej wersji jądra ani nowej funkcji, ponieważ jedynie zastępuje treści funkcji wewnątrz serii, która jest już uruchomiona. Nie może również poprawiać funkcji __init, które zostały już wykonane i zwolnione z pamięci w momencie, gdy serwer jest uruchomiony.