© psdesign1, Fotolia

Anfang März hat Linus Torvalds das scheue Krokodil freigesetzt. Ein paar Kommandos, Hinweise und Tricks reichen aus, um es auf einem Debian-Rechner zu einem nützlichen Arbeitstier zu machen.

Die Zeit war reif. Linus Torvalds hat an der großen Schraube gedreht, den Zeiger von 4 auf 5 verschoben und damit ein scheues Krokodil in die Freiheit entlassen: “Shy Crocodile” ist nämlich der Name der neuen Linux-Version 5.0, ihr Geburtsdatum ist der 3. März 2019. Dabei betont der Linux-Chef, dass ihm nach Version 4.20 Finger und Zehen zum Zählen ausgehen und er daher den großen Drehschalter für Major-Releases betätigt hat (Abbildung 1, siehe auch die “Kernel–News” in dieser Ausgabe).

Abbildung 1: Systemarchitektur des Audit-Subsystems in Kernel und Userland.

Mit aufregenden Änderungen an Schnittstellen oder Ähnlichem geht laut Torvalds der numerische Versionssprung nicht einher. Tatsächlich lassen die Linux-Entwickler sinnvolle Änderungen jederzeit einfließen und heben sich keine Knaller auf. Technikinteressierte müssen daher nicht jahrelang auf neue Features warten. Im kommerziellen Produktiveinsatz ist das nicht immer gewünscht, weshalb die Distributoren zumeist auf ältere, dafür jedoch bewährte Kernel mit Long Time Support (LTS) setzen.

Für den Nerd aber ist eine Major-Release Ansporn, seiner Hardware den neuesten Spectre- und Meltdown-Schutz zu bieten oder auch nur einen besseren Datendurchsatz im Netzwerk. Dafür öffnet er gerne eine Konsole, holt sich die neuesten Sourcen, tippt Kommandos ein und lässt die CPU heißlaufen. Denn das Generieren eines Kernels für eine Maschine, auf der bereits ein Linux läuft, ist gar nicht so schwierig und – abhängig von den eigenen Wünschen und der Hardware – auch nicht übermäßig zeitaufwändig.

Linuxer holen sich von Kernel.org oder gar bei Torvalds höchstselbst die Kernelquellen ab, würzen sie mit einer Mischung aus vorhandener und neuer Konfiguration an, verkürzen nach Möglichkeit die Bauzeit, indem sie später unbenutzte Treiber gleich ausknipsen, und werfen das Kernel-Buildsystem (KBS) an. Zugegeben, der schwierige Teil folgt erst danach: die Installation. Im einfachen Fall installieren sie die Treiber, erzeugen ein so genanntes Initram-FS, kopieren den Kernel an die korrekte Stelle im Dateisystem und aktualisieren schließlich die Bootloader-Konfiguration.

Falls das System jedoch dauerhaft im sicheren Modus (Secure Boot) starten soll oder muss, kommt noch einiges hinzu. Dann muss der Admin den Kernel und dessen Treiber mit einer digitalen Signatur versehen und die dazu passende Unterschriftenprobe beim Bootloader hinterlegen.

Auf Kommandos

Nun zu den Details: Listing 1 zeigt die Kommandos, um den 5.0-Kernel auf einem (und für ein) Ubuntu-System anzufertigen. Im einfachsten Fall kann sich der Benutzer auf einer Konsole per Kommando »sudo su« mit Rootrechten ausstatten. Etwas sicherer geht es jedoch zu, wenn er nur Schreibrechte auf das Linux-Quellcode-Verzeichnis vergibt und danach mit seinen normalen User-Rechten weiterarbeitet.

01 ID=`id -un` # Auf die rückwärtsgerichteten Anführungsstriche achten!
02 sudo mkdir /usr/src/linux
03 sudo chown $ID.$ID /usr/src/linux
04 sudo apt-get install build-essentials libncurses-dev bison flex bc libssl-dev
05 cd /usr/src/linux
06
07 # Stabile Version herunterladen, überprüfen und auspacken
08 wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.0.tar.xz
09 wget https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.0.tar.sign
10
11 unxz linux-5.0.tar.xz
12 gpg --verify linux-5.0.tar
13 tar xvf linux-5.0.tar
14 mv linux-5.0/* . # Dateien aus dem Archiv in das Linux-Verzeichnis verschieben
15
16 # Alternativ die Entwicklerquellen von Linus Torvalds
17 # cd /usr/src/
18 # git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
19 cd /usr/src/linux/
20
21 VERSION=`uname -r` # Auf die rückwärtsgerichteten Anführungszeichen achten!
22 cp /boot/config-$VERSION .config
23 make menuconfig
24
25 # Das nachfolgende Kommando ist optional.
26 # Ist der Kernel für die lokale Maschine gedacht, beschränkt das Kommando
die Zahl der Module auf diejenigen, die aktuell in Verwendung sind.
27 make localmodconfig # Optional, verkürzt die Generierungszeit
28
29 make -j6 bzImage modules

Dazu liest er in Zeile 1 die eigene ID aus, um damit die Besitzverhältnisse für das neu anzulegende Quellcodeverzeichnis anzupassen (Zeilen 2 und 3). Rootrechte sind allerdings ein weiteres Mal in Zeile 4 nötig, die einige Buildtools installiert. Die Herkunft der Quellcode-Dateien nötigt nun zu einer Richtungsentscheidung zwischen Sicherheit und Mut.

Alternative 1: Aus offizieller Quelle

Der besonnene Nutzer wechselt in das Verzeichnis »/usr/src/linux/« und holt von Kernel.org per »wget« die Sourcen einer offiziell freigegebenen Version, beispielsweise 5.0 (Zeile 8). Selbstverständlich lädt er auch die zugehörige digitale Unterschrift (Zeile 9) und stellt damit sicher, dass er den originalen und unveränderten Quellcode übernommen hat. Die Sicherheitsprüfung beschreibt der Kasten “Vertrauen schaffen”.

01 gpg --keyserver hkp://keys.gnupg.net --recv-keys 00411886 6092693E
02 gpg --edit-key 6092693E

Abbildung 2: Das Hochsetzen der Schlüssel-Vertrauensstufe vermeidet Warnungen.

Alternative 2: Mit Linus’ Laborversion

Der mutige Kernel-Bäcker holt sich dagegen per »git clone« eine direkte Kopie des Torvalds’schen Repository. Er weiß, dass unser Chefentwickler an der Version von morgen arbeitet, am so genannten Release-Kandidaten, und dass dessen Quellcode-Version experimentell ist (Listing 1, Zeilen 17 und 18).

Ist Git sei Dank der Quellcode installiert, wird eine passende Konfiguration nötig. Eine solche für einen x86-PC von Grund auf aufzubauen, ist eine mühsame, zeitaufwändige und folglich nicht empfehlenswerte Methode. Nahe liegt, sich auf die Suche nach einer existierenden Konfiguration als Basis zu machen.

Abbildung 3: Der Aufruf von »make menuconfig« aktualisiert die Konfiguration.

Ubuntu archiviert seine aktuelle Kernelkonfiguration unter einem eindeutigen Namen im Verzeichnis »/boot/«. Von dort kann man sich eine möglichst aktuelle einfach besorgen und als (versteckte) Datei ».config« ins Basisverzeichnis »/usr/src/linux/« kopieren (Zeilen 21 und 22). Ein Aufruf von »make menuconfig« (Zeile 23) startet die Konfigurationsoberfläche und aktualisiert später außerdem die Konfiguration. »Exit« und noch ein »Yes« als Antwort auf die elementare Frage »Do you wish to save your new configuration?« beenden die Konfigurationsoberfläche. Damit sind alle Änderungen übernommen (Abbildung 3).

Laufen lassen

Wer jetzt das Kernel-Buildsystem aktiviert und den Übersetzungslauf startet, muss Zeit (rund 45 Minuten auf einer CPU i5-7200U) und Speicherplatz (16 GByte) auf seiner SSD mitbringen. Denn die Ubuntu-Config-Rezeptur erzeugt so ziemlich alle Module, die irgendjemand irgendwann mal brauchen könnte.

Wer keine 45 Minuten warten will, sondern bloß eine Tasse guten Tees schlürfen (zirka 15 Minuten), ruft »make localmodconfig« vor dem Generierungslauf auf (Zeile 27). Das Kommando klammert alle Komponenten vom Build aus, die das lokale Linux nicht in Gebraucht hat. Der Generierungslauf selbst startet dann per »make -j6 bzImage modules« (Zeile 29). Das generiert den Kernel sowie die konfigurierten Module.

01 NEW_VERSION=5.0.0+  # Versionsnummer muss angepasst werden
02 make modules_install
03 sudo cp .config /boot/config-$NEW_VERSION
04 sudo mkinitramfs -o /boot/initrd.img-$NEW_VERSION $NEW_VERSION
05 sudo cp arch/x86/boot/bzImage /boot/vmlinuz-$NEW_VERSION
06 sudo update-grub

Ist die CPU wieder abgekühlt, geht es zur Kernel-Installation. Das »make modules_install« (Listing 3, Zeile 2) kopiert zunächst die Module in das Verzeichnis »/lib/modules/Versionsnummer«. Die Entwickler von Debian legen außerdem eine Kopie der Kernelkonfiguration in den Ordner »/boot/«, was Zeile 3 nachahmt. Zwingend ist, dass der Kernel ein initiales RAM-Filesystem (Initram-FS) bekommt. Das ist die Aufgabe von »mkinitramfs« (Zeile 4). Der Kernel selbst gehört in das Verzeichnis »/boot/« kopiert (Zeile 5). Am Ende aktualisiert ein »update-grub«-Lauf den Bootloader, sodass mit dem nächsten Neustart der frisch gebackene Kernel aktiv wird.

Kleiner Tipp: Sollte der Kernel nicht booten, drücken pfiffige Admins beim Hochfahren die Escape-Taste. Dadurch kommt er in das Grub-Menü und wählt dort einen ihm bekannten funktionierenden Kernel aus. Nach dem Neustart zeigt ein »uname -a« auf der Konsole, ob jetzt das scheue Krokodil unterwegs ist.

Sicheres Hochfahren

Wer einen Rechner mit eingeschaltetem Secure Boot betreibt, dürfte nach dem Reboot des Systems allerdings im Bootloader hängen bleiben. Der erzeugte Kernel trägt nämlich keine gültige digitale Signatur. Um dieses Problem zu lösen, kann der Admin den Secure Boot im Bios oder über den Linux vorgeschalteten Bootloader Shim deaktivieren. Besser und natürlich sicherer ist es, den Kernel digital zu unterschreiben und die Unterschriftenprobe als so genannten MOK (Machine Owners Key) zu hinterlegen (Listing 4).

Für die digitale Unterschrift bedarf es eines geeigneten Schlüsselpaars. Erfreulicherweise legt das Kernel-Buildsystem ein solches Paar in Form eines privaten Schlüssels und eines Zertifikats an. Ein Zertifikat besteht unter anderem aus einem öffentlichen Schlüssel und Meta-Informationen zur Identifikation des Schlüsselbesitzers.

01 cd /usr/src/linux/certs/
02 sbsign --key signing_key.pem --cert signing_key.pem../arch/x86/boot/bzImage --output /boot/vmlinuz-5.0.0+
03 update-grub
04 mokutil --import signing_key.x509

Die Meta-Info erwartet das Kernel-Buildsystem in der Datei »certs/x509.genkey« im Linux-Quellcode-Verzeichnis. Fehlt sie, wird beim Kernel-Make eine angelegt. Wer im Zertifikat nicht die Platzhalter »Unspecified company« und »Build time autogenerated kernel key« haben möchte, sollte vor dem ersten Kernel-Backvorgang die Datei jedoch selber anlegen und mit sinnvollen Angaben bestücken (Listing 5, Zeilen 9 bis 11).

Obacht beim Einmal-Passwort

Die Hintergründe von Secure Boot beschreibt [2] – allerdings nur den generellen Mechanismus, das Handling und das Signieren von Modulen, nicht aber das des Kernels selbst. Den selbst gebackenen Kernel digital zu unterschreiben – sodass ihn der Bootloader Shim akzeptiert –, gelingt mit dem zur UEFI-Firmware gehörigen Signaturprogramm »sbsign«. Anders als in [1] beschrieben, erwartet der aktuelle Kernel den privaten Schlüssel zum Unterschreiben nicht in der Datei »signing_key.priv«, sondern in der Datei »signing_key.pem« zusammen mit dem Zertifikat im so genannten PEM-Format (Privacy Enhanced Mail).

01 [ req ]
02 default_bits = 4096
03 distinguished_name = req_distinguished_name
04 prompt = no
05 string_mask = utf8only
06 x509_extensions = myexts
07
08 [ req_distinguished_name ]
09 O = Unspecified company
10 CN = Build time autogenerated kernel key
11 emailAddress = unspecified.user@unspecified.company
12
13 [ myexts ]
14 basicConstraints=critical,CA:FALSE
15 keyUsage=digitalSignature
16 subjectKeyIdentifier=hash
17 authorityKeyIdentifier=keyid

Während »sbsign« mit dem Base64-kodierten Schlüssel zufrieden ist, wünscht der Shim-Loader die Unterschriftenprobe im binären Zertifikatsformat DER (Distinguished Encoding Rules). Glücklicherweise legt das Kernel-Buildsystem den öffentlichen Teil auch im DER-Format in der Datei »signing_key.x509« ab (Abbildung 4), sodass sich diese per »mokutil« in die Datenbank des Bootloaders Shim laden lässt (Listing 4, Zeile 4).

Abbildung 4: Wer Secure Boot will, muss den Kernel signieren und den öffentlichen Schlüssel als MOK ablegen.

Bei diesem Vorgang ist ein Einmal-Passwort festzulegen, das der Bootloader mit dem nächsten Reboot abfragt. Allerdings erfolgt dieser Passwortcheck nicht wie bei gewöhnlichen Logins. Vielmehr fragt das System einzelne Zeichen des Passworts in einer zufällig gewählter Reihenfolge ab. Zudem muss der Benutzer den Vorgang über die direkt am Rechner angeschlossene Tastatur erledigen.

Daher wählt der umsichtige Admin auch nur Zeichen für das Passwort aus, die auf unterschiedlichen Tastaturen an identischer Stelle sind. Sonderzeichen, insbesondere Umlaute sind für ihn tabu. Sicherheitshalber sollte der Admin übrigens nach dem Signieren des Kernels noch einmal ein »update-grub« aufrufen. Ist das Passwort auf diese Art nach dem Reboot eingegeben, lässt sich die Unterschriftenprobe scharfschalten (Auswahlpunkt »Enroll MOK«). Mit jedem nachfolgenden Reboot überprüft der Bootloader die digitale Unterschrift und lädt nur bei Übereinstimmung den Kernel.

Pakete packen

Um aus dem selbst generierten Kernel ein Debian-Paket zu machen, das er auf einem anderen Rechner installieren will, hat der Admin früher auf das »make-kpkg«-Kommando zurückgegriffen. Mittlerweile übernimmt das Kernel-Buildsystem diese Aufgabe. Dazu ruft er im Quellcodeverzeichnis »make -j6 bindeb-pkg« auf. Die erzeugten Debian-Pakete tauchen nach einigen Minuten im Elternverzeichnis des Linux-Quellcodes auf, also unter »/usr/src/«.

Reifezeugnis

Linux hat einen Reifegrad erreicht, der einen Wechsel des Kernels nur selten erzwingt. Der Bedarf an Cutting-Edge-Features oder nach erhöhter Sicherheit sind jedoch gute Gründe, sich als Kernelbäcker zu betätigen. Aber auch einfach nur die Freude am Experimentieren oder das gute Gefühl, das Allerneueste auf seinem Hobel zu fahren, sind ausreichend Motivation. Last but not least braucht Linus Torvalds dringend umfangreiche Unterstützung beim Testen seiner Entwicklerkernel. Auf geht’s, backen!