# Kernel Deployment: Sicherheit und Validierung im großen Stil

TL;DR / Management Summary Ein selbstgebafter Kernel (Artikel 364) ist ein Risiko, wenn er ungetestet ausgerollt wird. In diesem Modul professionalisieren wir den Prozess: Wir lernen, wie wir eigene Kernels für UEFI Secure Boot signieren (via MOK), wie wir neue Versionen ohne Reboot mittels kexec testen und wie wir den Kernel in ein RPM oder DEB Paket verpacken, um ihn über den SUSE Manager oder Satellite (Artikel 111/175) sicher auf die gesamte Server-Flotte zu verteilen.

# 1. Einführung & Architektur

Vom Einzelstück zum Standard.

Ein manuell kopiertes vmlinuz ist schwer zu warten. Im Enterprise-Umfeld muss der Kernel ein Paket sein.

# Die Deployment-Pipeline (Mermaid)

graph TD
    A[Build Host: make binpkg] --> B[Artifact: kernel.rpm / .deb]
    B --> C[Signing Station: MOK / GPG]
    C --> D[Internal Repository]
    D --> E[Testing: Canary Nodes]
    E -->|Passed| F[Production Fleet]
    subgraph "Verification"
        G[kexec: Test without reboot]
        H[Secure Boot: Validate Signature]
    end
    E --- G
    F --- H

# 2. UEFI Secure Boot: Eigene Kernels signieren

Vertrauen erzwingen.

Standardmäßig lehnt UEFI einen selbstgebauten Kernel ab. Wir müssen unseren eigenen Schlüssel (MOK - Machine Owner Key) im System hinterlegen.

# Schritt 1: Schlüssel generieren

openssl req -new -x509 -newkey rsa:2048 -keyout MOK.key -out MOK.crt -nodes -days 3650 -subj "/CN=MyCompany Kernel CA/"

# Schritt 2: Kernel signieren

sudo sbsign --key MOK.key --cert MOK.crt --output /boot/vmlinuz-custom.signed /boot/vmlinuz-custom

# Schritt 3: Key im UEFI registrieren

sudo mokutil --import MOK.crt
# Beim nächsten Reboot muss das Passwort an der Konsole eingegeben werden (MOK Management).

# 3. Schnelles Testen mit kexec

Kernel-Tausch ohne Hardware-Initialisierung.

Anstatt den Server komplett neu zu starten, können Sie den neuen Kernel direkt in den Speicher laden und den alten Kernel “ersetzen”.

# Neuen Kernel laden
sudo kexec -l /boot/vmlinuz-custom --initrd=/boot/initramfs-custom.img --reuse-cmdline

# Alten Kernel beenden und neuen starten
sudo kexec -e

• Vorteil: Die Downtime sinkt von Minuten auf Sekunden. Ideal zum Testen von Kernel-Optionen.

# 4. Day-2 Operations: Packaging

Den Kernel paketieren.

Nutzen Sie die eingebauten Skripte des Kernel-Trees, um native Pakete zu bauen.

# RHEL / SLES (RPM)

make -j$(nproc) rpm-pkg

# Debian / Ubuntu (DEB)

make -j$(nproc) bindeb-pkg

Dies erstellt Pakete, die alle Files (/boot, /lib/modules) und Scripts (Post-Install) enthalten.

# 5. Troubleshooting & “War Stories”

Wenn die Flotte hinkt.

# Story 1: “Der Secure-Boot Lockout”

Symptom: Nach einem Massen-Rollout des neuen Kernels bootet kein einziger Server mehr. Alle hängen im UEFI-Error “Security Violation”. Ursache: Der Admin hat den Kernel zwar signiert, aber vergessen, den MOK-Key auf den Zielservern zu registrieren. Lösung: Nutzen Sie Ansible, um mokutil --import vorab auf allen Servern auszuführen. Lerneffekt: UEFI-Keys müssen pro physikalischem Board (oder VM) einmalig akzeptiert werden.

# Story 2: “Das hängende Paket-Update”

Symptom: Ein dnf upgrade bricht ab, weil der eigene Kernel eine höhere Versionsnummer hat als der Standard-Kernel, aber keine passenden Headers mitliefert. Ursache: Inkonsistentes Packaging. Lösung: Bauen Sie immer das Header-Paket (kernel-devel) mit und nutzen Sie Version-Pinning (Artikel 065), damit der Custom-Kernel nicht versehentlich durch ein Standard-OS-Update überschrieben wird.

# 6. Fazit & Empfehlung

• Sicherheit: Signieren Sie Ihre Kernels immer. Secure Boot ist ein mächtiges Werkzeug gegen Rootkits.
• Wahl: Nutzen Sie kexec nur zum Testen. Ein klassischer Reboot ist für die Stabilität (Hardware-Reset) vorzuziehen.
• Automation: Ein Custom-Kernel sollte niemals manuell kopiert werden. Nutzen Sie Pakete (.rpm / .deb).

# Anhang: Cheatsheet