Jak zainstalować niestandardowe moduły jądra w systemie SLES 15 z funkcją bezpiecznego rozruchu

Aby załadować niestandardowy moduł jądra w systemie SLES 15 z włączoną funkcją Secure Boot, skompiluj go dla konkretnego jądra, które będzie uruchamiane, podpisz ukończony .koplik zaufanym certyfikatem podpisu, zarejestruj ten certyfikat jako klucz właściciela maszyny (MOK), a następnie załaduj moduł za pomocą modprobe. MOK to lokalnie kontrolowany certyfikat, któremu shim systemu SUSE i jądro Linuksa mogą zaufać w celu weryfikacji modułu Secure Boot. Nie wyłączaj funkcji Secure Boot, aby obejść odrzucony podpis. Poniższy proces jest przeznaczony dla administratora, który kontroluje maszynę i może zatwierdzić rejestrację klucza podczas ponownego uruchomienia.

Niniejszy przewodnik jest zgodny z dokumentacją administracyjną systemu SUSE SLES 15 SP7 oraz wytycznymi dotyczącymi pakowania modułów jądra SUSE, sprawdzonymi 6 października 2026 r. Polecenia używają acme_driverprzykładowej nazwy modułu; .kow razie potrzeby należy ją zastąpić rzeczywistą nazwą modułu bez sufiksu. Są to przykłady poleceń, a nie dane wyjściowe z testowanego hosta.

Kiedy ta metoda jest odpowiednia

Zastosuj to podejście w przypadku niestandardowego modułu out-of-tree – dostarczanego oddzielnie od działającego jądra – gdy możesz przebudować lub uzyskać kompilację dla docelowego jądra SLES i zarejestrować certyfikat na serwerze. Dotyczy to systemów uruchamianych za pomocą SUSE Secure Boot i ścieżki shim. Jeśli dostawca dostarcza oficjalny pakiet sterowników SLES 15, najpierw skorzystaj z jego instrukcji instalacji i podpisywania; pakiet dostawcy może zapewnić lepszą zgodność jądra i aktualizacje niż kopia ręczna.

Bezpieczny rozruch weryfikuje łańcuch rozruchowy, a jądro sprawdza również podpisy ładowalnych modułów zgodnie z obowiązującą polityką. Moduł może być podpisany, ale mimo to nie załadować się, jeśli jest skierowany do innego interfejsu ABI jądra, opiera się na brakujących symbolach lub został zbudowany dla niewłaściwej architektury. Z drugiej strony, dopasowanie jądra nie czyni niepodpisanego modułu zaufanym. Podpisanie dotyczy zaufania; nie ustanawia zgodności ani nie potwierdza bezpieczeństwa kodu.

Zanim zaczniesz

• Użyj konta administratora i potwierdź, że masz okno konserwacyjne. Rejestracja MOK wymaga ponownego uruchomienia i zatwierdzenia w MokManager, zazwyczaj za pośrednictwem konsoli lokalnej lub zdalnej.
• Sprawdź działające jądro i stan bezpiecznego rozruchu za pomocą uname -rkomend i mokutil --sb-state. Zbuduj moduł, korzystając z plików rozwojowych i zestawu narzędzi jądra pasujących do danej wersji jądra. Nazwy pakietów i wymagane pliki różnią się w zależności od pakietu serwisowego SLES, wersji jądra i metody kompilacji, dlatego należy je zweryfikować z repozytoriami włączonymi w systemie docelowym.
• Zdecyduj, gdzie będzie przechowywany prywatny klucz podpisu. W przypadku floty produkcyjnej skorzystaj z usługi kontrolowanego podpisywania w organizacji lub zatwierdzonego procesu zarządzania kluczami. W przypadku laboratorium lub pojedynczego hosta kontrolowanego, praktyczny może okazać się klucz generowany lokalnie. Chroń klucz prywatny; serwer potrzebuje certyfikatu publicznego do rejestracji, a nie klucza prywatnego.
• Miej pod ręką ścieżkę odzyskiwania, kod źródłowy modułu lub pakiet dostawcy oraz znane, dobre jądro. Nie instaluj sterownika na sprzęcie produkcyjnym, dopóki nie poznasz jego wymagań dotyczących urządzenia i jądra.

1. Utwórz klucz podpisu i certyfikat publiczny

W chronionym systemie podpisywania utwórz klucz prywatny i certyfikat X.509 zakodowany w standardzie DER. Wskazówki dotyczące pakowania modułów jądra SUSE zalecają codeSigningrozszerzone użycie klucza w obecnych pakietach serwisowych SLES 15. W tym przykładzie użyto OpenSSL i opisowej nazwy certyfikatu:

openssl req -new -x509 -newkey rsa:2048 -sha256 \
  -keyout module-signing.key \
  -out module-signing.der -outform DER -nodes \
  -days 4745 -addext "extendedKeyUsage=codeSigning" \
  -subj "/CN=Custom Module Signing/"
chmod 600 module-signing.key

Ta -nodesopcja pozostawia klucz prywatny niezaszyfrowany, dlatego uprawnienia do plików i kontrola nad pamięcią masową mają znaczenie. Nie kopiuj tego klucza prywatnego na serwer ogólnego przeznaczenia ani nie osadzaj go w pakiecie. Jeśli polityka organizacji wymaga szyfrowanego klucza, podpisywania sprzętowego, rotacji kluczy lub innego cyklu życia certyfikatu, postępuj zgodnie z tą polityką i wymaganiami narzędzia do podpisywania. Przenieś klucz tylko module-signing.derdo systemu, który zarejestruje klucz publiczny.

2. Zbuduj moduł dla jądra docelowego i podpisz go

Zbuduj moduł dokładnie w oparciu o wersję jądra wskazaną przez uname -r. Instrukcje kompilacji projektu źródłowego określają wymagany kompilator, nagłówki i konfigurację; nie ma jednego polecenia kompilacji, które pasowałoby do każdego niestandardowego modułu. Sprawdź wyniki, vermagicjeśli modinfochcesz zdiagnozować niezgodność jądra.

Podpisz końcowy plik modułu po kompilacji i każdym etapie pakowania lub usuwania. SUSE dokumentuje swój pomocnik do podpisywania w punkcie /usr/lib/rpm/pesign/kernel-sign-file; poniższy przykład wykorzystuje format PKCS#7 i skrót SHA-256:

/usr/lib/rpm/pesign/kernel-sign-file -i pkcs7 sha256 \
  module-signing.key module-signing.der acme_driver.ko

Pomocnik musi być dostępny w integracji podpisu SUSE w systemie. Jeśli go brakuje, sprawdź oficjalną dokumentację SLES/KMP i włączone repozytoria, aby poznać obsługiwaną konfigurację podpisu, zamiast zastępować ją dowolnym poleceniem podpisu. Do pliku dodawany jest podpis modułu. Nie usuwaj, nie edytuj, nie kompresuj ani nie modyfikuj modułu po podpisaniu; taka zmiana może unieważnić podpis. Zachowaj nienaruszony artefakt kompilacji, aby móc powtórzyć ostatni krok podpisywania.

3. Zarejestruj certyfikat publiczny jako MOK

Na serwerze SLES umieść module-signing.dercertyfikat publiczny w miejscu, w którym użytkownik root będzie mógł go odczytać, a następnie umieść go w kolejce do rejestracji:

mokutil --root-pw --import module-signing.der
mokutil --list-new

Dokumentacja SUSE --root-pwopisuje sposób autoryzacji oczekującej rejestracji hasłem root. Polecenie importu umieszcza certyfikat w kolejce; nie rejestruje go natychmiast. Zrestartuj serwer. W programie MokManager wybierz opcję „Zarejestruj klucz z dysku” , wybierz certyfikat, potwierdź rejestrację i zakończ żądaną autoryzację. Treść menu może się nieznacznie różnić w zależności od wersji systemu shim/MokManager. Jeśli nie możesz uzyskać dostępu do ekranu rejestracji, sprawdź ścieżkę rozruchu i skonfiguruj dostęp do konsoli; nie zakładaj, że certyfikat został zarejestrowany tylko dlatego, że polecenie importu zakończyło się powodzeniem.

Po uruchomieniu serwera sprawdź, czy klucz znajduje się na liście zarejestrowanych:

mokutil --list-enrolled

4. Zainstaluj, odśwież zależności modułów i załaduj je

Skopiuj podpisany plik do katalogu extra-modules dla uruchomionego jądra, odśwież mapę zależności i zażądaj modułu według nazwy. Jeśli instalujesz z innego uruchomionego jądra, zastąp go rzeczywistą wersją jądra:

release=$(uname -r)
install -D -m 0644 acme_driver.ko \
  "/lib/modules/$release/extra/acme_driver.ko"
depmod -a "$release"
modprobe acme_driver

modprobeJest generalnie preferowany, insmodponieważ rozwiązuje zależności między modułami. Przetestuj rzeczywiste urządzenie lub funkcjonalność udostępnianą przez sterownik; samo poprawne wykonanie polecenia nie dowodzi, że sprzęt działa poprawnie. Jeśli moduł ma być ładowany podczas rozruchu, dodaj jego nazwę w osobnym wierszu w pliku, takim jak /etc/modules-load.d/acme_driver.conf. SLES korzysta z mechanizmu ładowania modułów systemd dla tych plików konfiguracyjnych.

5. Sprawdź ścieżkę zaufania i rozwiąż problemy

Przydatne kontrole obejmują:

mokutil --list-enrolled
modinfo -F signer /lib/modules/$(uname -r)/extra/acme_driver.ko
lsmod | grep acme_driver
journalctl -k -b | tail -n 80

modinfo -F signerWyświetla metadane sygnatariusza osadzone w module. Samo w sobie nie dowodzi, że certyfikat jest zarejestrowany ani że działające jądro zaakceptowało podpis. modprobeBardziej przydatnym dowodem jest pomyślne uruchomienie z włączonym bezpiecznym rozruchem, a następnie inspekcja logów jądra i sprawdzenie działania urządzenia. Wyświetlone na rysunku wyjście terminala jest przykładem poleceń i ilustracją, a nie raportem z testu przeprowadzonego na potrzeby tego artykułu.

SUSE śledzi również, czy moduł jest obsługiwany, a załadowanie nieobsługiwanego modułu może wpłynąć na status obsługi jądra lub stan skażenia. Ta zasada jest niezależna od weryfikacji podpisu: zmiana ustawienia nieobsługiwanego modułu nie rejestruje klucza podpisu i nie naprawia odrzuconego podpisu. Przed zmianą tej zasady w obsługiwanym systemie produkcyjnym należy zapoznać się z wytycznymi dotyczącymi pomocy technicznej SUSE.

Zaplanuj aktualizacje jądra i powtarzające się wdrożenia

Moduł zbudowany dla jednej wersji jądra nie jest automatycznie kompatybilny z kolejną. Po aktualizacji jądra należy zainstalować odpowiednie środowisko kompilacji, przebudować moduł dla nowego interfejsu ABI jądra, podpisać plik końcowy, zainstalować go w drzewie modułów tego jądra i odświeżyć informacje o jego zależnościach. Jeśli certyfikat podpisujący pozostaje zaufany, zazwyczaj nie ma potrzeby jego ponownej rejestracji. Certyfikat zastępczy lub rotowany wymaga własnej rejestracji i zatwierdzenia. Przetestuj nowe jądro i moduł razem, zanim zaczniesz korzystać z nienadzorowanego ładowania podczas rozruchu.

W przypadku floty lub sterowników, które muszą przetrwać rutynowe aktualizacje, należy zastosować powtarzalny przepływ pracy, taki jak podejście SUSE Kernel Module Package (KMP), w zależności od modelu sterowników i wsparcia. Pakowanie może organizować kompilacje i podpisywanie poszczególnych jąder, ale nie eliminuje konieczności zapewnienia prawidłowej ochrony kluczy, zgodności modułów, zaufania MOK i testowania aktualizacji. Zapoznaj się z dokumentacją dotyczącą konkretnego pakietu serwisowego SLES 15 i cyklu życia jądra obsługiwanego w Twojej organizacji.

Oficjalne referencje

• Podręcznik administratora systemu SUSE Linux Enterprise Server 15 SP7 — Bezpieczny rozruch i rejestracja MOK, ładowanie modułów i zasady dotyczące nieobsługiwanych modułów.
• Podręcznik pakietów modułów jądra SUSE — proces podpisywania KMP i wymagania dotyczące podpisywania mające zastosowanie w systemie SLES 15.
• Dokumentacja podpisywania modułów jądra Linux — zachowanie podpisu jądra i ograniczenia dotyczące podpisanych plików modułów.