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ń. Naprawiona 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 6 miesięcy był aktualizowany za pomocą live patchingu, nadal korzysta z tego samego obrazu jądra 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 go włączyć samodzielnie za pomocą dwóch poleceń, co warto wiedzieć przed dopłaceniem 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ź jego obecność w aktualnie uruchomionym jądrze:

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

Wiersz zawierający CONFIG_LIVEPATCH=y oznacza, że używane jądro zostało zbudowane z aktywnym rdzeniem. Bez tego mechanizmu żadna usługa live patching nie może wprowadzić zmian na danej maszynie.

Samo przekierowanie wykorzystuje ftrace, czyli narzędzie do śledzenia funkcji jądra. Większość funkcji jądra jest kompilowana z instrukcją wywołania umieszczoną na samym początku, jeszcze przed przetworzeniem argumentów lub modyfikacją stosu. Ftrace wykorzystuje ten punkt wywołania jako punkt zaczepienia (hook). W momencie nakładania poprawki rdzeń live patching rejestruje procedurę obsługi ftrace dla docelowej funkcji, która przekierowuje wykonanie kodu do funkcji zastępczej. Dokumentacja jądra określa 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 stwierdzenia wynikają dwie konsekwencje, które mają znaczenie w dalszej części. Możliwe do załatania są tylko te funkcje, które ftrace może przechwycić, więc funkcja skompilowana bez wspomnianego wywołania wejściowego nie może zostać załatana. Ponadto jednostką podlegającą łataniu jest cała funkcja, a nie pojedyncza linia kodu wewnątrz niej.

Trudniejszym zadaniem jest bezpieczne przełączenie działającego systemu. Jeśli stary kod nadal wykonuje się na stosie któregoś z procesorów w momencie zamiany funkcji, dochodzi do wymieszania starego i nowego zachowania. Główna gałąź Linux rozwiązuje ten problem za pomocą modelu spójności opartego na zadaniach (per-task consistency model), opisanego w dokumentacji jądra jako rozwiązanie hybrydowe: „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 dane zadanie nie znajduje się obecnie wewnątrz łatanej funkcji. Dopóki wszystkie zadania nie zostaną przeniesione, poprawka znajduje się w stanie przejścia.

Rezultat można sprawdzić samodzielnie. Zastosowane poprawki są widoczne w /sys/kernel/livepatch, gdzie każdy katalog odpowiada jednej poprawce, a wewnątrz znajdują się listy załatanych funkcji.

ls /sys/kernel/livepatch/

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

Czego nie naprawia aktualizacja jądra w czasie rzeczywistym

Modyfikowane są ciała 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 przepisanie obiektów, które są już przydzielone i używane. Projekt kpatch określa ten przypadek wprost: „Poprawki modyfikujące statycznie przydzielone dane nie są bezpośrednio wspierane”. Zmienne typu shadow oraz funkcje zwrotne (callbacks) stanowią obejście, jednak wymagają ręcznego przygotowania dla każdej poprawki, nie są automatyczne.
• Poprawki obejmujące jednocześnie kilka funkcji. Poprawka zmieniająca kolejność blokad (lock ordering) w grupie funkcji wymaga jednoczesnej zmiany wszystkich z nich, a model spójności przełącza zadania zamiast zamrażać całą maszynę w jednym momencie.
• Kod inicjalizacyjny. Funkcje oznaczone __init zostały już wykonane i zwolnione w momencie, gdy serwer jest uruchomiony, więc nie ma czego przekierowywać.
• Nowe wersje i funkcje jądra. Aktualizacja w czasie rzeczywistym pozwala na zmianę poziomu poprawek wewnątrz jednej serii jądra. Nigdy nie przenosi systemu między seriami i nie dodaje 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 wyznacza granicę: „Canonical Livepatch nie aktualizuje bibliotek przestrzeni użytkownika, takich jak OpenSSL czy glibc, ponieważ jest to zadanie narzędzia unattended-upgrades lub innego systemu zarządzania”. Jądro zaktualizowane w czasie rzeczywistym przy nieaktualnym 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ż ograniczenie dotyczące stopnia ważności. Canonical deklaruje, ż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 na konkretną lukę, a CVSS to przypisana do niej ocena. Luka w jądrze o średnim stopniu ważności jest naprawiana w pakiecie na dysku i nie jest wdrażana w czasie rzeczywistym, 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 korzystają z tego samego mechanizmu 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 darmowy 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 wersji jądra, obejmując jądra typu general availability (GA) w wydaniach o długoterminowym wsparciu (LTS) oraz ich warianty hardware enablement (HWE), w wersjach takich jak generic, aws, azure, gcp, oracle, ibm i lowlatency. Przed poleganiem na tym rozwiązaniu należy sprawdzić własne jądro względem opublikowanej listy jąder Canonical.

KernelCare, produkt firmy TuxCare, to komercyjny agent obsługujący wiele dystrybucji, w tym takie, które nie posiadają własnej usługi 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 i kGraft to rozwiązania pierwotne. kGraft wywodzi się z SUSE, kpatch z Red Hat, a obecny mechanizm poprawek w jądrze Linux jest połączeniem obu tych koncepcji. 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 głównym (upstream). W przypadku RHEL i jego pochodnych, zalecanym narzędziem jest natywna usługa dystrybucji, 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 pobierz token ze strony swojego 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 tokena inicjuje proces w przeglądarce i wyświetla kod, który należy wprowadzić na stronie Canonical. Dołączenie systemu automatycznie włącza zalecane usługi, co w przypadku aktualnego wydania LTS obejmuje Livepatch. Użyj sudo pro attach --no-auto-enable, jeśli wolisz samodzielnie wybrać usługi.

Jeśli Livepatch nie jest jeszcze włączony:

sudo pro enable livepatch
sudo canonical-livepatch status

Usługa działa w oparciu o snap canonical-livepatch, więc snapd musi być sprawny, aby proces włączania zakończył się powodzeniem. pro status wyświetla tabelę usług wraz z informacją o uprawnieniach i statusie. canonical-livepatch status wyświetla szczegóły dotyczące jądra, a dokumentacja Canonical przedstawia dane wyjściowe 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 usługą; ta linia zmienia status na negatywny po uruchomieniu jądra, którego Livepatch nie wspiera. patch state wskazuje, czy poprawki przeznaczone dla danego jądra zostały faktycznie załadowane. Jeśli jądro jest objęte wsparciem, ale 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 naprawić ustawieniami klienta.

Jak sprawdzić, czy wymagany jest restart systemu?

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

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 w celu zastosowania zmian, a nowy pakiet linux-image zawsze go tworzy. Plik .pkgs zawiera listę pakietów, które zgłosiły takie żądanie. Jeśli pierwsze polecenie zwraca No such file or directory, oznacza to, że od ostatniego uruchomienia systemu żadna usługa nie zażądała restartu. W bieżących wersjach Ubuntu /var/run jest dowodem 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ć ją bezpośrednio w jądrze systemu:

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

uname -r wyświetla wersję aktualnie uruchomionego jądra. Drugie polecenie wyświetla pakiety jądra zainstalowane na dysku. Obecność linux-image na tej liście, który jest nowszy niż wynik polecenia uname -r, oznacza, że maszyna pracuje na starym jądrze, niezależnie od statusu Livepatch. Jest to kluczowa weryfikacja, ponieważ mechanizm live patching 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 wyświetl", więc polecenie generuje raport 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, dlatego restart uruchamia system z użyciem tego, co wybierze linux-image bootloader, a klient Livepatch następnie ponownie aplikuje poprawki, które nadal mają zastosowanie. Pomiędzy tymi dwoma momentami system działa w oparciu o niezałatany kod, co stanowi kolejny powód, by uruchamiać aktualne jądro zamiast starego.

Pokrycie poprawkami dotyczy serii jąder, a serie te są wycofywane. Gdy używana seria wypada z listy wspieranych, linia kernel state przestaje raportować pokrycie, a jedynym rozwiązaniem jest nowsze jądro. To wymaga restartu. W wydaniach LTS nowsza seria zazwyczaj dociera do użytkownika jako jądro wspierające sprzęt (HWE), zawarte w wydaniu punktowym, takim jak 26.04.1, więc zamiennik znajduje się już w archiwum i brakuje jedynie zaplanowanego 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 poprawki nie czyszczą. 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, jeśli maszyna nie wróci do pracy.

• Potwierdź, że dostawca zapewnia dostęp do konsoli szeregowej lub podglądu 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, działające jądro. GRUB wyświetla je w sekcji "Advanced options for Ubuntu", a jego uruchomienie jest najszybszą metodą odzyskiwania systemu, gdy nowe jądro zawiedzie.
• Znajdź tryb ratunkowy (rescue mode) u swojego dostawcy, zanim będzie potrzebny. Jeśli po restarcie konsola wyświetla znak zachęty initramfs, to właśnie tam należy przeprowadzić naprawę.

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

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 do pracy, 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 niemal zawsze leży w ścieżce rozruchowej, a nie w sieci. Ścieżka odzyskiwania znajduje się w przewodniku dotyczącym VPS, który nie uruchamia się po aktualizacji jądra.

Dlaczego stare jądra wymagają usuwania

Live patching pogarsza ten problem, zamiast go rozwiązywać, ponieważ eliminuje potrzebę restartu systemu podczas instalacji kolejnych pakietów linux-image. Każde jądro instaluje obraz startowy, 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 instalacje 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 kwalifikują się one do usunięcia. Menedżer pakietów nie usunie jądra, na którym system może być aktualnie uruchomiony.

Należy zatem sprawdzać zainstalowane wersje, zachować aktualnie działające jądro oraz jedno sprawdzone jądro 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 narzędziem, które daje większą kontrolę, zapobiegając nieplanowanym restartom”. Zakres wsparcia kończy się również w momencie wycofania danej serii jądra, a poprawki 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 go przez system.

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ę katalogów odpowiadających załadowanym poprawkom. Pusta lista oznacza, że w pamięci nie ma obecnie żadnych poprawek, niezależnie od tego, co zgłasza 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 społeczności Ubuntu 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 z jednego z dwóch powodów. Poprawka może znajdować się poniżej progu ważności, ponieważ Canonical dostarcza w trybie live „luki w jądrze o krytycznym i wysokim priorytecie w skali Common Vulnerability Scoring System (CVSS) oraz z oceną Ubuntu Priority”, a resztę pozostawia pakietom 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 obiektach już zaalokowanych. W obu przypadkach rozwiązanie jest takie samo: zainstaluj zaktualizowany pakiet jądra i uruchom system z jego użyciem.

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 zadanie dla unattended-upgrades lub narzędzi do zarządzania systemem”. Nie może również dostarczyć nowej wersji jądra ani nowej funkcjonalności, ponieważ jedynie zastępuje treści funkcji wewnątrz serii, która jest aktualnie uruchomiona. Nie może także poprawić funkcji __init, które zostały już wykonane i zwolnione z pamięci w momencie, gdy serwer jest w pełni uruchomiony.