„Im nächsten Teil wird nicht nur erklärt, sondern gemacht. Mit einem nRF52840-Dongle und Logitacker schneide ich den Kopplungsvorgang einer Unifying-Tastatur mit, leite daraus den Schlüssel ab und lese die Eingaben mit.“ Das habe ich am Ende des letzten Beitrags geschrieben. Jetzt löse ich es ein.
Kurz zur Erinnerung, falls du den ersten Teil nicht gelesen hast: Logitech-Funktastaturen mit Unifying-Empfänger verschlüsseln die Übertragung mit AES, aber die Kopplung selbst, also der kurze Moment, in dem sich Tastatur und Empfänger gegenseitig kennenlernen, hat eine nie gepatchte Design-Lücke. Wer genau in diesem Moment mithört, kann daraus den Schlüssel ableiten. Das ist CVE-2019-13052, seit 2019 öffentlich, von Logitech nie gefixt.
Im ersten Teil stand das als Zeile in einer CVE-Datenbank und als Absatz in einer Offenlegung von Marcus Mengs. Diesmal nicht. Diesmal sitze ich mit einem Dongle für unter 30 Euro vor meiner eigenen MX Keys, schneide die Kopplung mit, und am Ende tippe ich auf der Tastatur, während eine Konsole live mitliest, was ich gerade drücke.
Vorweg die Grenze des Beitrags, damit du nicht am Ende danach suchst: den abgeleiteten AES-Schlüssel zeige ich nirgends. Warum, erkläre ich weiter unten. Die Kurzform: das war zum Zeitpunkt der Aufnahme ein aktives, funktionierendes Credential für meine echte Tastatur, kein historisches Artefakt.
Der Dongle, und welches Werkzeug ich benutze
Im ersten Teil hatte ich einen GeeekPi-Dongle über einen Amazon-Affiliate-Link verlinkt, als Empfehlung für genau dieses Vorhaben. Ehrlich gesagt bin ich am Ende nicht mit dem losgezogen. Zwischen dem Schreiben des ersten Beitrags und diesem Versuch lag noch eine Bestellung woanders, und am Ende kam das Board, das gerade greifbar war, nicht das verlinkte. In der Hand hatte ich stattdessen ein makerdiary nRF52840-MDK USB Dongle, anderer Hersteller, anderes Layout, aber derselbe Chip: ein Nordic nRF52840, auf dem Board direkt aufgedruckt mit N52840 QIAADO 2330FM. Kein Beinbruch, eher ein guter Aufhänger für den Bezugsquellen-Block weiter unten, den ich mir sonst hätte sparen können.
Die Verpackung des makerdiary nRF52840-MDK USB Dongle, mit aufgedrucktem Board und den Pin-Bezeichnungen.
Werkzeug ist LOGITacker, ursprünglich von mame82, also Marcus Mengs selbst, gebaut und heute unter RoganDawes auf GitHub aktiv gepflegt. Anders als etwa jackit läuft hier keine Angriffslogik auf dem Laptop, LOGITacker ist ein Standalone-Gerät. Die komplette Software steckt auf dem Dongle, bedient wird sie über eine serielle Konsole per USB, der Laptop selbst sieht am Ende nur ein weiteres USB-Gerät mit ein paar zusätzlichen Schnittstellen. Vier Boards werden offiziell unterstützt: der Nordic pca10059, zwei makerdiary-Boards, darunter genau das hier verwendete MDK Dongle, und ein Board von April Brother. Kein Zufallstreffer also. Das Board war von Anfang an ein sinnvoller Kauf für dieses Vorhaben, auch wenn es nicht das verlinkte war, und ich musste vor dem Kauf nicht einmal lange suchen, die Liste der unterstützten Boards steht direkt im Repository.
Geflasht habe ich logitacker_mdk_dongle.hex aus Release v0.2.3-beta, Stand 17. Januar 2020 und bis heute die aktuellste verfügbare Version. Kein Neubau aus dem Quellcode nötig, an der zugrundeliegenden Lücke hat sich seit 2020 nichts geändert. Pfostenstifte liegen dem Board bei, werden für dieses Experiment aber nicht gebraucht. Flashen und Betrieb laufen komplett über USB, kein Lötkolben in Sicht.
Das Board selbst, mit lesbarem Chip-Aufdruck N52840 2330FM. Die Pfostenstifte liegen bei, werden für dieses Experiment aber nicht gebraucht.
Flashen, und wie ich den Bootloader falsch eingeschätzt habe
Ich bin mit der Annahme reingegangen dass so ein Nordic-Board ein serielles DFU spricht, das man mit nrfutil bedient. Falsch gedacht. Hält man beim Einstecken den Knopf auf dem Board, meldet es sich stattdessen als schnödes USB-Massenspeichergerät:
Ein UF2-Bootloader, keine Nordic-eigene serielle Schnittstelle. LOGITackers Release liefert für dieses Board aber nur eine .hex-Datei, keine fertige .uf2. Also musste ich die Datei erst mit Microsofts eigenem uf2conv.py umwandeln, und zwar mit der richtigen Familien-ID, die ich mir nicht ausgedacht, sondern gegen die mitgelieferte uf2families.json geprüft habe:
Der Bootloader hat die Datei angenommen und das Laufwerk danach getrennt, das ist normales Verhalten beim Flashen. Was nicht normal lief: das Board hat sich anschließend nicht von selbst mit der neuen Firmware gemeldet. Erst ein einmaliges Aus- und wieder Einstecken hat es zurückgebracht, und dann korrekt:
$ lsusb
Bus 001 Device 021: ID 1915:520c Nordic Semiconductor ASA Logitacker by MaMe82
Vier neue Schnittstellen kamen dazu: seriell, Maus, Tastatur und HID-Rohdaten. Ein nettes Detail am Rand, die USB-Seriennummer trägt die Firmware-Version gleich mit, v0.2.3-beta.
Im UF2-Bootloader-Modus leuchten die LEDs des Dongles durchgehend grün.
Erstkontakt, und die Adresse stand quasi auf dem Karton
Serielle Konsole auf, 115200 Baud, fertig. Der Standardmodus von Logitacker heißt discover, eine Art passiver Dauerscan, und der bringt schon etwas, bevor ich überhaupt ein Kommando eingetippt habe:
<info> LOGITACKER_PROCESSOR_DISCOVER: DISCOVERY: received valid ESB frame (addr C3:1F:D0:D1:07, len: 15, ch idx 0, raw ch 5, rssi 47)
<info> LOGITACKER_PROCESSOR_DISCOVER: discovered device is Logitech
C3:1F:D0:D1:07. Das ist keine zufällige Adresse. Die USB-Seriennummer meines Tastatur-Empfängers, die sowohl solaar show meldet als auch auf dem Gehäuse aufgedruckt steht, lautet C31FD0D1. Exakt dieselbe Bytefolge, als Präfix der Funkadresse. Ohne jeden Angriff, nur weil das Gerät eingeschaltet ist, lässt sich die Funkadresse eines Unifying-Empfängers aus der Seriennummer ablesen, die außen auf dem Gehäuse steht.
Ich habe kurz gebraucht, um das wirklich zu glauben, und den Empfänger deshalb aus dem Rechner gezogen und die Seriennummer noch einmal mit der Lupe der Handykamera abfotografiert, im Vergleich zur Konsolenausgabe daneben. Kein Tippfehler, keine Verwechslung, dieselben acht Zeichen. Für einen Angriff braucht es das ohnehin nicht, discover läuft passiv und komplett ohne dass ich irgendetwas an Tastatur oder Empfänger anfassen müsste.
Drei Versuche, die nichts brachten, und der eine, der klappte
Zwei Versuche über die Easy-Switch-Taste brachten nichts, der dritte Versuch nach der dokumentierten Methode klappte sofort.
Um einen echten Kopplungsvorgang mitzuschneiden, muss erst einer stattfinden. Also den Mitschnitt-Modus starten und danach die schon gekoppelte MX Keys trennen, damit sie sich während laufendem Mitschnitt neu koppeln kann:
LOGITacker (discover) $ pair sniff run
<info> LOGITACKER_RADIO: Channel hopping stopped
<info> LOGITACKER_PROCESSOR_PAIR_SNIFF: Sniff pairing on address BB:0A:DC:A5:75
<info> ESB_ILLEGALMOD: Using channel table 'Unifying pairing'
<info> ESB_ILLEGALMOD: New channel table with length 11
$ solaar unpair 1DA452CF
Unpaired 1: MX Keys Keyboard (MX Keys) [408A:1DA452CF]
$ solaar pair C31FD0D1
Pairing: turn your new device on (timing out in 30 seconds).
Erster Versuch: Easy-Switch-Taste „1“ gehalten, laut solaar show genau der Kanal, der für diesen Rechner reserviert ist. Die LED blinkte brav weiter. Beim Dongle kam in den vollen 30 Sekunden, die solaar pair öffnet, nichts an:
<info> LOGITACKER_PROCESSOR_PAIR_SNIFF: dongle on channel 44
... (many more channel hops, receiver beacon tracked continuously) ...
<info> LOGITACKER_PROCESSOR_PAIR_SNIFF: Lost dongle in pairing mode, restart channel hopping
Zweiter Versuch, gleiche Methode, gleiches Ergebnis. solaar pair lief diesmal direkt in einen Timeout:
An der Stelle dachte ich kurz, das Board oder die Firmware hätten ein Problem, und habe testweise sogar den Kanal manuell auf den Standardwert zurückgesetzt und noch einmal von vorne begonnen. Half nichts. Meine Deutung dazu, ausdrücklich eine Deutung und kein gemessener Fakt: das Dauerblinken der Easy-Switch-LED zeigt vermutlich nur an, dass dieser Kanal aktuell keinen Empfänger kennt, keine aktive Funksuche. Analysiert habe ich das interne Verhalten der Tastatur nicht, dafür fehlt mir der Einblick, und ich will hier nichts behaupten, was ich nicht geprüft habe.
Dritter Versuch, diesmal nach der Methode, die die Logitacker-Dokumentation für Unifying-Geräte tatsächlich vorschreibt und die mit der Easy-Switch-Taste nichts zu tun hat: Tastatur ausschalten, Kopplungsfenster am Empfänger öffnen, Tastatur wieder einschalten. Erster Versuch nach dieser Methode, sofort erfolgreich:
<info> LOGITACKER_PROCESSOR_PAIR_SNIFF: PAIR SNIFF data received on channel 5
<info> LOGITACKER_PROCESSOR_PAIR_SNIFF: PAIR SNIFF assigned C3:1F:D0:D1:08 as new sniffing address
<info> LOGITACKER_PAIRING_PARSER: Device name: MX Keys
<info> LOGITACKER_PAIRING_PARSER: Device RF address: C3:1F:D0:D1:08
<info> LOGITACKER_PAIRING_PARSER: Device serial: 1D:A4:52:CF
<info> LOGITACKER_PAIRING_PARSER: Device WPID: 0x408A
<info> LOGITACKER_PROCESSOR_PAIR_SNIFF: device automatically stored to flash
<info> LOGITACKER_PROCESSOR_PAIR_SNIFF: Sniffed full pairing, moving on with passive enumeration for C3:1F:D0:D1:08
solaar show bestätigt unabhängig dieselbe Seriennummer 1DA452CF und denselben WPID 408A für dieselbe Tastatur, wobei die neu ersniffte Funkadresse C3:1F:D0:D1:08 denselben Präfix trägt wie die passive Sichtung von vorhin, nur eine Adresse höher.
Was ich da wirklich in der Hand hatte, und was ich bewusst nicht zeige
Ein erfolgreich mitgeschnittener Kopplungsvorgang liefert bei Logitacker fünf Dinge: Gerätename, Funkadresse, Seriennummer, WPID, und einen 16 Byte langen AES-Schlüssel. Die ersten vier stehen oben, alle unabhängig gegen Solaar geprüft. Der Schlüssel steht hier nicht. Kein einziges Byte davon, auch keine erfundenen Beispielwerte, die nur wie ein Schlüssel aussehen würden.
Der Unterschied zur EK-Zertifikat-Entscheidung im TPM-Beitrag lässt sich in einem Satz sagen: dort ging es um eine dauerhafte Geräte-Kennung, eindeutig, aber für sich genommen nicht ausnutzbar. Hier ging es um ein Credential, das im Moment der Aufnahme aktiv gültig war und echten Zugriff auf meine echte, gerade auf meinem Schreibtisch liegende Tastatur bedeutet hätte. Direkt im Anschluss an den Mitschnitt aus dem nächsten Abschnitt habe ich die Kopplung deshalb noch einmal neu gemacht, um den mitgeschnittenen Schlüssel ungültig zu machen:
$ solaar unpair 1DA452CF
Unpaired 1: MX Keys Keyboard (MX Keys) [408A:1DA452CF]
$ solaar pair C31FD0D1
Pairing: turn your new device on (timing out in 30 seconds).
Paired device 1: MX Keys Keyboard (MX Keys) [408A:1DA452CF]
Wieder die Aus-und-Einschalt-Methode, wieder auf Anhieb erfolgreich. Der Schlüssel aus dem Mitschnitt ist damit nicht mehr der Schlüssel, der heute im Einsatz ist. Falls du dich fragst, ob das den Beweis im nächsten Abschnitt irgendwie entwertet: nein, der wurde vorher aufgezeichnet, die Rotation kam erst danach.
Der Beweis: Tastenanschläge in Echtzeit entschlüsselt
Der Ablauf vom mitgeschnittenen Handshake bis zum entschlüsselten Klartext. Der Schlüssel selbst taucht in diesem Beitrag nirgends auf.
Nach dem erfolgreichen Mitschnitt wechselt Logitacker automatisch in einen passiven Mithör-Modus. Ich habe angefangen, auf der frisch wieder gekoppelten MX Keys zu tippen, und die Konsole hat live mitgeschrieben. Vier Tastendrücke aus derselben Sitzung, jeder mit eigenem Rohframe und eigenem entschlüsseltem Ergebnis:
Nacheinander gelesen: P, T, ., ENTER. Kein vollständiges Wort, sondern das Ende eines Satzes, den ich in dem Moment tatsächlich getippt habe, plus Enter. Genau das steht hier auch so, nicht schöngeredet zu mehr, als es ist.
Die Rohframes in der Tabelle sind Chiffretext, unbedenklich zum Zeigen, reines Rauschen ohne den Schlüssel. Was daraus die Klartext-Reports macht, ist der Schlüssel aus dem vorigen Abschnitt, und der taucht hier nicht auf. Ich habe dabei ziemlich bewusst langsam getippt, fast schon ein bisschen albern vor dem eigenen Bildschirm, nur um in der Konsole klar zuordnen zu können, welche Zeile zu welchem Tastendruck gehört. Es hat trotzdem gedauert, bis ich wirklich geglaubt habe, was da steht.
Was das nicht war
Eine kurze, ehrliche Einordnung. Dieser Versuch endet beim Mitlesen. Ich habe keine Einschleusung versucht, obwohl derselbe bekannte Schlüssel das technisch auch für gefälschte, eingeschleuste Tastenanschläge ermöglicht hätte, also für aktiven Angriff statt reinem Zuhören. Das ist die andere Hälfte von CVE-2019-13052, und die habe ich bewusst nicht angefasst. Nicht aus technischer Unfähigkeit, Logitacker kann das nachweislich, sondern weil eine aktive Einschleusung gegen die eigene Tastatur eine andere Kategorie Experiment ist als reines Zuhören, und weil das für den Beleg der Lücke in diesem Beitrag nicht nötig war.
Was das für die Empfehlung aus Beitrag 1 bedeutet
Im ersten Teil stand am Ende eine Rangfolge: Kabel für wirklich Geheimes, Logi Bolt oder sauberes Bluetooth fürs Büro, vorhandenes Unifying behalten und pflegen, No-Name-Funktastaturen ersetzen. An dieser Rangfolge ändert dieser Beitrag nichts. Was sich ändert, ist der Status des Arguments dahinter. Die Kopplungs-Lücke ist jetzt kein Datenbankeintrag mehr, sondern ein Ablauf, den ich mit handelsüblicher Hardware für unter 30 Euro selbst gegen mein eigenes Gerät durchgeführt habe, an einem gewöhnlichen Nachmittag, ohne Speziallabor und ohne Vorwissen, das ich mir nicht selbst aus der Dokumentation hätte holen können. Das praktische Risiko bleibt so klein wie im ersten Teil beschrieben, gebunden an den kurzen, seltenen Moment der Kopplung. Aber „das ist doch nur graue Theorie“ trägt als Einwand jetzt nicht mehr, und genau das war für mich der eigentliche Grund, diesen zweiten Teil überhaupt zu schreiben.
Was offen bleibt
Warum die Easy-Switch-Taste keine Kopplungsanfrage auslöst, bleibt meine Deutung des Dauerblinkens, keine bestätigte Analyse des Tastatur-internen Verhaltens. Sicher war ich einfach nur zu dumm die Tasten in der richtigen Reihenfolge zu drücken. gefettfingert
Die aktive Einschleusungshälfte von CVE-2019-13052 habe ich mit dem bekannten Schlüssel nicht ausprobiert. Ob und wann daraus noch ein dritter Teil wird, ist offen. Das hängt nun also an euch. Wenn ich sehen wollte, wie ich einfach Text oder Kommandos einschleuse, sagt es mir 🙂
Ob sich derselbe Ablauf gegen andere Unifying-Tastaturen als meine MX Keys genauso zuverlässig reproduzieren lässt, habe ich nicht geprüft. Aber hey, wir sind uns nun wohl alle sicher, dass es klappen wird, oder?
Die genaue Ursache der beiden ersten Kopplungsversuche, ob Timing, Tastatur-Firmware-Logik oder etwas Drittes, habe ich nicht bis auf die Funkebene nachverfolgt. gefettfingert
Bezugsquellen
Der folgende Link ist ein Affiliate-Link (Werbung). Kaufst du darüber, bekomme ich eine kleine Provision, für dich ändert sich am Preis nichts.
nRF52840-Dongle (vergleichbares Modell, nicht exakt das hier gezeigte Board): https://amzn.to/3RDuzQ8
Der Dongle in diesem Beitrag war tatsächlich ein makerdiary nRF52840-MDK USB Dongle, über einen anderen Kanal bezogen. Der verlinkte Dongle trägt denselben Nordic-nRF52840-Chip, ist aber ein anderes Board von einem anderen Hersteller. Ob Logitacker dieses konkrete Modell offiziell unterstützt, habe ich nicht geprüft. Offiziell gelistet sind der Nordic pca10059, zwei makerdiary-Boards und ein Dongle von April Brother.
Siehe auch
Die Maus funkt im Klartext, der erste Teil mit der Übersicht zu Funkmaus- und Funktastatur-Sicherheit unter Linux.
TPM 2.0 unter Linux, der andere Beitrag über Hardware, die kaum jemand anschaut.
Wenn ich irgendwo danebenliege, korrigiert mich gerne, dann lerne ich selbst etwas. Und die Frage an euch zum Schluss: Würdet ihr für ein bisschen mehr Sicherheit auf Logi Bolt oder Kabel umsteigen, oder ist euch das Restrisiko bei einer gepflegten Unifying-Tastatur egal? Wenn ihr mögt, dürft ihr mich dazu sehr gerne fragen.
Vor zwölf Jahren habe ich hier beschrieben, wie der Familienkalender meiner Frau in die ownCloud gewandert ist. Vorher gab es ein Büchlein in ihrer Tasche und einen großen Kalender an der Wand, und beide waren selten einer Meinung. Seitdem liegen Termine und Kontakte unter eigener Kontrolle, und alles Mögliche greift darauf zu. Nur ein Gerät hat es nie getan: das Telefon am Schreibtisch.
Das hat mich lange nicht gestört, bis ich es einmal ausprobiert habe. Ein Anruf kommt rein, auf dem Bildschirm steht eine nackte Rufnummer, und ich sitze vor einem Rechner, auf dem 144 Kontakte mit genau dieser Nummer liegen. Das ist albern.
Mein sipgate-Konto ist alt. Wie alt genau, wusste ich selbst nicht mehr. In diesem Blog taucht sipgate erstmals im August 2009 auf, und 2015 habe ich beim Abschalten meiner alten 01801-Nummer geschrieben, ich hätte sie „vor ? 13 ? Jahren“ bekommen. Die Fragezeichen waren schon damals meine. Also habe ich einfach den Support gefragt, ausdrücklich nur aus Neugier. Die Antwort kam am nächsten Morgen: angemeldet am 30. April 2005. Da sipgate 2004 mit den Basis-Accounts gestartet ist, bin ich also aus dem ersten Jahr dabei, gut zwanzig Jahre. Dass sich jemand die Mühe macht, so eine reine Neugier-Frage überhaupt zu beantworten, finde ich bemerkenswert.
Was ich wollte, war jedenfalls nichts Exotisches: ein Softphone unter Linux, das an diesem Konto hängt und beim Klingeln in mein eigenes Adressbuch schaut statt in gar keines. Dazu am besten noch die Kalender, damit ich beim Telefonieren sehe, ob der Termin, über den gerade gesprochen wird, überhaupt frei ist.
Der Weg dahin war überraschend kurz, aber die naheliegenden Kandidaten führen alle in die Irre. Deshalb schreibe ich beides auf.
Warum der naheliegende Weg nicht funktioniert
Der erste Reflex ist, das Softphone des Anbieters zu nehmen. Bei sipgate steht dazu im eigenen Hilfecenter, dass es unter Linux nicht installiert, sondern nur ausgeführt wird, dass es kein 64 Bit kann, also weder auf x86_64 noch auf ARM läuft, und dass der Support in Kürze eingestellt wird und keine Updates mehr kommen. Das ist eine erfrischend ehrliche Ansage, hilft aber nicht weiter.
Der zweite Reflex heißt Linphone, und das ist die Falle, in der ich am längsten gesteckt habe. Linphone kann CardDAV wirklich, die Funktionen stecken vollständig in der Bibliothek liblinphone. Nur hat die Oberfläche der paketierten Version keinen einzigen Schalter dafür, dort gibt es bei den Adressbuchquellen ausschließlich LDAP. In die Oberfläche kam CardDAV erst mit Version 6.0, und die liegt in keinem einzigen Linux-Distributionsrepo. Ein Blick auf Repology zeigt für linphone-desktop gerade einmal AUR bei 6.1.2, alles andere hängt bei 4.x oder 5.x, Debian unstable bei 5.2.6. Der Hersteller selbst liefert für Linux ausschließlich AppImages aus, ohne veröffentlichte Prüfsumme und ohne eingebettete Update-Information. Wer sich nicht um Aktualisierungen kümmern will, ist damit an der falschen Adresse.
Blink fällt aus, weil es zwar ein ausgereifter SIP-Client ist, beim Adressbuch aber nur Google Contacts kennt. GNOME Calls wäre technisch ein Weg, ist aber für Telefone gebaut und als Desktop-Softphone dünn.
Nebenbei: die Frage wird gestellt. Im Nextcloud-Forum steht ein Thread vom August 2025 mit genau diesem Wunsch, und der Fragesteller verweist darin auf einen älteren Thread zum selben Thema, der ohne Ergebnis blieb. Die Antworten waren eine kommerzielle Lösung und ein Umweg über die FRITZ!Box. Was ich jetzt benutze, kam in keinem der beiden vor.
Die Kette, die tatsächlich funktioniert
Der Trick besteht darin, dass das Softphone gar nicht mit der Nextcloud sprechen muss. Unter Linux gibt es dafür längst eine Zwischenschicht, und die heißt evolution-data-server. Sie ist auf so gut wie jedem Desktop installiert, weil Kalender- und Kontaktanwendungen darauf aufsetzen. Und sie spricht CalDAV und CardDAV von Haus aus.
Das Softphone ist damit austauschbar, und die Zugangsdaten der Cloud liegen genau an einer Stelle statt in jeder Anwendung noch einmal. Als Softphone nehme ich GOnnect von der GONICUS GmbH, einem Open-Source-UC-Client, den es als Flatpak auf Flathub gibt. Er kann als Adressbuchquellen LDAP, CardDAV, CSV und eben evolution-data-server.
Dass er über Flathub kommt, war für mich das Ausschlusskriterium gegen alles andere. Ein AppImage müsste ich von Hand nachziehen, ein Flatpak läuft mit flatpak update einfach mit.
Schritt 1: Die Nextcloud in die Online-Konten hängen
Unter Linux Mint findest du das unter „Online-Konten“, dahinter steckt gnome-online-accounts-gtk. Dort legst du ein Konto vom Typ Nextcloud an, trägst die Adresse deiner Instanz, deinen Benutzernamen und ein App-Passwort ein und hakst Kalender und Kontakte an.
Ein Konto vom Typ Nextcloud in den Online-Konten, Kalender und Kontakte angehakt. Ab hier kennt der ganze Rechner die Daten, nicht nur ein Programm.
Nimm dafür wirklich ein App-Passwort aus den Sicherheitseinstellungen deiner Nextcloud und nicht dein normales. Falls du später den Zugriff eines einzelnen Rechners zurückziehen willst, geht das damit mit einem Klick, ohne dass du überall sonst neue Zugangsdaten eintragen musst.
Wenn es geklappt hat, sieht die Konfiguration hinterher so aus:
Auf AcceptSslErrors=false lohnt ein Blick. Steht dort true, akzeptiert die Verbindung kaputte Zertifikate, und dann kannst du dir den ganzen Rest sparen.
Ab hier haben alle Programme auf dem Rechner Zugriff, die evolution-data-server nutzen. Das Softphone ist nur eines davon.
Schritt 2: GOnnect installieren
flatpak install flathub de.gonicus.gonnect
Das war der ganze Schritt. Rund 310 MB, und beim ersten Start liest GOnnect die Kontakte und Kalender aus evolution-data-server ein, ohne dass du irgendwo CardDAV konfigurieren müsstest. Bei mir standen im Protokoll direkt beim ersten Start:
gonnect.app.addressbook: Found 1 active configurations for address book plugin "EDS"
gonnect.app.feeder.EDSAddressBookFeeder: Loaded 144 contact(s) of source "Kontakte"
Ja, und die Kalender ebenfalls, inklusive der Familienkalender aus dem Beitrag von 2014. Die stehen dann rechts im Fenster, unter den Favoriten und neben der Anrufliste.
Links die Anrufliste, rechts die Favoriten und darunter die Termine aus dem Familienkalender. Namen, Nummern und Kontaktbilder sind unkenntlich gemacht.
Und die Suche oben im Fenster greift auf dasselbe Adressbuch zu. Ein paar Buchstaben genügen, dann steht der Treffer da, und darüber die Quelle, aus der er kommt: eds-contacts. Genau darum ging es. Kein Zwischenschritt, kein Export, keine zweite Kontaktverwaltung im Softphone.
Ein paar Buchstaben genügen. Über dem Treffer steht die Quelle: eds-contacts, also das Adressbuch aus der eigenen Nextcloud.
Schritt 3: Das sipgate-Konto eintragen
Hier kommt die Eigenheit von GOnnect, an der man sich einmal stoßen muss: es gibt keinen Einrichtungsassistenten und keinen Einstellungsdialog für das SIP-Konto. Der Client ist dafür gebaut, in Firmen ausgerollt zu werden, und erwartet deshalb eine fertige Konfigurationsdatei. Die liegt hier:
Unter der Haube arbeitet PJSIP, entsprechend sehen die Schlüssel aus. Das hier ist die vollständige Konfiguration, die bei mir mit einem sipgate-Basis-Konto läuft:
1234567e0 ist deine SIP-ID aus dem sipgate-Konto, nicht deine Rufnummer.
Wichtig ist die Zeile type=digest. Du kannst dort auch dein Passwort im Klartext hinterlegen, aber das musst du nicht. SIP authentifiziert sich per Digest, und der Hash dafür ist schlicht MD5(Benutzer:Realm:Passwort). Den rechnest du dir selbst aus:
Das Ergebnis kommt hinter data=. Danach setzt du die Datei noch auf chmod 600.
Damit steht dein Passwort nicht mehr wörtlich in einer Konfigurationsdatei. Ehrlich bleiben muss man trotzdem: der Hash ist für diesen Realm genauso viel wert wie das Passwort selbst, wer ihn hat, kann sich anmelden. Der Gewinn ist ein anderer. Falls du dieses Passwort irgendwo sonst auch verwendest, liegt es hier nicht lesbar herum.
Ein Detail, das mich beim Ändern der Datei erwischt hat: GOnnect muss dabei beendet sein. Der Client schreibt die Datei beim Beenden aus dem Speicher zurück und überschreibt deine Änderungen sonst kommentarlos.
Was der Desktop davon merkt
Zwei Dinge sind mir erst im Betrieb aufgefallen, und beide gehören zu der Sorte, die man nicht vermisst, solange man sie nicht kennt.
Wenn ein Anruf reinkommt oder du selbst einen startest, pausiert die laufende Medienwiedergabe von selbst. Das YouTube-Video im Firefox hält an, der Musikplayer ebenso, und nach dem Auflegen läuft beides weiter. Dahinter steckt MPRIS, die Schnittstelle, über die sich Medienplayer unter Linux fernsteuern lassen. Für mich war das der Moment, in dem sich das Ding nicht mehr nach Fremdkörper angefühlt hat, sondern nach Teil des Desktops.
Das zweite: sip:-Links auf Webseiten funktionieren. Ein Klick darauf öffnet die Anwendung und wählt sofort. Der Client trägt sich beim Installieren als Handler für dieses Schema ein, du musst dafür nichts konfigurieren.
Verschlüsselung, und warum eine Zeile davon die wichtigste ist
sipgate kann das seit über zwanzig Jahren. Heise hat am 1. Februar 2006 über „sipgate-Crypto“ berichtet, damals schon mit TLS für die Signalisierung und SRTP für die Sprache bis zum Festnetz-Gateway. Das Problem war seinerzeit, dass kaum ein Endgerät mitspielte, weshalb sipgate passende Hardware gleich mit anbot. Zwanzig Jahre später kann es jedes Gerät, und trotzdem steht es in kaum einer Anleitung.
Eingeschaltet ist es nämlich nicht von allein. Die Standardkonfiguration läuft über UDP und unverschlüsselt, du musst zwei Dinge selbst ändern: sip.sipgate.de als Proxy eintragen und die Signalisierung von UDP auf TLS umstellen.
Interessant ist, was danach passiert. In der sipgate-Dokumentation steht dieser Satz:
Bei verschlüsselter Signalisierung erfordern wir ebenfalls, dass die Sprachdaten verschlüsselt werden. Ist diese Einstellung falsch, so werden Anrufe mit Fehler „488 No Acceptable here“ abgewiesen.
Sobald die Signalisierung verschlüsselt ist, erzwingt sipgate also auch die Sprachverschlüsselung. Das ist die angenehmste Sorte Sicherheitsentscheidung, weil sie einem die Wahl abnimmt. srtpUse=mandatory ist damit nicht meine Strenge, sondern schlicht das, was die Gegenseite ohnehin verlangt. Ein optional würde dir nichts retten, der Anruf käme trotzdem nicht zustande, nur mit einer verwirrenderen Fehlermeldung.
Kleine Randbemerkung, weil es mich gefreut hat: gefunden habe ich diesen Satz nicht durch Klicken im Hilfecenter, sondern hier:
curl https://help.sipgate.de/llms-full.txt
Das ist das komplette Hilfecenter als eine Textdatei, rund 350 KB, gedacht als maschinenlesbare Fassung für Sprachmodelle. Zum Durchsuchen mit grep ist das erheblich angenehmer als jede Suchmaske, und es beantwortet Fragen, die im Menü drei Ebenen tief liegen. Ich habe so etwas seit einer Weile selbst auf diesem Blog liegen, und es ist schön zu sehen, dass es sich langsam herumspricht.
Die eigentlich wichtige Zeile ist eine andere, und die steht in keinem Beispiel, das ich gefunden habe:
Die Voreinstellung von PJSIP ist verifyServer=false. Übersetzt heißt das: die Verbindung wird verschlüsselt, aber es wird nicht geprüft, mit wem. Jedes beliebige Zertifikat wird angenommen. Gegen jemanden, der auf dem Weg sitzt und die Verbindung übernimmt, ist so eine Verschlüsselung wertlos, weil er einfach sein eigenes Zertifikat vorzeigt. Erst mit diesen zwei Zeilen wird geprüft, und zwar gegen den Zertifikatsspeicher deines Systems.
Nachmessen statt glauben
Dass die Registrierung mit code=200 klappt, sagt über die Verschlüsselung nichts. Also nachsehen. Der einfachste Test zeigt, wohin die Verbindung überhaupt geht:
Port 5061, und auf Port 5060 liegt nichts mehr, es läuft also kein Klartext-SIP nebenher. Meine eigene Adresse habe ich ersetzt, die Gegenstellen sind echt. Ein whois auf 2001:ab7::/36 nennt die netzquadrat GmbH, und sip.sipgate.de löst genau auf diese Adressen auf. Das Zertifikat dazu:
TLSv1.2:
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
...
TLSv1.3:
TLS_AKE_WITH_AES_256_GCM_SHA384 (ecdh_x25519) - A
TLS_AKE_WITH_CHACHA20_POLY1305_SHA256 (ecdh_x25519) - A
TLS_AKE_WITH_AES_128_GCM_SHA256 (ecdh_x25519) - A
cipher preference: server
least strength: A
Das Ergebnis ist erfreulich unaufgeregt. Es gibt nur TLS 1.2 und 1.3, die alten Versionen habe ich gegengeprüft und beide werden abgelehnt. Alles bewertet mit A, der Server bestimmt die Reihenfolge, und das Zertifikat ist RSA mit 4096 Bit. Ausgehandelt wird in der Praxis TLS 1.3 mit TLS_AES_256_GCM_SHA384 über X25519.
Ein Schönheitsfehler bleibt: unter TLS 1.2 stehen auch noch reine TLS_RSA_WITH_*-Suiten in der Liste, also solche ohne Forward Secrecy. Weil der Server die Reihenfolge vorgibt und ECDHE oben steht, bekommt sie in der Praxis niemand, sie sind der Rückfall für Uraltgeräte. Schöner wäre es trotzdem ohne.
Bleibt die Sprache. Während des Gesprächs zeigt GOnnect oben links ein grünes Schild, das ist die Verschlüsselungsanzeige.
Das grüne Schild oben links ist die Verschlüsselungsanzeige. Was dahinter wirklich passiert, steht erst im Protokoll.
Ein Symbol ist aber nur ein Symbol. Was dahinter passiert, protokolliert der Client erst, wenn du ihn darum bittest:
[logging]
level=6
Danach einmal telefonieren und ins Protokoll schauen. Was du sehen willst, sind zwei Dinge. Erstens die Aushandlung, in der beide Seiten RTP/SAVP sprechen statt RTP/AVP:
Und zweitens die Bestätigung, welche der angebotenen Suiten die Gegenstelle genommen hat:
srtp0x... SRTP started, keying=SDES, crypto=AES_256_CM_HMAC_SHA1_80
SRTP status: Active Crypto-suite: AES_256_CM_HMAC_SHA1_80
sipgate hat also die stärkste der vier angebotenen Varianten gewählt. Erst damit weiß ich, dass srtpUse=mandatory wirklich gegriffen hat und nicht still auf „aus“ stand. Nebenbei: mehr als diese vier hat der Client gar nicht im Angebot, alle mit AES im Counter-Modus und HMAC-SHA1. AES-GCM kennt diese PJSIP-Variante nicht, an der Stelle ist also nichts zu optimieren.
Und dann dreh den Loglevel wieder runter. In den Zeilen oben stehen die SRTP-Schlüssel im Klartext, die haben in einer Protokolldatei nichts verloren.
Was dabei nicht verschlüsselt ist
Hier muss ich die gute Laune etwas bremsen, denn „alles verschlüsselt“ wäre falsch.
Verschlüsselt ist die Strecke zwischen deinem Rechner und sipgate. Das ist viel wert, es schützt gegen dein WLAN, gegen fremde Netze und gegen deinen Provider, und zwar sowohl den Gesprächsinhalt als auch die Information, wen du wann anrufst.
Es endet aber bei sipgate. Rufst du ein Mobiltelefon an, läuft der Anruf ab dort durch das normale Telefonnetz, und dort gibt es keine Verschlüsselung. Dazu kommt, dass SDES als Schlüsselaustausch bedeutet, dass die Schlüssel im Signalisierungsweg stehen, den sipgate liest. Der ist zwar durch TLS gegen Dritte geschützt, aber sipgate kennt deine Schlüssel und könnte mithören. Etwas anderes steht auch gar nicht zur Wahl: ZRTP und DTLS-SRTP kommen in der gesamten sipgate-Dokumentation kein einziges Mal vor.
Echte Ende-zu-Ende-Verschlüsselung bekommst du nur zwischen zwei Clients, die direkt miteinander eines von beidem sprechen. Mit einem Anbieter dazwischen ist das, was hier läuft, die Obergrenze. Das ist kein Grund, es zu lassen, man sollte es nur nicht mit etwas verwechseln, das es nicht ist.
Kleinkram, der auffällt
Zwei Meldungen im Protokoll haben mich kurz beunruhigt und sind harmlos. Failed to connect to pipewire instance erscheint, weil das Flatpak den PulseAudio-Socket hat und auf pipewire-pulse zurückfällt. Die Geräte werden danach sauber gesetzt, der Ton funktioniert. Die Fehler des JitsiConnector betreffen die Videokonferenz-Anbindung und nicht das Telefonieren.
Was tatsächlich nicht geht: globale Tastenkürzel. Cinnamon bringt das Portal org.freedesktop.portal.GlobalShortcuts nicht mit, Anrufe per Tastendruck annehmen fällt damit aus. Alles andere, auch das Symbol im Systemabschnitt der Kontrollleiste, funktioniert.
Fazit
Der Teil, den ich für den schwierigen hielt, war der einfachste. Ich musste am Softphone überhaupt kein CardDAV einrichten, weil evolution-data-server das längst erledigt hatte. Ein Konto in den Online-Konten, und die Kontakte und Kalender stehen jedem Programm auf dem Rechner zur Verfügung.
Aufwendig war stattdessen, überhaupt einen Client zu finden, der unter Linux gepflegt wird und den man ohne AppImage-Gefummel aktuell hält. Dass ausgerechnet ein Client, der eigentlich für den Rollout in Firmen gedacht ist und deshalb keinen Einrichtungsdialog hat, für einen einzelnen Basis-Account die beste Wahl ist, hätte ich vorher nicht erwartet.
Und der Familienkalender, der 2014 in die ownCloud gewandert ist, steht jetzt neben dem Telefon. Nur zwölf Jahre später.
Ein Detail, das mich an dieser Maschine bis heute amüsiert: die Kiste, die hier steht, hat weniger Kerne als die, die sie ersetzt hat. Vorher waren es zwei Xeon E5-2687W v3, zusammen 20 Kerne und 40 Threads. Jetzt ist es ein einzelner Xeon Gold 5315Y mit 8 Kernen und 16 Threads. Auf dem Papier ein deutlicher Rückschritt, in der Praxis für fast alles was ich mache ein Fortschritt, weil jeder einzelne Kern erheblich mehr leistet und weil PCIe 4.0 und 256 GB Speicher am Ende mehr wert sind als zwölf zusätzliche langsame Kerne.
Womit wir bei der Seite wären, um die es heute geht. Das hier ist die dritte Folge meiner Reise durch das BIOS dieses Supermicro-Boards, alle Teile stehen gesammelt unter BIOS & Firmware. Dran ist Advanced > CPU Configuration, und zwar die obere Hälfte. Die untere mit AES-NI, SGX und den Sicherheitsfunktionen bekommt die nächste Folge, sonst wird es zu lang.
Der Teil zum Anschauen
Oben auf der Seite steht ein Block, an dem man nichts einstellen kann. Trotzdem lohnt sich der Blick, weil dort Dinge stehen, die man sonst zusammensuchen müsste:
Processor BSP Revision 606A6 - ICX M1
Processor ID 000606A6
Processor Frequency 3.200GHz
Processor Max Ratio 20H
Processor Min Ratio 08H
Microcode Revision 0D000421
L1 Cache RAM(Per Core) 80KB
L2 Cache RAM(Per Core) 1280KB
L3 Cache RAM(Per Package) 12288KB
606A6 ist die Prozessorsignatur, aufgedröselt: Familie 6, Modell 6A, Stepping 6. ICX M1 ist Intels interne Bezeichnung dafür, ICX steht für Ice Lake. Die beiden Ratios sind Multiplikatoren in hexadezimal, 08H sind 8 und 20H sind 32. Mit dem üblichen Referenztakt von 100 MHz ergibt das 800 MHz im Leerlauf und 3,2 GHz als Basistakt. Genau diese Spanne meldet auch Linux:
lscpu | grep MHz
# CPU max MHz: 3600,0000
# CPU min MHz: 800,0000
Die 3600 oben drüber sind der Turbo, der geht über den Basisratio hinaus. Dazu mehr, sobald ich das Power-Management-Menü nachgereicht bekomme, das fehlt mir in meiner Aufzeichnung noch.
Am interessantesten finde ich die Cache-Zeilen. 1280 KB L2 pro Kern klingt viel, und das ist es auch. Bei Ice Lake hat Intel den L2 gegenüber der Vorgängergeneration deutlich aufgebohrt und im Gegenzug den gemeinsamen L3 kleiner gemacht. 12 MB L3 für acht Kerne sind für einen Xeon nicht üppig. Der Gedanke dahinter ist, dass Daten näher am Kern liegen und seltener über den Ring wandern müssen. Ob das für die eigene Last aufgeht, merkt man erst beim Messen, aber die Zahlen im Setup erzählen die Designentscheidung ziemlich direkt.
Das Microcode Revision 0D000421 ist übrigens der Wert, den auch Linux meldet:
Das BIOS bringt also bereits den Mikrocode mit, den auch das Betriebssystem laden würde. Wer sich fragt, ob ein BIOS-Update wegen Mikrocode nötig wäre: hier eindeutig nein.
Kerne abschalten, in hexadezimal
> CPU1 Core Disable Bitmap
Ein eigenes Untermenü mit genau einem Eintrag, und dieser Eintrag ist herrlich unhöflich. Das Handbuch beschreibt ihn so:
Select 0 to enable all cores or FFFFFFFFFFF to disable all cores. One core must be enabled.
Man gibt also eine Bitmaske in hexadezimal ein, in der jedes gesetzte Bit einen Kern abschaltet. Keine Auswahlliste, keine Zahl „wie viele Kerne hätten Sie gern“, eine Bitmaske. Und dann der wunderbare Nachsatz, dass mindestens ein Kern übrig bleiben muss, was man vermutlich nicht schreiben würde, wenn es nicht mal jemand ausprobiert hätte.
Wozu macht man so etwas? Der häufigste Grund ist Lizenzkosten. Es gibt genug Software, die pro Kern abgerechnet wird, und wenn eine Maschine dafür zu viele hat, schaltet man welche ab. Der zweite Grund ist Testen: Verhalten einer Anwendung auf weniger Kernen prüfen, ohne die Hardware zu tauschen. Bei mir steht das erwartungsgemäss auf 0, alle 16 logischen Prozessoren sind da:
Wichtig zu verstehen ist der Unterschied zum Abschalten unter Linux. Wenn ich dort einen Kern offline nehme, existiert er weiter, er bekommt nur keine Arbeit mehr. Die Bitmaske im BIOS blendet ihn aus, bevor das Betriebssystem überhaupt startet. Für eine Lizenzzählung, die sich ansieht was die Maschine meldet, ist das ein Unterschied.
Hyper-Threading
Hyper-Threading [ALL] [Enable]
Der bekannteste Schalter der Seite. Aus acht physischen Kernen werden sechzehn logische, weil jeder Kern zwei Befehlsströme gleichzeitig verwaltet und die Recheneinheiten teilt, die gerade nichts zu tun haben. Der Gewinn liegt je nach Last irgendwo zwischen nichts und dreissig Prozent.
Es gibt drei gute Gründe, das abzuschalten, und keiner davon trifft auf mich zu. Der erste sind Seitenkanalangriffe: mehrere der Spectre-Nachfolger nutzen aus, dass sich zwei Threads einen Kern teilen, und wer fremden Code auf seiner Maschine ausführen lässt, fährt ohne Hyper-Threading sicherer. Der zweite ist Latenz: bei harten Echtzeitanforderungen ist ein Kern, der sich mit niemandem abstimmen muss, berechenbarer. Der dritte sind wieder Lizenzen.
Für eine Workstation, auf der ich weiss was läuft, überwiegt der Durchsatz. Bleibt an.
Fünf Zeilen, die aussehen wie eine Liste von Marketingbegriffen und in Wirklichkeit fünf verschiedene Stücke Hardware beschreiben. Alle haben dieselbe Aufgabe: raten, welche Daten die CPU als nächstes braucht, und sie schon mal holen. Speicher ist quälend langsam gegenüber dem Prozessor, ein Zugriff der bis zum RAM durchschlägt kostet ein Vielfaches dessen, was aus dem Cache kommt. Jeder erfolgreiche Rateversuch spart diese Wartezeit.
Sie raten nur unterschiedlich:
Hardware Prefetcher ist der Streaming-Prefetcher für den L2. Er erkennt, dass ein Programm Speicher der Reihe nach durchläuft, und holt vorausschauend nach. Der klassische Fall ist eine Schleife über ein grosses Array.
Adjacent Cache Prefetch ist der simpelste von allen. Er holt zu jeder angeforderten 64-Byte-Cachezeile gleich die benachbarte mit, arbeitet also faktisch in 128-Byte-Blöcken. Die Wette lautet: wer diese Zeile braucht, braucht gleich auch die daneben.
DCU Streamer Prefetcher macht dasselbe wie der erste, aber eine Ebene näher am Kern, für den L1-Datencache. DCU steht für Data Cache Unit.
DCU IP Prefetcher ist der cleverste. IP steht hier für Instruction Pointer. Er merkt sich pro Befehl, welche Zugriffsmuster dieser Befehl in der Vergangenheit erzeugt hat, und extrapoliert daraus. Damit erwischt er auch Muster mit konstantem Abstand, etwa jedes achte Element einer Struktur, an denen ein reiner Streaming-Prefetcher scheitert.
LLC Prefetch zieht Daten in den gemeinsamen L3, den Last Level Cache.
Das Handbuch beschreibt den DCU IP Prefetcher übrigens als etwas, das „IP addresses“ vorlädt und damit „network connectivity“ verbessert. Das ist schlicht falsch, da hat jemand Instruction Pointer mit Internet Protocol verwechselt und den Satz nie wieder gelesen. Solche Sätze stehen in erstaunlich vielen Handbüchern, und sie sind eine gute Erinnerung daran, dass auch offizielle Dokumentation nur von Menschen geschrieben wird.
Die Gegenprobe: was davon kommt wirklich an
Das Schöne an diesen fünf Schaltern ist, dass man sie nicht glauben muss. Sie landen in einem Prozessorregister, und das kann man auslesen. MSR 0x1A4 heisst Prefetch Control, und die unteren vier Bits schalten die Prefetcher ab, wenn sie gesetzt sind:
modprobe msr
rdmsr -0 0x1a4
# 0000000000000000
Null. Kein Bit gesetzt, also kein Prefetcher abgeschaltet. Das deckt sich exakt mit dem, was das Setup anzeigt. Die Zuordnung ist Bit 0 für den Hardware Prefetcher, Bit 1 für Adjacent Cache Line, Bit 2 für den DCU Streamer und Bit 3 für den DCU IP Prefetcher. Man beachte die umgekehrte Logik: gesetztes Bit bedeutet aus.
Ich mag solche Gegenproben. Ein Screenshot zeigt, was das Setup behauptet. Das Register zeigt, was die CPU tatsächlich macht. Bei Firmware ist das nicht immer dasselbe.
Wann man daran drehen würde
Fast nie, ehrlich gesagt. Die Prefetcher sind für allgemeine Lasten deutlich im Plus, sonst hätte Intel sie nicht eingebaut. Es gibt aber Fälle, in denen sie schaden:
Bei Datenbanken und Graphen-Workloads mit stark zufälligem Zugriffsmuster liegt der Prefetcher regelmässig daneben, holt Daten die keiner braucht, und verdrängt dabei Daten die jemand gebraucht hätte. Bei Echtzeitanwendungen sind sie eine Jitter-Quelle, weil sie Speicherbandbreite zu unvorhersehbaren Zeitpunkten verbrauchen. Und bei manchen HPC-Codes, die ihre Zugriffe selbst sehr genau steuern, stört der Prefetcher mehr als er hilft.
Der entscheidende Punkt: das misst man, das rät man nicht. Und der grosse Vorteil des MSR ist, dass man dafür gar nicht ins BIOS muss. Man kann die Bits im laufenden System setzen, messen, und wieder zurücksetzen. Wer das ernsthaft ausprobiert, sollte allerdings wissen, dass wrmsr genau so gefährlich ist wie es klingt, und dass die Einstellung pro logischem Prozessor gilt.
Nächste Folge: die untere Hälfte derselben Seite. AES-NI, TME, SGX und ein Schalter namens Extended APIC, der aussieht wie eine vergessene Optimierung und keine ist.
Hat jemand von euch schon mal Prefetcher gezielt abgeschaltet und dabei etwas gemessen, das sich gelohnt hat? Das würde mich wirklich interessieren, ihr dürft mich jederzeit fragen.
Der erste Start der neuen Maschine war laut. Nicht akustisch, sondern optisch: eine Wand aus weissem Text auf schwarzem Grund, Speichertest, Controller die sich melden, Netzwerkkarten die ihre MAC-Adressen ausspucken, und das alles über mehrere Bildschirmseiten. Bei einem Desktop-Board wäre da ein Herstellerlogo gewesen und darunter vielleicht ein dezenter Fortschrittsbalken. Ich habe die Textwand gelassen wie sie ist, und der Grund dafür steht in den ersten beiden Zeilen des Menüs, um das es heute geht.
Das hier ist Teil 2 der Serie, in der ich das BIOS meines Supermicro-Boards Stück für Stück durchgehe. Die bisherigen Folgen findest du gesammelt in der Kategorie BIOS & Firmware. Heute: Boot Feature, die erste Seite unter Advanced, neun Einstellungen rund um das Einschalten.
Die Anzeige, oder: warum ich kein Logo will
Quiet Boot [Disabled]
Option ROM Messages [Force BIOS]
Bootup NumLock State [On]
Quiet Boot ist der Schalter für genau die Textwand von oben. Auf Enabled zeigt das Board beim Start ein Logo, auf Disabled die POST-Meldungen. Das Logo ist hübscher, aber es versteckt genau die Informationen, die man braucht wenn etwas nicht stimmt. Auf einer Maschine mit vier Netzwerkports, einem Beschleuniger und einer NVMe an einem Breakout-Kabel möchte ich beim Booten sehen, wer sich meldet und wer nicht. Das kostet mich drei Sekunden Wartezeit und hat mir schon zweimal eine Fehlersuche erspart.
Option ROM Messages ist der kleine Bruder davon. Steckkarten bringen eigene Firmware mit, das Option ROM, und die möchte beim Start etwas ausgeben. Force BIOS heisst: das BIOS bestimmt, wie diese Ausgaben aussehen und dass sie überhaupt erscheinen. Keep Current überlässt das der Karte. Auch hier gilt, ich möchte die Meldungen sehen.
Bootup NumLock State ist der harmloseste Schalter des ganzen Setups und trotzdem einer, über den sich Menschen erstaunlich zuverlässig streiten. Er legt fest, ob der Ziffernblock nach dem Einschalten an ist. Bei mir: an.
Wait For „F1“ If Error
Wait For "F1" If Error [Disabled]
Das ist der Klassiker unter den Server-Fallstricken. Steht der Schalter auf Enabled und beim Start tritt irgendein Fehler auf, dann bleibt die Maschine stehen und wartet darauf, dass jemand F1 drückt. Bei einem Rechner unter dem Schreibtisch ist das ärgerlich. Bei einem Server im Rechenzentrum ist es der Grund, warum man nachts hinfährt.
Der Fehler muss dabei nicht dramatisch sein. Eine leere CMOS-Batterie reicht, oder eine Konfigurationsänderung, die das BIOS für erwähnenswert hält. Auf Disabled protokolliert das Board den Fehler und bootet trotzdem weiter. Für alles ohne Tastatur davor ist das die einzig sinnvolle Einstellung. Wer den Rechner täglich vor sich hat, kann anderer Meinung sein, dann merkt man wenigstens sofort dass etwas war.
Der Interrupt aus dem Jahr 1981
INT19 Trap Response [Immediate]
Und hier wird es schön. Das Handbuch erklärt den Schalter so:
Interrupt 19 is the software interrupt that handles the boot disk function.
Interrupt 19h, genauer INT 19h, ist der Bootstrap Loader aus dem BIOS des originalen IBM PC von 1981. Der Ablauf war denkbar einfach: das BIOS beendet seinen Selbsttest und ruft INT 19h auf. Was dahinter liegt, lädt den ersten Sektor eines Laufwerks und übergibt die Kontrolle dorthin. Das war der komplette Bootvorgang.
Interessant wird es durch das, was Steckkarten daraus gemacht haben. Ein SCSI-Controller mit eigenem Option ROM konnte sich in INT 19h einhängen, den Aufruf abfangen und stattdessen von seiner eigenen Platte booten. Genau so wurden Karten bootfähig, ohne dass das Mainboard-BIOS je von ihnen gehört hatte. Immediate heisst, die Karte darf sich den Interrupt sofort greifen. Postponed heisst, sie muss warten bis das System-BIOS fertig ist.
Meine Maschine bootet im reinen UEFI-Modus, ohne CSM, und lädt einen EFI-Bootloader von der NVMe. INT 19h spielt dabei überhaupt keine Rolle mehr. Der Schalter ist trotzdem noch da, weil irgendwo auf der Welt noch eine Karte steckt, die ihn braucht. Ich mag solche Fundstücke. Man scrollt durch ein Setup von 2025 und stolpert über einen Mechanismus, der älter ist als die meisten Leute, die ihn konfigurieren.
Neustart bei Fehlschlag, und der Watchdog
Re-try Boot [Disabled]
Watch Dog Function [Disabled]
Re-try Boot startet die Maschine automatisch neu, wenn der erste Bootversuch fehlschlägt. Klingt hilfreich, ist es in einer Endlosschleife aber nicht. Wenn die Bootplatte weg ist, dann ist sie auch beim vierzigsten Versuch weg, und ich bekomme statt einer klaren Fehlermeldung eine Maschine die im Sekundentakt neu startet. Auf Disabled bleibt sie stehen und sagt mir was los ist. Wer eine Maschine an einem Ort betreibt, an den er schlecht hinkommt, wägt das anders ab.
Der Watchdog ist ein anderes Kaliber. Laut Handbuch löst er nach fünf Minuten aus und macht dann wahlweise einen Reset oder einen NMI, also einen nicht maskierbaren Interrupt. Der Sinn dahinter: eine Software auf dem laufenden System muss den Timer regelmässig zurücksetzen. Passiert das nicht mehr, weil das System hängt, greift der Watchdog ein.
Der Haken ist der zweite Halbsatz. Es braucht diese Software. Ohne einen Dienst, der den Timer füttert, hat man einen Timer der nach fünf Minuten unangekündigt die Reset-Leitung zieht, und das ist keine Verfügbarkeitsmassnahme sondern eine Zeitbombe. Unter Linux gäbe es dafür watchdogd, und wenn ich das eines Tages sauber einrichte, schalte ich den Schalter an. Vorher nicht.
Zwei Schalter, die ich gar nicht sehe
Im Handbuch stehen an dieser Stelle noch Front USB Port(s) und Rear USB Port(s), mit denen sich die USB-Anschlüsse einzeln abschalten lassen. Auf einem Rechner an einem öffentlich zugänglichen Ort ist das eine ernstzunehmende Massnahme. In meinem Setup tauchen die beiden Zeilen nicht auf, und das Handbuch sagt auch warum:
The next two features are available for configuration if the SFT-DCMS-SINGLE license is installed.
Wer Teil 1 gelesen hat, kennt die Lizenz schon. Sie ist der Grund, warum ich meine BIOS-Konfiguration nicht maschinell auslesen kann. Dass sie zusätzlich zwei Sicherheitseinstellungen im Setup versteckt, hatte ich nicht erwartet. Das ist kein Management-Feature für Flottenbetreiber mehr, das ist eine Funktion des Boards, das ich gekauft habe, hinter einer Bezahlschranke im eigenen Setup.
Nach dem Stromausfall bleibt sie aus
Restore on AC Power Loss [Stay Off]
Power Button Function [4 Seconds Override]
Drei Möglichkeiten gibt es: Stay Off, Power On und Last State. Der Werksdefault ist Last State, also der Zustand von vor dem Stromausfall. Bei mir steht es auf Stay Off, und das ist eine bewusste Entscheidung gegen den naheliegenden Reflex.
Der Reflex sagt: klar soll die Maschine wieder hochkommen, sonst steht sie nach einem Stromausfall im Urlaub zwei Wochen tot herum. Für einen Server stimmt das auch. Für meine Workstation nicht. Wenn hier der Strom weg war, dann ist etwas passiert, und ich möchte selbst entscheiden wann und ob die Kiste wieder angeht. Dazu kommt der Fall, den man leicht übersieht: ein flatternder Strom, der mehrfach hintereinander kommt und geht. Mit Power On fährt das Board dann jedes Mal wieder an, mitten in den nächsten Ausfall hinein. Ein Rechner der aus ist, kann nicht kaputtgehen.
Beim Power Button Function habe ich 4 Seconds Override gelassen. Kurz drücken meldet dem Betriebssystem einen Shutdown-Wunsch, den es sauber abarbeitet. Vier Sekunden halten schneidet den Strom hart ab. Die Alternative Instant Off macht das sofort, ohne Rückfrage, und dafür sehe ich keinen Grund. Ein versehentlicher Stups ans Gehäuse soll keine ungespeicherte Arbeit kosten.
Fazit
Neun Schalter, davon acht auf Default und einer bewusst geändert. Das ist ungefähr die Quote, die sich durch das ganze Setup zieht, und sie ist auch in Ordnung so. Interessant sind trotzdem alle neun, weil hinter jedem eine Entscheidung steckt, die jemand mal getroffen hat.
Falls du beim Watchdog oder bei INT 19h anderer Meinung bist oder ich etwas verkürzt dargestellt habe: immer her damit. Besonders bei INT 19h würde mich interessieren, ob jemand noch aktiv Hardware betreibt, bei der Postponed einen Unterschied macht. Ich habe keine gefunden.
Nächste Folge: die CPU. Kerne, Threads und die fünf Prefetcher, von denen die Hälfte Namen trägt, die nach Marketing klingen und es nicht sind.
Siehe auch
Teil 1 der Serie (warum es diese Serie gibt, und der Weg ins Setup)
Am kommenden Wochenende ist wieder FrOSCon. Samstag der 15. und Sonntag der 16. August, wie immer an der Hochschule Bonn-Rhein-Sieg in Sankt Augustin, Grantham-Allee 20. Der Eintritt ist frei, es laufen sieben Vortragsschienen und zwei Workshop-Räume parallel, samstagabend gibt es das Social Event. Das Programm steht online.
Es ist die 21. Ausgabe. Die erste war 2006, die Konferenz wird also gerade zwanzig. Ich bin an beiden Tagen dort und würde mich sehr freuen, wenn wir uns treffen und ein bisschen quatschen. Also: ist noch jemand von euch da? Sag mir gerne vorher Bescheid, dann verabreden wir uns, oder sprich mich einfach an, wenn du mich irgendwo im Foyer siehst.
Und falls du noch nie dort warst: fahr hin. Der Eintritt kostet nichts, das Programm ist gut, und diese Mischung aus Vorträgen, Ständen und Leuten, die dir ungefragt ihr Projekt erklären wollen, gibt es in der Form nicht oft.
Warum es nicht jedes Jahr klappt
Ich versuche eigentlich jedes Jahr, auf die FrOSCon zu kommen. Das scheitert regelmäßig daran, dass meine Kinder rund um dieses Wochenende Geburtstag haben, und das geht dann selbstverständlich vor. Dieses Jahr passt es, deshalb schreibe ich das hier überhaupt.
Beim Zusammensuchen der alten Beiträge habe ich dann etwas gefunden, das mich kurz sehr still gemacht hat. In meinen Entwürfen liegt ein Beitrag vom 9. August 2013, der nie veröffentlicht wurde. Darin steht:
Ich habe gerade die Bestätigung meines FrOSCon Tickets bekommen 🙂 Die FrOSCon ist dieses Jahr vom 24.08-25.08.2013 in Sankt Augustin. Ich schaffe es nicht immer zur FrOSCon denn meine Kinder haben immer um diesen Dreh Geburtstag. Das geht dann vor! In diesem Jahr klappt es genau und dieses freut mich natürlich umso mehr! Wir sehen uns also auf der FrOSCon….
Ich, in einem Entwurf vom 9. August 2013, den ich nie veröffentlicht habe
Dreizehn Jahre später sitze ich hier und schreibe im Grunde denselben Absatz noch einmal. Gleiche Konferenz, gleicher Ort, gleiche Terminkollision, gleiche Freude, dass es diesmal passt. Nur die Kinder sind inzwischen deutlich größer. Den Beitrag von 2013 lasse ich übrigens in der Schublade, der hat sich seinen Platz dort verdient.
Und die Kinder?
Möglicherweise dreht sich die Sache dieses Jahr sogar. Teckids e.V. macht an beiden Tagen die Mini-FrogLabs, das Jugendprogramm der Konferenz. Samstag geht es um Luanti, also eigene Mods und Kreaturen in 3D, Sonntag um Spieleprogrammierung mit Python. Gedacht ist das etwa ab der vierten Klasse bis sechzehn, Vorkenntnisse braucht niemand, bezahlt wird so viel man mag, und man meldet sich für jeden Tag einzeln an. Das schaue ich mir für meine Kinder auf jeden Fall an. Nach all den Jahren, in denen die Kinder der Grund waren, nicht hinzufahren, wäre das eine schöne Wendung.
Wie das bei mir angefangen hat
Wann ich zum ersten Mal dort war, kriege ich nicht mehr sicher zusammen. Mein Gefühl sagt 2006, belegen kann ich 2007. Es gibt Bilder aus dem Jahr in meiner Galerie, in einem Beitrag von 2013 hängt ein Schlüsselband von der FrOSCon 2007 an meinem Schlüsselbund, und der Ausweis hängt bis heute bei mir im Arbeitszimmer an der Wand.
Der Ausweis von 2007 hängt noch im Arbeitszimmer, rechts senkrecht steht Aussteller. Darunter das hellblaue Schild von 2013, das belegt, dass ich in dem Jahr tatsächlich dort war, auch wenn der Beitrag dazu nie erschienen ist. Rechts daneben der Besucherausweis der OpenRheinRuhr 2010.
Damals habe ich am Stand von CAcert mitgeholfen, einer von der Gemeinschaft betriebenen Zertifizierungsstelle, die kostenlos Zertifikate ausgestellt hat, lange bevor das normal war. Das Vertrauen kam dort nicht von einem Audit, sondern von Menschen: Punkte gab es, wenn man einem Assurer seinen Ausweis zeigte. Genau das haben wir den ganzen Tag gemacht, und ich fand das damals ganz große Klasse.
Geworden ist daraus nichts. Der Antrag auf Aufnahme in den Truststore von Mozilla wurde noch im selben Jahr zurückgezogen, und bis heute vertraut kein Browser dieser Wurzel. Ein curl auf die Seite bricht immer noch mit self-signed certificate in certificate chain ab, gerade nachgesehen. Gelöst hat das Problem später Let’s Encrypt, mit einem Protokoll statt mit Menschen und Ausweisen. Technisch die bessere Antwort, ein bisschen wehmütig macht es mich trotzdem.
Hängengeblieben ist trotzdem etwas. Mein Interesse an Zertifikaten, Schlüsseln und dem ganzen Vertrauenskram hat genau dort angefangen, und das hat mich seitdem nicht mehr losgelassen.
Die Keysigning-Party
Zum selben Themenkreis gehört das andere, wozu ich früher immer gegangen bin, wenn es sich einrichten ließ: die GPG-Keysigning-Party. Das Prinzip war schön unaufgeregt. Vorher schickt jeder seinen Schlüssel-Fingerprint ein, vor Ort steht man in einer Reihe, vergleicht die Zeile auf dem ausgedruckten Zettel mit dem, was die andere Person vorliest, sieht sich einen Ausweis an, hakt ab. Zu Hause signiert man dann die Schlüssel, deren Zeile gestimmt hat. Eine Stunde Anstehen, ein Blatt Papier, und danach hängt das eigene Schlüsselbund ein Stück fester im Netz.
Im offiziellen Zeitplan für dieses Jahr finde ich keine Keysigning-Party. Das muss nichts heißen, solche Runden organisieren sich oft nebenbei und stehen dann in keinem Programmheft. Falls sich jemand findet, bin ich sofort dabei. Und ganz unabhängig davon, weil es der einfachere Weg ist: wenn wir uns auf der FrOSCon über den Weg laufen, würde ich mich sehr über ein Cross-Signing meines neuen Schlüssels freuen. Der ist frisch, trägt die Kennung 0x893DE0CDDE986DEB, den Fingerprint bringe ich ausgedruckt mit und den Personalausweis sowieso. Wie ich ihn gebaut und woran ich ihn beim Härten kaputt gemacht habe, steht hier im Blog. Die Rolle, die früher der Ausweis am Klapptisch hatte, übernehmen bei mir mittlerweile nachprüfbare Identity-Claims. Funktioniert gut, ersetzt aber das Anstehen nicht.
Ein Gruß an Jens Link, und eine offene Frage
Aus den frühen Jahren ist mir ein Vortrag bis heute im Kopf geblieben, und zwar einer über IPv6 von Jens Link. Der Mann hat es geschafft, mich mit Adressarchitektur und Autokonfiguration zum Lachen zu bringen und mir im selben Vortrag klarzumachen, dass da erheblich mehr dahintersteckt als eine Pflichtaufgabe, die man irgendwann mal erledigen muss. Das können nicht viele. Ich bin danach an dem Thema hängengeblieben und habe es nie wieder losgelassen.
Fair muss ich dazusagen, dass ich nicht durch ihn angefangen habe. Mein ältester Beitrag zu IPv6 hier im Blog ist vom März 2003, vier Jahre vor diesem Wochenende, es ging um Adressarchitektur und radvd unter Linux. Dass daraus vierunddreißig Beiträge geworden sind, verteilt über die Jahre bis 2021, dafür trägt dieser Vortrag aber einen guten Teil der Schuld. Wenn man einmal gesehen hat, wie jemand über so ein Thema begeistert und komisch reden kann, schaut man danach anders hin. Einen Gruß nach Berlin also, und ein Dankeschön obendrauf.
Genau erinnern kann ich mich nach knapp zwanzig Jahren natürlich nicht mehr, weder an das Jahr noch an die Folien. Der Eindruck ist geblieben, das reicht mir.
Und eine Frage, bei der ihr mir helfen könnt. In meiner Erinnerung wollte er damals ein Buch über IPv6 schreiben. Ich habe es nie gesehen, was aber genauso gut daran liegen kann, dass es an mir vorbeigegangen ist. Auf seiner Seite finde ich keins, und sein Vortragsarchiv reicht nicht so weit zurück, dass ich damit etwas belegen könnte. Weiß es jemand? Ist das Buch erschienen, ist es liegen geblieben, oder habe ich mir das über die Jahre selbst zusammengebaut? Im Fediverse ist er als @quux unterwegs.
Worauf ich schauen will
Festlegen will ich mich nicht, das wird bei mir sowieso spontan. Auf dem Zettel stehen aber diese acht:
Wenn ich die Liste so ansehe, ist das Muster ziemlich eindeutig. Sechs von acht liegen in der Security-Schiene, die anderen zwei kommen aus dem Themenblock zum Recht auf Reparatur, und mehrfach geht es um Haftung und Regulierung statt um Technik. Das ist neu für mich. Drei davon laufen am Samstag im selben Raum, zwei sogar direkt hintereinander, das kommt mir sehr entgegen. Ob ich es aus dem CrypTool-Workshop rechtzeitig rausschaffe, steht auf einem anderen Blatt, der Zeitplan verrät keine Endzeiten.
Die Stände, an denen ich hängen bleiben werde
Auf meiner Runde stehen das CrypTool Projekt, ElectroBSD, Freie Software und Bildung, illumos, Matrix, The PHP Foundation, XMPP und der Datenburg e.V. Bei illumos werde ich vermutlich am längsten stehen, aus reiner Nostalgie, mein Solaris-Archiv hier im Blog hat immerhin achtunddreißig Beiträge. Bei The PHP Foundation habe ich sogar eine konkrete Frage im Gepäck, nachdem ich mich neulich durch einen PHP-Absturz bis in den Laufzeitlinker von FreeBSD gegraben habe.
Auf der Ausstellerliste steht übrigens ein Name, bei dem ich kurz grinsen musste: CAcert ist dieses Jahr wieder mit einem Stand da, neunzehn Jahre später, im selben Gebäude. Die Wurzel liegt weiterhin in keinem Truststore, die Leute stehen trotzdem wieder hinter dem Tisch. Da gehe ich vorbei und sage einmal Danke.
Zwanzig Jahre
Was mich beim Schreiben am meisten getroffen hat, ist nicht die CAcert-Geschichte, sondern die Rechnung dahinter. Von meinem belegten ersten Besuch bis heute sind es neunzehn Jahre. Rechne ich mein Gefühl mit, dass es 2006 war, sind es zwanzig. Die Konferenz gibt es genauso lange. Zwischen dem Klapptisch mit den Assurance-Formularen und dem Beitrag, den ich neulich über einen TPM-Chip geschrieben habe, liegt also ziemlich genau mein halbes Leben mit diesem Hobby. Ich habe mich beim Nachrechnen ehrlich alt gefühlt.
Andererseits: das Wochenende ist immer noch dasselbe Wochenende. Gleiche Hochschule, freier Eintritt, Leute, die einem an einem Stand irgendetwas erklären, wovon sie viel zu begeistert sind. Das ist eine ziemlich gute Konstante.
Siehe auch:
FrOSCon 2017, der letzte Beitrag dieser Sorte hier im Blog
Wenn du auch auf der FrOSCon bist, sag gerne Bescheid, ich freue mich über jeden Kaffee im Stehen und über jede Signatur. Und wenn du die Sache mit dem IPv6-Buch aufklären kannst, oder sonst etwas dazu wissen möchtest, dann darfst du mich sehr gerne fragen.
Vor Kurzem saß ich in einer Arztpraxis im Wartezimmer, und weil ich so bin wie ich bin, habe ich statt der Zeitschriften die Rechner am Empfang angeschaut. An jedem hing eine Funkmaus und eine Funktastatur, dazu der kleine Adapter im USB-Port. Von einem Hersteller, den ich nicht kannte, der Eindruck war sehr günstiges No-Name-Gerät. So etwas nenne ich selbst gern etwas abfällig „Chinaprodukt“, was eigentlich unfair ist, denn die können das inzwischen richtig gut.
Im Gespräch mit dem Arzt kam heraus, dass ihm ein Punkt völlig neu war: dass die Tastatureingaben als Funk durch die Luft gehen und dass man Funk mithören kann. An seinem Platz werden Diagnosen, Namen und Medikamente getippt, und die Frage, ob das jemand aus dem Nachbarzimmer mitlesen könnte, hatte sich vorher schlicht nie gestellt. Aus genau dieser Unterhaltung ist dieser Beitrag entstanden, und er wollte ihn selbst lesen. Also, hallo an dieser Stelle, danke für den Anstoß.
Ich will die Praxis dabei nicht an den Pranger stellen. Über die Sicherheit genau dieses No-Name-Geräts kann ich nichts sagen, ich habe es nie in der Hand gehabt. Der Punkt ist ein anderer: fast jeder benutzt so einen Adapter, und kaum jemand hat sich die Frage je gestellt. Bei einer Mausbewegung ist das auch egal. Bei einem Passwort, einer PIN oder einem Login nicht. Also drei Fragen, die den Beitrag tragen. Kann man das wirklich abhören? Kann man sogar eigene Tasten einschleusen? Und wie sieht man, ob das eigene Gerät geschützt ist?
Ich mache das am Beispiel von Logitechs Unifying-Adapter, dem mit dem kleinen orangen Stern, weil ich davon zwei Stück im Rechner habe und weil Logitech einer der Hersteller ist, bei dem man den Unterschied zwischen „kein Krypto“ und „verschlüsselt“ schön sehen kann. Alles, was ich hier auf dem Rechner prüfe, zeige ich mit dem Befehl und der echten Ausgabe. Und wo etwas unklar bleibt, sage ich das auch.
Durch die Luft, und schon sind es zwei Probleme
Bevor es um Logitech geht, muss eine Sache sauber getrennt sein, denn der ganze Beitrag hängt daran. Wer an einem Funkgerät lauscht, will eines von zwei Dingen, und die sind unterschiedlich gefährlich.
Mitlesen, passiv. Der Angreifer hört den Funk nur mit. Das ist gefährlich bei allem, was die Tastatur sendet, also Passwörter, PINs, Nachrichten. Bei der Maus dagegen gehen nur Bewegungen und Klicks über die Luft, da ist Mitlesen fast folgenlos.
Einschleusen, aktiv. Der Angreifer sendet selbst und gibt sich als euer Gerät aus. Damit tippt er auf eurem Rechner, öffnet ein Terminal, lädt etwas nach. Das ist der unangenehmere Fall, weil er nicht davon abhängt, dass ihr gerade etwas tippt. Der Rechner steht am Empfang, niemand sitzt davor, und trotzdem passiert etwas.
Daraus ergeben sich drei Schutzstufen, und die Reihenfolge ist wichtig.
Kein Schutz. Klartext. Jeder in Funkreichweite liest mit und kann einschleusen.
Verschlüsselung. Der Funk ist chiffriert. Wer mithört, bekommt nur Kauderwelsch. Logitech nimmt dafür bei Tastaturen AES-128.
Authentisierung. Der Empfänger prüft, ob ein Paket wirklich vom gekoppelten Gerät stammt. Erst das schließt das Einschleusen zuverlässig, denn Verschlüsselung allein sagt nur, dass keiner mitliest, nicht, dass keiner sich einschleicht.
Und hier kommt die Design-Entscheidung, die uns später um die Ohren fliegt. Eine Tastatur braucht zwingend Verschlüsselung, weil sie Geheimes sendet. Eine Maus bekam bei Unifying historisch keine, weil sie ja nichts Geheimes sendet. Das klingt vernünftig, und für sich genommen ist es das auch. Zum Einfallstor wurde es trotzdem, weil ein Empfänger, der offene Maus-Pakete akzeptiert, sich dazu bringen ließ, auch gefälschte Tastatur-Pakete zu schlucken. Genau das war MouseJack. Dazu gleich mehr.
Der Funkweg. Die Tastatur funkt AES-128-verschlüsselt, die Maus im Klartext. Ein Angreifer mit Antenne hört beide Strecken, von der Tastatur bekommt er aber nur Kauderwelsch.
KeySniffer, so sieht es aus, wenn gar nichts da ist
Damit klar wird, wovon wir reden, erst das schlechte Beispiel. 2016 zeigte die Firma Bastille unter dem Namen KeySniffer, dass Funktastaturen von acht Herstellern die Tastenanschläge komplett im Klartext funken, ohne jede Verschlüsselung. Betroffen waren Anker, EagleTec, General Electric, Hewlett-Packard, Insignia, Kensington, Radio Shack und Toshiba. Mitlesbar aus rund 75 Metern, mit Hardware für unter hundert Dollar. Man tippt sein Passwort, und einer im selben Gebäude schreibt es Zeichen für Zeichen mit.
Zwei Dinge daran sind wichtig. Erstens ist das kein „schwaches Krypto“, das ist „kein Krypto“. Diesen Unterschied wirft man gern in einen Topf, aber er ist der ganze Punkt. Zweitens kann man diese Tastaturen nicht per Update retten. Da hilft nur wegwerfen und ersetzen. Und genau das ist der Unterschied zu Logitech, wo ein Empfänger-Update wirklich etwas ändert, wie wir noch sehen werden. Bluetooth-Tastaturen und die höherwertigen Geräte von Logitech, Dell und Lenovo waren von KeySniffer übrigens nicht betroffen. Das ist die Brücke zu Logitech.
Ein Stern, sechs Geräte: wie Unifying funktioniert
Unifying ist der kleine USB-Adapter mit dem orangen Stern, an den sich bis zu sechs Geräte koppeln lassen. Eine Maus, eine Tastatur, vielleicht ein Ziffernblock, alles über einen Stick. Technisch funkt das bei 2,4 GHz auf Nordics nRF24-Technik, nicht Bluetooth. Das ist ein wichtiger Punkt, den ich später beim Abhören noch brauche. Tastaturen werden mit AES-128 verschlüsselt, der Schlüssel wird beim Koppeln festgelegt. Mäuse funken offen.
MouseJack, 2016, und die offene Maus als Hebel
Ebenfalls 2016, wieder Bastille, diesmal Marc Newlin. Über die offene, nicht authentifizierte Maus-Strecke ließen sich gefälschte Tastatur-Pakete in viele Empfänger einschleusen, dazu erzwungenes Koppeln. Betroffen waren Geräte vieler Hersteller, nicht nur Logitech. Der Angreifer musste nicht warten, bis jemand tippt. Er gab sich als neue Tastatur aus und schrieb selbst.
Logitech reagierte mit mehreren Firmware-Ständen für die Empfänger. Nach Logitechs eigenen Release-Notes sind die Kern-MouseJack-Punkte, also erzwungenes Koppeln, Tastatur-Injektion und gefälschte Maus, ab RQR12.05 beziehungsweise RQR24.03 geschlossen. Eine später gefundene Schwäche, die verschlüsselte Injektion (Bastille-Punkt #13, als CVE-2016-10761 geführt), folgte erst ab RQR12.08 und RQR24.06. Diese zwei Generationsnummern solltet ihr euch merken, sie kommen beim Testgerät gleich wieder.
Die vier Lücken von 2019, und die eine, die blieb
2019 nahm sich Marcus Mengs, im Netz MaMe82, Unifying noch einmal vor. Vier CVEs, und der Unterschied zwischen ihnen ist der eigentliche Lehrwert.
CVE
Was
Fix
CVE-2019-13052
Aus dem Mitschnitt der Kopplung den AES-Schlüssel ableiten, danach mitlesen und einschleusen
kein Patch, Logitech lehnte ab
CVE-2019-13053
Einschleusen in die verschlüsselte Strecke, setzt einmaligen physischen Zugriff voraus
kein Patch für die erweiterte Form
CVE-2019-13054
Schlüssel aus R500- und Spotlight-Presentern auslesen, physischer Zugriff
Fix für August 2019 angekündigt
CVE-2019-13055
Alle gekoppelten Schlüssel aus einem Empfänger in unter einer Sekunde, physischer Zugriff
Fix für August 2019 angekündigt
Die spektakuläre Fernübernahme, MouseJack, ist an einem aktuellen Empfänger zu. Was bleibt, ist die erste Zeile: CVE-2019-13052. Wer den Moment der Kopplung mitschneidet, kann daraus den AES-Schlüssel ableiten und danach mitlesen und einschleusen. Diese Lücke wurde nie geschlossen. Logitech hat erklärt, dafür keinen Patch zu liefern, sie steckt im Design.
Das praktische Risiko ist gering, weil man dafür genau dann mithören muss wenn ihr ein Gerät neu koppelt, und weil der Schlüssel danach nicht neu ausgehandelt wird. Koppeln passiert selten und ist schnell vorbei. Aber der Satz „Firmware aktuell, also alles gut“ wäre trotzdem falsch, und genau diese Ehrlichkeit macht für mich den Reiz an der Sache aus. Diese Kopplungs-Lücke ist übrigens auch der Aufhänger für den zweiten Teil.
Die Angriffe über die Zeit. MouseJack wurde per Firmware geschlossen, aus der 2019er-Serie blieb CVE-2019-13052 offen, und Logi Bolt zieht 2021 die Konsequenz.
Logi Bolt, der Nachfolger, der es richtig macht
2021 brachte Logitech mit Logi Bolt einen neuen Empfänger heraus, der Sicherheit von Anfang an mitdenkt. Die Kernpunkte, alle belegt:
Bolt setzt auf Bluetooth Low Energy im Security Mode 1, Level 4, also Secure Connections Only. Das heißt verschlüsselt und authentifiziert. Genau der Schutz gegen Einschleusen, der Unifying von Haus aus fehlte.
Es ist ein geschlossenes System, ein Bolt-Empfänger spricht nur mit Bolt-Geräten.
Pro Kopplung eine andere Bluetooth-Adresse und eigene Schlüssel.
Koppeln geht nur nach einem ausdrücklichen, langen Knopfdruck von einigen Sekunden. Das schließt das erzwungene Koppeln.
Firmware ist zentral ausrollbar, mit Schutz gegen das Zurückrollen auf alte Stände.
Ein Missverständnis will ich gleich einfangen. Bolt ist Bluetooth-basiert, aber es ist ein geschlossenes, gehärtetes System, kein normales Bluetooth-Pairing, wie ihr es vom Kopfhörer kennt. Verwechselt das nicht, das eine ist gehärtet, das andere ist ein bunter Haufen.
Zwei Empfänger, eine Maus, eine Tastatur
Genug Geschichte, jetzt der eigene Rechner. Auf dem Testgerät, einem Notebook mit Linux Mint 22.3, stecken zwei Unifying-Empfänger gleichzeitig. Am einen hängt die Maus, eine Logitech Marathon Mouse M705, am anderen die Tastatur, eine MX Keys. Beide Sticks tragen denselben orangen Stern, und wie sich gleich zeigt, tragen sie trotzdem zwei verschiedene Sicherheitsgeschichten mit sich herum.
Die Maus M705 und ein Unifying-Empfänger mit dem orangen Stern.
Der orange Stern ist das Erkennungszeichen von Unifying.
Die Tastatur, eine Logitech MX Keys.
Erst einmal schauen, ganz ohne Spezialwerkzeug
Man muss nicht sofort ein Paket installieren, um zu verstehen, was da steckt. Das Betriebssystem verrät schon eine ganze Menge. Erst schaue ich, welche USB-Geräte hängen. Mit lsusb sehe ich beide Empfänger, und interessant ist, dass sich beide als exakt dieselbe Kennung melden.
$ lsusb | grep -i logitech
Bus 001 Device 011: ID 046d:c52b Logitech, Inc. Unifying Receiver
Bus 001 Device 012: ID 046d:c52b Logitech, Inc. Unifying Receiver
046d ist Logitech, c52b ist der Unifying-Empfänger. Zwei gleiche Kennungen, zwei physische Sticks. Als Nächstes die Kernelmodule, die diese Sticks bedienen.
Zwei Module machen die Arbeit, und die Aufgabenteilung lohnt sich zu verstehen. hid_logitech_dj kümmert sich um das Multiplexing des Unifying-Empfängers, also darum, dass ein einziger Stick mehrere Geräte tragen kann. hid_logitech_hidpp spricht das Feature-Protokoll HID++, über das gleich auch Solaar redet. Und über die Geräteknoten /dev/hidraw* reden die Werkzeuge am Ende mit den Sticks. So versteht man die Schichten, bevor überhaupt ein Zusatzprogramm im Spiel ist.
Solaar, das eine Werkzeug, das man wirklich braucht
Solaar ist die grafische Oberfläche und zugleich ein Kommandozeilen-Werkzeug für Unifying und HID++. Damit koppelt man Geräte, sieht den Akkustand, den Verschlüsselungsstatus und kann Tasten umbelegen. Auf dem Testgerät läuft Version 1.1.11. Der eine Befehl, der alles auf einmal ausgibt, ist solaar show. Für den Empfänger der Maus, gekürzt auf das Wesentliche:
Unifying Receiver
USB id : 046d:C52B
Serial : 3CE0986A
Firmware : 12.11.B0032
Has 1 paired device(s) out of a maximum of 6.
1: Marathon Mouse M705 (M-R0073)
Kind : mouse
Protocol : HID++ 4.5
Battery: 50%, discharging, next level 20%.
Solaar zeigt den Empfänger der Maus. USB-ID 046d:C52B, Firmware 12.11.B0032, ein gekoppeltes Gerät.
Und für den Empfänger der Tastatur:
Unifying Receiver
USB id : 046d:C52B
Serial : C31FD0D1
Firmware : 24.11.B0036
Has 1 paired device(s) out of a maximum of 6.
1: MX Keys Keyboard
Kind : keyboard
Protocol : HID++ 4.5
Der zweite Empfänger, der für die Tastatur. Dieselbe USB-Kennung, aber Firmware 24.11.B0036.
Hier fällt schon auf, was ich gleich groß mache. Zwei Unifying-Sticks, aber zwei Firmware-Linien: RQR12 für die ältere Maus-Generation, RQR24 für die neuere Tastatur. Beide tragen denselben orangen Stern, dahinter stecken aber zwei Baujahre und zwei Geschichten.
Zwei Sterne, ein Unterschied
Das ist das Herzstück, und es ist ein einziger Blick in Solaar. In der Geräteansicht steht bei jedem gekoppelten Gerät eine Zeile „Drahtlose Verbindung“. Für die Maus M705 meldet Solaar dort „nicht verschlüsselt“, mit einem roten Schild. Für die Tastatur MX Keys meldet dieselbe Zeile „verschlüsselt“, mit einem geschlossenen Schloss.
Solaar meldet für die Maus M705 eine nicht verschlüsselte Funkverbindung, mit rotem Schild.
Für die Tastatur MX Keys meldet Solaar dieselbe Übersicht als verschlüsselt, mit geschlossenem Schloss.
Was das heißt, und was nicht. Die Tastatur ist mit AES-128 verschlüsselt, der Schlüssel wurde beim Koppeln festgelegt. Wer die Funkstrecke mithört, bekommt Kauderwelsch. Die Maus funkt offen, was für Bewegungen und Klicks kein Problem ist. Und dann die ehrliche Einschränkung, die uns direkt zum Angriff führt: dass die Maus offen funkt, war historisch genau der Hebel für das Einschleusen, bis die Firmware das abgestellt hat.
Ein Gedanke, der jetzt naheliegt, führt in die Irre: dann schalte ich die Verschlüsselung der Tastatur eben ab und schaue, was durchgeht. Geht nicht. Die AES-Verschlüsselung der Tastatur hat keinen Ausschalter. Sie steckt fest im Unifying-Protokoll, Solaar hat dafür keinen Schalter, das alte ltunify auch nicht. Wer die Klartext-Eingaben der Tastatur sehen will, muss das AES brechen, nicht abschalten.
Was man installieren sollte, und was nicht
Für die reine Frage „bin ich sicher“ braucht man erstaunlich wenig. Zwei Pakete reichen, und beide waren auf dem Testgerät sowieso schon da.
Ein paar Werkzeuge, über die man im Netz stolpert, braucht man hier ausdrücklich nicht, und ich schreibe dazu, warum.
Paket
Warum nicht
ltunify
ältere Unifying-Kommandozeile, von Solaar überholt
libratbag / piper
DPI- und Tastenkonfiguration für Gaming-Mäuse, für die M705 unnötig, Solaar deckt sie ab
jackit, nrfutil, dfu-tool
Angriffs- und Flash-Werkzeuge für nRF-Hardware, hier nicht installiert. jackit gehört zum Crazyradio-am-Laptop-Weg, in diesem Aufbau macht die Funkarbeit stattdessen der Flipper
Bin ich sicher? Zwei Blicke genügen
Der erste Blick ist der Verschlüsselungsstatus, den Solaar meldet. Tastatur verschlüsselt, Maus nicht. Das ist bei Unifying normal und in Ordnung, solange man weiß, dass die Maus offen funkt und dort nichts Geheimes durchgeht.
Der zweite Blick ist die Firmware. fwupd kennt beide Empfänger über LVFS, und fwupdmgr get-updates sagt, ob etwas ansteht.
$ fwupdmgr get-updates --no-unreported-check
Devices with the latest available firmware version:
• Unifying Receiver
• Unifying Receiver
Beide sind auf dem neuesten Stand, den LVFS anbietet, das ist RQR12.11 und RQR24.11. Und jetzt die Verbindung zur Geschichte, die den Abschnitt wertvoll macht. Die MouseJack-Fixes stecken in den Firmware-Generationen ab RQR12.05 beziehungsweise RQR24.03 für die Kern-Punkte, und ab RQR12.08 beziehungsweise RQR24.06 für die verschlüsselte Injektion. Beide Empfänger liegen mit 12.11 und 24.11 deutlich darüber. Die Fernübernahme von 2016 ist an diesem Gerät also zu. Das ehrliche Ergebnis dieses Abschnitts ist „hier ist nichts zu tun“, und das darf man auch so hinschreiben.
Trotzdem der Handgriff für den Fall, dass doch einmal ein Update ansteht, als Verfahren, nicht als Messung. Auf dem Testgerät gab es nichts zu aktualisieren, ich habe die letzte Zeile hier also nicht wirklich ausgeführt.
Jetzt die andere Seite. Unifying funkt bei 2,4 GHz auf nRF24-Technik mit einer eigenen Paketstruktur, Enhanced ShockBurst nennt Nordic das. Normale SDR-Empfänger und die üblichen Sub-Gigahertz-Geräte sehen das schlicht nicht. Man braucht ein nRF24-Radio, das in einen Mithör-Modus versetzt wird. Und genau hier wird es interessant, was ein Flipper Zero kann und was nicht.
Der Flipper Zero, und warum er allein nicht reicht
Das eingebaute Funkteil des Flipper ist ein CC1101. Das arbeitet unter einem Gigahertz, grob 300 bis 928 MHz. Es kommt physikalisch nicht an die 2,4 GHz von Unifying heran. Aus der Schachtel heraus kann der Flipper diesen Angriff also gar nicht, egal welche Firmware drauf ist.
Welches Radio an 2,4 GHz herankommt. Der eingebaute CC1101 des Flippers arbeitet unter einem Gigahertz und sieht die Strecke nicht. Erst ein nRF24-Radio kommt heran.
Auf meinem Aufbau steckt der Flipper mit der Momentum-Firmware und einem Zusatzmodul, einem AIO Board. Auf dem Board steht die Bestückung selbst drauf: RED NRF24, GREEN ESP32, BLUE CC1101, dazu ein EBYTE-Modul und externe Antennen. Das entscheidende Teil für uns ist das nRF24-Radio. Genau das, was dem Flipper von Haus aus fehlt. Damit werden die Apps NRF24: Sniffer und NRF24: Mouse Jacker nutzbar, beide aus dem Projekt von mothball187 und in Momentum enthalten.
Flipper Zero mit aufgestecktem AIO Board V1.4. Das Board liefert das nRF24-Radio für 2,4 GHz, neben ESP32 und CC1101, das dem Flipper allein fehlt.
Der Ablauf ist in zwei Schritten schnell erzählt. Erst sucht der Sniffer die Kanäle ab und findet die Funkadresse des Empfängers. Dann bekommt der Mouse Jacker diese Adresse und ein Tastatur-Skript und versucht, Tasten einzuschleusen. Klingt einfach. Der erste Schritt ist es aber schon nicht.
Der NRF24-Sniffer meldet eine gefundene Adresse auf einem 2,4-GHz-Kanal.
Der nRF24-Treiber der Flipper-App gilt selbst als funktionierend, aber unfertig, und das Sniffen im 2,4-GHz-Band rastet gern auf zufälliges Rauschen ein und meldet Adressen, die es gar nicht gibt. Drei Läufe brachten bei mir drei verschiedene Adressen, einmal sogar mit „Unique 0“, also ohne einen einzigen wiederholten Treffer. Eine echte Logitech-Adresse taucht über mehrere Läufe immer wieder auf, das ist das Erkennungszeichen. Mit etwas Geduld, Maus dabei bewegen und jeden Durchlauf sauber mit OK beenden, damit die App überhaupt speichert, hat sich am Ende die Adresse 086A98E03C als die stabile, echte herauskristallisiert. Das Erkennen klappt also, aber es ist selbst schon eine Hürde und nicht der Sofort-Erfolg, den man sich vorstellt.
Die offene Maus lässt sich mit demselben Radio mitschnüffeln, man sieht rohe Pakete. Passwörter sind da natürlich keine drin, nur Bewegung und Klicks. Genau das ist der greifbare Beleg für „die Maus funkt im Klartext“.
Und jetzt der eigentliche Versuch. Ich habe einen einfachen Texteditor auf dem Notebook geöffnet und ihm den Fokus gegeben. Der Mouse Jacker bekam die ersniffte Adresse 086A98E03C und ein harmloses Skript, das nur den Text MOUSEJACK-TEST-0810 tippen sollte, sonst nichts. Der Flipper zeigte „Running duckyscript“.
Mouse Jacker feuert das Skript gegen die Adresse. Auf dem gepatchten Empfänger landet keine einzige Taste.
Im Editor erschien nichts. Keine einzige Taste kam durch. Das ist kein Misserfolg des Versuchs, sondern das erwartete Verhalten an einem Empfänger, der über dem MouseJack-Fix liegt.
Hier bleibe ich bei der Ursache ehrlich, das ist mir wichtig. „Nichts passiert“ allein trennt nicht sauber, ob die Firmware das Paket abgewiesen hat oder ob die ersniffte Adresse nicht exakt der Empfänger war. Um das isoliert zu beweisen, müsste ein bewusst verwundbarer Vergleichs-Empfänger danebenstehen, an dem derselbe Angriff gelingt, und der stand hier nicht daneben. Sicher ist: die klassische MouseJack-Übernahme aus der Ferne, ohne Anfassen, gelang an diesem aktuellen Setup mit RQR12.11 nicht, und das passt dazu, dass fwupd die Firmware als aktuell und über dem Fix meldet. Mehr behaupte ich an dieser Stelle nicht. Das ist gemessen, die Deutung der Ursache ist plausibel, aber nicht bewiesen.
Nur eine von mehreren Möglichkeiten
Der Flipper ist nur ein Weg, und ehrlich gesagt der bequeme für unterwegs. Damit klar ist, was sonst noch geht:
Crazyradio PA, ein nRF24-USB-Stick mit der Bastille-Firmware plus jackit. Das klassische MouseJack-Werkzeug, läuft am Laptop und kann mitschreiben.
nRF52840-Dongle mit Logitacker von Marcus Mengs. Das moderne Werkzeug, das auch die 2019er-Lücken kann, inklusive der Kopplungs-Lücke CVE-2019-13052. Genau dieses Gespann kommt im zweiten Teil zum Einsatz.
Raspberry Pi mit nRF24-Modul. Möglich, aber deutlich fummeliger, weil das Timing schlechter ist als bei einer dedizierten Crazyradio.
Die Grenze des Flippers ist dabei klar. Er ist gut zum Erkennen und für den MouseJack-Versuch, aber er leitet keine Schlüssel ab und entschlüsselt keine Tastatur. Dafür braucht es Logitacker auf dem nRF52840, und das ist der zweite Teil.
Was ich für sichere Umgebungen empfehle
Kein Wischiwaschi, eine klare Rangfolge.
Kabel. Eine USB-Tastatur funkt gar nicht. Für alles, wo wirklich Geheimes getippt wird, ist das die ruhigste Lösung.
Logi Bolt oder eine sauber gekoppelte Bluetooth-Verbindung mit Secure Connections. Verschlüsselt und authentifiziert, also auch gegen Einschleusen geschützt.
Aktuelles Unifying. Völlig brauchbar, wenn die Empfänger-Firmware gepflegt ist. Die Tastatur ist verschlüsselt, die Fernübernahme ist zu. Das Restrisiko ist die Kopplungs-Lücke.
Alles ohne Verschlüsselung, KeySniffer-Klasse, gehört ersetzt. Da hilft kein Update.
Dazu zwei Handgriffe, die jeder machen kann. Die Firmware der Empfänger aktuell halten, mit fwupdmgr, das ist eine Minute Arbeit. Und Geräte nur in vertrauenswürdiger Umgebung koppeln, nicht im Café und nicht im vollen Großraumbüro, wegen genau dieser Kopplungs-Lücke CVE-2019-13052.
Eine kurze Entscheidungshilfe für das eigene Funk-Setup.
Was offen bleibt
Warum das Einschleusen genau scheiterte. Der Durchlauf ist gemessen, der Sniffer findet 086A98E03C und die Injektion landet nichts, aber ob die Firmware abwies oder die ersniffte Adresse nicht exakt saß, ist ohne einen verwundbaren Vergleichs-Empfänger nicht isoliert nachgewiesen.
Die Kopplungs-Lücke CVE-2019-13052 ist beschrieben, aber nicht vorgeführt. Das ist der Kern des zweiten Teils.
Ob sich auf genau diesem nRF24-Modul die Adresse zuverlässig mitschneiden lässt, hängt von Kanal und Timing ab und ist nicht erschöpfend getestet.
Ob die MX Keys selbst per fwupd ein Firmware-Update bekommen könnte, habe ich nicht geprüft, nur die beiden Empfänger.
Reichweite und Störumgebung. Alle Aussagen zum Mithören beziehen sich auf die Laborsituation direkt am Gerät.
Wie es weitergeht
Im nächsten Teil wird nicht nur erklärt, sondern gemacht. Mit einem nRF52840-Dongle und Logitacker schneide ich den Kopplungsvorgang einer Unifying-Tastatur mit, leite daraus den Schlüssel ab und lese die Eingaben mit. Das ist die Design-Lücke CVE-2019-13052, und sie betrifft auch die aktuelle Firmware, an der der Flipper heute noch abgeprallt ist. Aus „die Tastatur ist verschlüsselt“ wird dann „und trotzdem lesbar, wenn ich im richtigen Moment dabei war“. Das ist der interessante Teil, und er kommt.
Bezugsquellen
Die folgenden Links sind Affiliate-Links (Werbung). Kaufst du darüber, bekomme ich eine kleine Provision, für dich ändert sich am Preis nichts.
Wenn ich irgendwo danebenliege, korrigiert mich gerne, dann lerne ich selbst etwas. Ich bin ja auch nur doof ;-). Und die Frage an euch zum Schluss: Nutzt ihr Funk oder Kabel, und habt ihr je nachgesehen, ob eure Tastatur überhaupt verschlüsselt funkt? Wie das geht, wisst ihr jetzt. Wenn ihr mögt, dürft ihr mich dazu sehr gerne fragen.
Es gibt Dinge, die unter Linux in der breiten Masse vernachlässigt werden. Secure Boot ist so ein Beispiel, TPM ist ein anderes. Vielleicht ist es an der anfangs bescheidenen Unterstützung gescheitert, vieleicht sind die Themen technisch einfach unangenehm, am ehesten aber liegt es daran, dass der Mehrwert für die meisten überschaubar bleibt. Heute nehme ich mir den TPM vor.
Aufgefallen ist mir der Chip zweimal. Das erste Mal, als er durch die Medien ging, weil die Angst groß wurde, Microsoft mache damit unsere IT kaputt, und weil jemand anfing, sehr viele Patente einzureichen. Das zweite Mal viele Jahre später, als TPM 2.0 zur harten Voraussetzung für Windows 11 wurde. Dazwischen lagen zwanzig Jahre, in denen der Chip in fast jedes Endgerät gewandert ist, ohne dass sich jemand dafür interessiert hat.
In Notebooks und Fertig-PCs ist er heute meist fest verlötet. Bei Server-Mainboards kauft man ihn dagegen als Option dazu, ein kleines Steckmodul auf einem eigenen Header. Der Chip in meinem Testgerät ist ein Infineon OPTIGA SLB 9670, und genau dieselbe Chip-Familie sitzt auf den steckbaren TPM-Modulen für Supermicro-Boards. Damit schließt der Beitrag an die BIOS-Serie an, in der ich mich gerade Menü für Menü durch ein Serverboard arbeite.
Das nachgerüstete TPM-Modul für den JTPM1-Header, hier freigestellt. Auf der Rückseite steckt ein echter Infineon SLB9670. Bei vielen Server-Boards gehört der Chip nicht zum Lieferumfang.
Erst die Geschichte, dann die Hände in den Chip. Alle Ausgaben hier sind echt und stammen vom 10. August 2026, gemessen auf einem Fujitsu Celsius H780 mit Linux Mint 22.3, Kernel 7.0.0-28-generic und tpm2-tools 5.6. Wo ich etwas nur aus Dokumentation kenne oder wo ich vermute, steht das dabei.
Angefangen hat alles mit einer Seriennummer in der CPU
Mitte der neunziger Jahre wollte Intel eine Identifizierungsfunktion direkt in den Prozessor bringen. Der erste Schritt war 1999 die Prozessor-Seriennummer im Pentium III, eine eindeutige Kennung, die jede Software auslesen konnte. Der öffentliche Widerstand war so heftig, dass Intel zurückzog. Das Vorhaben verschwand aber nicht, es suchte Deckung in einem Konsortium. Dieses Detail ist wichtig, weil es das Muster für alles setzt, was danach kam.
1999 gründeten Compaq, HP, IBM, Intel und Microsoft die Trusted Computing Platform Alliance, kurz TCPA. Im April 2003 wurde daraus die Trusted Computing Group, TCG, getragen von AMD, HP, IBM, Intel und Microsoft. Aus einer Firmenidee war ein Industriestandard geworden.
Der Chip, der nach einem Senator benannt wurde
In der Debatte bekam der TPM den Spottnamen „Fritz-Chip“. Der Name ging auf den US-Senator Fritz Hollings aus South Carolina zurück, der den CBDTPA vorantrieb, ein Gesetzesvorhaben, das Kopierschutz in aller Consumer-Elektronik verpflichtend machen sollte. Der Spottname war also ein politischer Vorwurf und keine technische Bezeichnung. Er hat trotzdem länger gehalten als das Gesetz, aus dem er kam.
Vertrauen, aber nicht dein Vertrauen
Ross Anderson von der Universität Cambridge schrieb 2002 und 2003 die Trusted Computing FAQ. Dieses Dokument hat die Debatte stärker geprägt als jede Herstellerankündigung, und es liegt bis heute unverändert online. Sein Kernargument in einem Satz: bei „Trust“ geht es nicht darum, dass der Nutzer dem Rechner vertraut, sondern darum, dass der Rechner dem Nutzer nicht vertraut.
Richard Stallman legte 2002 mit „Can you trust your computer?“ nach und prägte den Gegenbegriff treacherous computing, verräterisches Rechnen. Die FSF benutzt ihn heute noch. IBM antwortete mit einer Gegendarstellung von David Safford, „Clarifying Misinformation on TCPA“.
Die EFF ging einen dritten Weg, und der ist der interessanteste. Seth Schoen veröffentlichte im Oktober 2003 Trusted Computing: Promise and Risk und schlug ein konkretes Feature vor, den Owner Override. Der Eigentümer des Rechners sollte die Attestierung überstimmen können, seinem Bank-Server also erzählen dürfen, sein Opera sei ein Internet Explorer. Die Kritik hatte damit einen Reparaturvorschlag und war nicht bloß dagegen. Die TCG hat den Owner Override nie übernommen.
Microsoft nannte sein eigenes Vorhaben Palladium und benannte es am 24. Januar 2003 in Next-Generation Secure Computing Base um, NGSCB. Der Name wurde harmloser, die Architektur blieb dieselbe.
Zwei Patente von 2001, und ein Cypherpunk der zurückschoss
Im Dezember 2001 wurden Microsoft zwei Patente erteilt. Das eine ist US 6,330,670, „Digital rights management operating system“, angemeldet im Januar 1999, erteilt am 11. Dezember 2001, als Erfinder Paul England, John DeTreville und Butler Lampson. Das andere ist US 6,327,652, „Loading and identifying a digital rights management operating system“. Zusammen decken sie viele Grundelemente eines vertrauenswürdigen Betriebssystems ab.
Die Sorge dahinter war handfest und nicht abwegig. Wenn Palladium unter dieses Patent fällt, dann verletzt jeder unabhängige Nachbau das Patent. Also jeder einzelne Entwickler, jedes Open-Source-Projekt, jeder Wettbewerber. Ohne Lizenz von Microsoft kein freies Trusted Computing. Kritiker beschrieben das damals als Kombination aus Patentschutz und faktischem Zwang zur Nutzung, mit deutlich wettbewerbsrechtlichem Geschmack.
Der Gegenzug kam im August 2002 von einem Cypherpunk, der unter dem Namen Lucky Green auftrat. Er meldete selbst ein Patent an, und zwar auf Verfahren, mit denen Software auf einer Palladium- oder TCPA-Plattform gegen Kopieren geschützt werden kann. Der Zweck war offen defensiv: wer die Ansprüche hält, kann verhindern, dass genau diese Anwendungen ausgerollt werden. Auf einem Panel der USENIX Security wurde er gefragt, ob Microsoft nicht einfach Prior Art geltend machen könne. Sein Argument: Prior Art müsste unter Eid erklärt werden, und nach Jahren Arbeit am Projekt und einem ausführlichen eigenen DRM-Patent sei kaum vorstellbar, dem Palladium-Team wäre relevante Prior Art entgangen. Im September 2002 hielt er zusätzlich einen Vortrag mit dem Titel „TCPA: the mother(board) of all Big Brothers“.
Was daraus geworden ist
Die Auflösung ist unbequemer, als es beide Lager damals gedacht haben. NGSCB ist gescheitert, aber nicht an den Patenten. Im Mai 2004 stellte Microsoft die vollständige Architektur zurück, und die Begründung war wirtschaftlich: die Hardware-Landschaft war nicht reif, und vor allem waren die unabhängigen Softwarehersteller nicht bereit, ihre Anwendungen auf die nötigen neuen APIs umzuschreiben. Curtained Memory und der Nexus-Kernel fielen weg, die TPM-Unterstützung blieb übrig.
Der Chip selbst wurde offen. Nach TPM 1.2 kam TPM 2.0, veröffentlicht 2014 und als ISO/IEC 11889 internationaler Standard. Die TCG stellt die Referenz-Implementierung unter eine royalty-free Copyright-Lizenz, das Patentregime zwischen den Mitgliedern ist RAND. Damit war der Nachbau möglich und dem Patenthebel die Grundlage entzogen.
Linux hat es dann einfach implementiert. Der Treiber tpm_tis sitzt im Kernel, IBM brachte TrouSerS für TPM 1.2, für TPM 2.0 entstand mit Beteiligung von Intel und TCG der tpm2-tss-Stack samt tpm2-tools. Seit Linux 4.12 gibt es den Resource Manager im Kernel unter /dev/tpmrm0, wodurch der frühere Userspace-Daemon tpm2-abrmd für die meisten Fälle überflüssig wurde. Nichts davon brauchte eine Lizenz von Microsoft.
Die befürchtete Abriegelung kam trotzdem, nur von woanders. Kein einziger der Horror-Fälle aus der TCPA-FAQ wurde durch den TPM Realität. Wo Nutzer heute tatsächlich ausgesperrt werden, steckt eine andere Technik dahinter: Widevine beim Streaming, Play Integrity und früher SafetyNet bei Android, verriegelte Bootloader bei Telefonen, die Secure Enclave bei Apple, Attestierung bei Spielkonsolen. Der TPM wurde stattdessen ein langweiliger Schlüsselspeicher.
Ein Teil der Angst hat sich dann doch erfüllt, nur in anderer Form. Windows 11 macht TPM 2.0 zur harten Voraussetzung, und damit gilt funktionierende Hardware plötzlich als nicht unterstützt. Das ist keine DRM-Geschichte, sondern eine Elektroschrott- und Lebensdauer-Geschichte. Der Mechanismus ist aber derselbe: eine Hardware-Eigenschaft entscheidet, was auf dem Gerät laufen darf.
Und dann kam der Kreis zurück. 2023 schlugen Chrome-Entwickler bei Google die Web Environment Integrity API vor. Der Browser sollte sich von einer Vertrauensinstanz einen Nachweis über seine Umgebung ausstellen lassen, den Webseiten dann prüfen können. Das ist praktisch Wort für Wort das Szenario, vor dem Anderson zwanzig Jahre früher gewarnt hatte, nur ohne TPM. Nach massivem Widerstand zog Google den Vorschlag im November 2023 für Chromium auf dem Desktop zurück.
Hat die Patentanmeldung von damals also geholfen?
Das ist die Frage, mit der ich in die Recherche gegangen bin, und die Antwort ist zweiteilig. Die defensive Patentanmeldung hat, soweit öffentlich nachvollziehbar, nichts bewirkt. Es gibt kein erteiltes Patent, das man heute als den Grund benennen könnte, warum TCPA-DRM nicht kam. Der Gegenzug war eine wirksame Geste, aber kein wirksames Rechtsmittel. Gewirkt hat etwas anderes: erstens die Wirtschaftlichkeit, weil die Softwarehersteller nicht umschreiben wollten und es damit kein Produkt gab, zweitens die Öffnung der Spezifikation und die ISO-Standardisierung, die den Nachbau erlaubten.
Der zweite Teil verdient Anerkennung. Die Kampagne selbst hat gewirkt, nur nicht juristisch, sondern politisch. Der Lärm um TCPA hat plausibel dazu beigetragen, dass die TCG die Spezifikation öffnete, die aggressivsten Ideen fallen ließ und dass Fernattestierung zwanzig Jahre lang aus dem Consumer-Web draußen blieb. Als der Versuch 2023 mit Web Environment Integrity wiederkam, war das Muster des Widerstands eingeübt und der Vorschlag nach Monaten weg. Wichtig dabei: das ist meine Deutung. Die Kausalkette von der Kampagne 2002 zur offenen Spezifikation 2014 ist nirgends dokumentiert, das ist ein Plausibilitätsargument und keine Messung.
Bleibt der Eindruck: die Angst war berechtigt und falsch adressiert. Berechtigt, weil die Mechanik der Fernattestierung tatsächlich genau das kann, was befürchtet wurde. Falsch adressiert, weil der TPM davon der harmloseste Teil war und am Ende zu dem wurde, was jetzt kommt. Ein langsamer, sturer kleiner Chip, der Schlüssel nicht herausgibt.
Erst suchen, ganz ohne TPM-Werkzeug
Bevor ihr irgendetwas installiert: der Kernel weiß längst, ob da ein Chip sitzt. Er sagt es beim Start.
Drei Dinge stehen da drin. In der ersten Zeile übergibt UEFI die Adresse des Event-Logs, TPMEventLog=0x798c0018, also der Liste aller Messungen aus dem Startvorgang. Dann die ACPI-Tabelle TPM2, über die die Firmware mitteilt, wo und wie der Chip ansprechbar ist. Und in der letzten Zeile das Ergebnis: der Treiber tpm_tis hat unter der ACPI-Kennung MSFT0101 ein TPM der Version 2.0 gefunden.
Danach existieren zwei Gerätedateien, und der Unterschied zwischen ihnen ist wichtig.
# ls -la /dev/tpm*
crw-rw---- 1 tss root 10, 224 Aug 10 09:31 /dev/tpm0
crw-rw---- 1 tss tss 252, 65536 Aug 10 09:31 /dev/tpmrm0
/dev/tpm0 ist der rohe Zugang zum Chip. Daran kann genau ein Prozess gleichzeitig arbeiten, und wer die Ressourcen im Chip verwaltet, ist selbst dafür verantwortlich. /dev/tpmrm0 geht über den Resource Manager im Kernel, der das Ein- und Auslagern der Schlüssel-Kontexte übernimmt und mehrere Nutzer nebeneinander erlaubt. In der Praxis nimmt man immer /dev/tpmrm0, und die tpm2-tools tun das von sich aus.
Die Version steht ebenfalls im sysfs, und die solltet ihr prüfen, bevor ihr weiterlest.
# ls /sys/class/tpm/tpm0/
dev device pcr-sha1 pcr-sha256 power ppi subsystem tpm_version_major uevent
# cat /sys/class/tpm/tpm0/tpm_version_major
2
Eine 2 heißt TPM 2.0 und alles in diesem Beitrag gilt. Eine 1 heißt TPM 1.2, und dann gilt fast nichts davon, weil es ein anderer Standard mit einem anderen Software-Stack ist. Nebenbei verrät das Verzeichnis noch etwas: es gibt eine pcr-sha1– und eine pcr-sha256-Bank, der Chip führt die Messregister also in zwei Hash-Verfahren parallel.
Und weil der Kernel das ohnehin bereitstellt, kommt hier der erste kleine Aha-Moment, noch ganz ohne installiertes Paket. Die Messwerte des Startvorgangs liegen als Dateien herum.
Das sind drei der Platform Configuration Register, kurz PCR. Merkt euch den Wert von PCR 7, der taucht später mehrfach auf.
Die Falle mit lsmod
Das ist eine häufige Fehldiagnose, deshalb steht sie hier als eigener Punkt. Auf meinem Testsystem liefert lsmod | grep tpm nämlich schlicht nichts. Kein Modul, keine Ausgabe. Der Chip arbeitet trotzdem einwandfrei, weil tpm_tis in diesen Kernel fest eingebaut ist und deshalb in der Modulliste gar nicht erscheinen kann. Wer nach lsmod urteilt, hält ein funktionierendes TPM für abwesend. Fragt stattdessen nach der Treiberbindung.
# ls -l /sys/class/tpm/tpm0/device/driver
lrwxrwxrwx 1 root root 0 Aug 10 09:31 /sys/class/tpm/tpm0/device/driver -> ../../../bus/platform/drivers/tpm_tis
# cat /sys/class/tpm/tpm0/device/modalias
acpi:MSFT0101:MSFT0101:
Der Symlink zeigt, welcher Treiber das Gerät tatsächlich bedient. Das ist die Antwort auf die Frage, die lsmod nicht beantworten kann.
Wenn nichts auftaucht
Bleibt dmesg stumm und existiert kein /dev/tpm0, dann gibt es drei realistische Ursachen, in dieser Reihenfolge.
Im Firmware-Setup abgeschaltet. Die Option heißt je nach Hersteller „Security Device Support“, „TPM State“, „Trusted Computing“, „PTT“ oder „fTPM“. Wo diese Menüs bei einem Serverboard liegen und wie man sich dort zurechtfindet, habe ich in der BIOS-Serie ausführlich aufgeschrieben.
Physisch nicht vorhanden. Bei Server-Boards ist der TPM oft ein steckbares Modul auf einem eigenen Header, bei Supermicro etwa die AOM-TPM-Module auf dem Anschluss JTPM1. Wer ihn nicht mitbestellt hat, hat einen leeren Steckplatz. Bei Notebooks ist der Chip dagegen fast immer verlötet.
Vorhanden, aber als fTPM in der CPU statt als eigener Chip. Woran man das unterscheidet, steht weiter unten, und man liest es an einer einzigen Zeile ab.
Zwei Details aus dem Firmware-Setup, die hier gut passen. Erstens sind SHA-1-Bank und SHA-256-Bank oft getrennt schaltbar. Dass mein Testgerät beide Banks führt, ist also keine Selbstverständlichkeit, sondern eine Einstellung. Zweitens steht in demselben Menü meist ein TPM Clear. Finger weg, solange ihr nicht genau wisst, was daran hängt. Ein Clear wirft die Hierarchien im Chip weg, und damit ist alles, was gegen diesen Chip versiegelt war, unwiederbringlich verloren. Auch der BitLocker-Schlüssel eines parallel installierten Windows.
Die Schichten, bevor das erste Paket installiert wird
Es hilft, den Stack einmal von unten nach oben gesehen zu haben. Sonst installiert man ein Paket und wundert sich später, welche der vielen Bibliotheken wofür zuständig ist.
Der Weg eines Kommandos vom Werkzeug bis in den Chip. Über /dev/tpm0 arbeitet genau ein Prozess, über /dev/tpmrm0 mehrere.
Ganz unten der Chip, darüber der Kerneltreiber, darüber die beiden Gerätedateien. Erst dann kommt Userspace: die TCTI-Schicht kümmert sich um den Transport zur Gerätedatei, die ESAPI-Schicht um Kommandos, Sessions und HMAC-Absicherung. Ganz oben die drei Werkzeuge, die man tatsächlich in die Hand nimmt. Für die Pflichtausstattung reichen zwei Pakete.
Paket
Wofür
tpm2-tools
die tpm2_*-Kommandozeile, alles in diesem Beitrag läuft darüber
libtss2-*
der TSS2-Stack darunter, meist schon über systemd installiert
Dazu zwei optionale, die ich beide benutze, weil sie den Chip an Software anschließen, die von TPM nichts wissen muss.
Paket
Wofür
tpm2-openssl
Provider für OpenSSL 3, Schlüssel im Chip über die gewohnten openssl-Aufrufe
libtpm2-pkcs11-1 und libtpm2-pkcs11-tools
PKCS#11-Schnittstelle, damit SSH und Browser den Chip nutzen können
Und zwei, die ich ausdrücklich nicht installiere.
Paket
Warum nicht
tpm2-abrmd
Resource Manager im Userspace mit D-Bus-Schnittstelle. Seit Linux 4.12 macht der Kernel das über /dev/tpmrm0 selbst. Das Projekt ist nicht tot, es wird weiter gepflegt und ist für Simulatoren, Tests und manche Integrationen nach wie vor sinnvoll. Beides parallel zu betreiben führt aber zu Konflikten, deshalb hier bewusst nur der Kernel-Weg.
clevis, clevis-tpm2
binden ausschließlich LUKS2-Header. Ohne LUKS nutzlos, und auf diesem Gerät gibt es kein LUKS.
Auf meinem Mint 22.3 sind damit tpm2-tools 5.6, tpm2-openssl 1.2.0 und tpm2-pkcs11 1.9.0 gelandet. Der TSS2-Stack war schon da, den bringt systemd mit. Auf Fedora und RHEL heißt das Hauptpaket ebenfalls tpm2-tools, dazu tpm2-tss, unter Arch genauso tpm2-tools mit tpm2-tss als Abhängigkeit.
Eine Kleinigkeit, über die jeder beim ersten Mal stolpert: /dev/tpmrm0 gehört tss:tss. Entweder arbeitet ihr mit sudo, oder ihr nehmt euren Benutzer in die Gruppe tss auf. Die Rechte in der Ausgabe von ls -la /dev/tpm* weiter oben sagen genau das, crw-rw---- und keine Rechte für alle anderen.
Spricht der Chip?
Es gibt drei Stufen, aufsteigend im Aussagewert. Die erste ist der Lebenstest.
# tpm2_getrandom --hex 16
Kommen 16 Bytes zurück, dann funktioniert die ganze Kette von der Bibliothek über die Gerätedatei bis in die Hardware. Der Zufall kommt dabei wirklich aus dem Chip, und er ist gemächlich, dazu unten die Zahlen. Stufe zwei ist tpm2_getcap properties-fixed, da sagt der Chip, wer er ist. Stufe drei ist tpm2_getcap properties-variable, da sagt er, in welchem Zustand er ist. Beide sind gleich interessant, nur aus unterschiedlichen Gründen.
Rohe Hex-Werte, die plötzlich Sinn ergeben, wenn man sie einmal übersetzt. Das ist einer meiner Lieblingsmomente an dem ganzen Thema.
TPM2_PT_MANUFACTURER: 0x49465800 ist ASCII IFX, also Infineon.
VENDOR_STRING_1 und _2 ergeben zusammengesetzt SLB9 und 670, also ein Infineon OPTIGA SLB 9670.
TPM2_PT_REVISION: 0x74 ist Spezifikations-Revision 1.16, datiert auf Tag 265 des Jahres 2016.
FIRMWARE_VERSION_1: 0x7003F ist Firmware 7.63.
TPM2_PT_PCR_COUNT: 0x18 sind 24 PCRs.
TPM2_PT_HR_PERSISTENT_MIN: 0x7 heißt, dass nur sieben persistente Schlüsselplätze garantiert sind. Diese Zahl wird später richtig wichtig.
TPM2_PT_NV_COUNTERS_MAX: 0x8 sind genau acht monotone Zähler.
Und dann TPM2_PT_NV_INDEX_MAX: 0x680, also 1664. Hier lauert eine Fehldeutung, die in vielen Texten steht: das ist nicht der gesamte NV-Speicher des Chips, sondern die maximale Größe eines einzelnen NV-Index-Datenbereichs. Wie viel NV insgesamt frei ist, sagt diese Eigenschaft überhaupt nicht. Das steht im Datenblatt des Herstellers und liegt bei diesem Chip im Bereich einiger Kilobyte. Ich habe es nicht ermittelt, also behaupte ich hier auch keine Gesamtgröße.
Diskreter Chip oder fTPM in der CPU
Diese Unterscheidung ist keine Nebensächlichkeit, und man liest sie direkt am Hersteller-String ab.
Hersteller-String
Was es ist
IFX, NTC, STM, IBM
diskreter Chip auf dem Board oder auf einem Steckmodul
INTC
Intel Platform Trust Technology, läuft in der Management Engine
AMD
AMD fTPM, läuft im Platform Security Processor
Ein diskreter Chip hängt an einem physischen Bus, den man anzapfen kann. Ein fTPM hat diesen Bus nicht, dafür hat er andere Probleme. Beides kommt im Angriffs-Abschnitt zurück.
Für mein Testsystem ist die Sache klar: IFX, also ein diskreter Infineon SLB 9670. Aus Linux-Sicht hängt er als memory-mapped TIS an der ACPI-Kennung MSFT0101 und wird von tpm_tis bedient. Ob die physische Leitung dahinter LPC oder SPI ist, lässt sich aus dem Betriebssystem allein nicht entscheiden, weil der PCH einen SPI-TPM auch als MMIO-TIS durchreichen kann. Das ist also plausibel, aber nicht gemessen. Die einzige echte Antwort wäre ein Foto vom offenen Gerät, und dafür müsste das Notebook auseinander.
32 Fehlversuche, und deshalb reicht eine kurze PIN
Jetzt der Zustand, und das ist der wichtigste einzelne Abschnitt des ganzen Beitrags, weil er später alles trägt.
Diese drei Werte werden fast immer verwechselt, also einmal sauber.
MAX_AUTH_FAIL: 0x20 sind 32 fehlgeschlagene Authentifizierungsversuche, danach sperrt der Chip.
LOCKOUT_INTERVAL: 0x1C20 sind 7200 Sekunden, also 2 Stunden. Nach dieser Zeit wird der Fehlerzähler um genau eins verringert.
LOCKOUT_RECOVERY: 0x15180 sind 86400 Sekunden, also 24 Stunden. Das ist aber nicht die Erholung des normalen Zählers, sondern die Wartezeit, bevor nach einem fehlgeschlagenen Versuch mit lockoutAuth erneut mit lockoutAuth gearbeitet werden darf.
Einmal vorgerechnet, weil die Zahlen so viel deutlicher sind: ein einzelner Fehlversuch altert nach 2 Stunden aus. Von 32 verbrauchten Versuchen zurück auf null dauert also 64 Stunden und nicht 24.
Und das ist der eigentliche Mehrwert des ganzen Bauteils. Der Chip zählt Fehlversuche und sperrt. Deshalb reicht bei einem TPM eine sechsstellige PIN, wo ein Passwort-Hash auf der Platte eine Passphrase mit hoher Entropie bräuchte. Wer die Platte hat, probiert Millionen Passphrasen pro Sekunde durch. Wer vor dem TPM sitzt, bekommt 32 Versuche und darf dann zwei Stunden warten, um einen einzigen zurückzubekommen. Die Stärke kommt nicht aus dem Geheimnis, sie kommt aus der Hardware, die das Raten unterbindet. Fast jeder Text über TPM lässt diesen Punkt weg, und dann klingt die kurze PIN nach Leichtsinn.
Das Geburtszertifikat des Chips
Jetzt kommt der Teil, den ich in keinem der üblichen TPM-Howtos gesehen habe. In dem Chip liegt ab Werk ein Zertifikat, ausgestellt vom Hersteller auf den Endorsement Key. Erst die Liste der belegten NV-Indizes, dann das Zertifikat selbst.
0x1C00002 ist der TCG-Standardindex für das RSA-EK-Zertifikat, 0x1C0000A derselbe für ECC. 1184 Bytes, das passt zu einem X.509-Zertifikat. Also raus damit und mit gewohnten Werkzeugen anschauen.
# tpm2_nvread 0x1C00002 -o ek_rsa.der
WARN: Reading full size of the NV index
# openssl x509 -inform der -in ek_rsa.der -noout -subject -issuer -dates
subject=
issuer=C = DE, O = Infineon Technologies AG, OU = OPTIGA(TM) TPM2.0, CN = Infineon OPTIGA(TM) RSA Manufacturing CA 035
notBefore=Aug 21 14:09:40 2019 GMT
notAfter=Aug 21 14:09:40 2034 GMT
Zwei Dinge fallen sofort auf. Der Aussteller ist eine echte Hersteller-CA, „Infineon OPTIGA(TM) RSA Manufacturing CA 035“, und Infineon hat diesen Chip am 21. August 2019 signiert. Und der Subject ist leer. Ein TPM hat keinen Namen. Die Identität steckt woanders, nämlich in den Erweiterungen.
Der Subject Alternative Name trägt drei TCG-OIDs, und die decken sich exakt mit dem, was der Chip vorher selbst über sich gesagt hat. 2.23.133.2.1 ist der Hersteller, id:49465800, also wieder IFX. 2.23.133.2.2 ist das Modell, SLB 9670 TPM2.0. 2.23.133.2.3 ist die Firmware, id:073f, was genau die 7.63 von oben bestätigt. Die Extended Key Usage 2.23.133.8.1 ist tcg-kp-EKCertificate, dieses Zertifikat darf also nichts anderes sein als der Nachweis eines Endorsement Keys. Und Infineon veröffentlicht dazu eine Sperrliste.
Was ich hier bewusst weglasse, sind die Zertifikats-Seriennummer und der öffentliche EK-Schlüssel. Beide kennzeichnen dauerhaft und eindeutig genau dieses eine Notebook, und die TCG behandelt den EK aus genau diesem Grund als datenschutzrelevant. Damit erklärt sich beiläufig, warum es überhaupt Attestierungsschlüssel gibt: damit man für eine Attestierung nicht jedes Mal die dauerhafte Chip-Identität vorzeigen muss.
Das hier ist die Wurzel, auf der Fernattestierung aufsetzt. Ein Prüfer kann feststellen, dass in dieser Maschine ein echter, von Infineon signierter TPM sitzt, ohne dem Betriebssystem eine einzige Zeile zu glauben. Genau formuliert beweist das Zertifikat aber nur die Echtheit des Chips. Dass ein bestimmter Attestierungsschlüssel wirklich in diesem Chip liegt, ist ein zusätzlicher Schritt, und den nehme ich mir im Server-Teil vor.
Drei Dinge, alles andere ist Kombination
Bevor irgendein Anwendungsfall kommt: ein TPM bietet im Kern nur drei Dinge an. Alles, was danach als Feature verkauft wird, ist eine Kombination daraus.
Schlüssel, die nicht herauskommen. Ein Schlüssel mit dem Attribut fixedTPM wird im Chip erzeugt und verlässt ihn nie. Man kann ihn benutzen, man kann ihn nicht kopieren.
PCRs, Register die nur wachsen. 24 Register, hier mit SHA-1- und SHA-256-Bank. Man kann sie nicht setzen, nur erweitern, und die Rechenvorschrift dafür ist neu = hash(alt || messwert). Bei den Registern, auf die es ankommt, nämlich PCR 0 bis 15 auf einer PC-Client-Plattform, geht es nur über einen Neustart zurück. Deshalb kann man die Boot-Historie nicht nachträglich fälschen. Zwei Ausnahmen gehören dazu, sonst wird es ungenau: PCR 16 und PCR 23 sind zur Laufzeit zurücksetzbar. PCR 16 ist ausdrücklich als Debug-Register vorgesehen, und genau deshalb benutze ich es weiter unten für die Demonstration. Gegen ein zurücksetzbares PCR versiegelt niemand etwas Echtes.
Sealing, Geheimnisse an einen Zustand binden. Ein Geheimnis wird so verschlüsselt, dass der Chip es nur herausgibt, wenn eine Policy erfüllt ist, typischerweise ein bestimmter PCR-Zustand.
Dazu kommen als Nebenfunktionen die schon erwähnten monotonen Zähler, ein winziger NV-Speicher, ein Zufallszahlengenerator und die Lockout-Logik von oben.
Und weil es das häufigste Missverständnis überhaupt ist, gleich früh und deutlich: ein TPM ist kein Krypto-Beschleuniger, keine Secure Enclave mit eigener Rechenumgebung und kein Schutz gegen einen kompromittierten laufenden Kernel. Er schützt Schlüssel im Ruhezustand und er misst den Startvorgang. Wenn der laufende Kernel übernommen ist, benutzt der Angreifer den TPM einfach mit, ganz höflich über dieselbe Schnittstelle.
Measured Boot in acht Befehlen
Genug Theorie, jetzt der Beweis. Ich baue eine Policy aus dem aktuellen Zustand von PCR 7, erzeuge einen Primary Key im Chip und versiegle damit ein Geheimnis.
Das Geheimnis kommt zurück, weil PCR 7 noch genau den Wert hat, gegen den versiegelt wurde. Schön, beweist aber noch nichts. Interessant wird es erst, wenn sich die Messung ändert.
Dafür wechsle ich auf PCR 16, das Debug-Register. Der Grund ist praktisch: PCR 16 lässt sich ohne Neustart und ohne Firmware-Änderung erweitern, damit ist die Demonstration in einer einzigen Terminal-Sitzung reproduzierbar. Der Mechanismus ist derselbe wie bei PCR 7.
Und jetzt ändere ich die Messung. Das folgende Kommando ist genau das, was ein ausgetauschter Bootloader auch täte, nur mit einem selbstgewählten Messwert.
0x99D ist TPM_RC_POLICY_FAIL. Das Geheimnis liegt noch im Blob, es ist nicht gelöscht, es ist nur unerreichbar, solange PCR 16 diesen Wert trägt. Und jetzt der Punkt, auf den es mir ankommt: das ist keine Zugriffskontrolle im Betriebssystem. Da hat kein Dateisystem eine Berechtigung geprüft und kein Dienst eine Regel angewendet. Das ist eine Weigerung der Hardware. Sudo hilft hier nicht, weil root für diese Entscheidung überhaupt nicht zuständig ist.
Wer was misst, und was am Ende über das Entsiegeln entscheidet.
Und wenn ich das Register einfach zurücksetze?
Das ist die Frage, die jeder aufmerksame Leser an dieser Stelle stellt, und sie ist völlig berechtigt. Bei PCR 16 geht das tatsächlich, ohne Neustart.
Dasselbe Kommando gegen PCR 7 lehnt die Hardware ab.
# tpm2_pcrreset 7
ERROR: Esys_PCR_Reset(0x907) - tpm:warn(2.0): bad locality
ERROR: Could not reset PCR index: 7
ERROR: Unable to run tpm2_pcrreset
0x907 ist TPM_RC_LOCALITY. Der Chip unterscheidet, aus welcher Vertrauensstufe ein Kommando kommt, und root auf dem laufenden System hat die Locality, die zum Zurücksetzen eines Boot-Mess-Registers nötig wäre, gar nicht. Das ist der ganze Unterschied zwischen einem Debug-Register und einem Boot-Mess-Register, ausgedrückt in einer Fehlermeldung.
PCR 16 lässt sich zurücksetzen, PCR 7 nicht. Root ändert daran nichts.
Die Platte startet ohne Passphrase, aber nur mit PIN
Der Klassiker am Arbeitsplatz ist LUKS2 zusammen mit systemd-cryptenroll. Der Nutzen ist echt: das Notebook startet ohne Eingabe, und ein ausgebautes Laufwerk bleibt trotzdem verschlüsselt.
Ehrlichkeit an dieser Stelle: dieses Kommando habe ich nicht ausgeführt, und ich konnte es auch nicht. Die Maschine hat gar kein LUKS, die Wurzel liegt auf ZFS mit der ZFS-eigenen Verschlüsselung, aes-256-gcm. Der Befehl steht hier also als dokumentiertes Verfahren nach Manpage und nicht als Messung.
Das Wichtigste daran ist das --tpm2-with-pin=yes. Ohne PIN entsperrt sich das Gerät für jeden, der es einschaltet, und die Festplattenverschlüsselung schützt dann nur noch gegen den Ausbau der SSD, nicht gegen den Diebstahl des Rechners. Mit PIN greift die Lockout-Logik von weiter oben, und genau dadurch wird eine kurze PIN sicher.
Bei der Auswahl der PCRs gibt es dann einen echten Zielkonflikt, der meist verschwiegen wird.
Nur PCR 7 gebunden übersteht Kernel-Updates, misst aber im Kern nur den Secure-Boot-Zustand. Das ist wenig Aussage für viel Bequemlichkeit.
PCR 7 plus 11 gebunden, zusammen mit einem Unified Kernel Image, erfasst tatsächlich Kernel und initrd. Dafür bricht jedes Kernel-Update die Bindung, wenn man nicht mit signierter Policy arbeitet. Eine wichtige Präzisierung dazu, sonst erklärt man die Folgen falsch: PCR 11 ist kein reines Kernel-Register. systemd-stub misst dort das UKI hinein, danach schreibt systemd-pcrphase im Verlauf des Startvorgangs weitere Phasen-Messungen in dasselbe Register. Der Wert von PCR 11 hängt also davon ab, in welcher Boot-Phase man ihn liest, und genau darauf beruht der Trick, dass ein Geheimnis nur im initrd aufgeht und im laufenden System nicht mehr.
PCR 0 bis 7 gebunden ist die strengste Variante, und dann sperrt euch jedes BIOS-Update aus. Das ist der Grund, warum es systemd-pcrlock gibt, das die erwarteten Messwerte vorab berechnet und die Policy nachzieht. Dieselbe Manpage bezeichnet sich allerdings selbst noch als experimentell.
Wer welches Register wofür benutzt, hat die UAPI Group in einer PCR-Registry für Linux zusammengetragen. Das ist die Tabelle, die man beim Basteln offen haben will.
Eine Lücke betrifft ziemlich viele Linux-Nutzer, deshalb sage ich sie deutlich: systemd-cryptenroll und clevis luks bind schreiben beide in einen LUKS2-Header. Wer seine Wurzel auf ZFS-Native-Encryption hat, hat keinen. Upstream-ZFS bringt keine TPM-Integration mit. Ein TPM-gestütztes Entsperren bräuchte dort ein eigenes tpm2_unseal, das zfs load-key füttert, gebaut ins initramfs. Das ist eine echte offene Baustelle und kein Rezept, das ich hier nebenbei hinschreibe.
Ein SSH-Schlüssel, der keine Datei hat
Das ist mein Lieblings-Anwendungsfall am Arbeitsplatz, weil der Nutzen in einem Satz erklärt ist. Ein Angreifer mit Lesezugriff auf ~/.ssh bekommt nichts Verwendbares. Der Schlüssel kann die Maschine nicht verlassen. Er ist nicht gestohlen, er ist an das Blech gebunden.
Die CKA_ID wird pro Schlüssel erzeugt, bei euch steht dort etwas anderes. Den öffentlichen Teil holt man sich in einem Format, das sshd versteht, direkt über den PKCS#11-Provider.
Diese Zeile wandert wie gewohnt in authorized_keys. Und damit der Nachweis auch etwas wert ist, zeige ich ihn als Vorher und Nachher. Auf dieser Maschine liegt in /root/.ssh nämlich kein einziger privater Schlüssel, es gibt also keine zweite Erklärung für einen erfolgreichen Public-Key-Login.
# ls /root/.ssh/id_*
ls: cannot access '/root/.ssh/id_*': No such file or directory
# ssh -o BatchMode=yes root@localhost true
root@localhost: Permission denied (publickey,password).
Die PIN habe ich für diesen Test über SSH_ASKPASS nicht interaktiv geliefert, im Alltag fragt ssh einfach danach. Richtig sehenswert wird es aber mit -v, denn da erzählt OpenSSH selbst, mit welchem Bauteil es gerade arbeitet.
debug1: provider /usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so: manufacturerID <tpm2-software.github.io> cryptokiVersion 2.40 libraryDescription <TPM2.0 Cryptoki> libraryVersion 1.9
debug1: provider /usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so slot 0: label <ssh> manufacturerID <Infineon> model <SLB9670> serial <0000000000000000> flags 0x40d
debug1: Will attempt key: ECDSA SHA256:otJuTNX5LzFzJKqbTu9UoYROpZSXMMWIWMZUe02v1D4 token
debug1: Will attempt key: /root/.ssh/id_rsa
debug1: Will attempt key: /root/.ssh/id_ecdsa
debug1: Will attempt key: /root/.ssh/id_ed25519
debug1: Will attempt key: /root/.ssh/id_dsa
debug1: Offering public key: ECDSA SHA256:otJuTNX5LzFzJKqbTu9UoYROpZSXMMWIWMZUe02v1D4 token
debug1: Server accepts key: ECDSA SHA256:otJuTNX5LzFzJKqbTu9UoYROpZSXMMWIWMZUe02v1D4 token
Drei Sachen daran finde ich stark. Erstens nennt OpenSSH den Chip beim Namen, manufacturerID <Infineon> model <SLB9670>. Der SSH-Client sagt dir, welches Bauteil da gerade unterschreibt. Zweitens steht der TPM-Schlüssel in der Kandidatenliste mit dem Wort token, wo bei allen anderen ein Dateipfad steht, und diese Dateien existieren nicht einmal. Dieser Kontrast in einem Bildschirm ist das ganze Argument: dieser Schlüssel hat keine Datei. Drittens wird der Token-Schlüssel zuerst probiert, noch vor den nicht existierenden Dateien.
OpenSSH nennt Hersteller und Modell des Chips. Der Schlüssel steht als token in der Liste, alle anderen Kandidaten sind Dateien, die es nicht gibt.
Lasst mal kurz etwas heraus zoomen 😀 Meine Frau weist mich grade auf mein RBF hin. Wenn ich so konzentriert am Computer sitze und wie in diesem Fall etwas schreibe, dann schaue ich wohl meinen Monitor an, als wenn ich ihn gleich töten möchte. Tjo, und nun? Nun zoomen wir wieder ins Thema!
Die Zahl, die meine eigene Erwartung widerlegt hat
Meine Annahme vor der Messung war schlicht: eine ECDSA-Signatur kostet im Chip rund 97 Millisekunden, also merkt man beim Login nichts. Gemessen kommt etwas anderes heraus.
Weg
5 Logins
pro Login
Aufschlag
Schlüssel auf der Platte, Referenzwert
1,552 s
etwa 310 ms
Referenz
PKCS11Provider bei jedem Aufruf
8,013 s
etwa 1603 ms
etwa 1293 ms
Token einmal im ssh-agent
2,806 s
etwa 561 ms
etwa 251 ms
Die Ursache ist lehrreich. Bei PKCS11Provider baut ssh bei jedem einzelnen Login die komplette Kette neu auf: Store öffnen, Primary Key im TPM erzeugen, Kindschlüssel laden, signieren. Allein die Erzeugung des Primary Keys habe ich weiter oben mit 0,537 Sekunden gemessen. Die eigentliche Signatur ist damit der kleinste Posten in der Rechnung.
# ssh-add -s /usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so
Card added: /usr/lib/x86_64-linux-gnu/pkcs11/libtpm2_pkcs11.so
# ssh-add -l
256 SHA256:otJuTNX5LzFzJKqbTu9UoYROpZSXMMWIWMZUe02v1D4 /usr/lib/x86_64-linux-gnu/libtpm2_pkcs11.so.1.9.0 (ECDSA)
# time (for i in 1 2 3 4 5; do ssh root@localhost true; done)
real 0m2.806s
Mit ssh-add -s passiert diese Initialisierung einmal pro Sitzung statt einmal pro Verbindung, und die PIN wird auch nur einmal abgefragt. Zwei Gründe, dieselbe Empfehlung, also ganz klar: nehmt ssh-add -s und nicht PKCS11Provider bei jedem Aufruf.
Zur Messhygiene, wie immer: fünf Logins pro Zeile über Loopback, jeweils mit vollem Verbindungsaufbau und Prozessstart, kleine Stichprobe, keine Streuung berechnet. Das sind Größenordnungen und keine Benchmarks.
Der Nebeneffekt, den niemand erwähnt
Diesen Punkt habe ich selbst erst beim Aufräumen gemerkt, und jeder, der dem SSH-Abschnitt folgt, läuft hinein. tpm2_ptool init legt stillschweigend einen Primary Key an und macht ihn persistent im Chip. Vor der Demo waren drei persistente Handles belegt, danach vier.
Und jetzt zurück zu einer Zahl von weiter oben: TPM2_PT_HR_PERSISTENT_MIN ist auf diesem Chip 0x7. Garantiert sind also nur sieben persistente Plätze, und drei davon waren schon vorher weg. Wer bei jedem Basteln ein Handle liegen lässt, macht den Chip irgendwann voll. Den eigenen Müll findet und räumt man so weg:
Dazu eine Warnung, die ich nicht deutlich genug schreiben kann: räumt niemals Handles weg, die ihr nicht selbst angelegt habt. Die drei anderen lagen auf meinem Gerät schon vorher dort, vermutlich aus der Hersteller-Provisionierung oder aus einem früheren Windows-Leben. Wer einen fremden Primary Key entfernt, vernichtet alles, was darunter versiegelt war. Der sichere Weg führt über den Token-Store, denn dort steht das Handle drin, das zum eigenen Werkzeug gehört. Bei mir war es genau das 0x81000000 aus der Ausgabe oben, und ich habe vor dem Entfernen im Store nachgesehen, statt der Reihenfolge zu vertrauen.
Schlüssel im Chip, benutzt über OpenSSL
Für alles, was kein PKCS#11 spricht, gibt es den OpenSSL-3-Provider. Der schönste Moment daran ist ein PEM-Header.
Diese Datei enthält keinen privaten Schlüssel. Sie enthält einen Blob, den ausschließlich dieser eine Chip auspacken kann. Kopiert die Datei auf eine andere Maschine und sie ist wertlos. Signieren geht im Chip, prüfen geht überall.
Zum Prüfen habe ich nur den Standard-Provider gebraucht. Es ist eine ganz normale ECDSA-Signatur, die Gegenseite muss von einem TPM überhaupt nichts wissen. Deshalb lässt sich das in bestehende PKI einbauen, ohne irgendetwas umzustellen, und damit gehen Client-Zertifikate für VPN, 802.1X, mTLS und auch AWS IAM Roles Anywhere.
Der Zufallsgenerator, ehrlich klein geredet
Auf diesem System ist der TPM tatsächlich der Hardware-Zufallsgenerator, den der Kernel benutzt.
Der Nutzen davon ist vorhanden, aber klein. Moderne CPUs haben RDRAND, der Kernel hat einen guten Entropiepool, und rund 67 Millisekunden pro tpm2_getrandom-Aufruf sind für nichts geeignet, was Durchsatz braucht. Als zusätzliche, unabhängige Quelle im Pool ist es geschenkt und in Ordnung. Mehr würde ich daraus nicht machen.
Fernattestierung, der eigentliche große Fall
Auf Servern liegt der größere Nutzen, nicht am Arbeitsplatz. Das Problem zuerst: bei einer Kiste im Rechenzentrum oder in der Colo weiß man normalerweise nicht, ob sie noch die Software fährt, die man dort installiert hat. Alles, was man fragen kann, ist der Server selbst. Und wenn er kompromittiert ist, lügt er.
Der TPM löst das, weil er eine Aussage über den Startvorgang signiert, die das Betriebssystem nicht fälschen kann. Zwei Schlüssel braucht es dafür: den Endorsement Key als Chip-Identität und einen Attestierungsschlüssel, mit dem tatsächlich signiert wird.
Der qualified name ist didaktisch schön, weil er die Abstammung des Schlüssels von seinem Elternschlüssel mit einbezieht. Jetzt das Quote, mit einer Nonce, die sich der Prüfer ausdenkt. Ich nehme deadbeef in Hex.
Der quoted-Blob sieht wie Rauschen aus, ist aber lesbar, wenn man weiß wo man hinschaut.
ff544347 ist die Konstante TPM_GENERATED_VALUE und markiert die Struktur als im TPM entstanden. Wichtig für das Verständnis: sie allein verhindert keine Fälschung. Der Schutz entsteht daraus, dass ein Attestierungsschlüssel ein restricted Signaturschlüssel ist, der nur Daten unterschreibt, die der Chip selbst erzeugt hat. Diese Konstante ist das Erkennungsmerkmal dafür und nicht der Mechanismus.
8018 ist TPM2_ST_ATTEST_QUOTE, der Strukturtyp.
6465616462656566 ist meine Nonce, unverändert zurück. Genau das schlägt einen Replay.
07003f000d1900 ist die Firmware-Version, die in jedem Quote mitläuft. Das ist wieder die 7.63 von oben.
Geprüft wird offline, und zwar mit nichts als dem öffentlichen Attestierungsschlüssel.
Der Ablauf einer Attestierung. Der Prüfer glaubt dem Knoten nichts, er rechnet nach.
Die Lücke, die fast jedes Howto verschweigt
Und hier muss ich mich selbst bremsen, denn die Versuchung ist groß, die beiden vorherigen Abschnitte einfach nebeneinanderzulegen und „echte Hardware bestätigt echten Bootzustand“ daraus zu machen. Das wäre eine Beweiskette mit einem Loch in der Mitte.
tpm2_checkquote mit dem öffentlichen Attestierungsschlüssel beweist genau eine Sache: irgendjemand, der diesen Schlüssel besitzt, hat dieses Quote signiert. Es beweist nicht, dass dieser Schlüssel in demselben Chip steckt, dessen Infineon-Zertifikat ich weiter oben gezeigt habe.
Die fehlende Verbindung heißt Credential Activation. Der Prüfer verschlüsselt dabei ein Geheimnis so, dass es nur ausgepackt werden kann, wenn Endorsement Key und Attestierungsschlüssel im selben TPM liegen, klassisch über TPM2_MakeCredential auf der Prüferseite und TPM2_ActivateCredential auf der Knotenseite. Erst wenn der Knoten das Geheimnis zurückmelden kann, ist bewiesen, dass der Schlüssel zu diesem zertifizierten Chip gehört. Alternativ stellt eine Attestierungs-CA ein echtes AK-Zertifikat aus, nachdem sie diese Prüfung einmal gemacht hat. Wie das im Detail aussieht, steht in RFC 9683. Diesen Schritt habe ich hier nicht durchgeführt. Gemessen sind Quote und Signaturprüfung, die Bindung ist dokumentiertes Verfahren.
Keylime, vier Rollen und ein Prüfer der nicht aufhört
Genau diesen Schritt macht Keylime, und genau deshalb ist Keylime mehr als ein Skript um tpm2_quote herum. Die Architektur hat vier Rollen: einen Agent auf dem Knoten, einen Registrar, einen Verifier und einen Tenant. Der Agent schickt Event-Log, IMA-Hashes und Measured-Boot-Daten, der lokale TPM bürgt für die Echtheit, und über das EK-Zertifikat lässt sich beweisen, dass es überhaupt ein echter TPM ist. Der Verifier prüft dann fortlaufend und nicht nur einmal beim Start.
Damit das nicht nach Bastelei klingt: Keylime läuft in der IBM Cloud als Teil der Compliance-Anforderungen für FedRAMP und HITRUST, und SUSE dokumentiert es offiziell für SUSE Linux Micro. Das ist kein Laborspielzeug.
IMA und EVM, zwei Dinge die ständig verwechselt werden
Beide gehören zur Laufzeit-Integrität, machen aber Verschiedenes.
IMA, die Integrity Measurement Architecture, hasht Dateien beim Zugriff. Im Messmodus schreibt sie die Hashes in ein Kernel-Log und erweitert damit PCR 10. Im Appraisal-Modus verweigert sie zusätzlich die Ausführung, wenn Hash oder Signatur nicht passen.
EVM schützt die zugehörigen erweiterten Attribute, also die Sicherheits-Metadaten der Datei, mit einem HMAC oder einer Signatur. Ohne EVM könnte ein Angreifer mit Schreibrechten die IMA-Attribute einfach mitfälschen.
Der TPM-Bezug liegt bei IMA und bei PCR 10. Eine veränderte Binärdatei erzeugt eine Messung, die im TPM landet und rückwirkend nicht mehr zu entfernen ist, weil PCRs nur wachsen. Zusammen mit Secure Boot und Measured Boot entsteht so eine Kette von der Firmware bis zur einzelnen ausgeführten Datei. Ohne TPM wäre dieses Logbuch fälschbar, mit TPM nicht.
Verschlüsselte Server, die allein neu starten können
Operativ ist das der handfesteste Nutzen im Rechenzentrum. Ein verschlüsselter Server, der nach einem Reboot auf eine Passphrase wartet, ist ein Betriebsproblem, spätestens um drei Uhr nachts. Mit TPM-Bindung startet er durch. Der Zielkonflikt dahinter ist eine echte Architekturentscheidung.
TPM allein. Der Server startet ohne Menschen. Wer den ganzen Server stiehlt, bekommt einen Server, der sich selbst entsperrt.
Tang und Clevis, netzgebunden. Entsperrt nur, wenn der Server einen Tang-Server im eigenen Netz erreicht. Aus dem Rack getragen bleibt er zu. Braucht dafür einen erreichbaren Tang-Server, was beim Kaltstart eines ganzen Rechenzentrums ein Henne-Ei-Problem ist.
Beides kombiniert über Shamir Secret Sharing in Clevis, also zum Beispiel TPM und Tang zusammen.
Meine Empfehlung, und die ist unspektakulär: im eigenen Rack mit eigenem Netz nehmt Tang plus TPM über Clevis, weil dann beide Bedingungen gleichzeitig gelten müssen. Bei einer einzelnen Kiste in fremder Colo nehmt TPM mit PIN und tippt die eben ein, wenn es tatsächlich einen Kaltstart gibt. Ein Server, der sich ohne jede Bedingung selbst entsperrt, ist Verschlüsselung fürs Protokoll und nicht gegen einen Angreifer.
Maschinenidentität, die man nicht in eine VM klonen kann
Ein Schlüssel der die Maschine nicht verlassen kann ist eine Identität, die man nicht mitkopieren kann. Für Zero-Trust-Architekturen ist das der interessante Teil: SPIRE hat dafür einen TPM-Node-Attestor, und für Kubernetes-Knoten, die sich beim Beitritt beweisen sollen, ist das der saubere Weg. Verglichen mit einem Token in einer Cloud-Init-Datei, das jeder mitlesen und in eine beliebige VM kopieren kann, ist das ein anderes Sicherheitsniveau.
Ein TPM für jede VM, und was er nicht leistet
Ein physischer TPM hat genau eine Instanz und lässt sich nicht sinnvoll auf viele Gäste aufteilen. Die Lösung ist ein virtueller TPM pro VM. swtpm stellt dafür eine TPM-2.0-Implementierung im Userspace bereit, QEMU und libvirt binden sie als Gerät in die VM ein. Der Gast sieht ein ganz normales /dev/tpm0 und braucht keine Anpassung. Der Kernel bringt dazu den vTPM-Proxy-Treiber mit, /dev/vtpmx, über den Container und VMs eigene TPM-Instanzen bekommen. Genau so machen es die Cloud-Anbieter, und genau so kommt Windows 11 in einer VM überhaupt an seine TPM-2.0-Voraussetzung.
Die ehrliche Einordnung gehört dazu, weil das in Cloud-Architekturen regelmäßig falsch verstanden wird. Ein vTPM ist Software. Sein Zustand liegt als Datei auf dem Hypervisor. Wer den Hypervisor kontrolliert, kontrolliert den vTPM, und ein Angreifer mit root auf dem Host kann den Schlüsselzustand kopieren. Ein vTPM löst also das Problem „der Gast braucht ein TPM-Interface“, er liefert aber keine Hardware-Vertrauenswurzel für den Gast. Wer echte Attestierung einer VM will, braucht eine Kette, die beim TPM des Hosts beginnt, oder Confidential-Computing-Technik wie AMD SEV-SNP oder Intel TDX.
Zum Schluss noch ein kleiner Anwendungsfall, der technisch nichts Neues ist und praktisch viel bringt: die Datenbank-Zugangsdaten eines Dienstes so versiegeln, dass sie nur auf dieser Maschine und nur in diesem Bootzustand aufgehen. Derselbe Seal-Mechanismus wie oben, nur mit einem anderen Geheimnis. Ein kopiertes Image oder eine in eine VM gehobene Platte bringt die Zugangsdaten dann nicht mit.
Was geht, aber nichts bringt
Dieser Abschnitt ist mir genauso wichtig wie der Nutzen-Teil, also kürze ich ihn nicht ab. Zuerst das Missverständnis, das sich am leichtesten messen lässt.
1. Der TPM als Krypto-Beschleuniger. Gemessen und erledigt.
Operation
Wo
Zeit
RSA-2048-Schlüssel erzeugen
TPM
19,703 s
RSA-2048-Schlüssel erzeugen
CPU, openssl
0,220 s
ECC-P-256-Primary erzeugen
TPM
0,537 s
ECDSA P-256 signieren, 50 mal
TPM
4,862 s
ECDSA P-256 signieren, 50 mal
CPU, openssl
0,286 s
# time tpm2_createprimary -C o -g sha256 -G rsa2048 -c rsa_primary.ctx
real 0m19.703s
user 0m0.039s
sys 0m0.016s
# time openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:2048 -out /dev/null
real 0m0.220s
user 0m0.210s
sys 0m0.010s
Rund 90 mal langsamer bei der RSA-Schlüsselerzeugung. Ein Detail zur Messhygiene ist mir dabei wichtig: während der 19,7 Sekunden liegen user und sys bei 0,039 und 0,016 Sekunden. Die CPU langweilt sich also, die Zeit vergeht wirklich im Chip. Das ist eine Messung des TPM und nicht des Prozess-Overheads.
Die richtige Schlussfolgerung ist nicht, dass der TPM schlecht wäre, sondern dass er kein Beschleuniger ist und nie einer war. Das ist die interessante Kehrseite zu der Krypto-Beschleunigerkarte, die ich neulich gegen dieselbe Klasse moderner CPU gemessen habe. Dort verlor Spezial-Hardware, die schnell sein wollte. Hier verliert sie noch deutlicher, nur ist das kein Befund, sondern die Bauart. Der TPM wollte nie schnell sein, er wollte stur sein.
2. Massendaten im TPM verschlüsseln. Es gibt keinen Datenpfad dafür, und bei den Zahlen von oben erübrigt sich die Diskussion.
3. LUKS nur am TPM, ohne PIN. Technisch drei Minuten Arbeit. Ergebnis ist ein Notebook, das sich für jeden entsperrt, der den Deckel aufmacht. In Kombination mit dem Bus-Sniffing weiter unten ist das nahe an Sicherheitstheater. Wer die Passphrase-Eingabe loswerden will, nimmt die PIN.
4. Der TPM als Passwortspeicher oder Secret Store. Ein einzelner NV-Index kann auf diesem Chip höchstens 1664 Bytes halten, und es gibt genau 8 NV-Zähler. NV im TPM ist Flash mit begrenzten Schreibzyklen und als Ablage für Inhalte nicht gedacht. Der richtige Weg ist immer derselbe: die Geheimnisse liegen verschlüsselt auf der Platte, und nur der Schlüssel dafür wird im TPM versiegelt. Genau das tun systemd-cryptenroll und Clevis auch.
5. Sealing gegen PCR 0 bis 7 auf einem Gerät, das Firmware-Updates bekommt. Jedes BIOS-Update ändert die Messungen und sperrt euch aus. Ein Fall, in dem die Technik funktioniert und die Betriebspraxis daran zerbricht. Der Ausweg heißt signierte Policies und systemd-pcrlock, und im selben Atemzug gehört dazu, dass sich systemd-pcrlock selbst noch als experimentell bezeichnet.
6. Attestierung ohne unabhängigen Prüfer. Ein Quote, das auf derselben Maschine geprüft wird, beweist nichts. Wenn die Maschine übernommen ist, ist die Prüfung übernommen. Attestierung ergibt nur mit einem separaten Verifier und mit bekannten Referenzwerten Sinn. Sehr viele Aussagen der Art „wir nutzen TPM“ sind bei genauem Hinsehen genau das, eine Selbstprüfung.
7. TPM 1.2 im Jahr 2026. SHA-1 und RSA-2048, kein ECC, keine Algorithmen-Agilität, ein völlig anderer Software-Stack, nämlich TrouSerS statt tpm2-tss. Wer noch einen findet, sollte darauf nichts Neues bauen.
8. Die Erwartung, ein TPM schütze ein laufendes System. Das ist das größte Missverständnis, deshalb steht es hier noch einmal als eigener Punkt. Ein TPM schützt Schlüssel im Ruhezustand und misst den Start. Er tut nichts gegen einen Angreifer, der schon im Kernel sitzt, denn der fragt den Chip einfach ganz normal.
Fünf häufige Vorhaben und die kurze Antwort dazu.
Die Grenzen, und die Angriffe die es wirklich gibt
Ohne diesen Abschnitt wäre der Beitrag Werbung. Der Kern des Problems bei diskreten Chips ist unangenehm einfach: nach dem Entsiegeln gibt der TPM das Geheimnis über den Bus heraus, und klassisch liegt es dort im Klartext. Wer LPC oder SPI anzapft, liest den Schlüssel mit. Für BitLocker ist das seit Jahren praktisch demonstriert, und es ist ausdrücklich nicht auf Windows beschränkt. Securitum hat im September 2024 in einem echten Penetrationstest genau das gegen ein Linux-System mit LUKS und Clevis gezeigt.
Das betrifft mein Testsystem direkt, und ich schreibe das lieber offen hin, als es zu verstecken: der SLB 9670 ist ein diskreter Chip auf dem Board. Der Angriff braucht physischen Zugriff und Löterfahrung, aber er ist kein Papier-Szenario.
Die Gegenmaßnahme kann TPM 2.0 von sich aus: Sessions mit HMAC-Absicherung und Parameter-Verschlüsselung, und systemd benutzt das inzwischen. Die Grenze davon wird oft zu großzügig beschrieben, deshalb genau: das ist keine Vollverschlüsselung des Bus-Protokolls. Parameter Encryption schützt gezielt einzelne sensible Parameter in Kommandos und Antworten, also genau die Stelle, an der ein entsiegelter Schlüssel herauskäme. Kommandocodes, Handles und die übrigen Parameter bleiben sichtbar. Gegen das passive Mitlesen des Schlüssels ist es wirksam, gegen Verkehrsanalyse nicht, und gegen einen aktiven Interposer hilft es nur insofern, als die HMAC-Absicherung Manipulationen auffallen lässt. Der Kernel hat zu dieser Interposer-Frage eine eigene Dokumentationsseite. Und noch eine Einschränkung, die systemd selbst dokumentiert: die Art der Einbindung entwickelt sich weiter, alte Enrollments profitieren nicht rückwirkend. Wer vor Jahren enrolliert hat, sollte das neu machen.
Und dann eine Ironie, die zeigt wie dünn das Eis ist: CVE-2023-1017 saß genau in CryptParameterDecryption, also in dem Code, der diese verschlüsselten Parameter auspackt. Die Schutzfunktion war selbst der Angriffsweg.
Wer jetzt denkt, ein fTPM in der CPU sei automatisch besser, hat nur andere Probleme. faulTPM hat gezeigt, dass sich AMDs fTPM über Spannungs-Glitching am Platform Security Processor angreifen lässt. Und TPM-Fail demonstrierte 2019 Timing-Seitenkanäle, mit denen sich private ECDSA-Schlüssel rekonstruieren ließen, und zwar aus Intel PTT (CVE-2019-11090) und aus dem ST33 von STMicroelectronics (CVE-2019-16863). Zwei Details daran tragen den Punkt: der lokale Angriff auf Intels fTPM brauchte je nach Zugriffsrechten 4 bis 20 Minuten, und der ST33 trug eine Common-Criteria-Zertifizierung nach EAL 4+, die Schutz gegen Seitenkanäle ausdrücklich einschließt. Ein Zertifikat ist also kein Beweis.
Auch die Referenz-Implementierung selbst hatte Löcher. CVE-2023-1017 war ein Out-of-bounds-Write, CVE-2023-1018 ein Out-of-bounds-Read, beide in der TPM-2.0-Module-Library, also im Referenzcode der TCG. Betroffen waren dadurch gleichzeitig Software-TPMs wie libtpms und eine Reihe von Hardware-TPMs, deren Firmware auf diesem Code aufbaut. Gefunden hat sie Quarkslab und meldete sie im November 2022. Zwei Bytes über den Puffer hinaus, im ungünstigen Fall Codeausführung im TPM-Kontext, also genau in dem Bauteil, dessen einzige Aufgabe es ist, eine Vertrauensgrenze zu ziehen.
Was bleibt also unterm Strich: ein TPM hebt die Messlatte von „Platte ausbauen und kopieren“ auf „an das Board löten oder den SoC glitchen“. Das ist ein echter Fortschritt und kein magischer Schild. Mit PIN wird es deutlich stärker, weil dann die Lockout-Logik greift und Bus-Sniffing allein nicht mehr reicht.
Der Zustand dieses Testsystems, unbequem und aufschlussreich
Und jetzt der Teil, der mir selbst am meisten zu denken gibt. Der Chip in diesem Notebook arbeitet einwandfrei, wie alles hier oben zeigt. Benutzt wird er von diesem System für praktisch nichts.
Baustein
Zustand
Secure Boot
aus, und als 00 in PCR 7 gemessen
Wurzel-Dateisystem
ZFS-Native-Encryption, aes-256-gcm, nirgends LUKS
systemd-cryptenroll
vorhanden, systemd 255.4, ohne LUKS2 aber nutzlos
clevis
nicht installiert, würde hier auch nicht helfen
Unified Kernel Image
nicht im Einsatz
systemd-pcrextend.socket
übersprungen, ConditionSecurity=measured-uki nicht erfüllt
systemd-pcrmachine.service
übersprungen, dieselbe Bedingung
systemd-tpm2-setup-early.service
übersprungen, dieselbe Bedingung
die elf systemd-pcrlock-*-Units
alle disabled
TPM als /dev/hwrng
aktiv, tpm-rng-0
Die drei übersprungenen Units sind der interessanteste Eintrag in dieser Tabelle. Die Bedingung ConditionSecurity=measured-uki prüft nicht das Dateiformat, sondern den Bootweg. Weil dieses System nicht als gemessenes Unified Kernel Image über systemd-stub gestartet ist, überspringt systemd die halbe TPM-Infrastruktur einfach lautlos, ohne Fehler und ohne Warnung. Das ist genau die These aus der Einleitung, jetzt belegt: der Chip ist da, er funktioniert, und die Distribution benutzt ihn nicht.
Der Event-Log, und die Falle mit ls
Zum Abschluss noch eine Kleinigkeit, über die ich zuerst gestolpert bin. Der Event-Log, dessen Adresse die Firmware ganz oben in der ersten dmesg-Zeile übergeben hat, liegt im securityfs. Und ls behauptet, die Datei sei leer.
# ls -la /sys/kernel/security/tpm0/
total 0
-r--r----- 1 root tss 0 Aug 10 09:30 binary_bios_measurements
# tpm2_eventlog /sys/kernel/security/tpm0/binary_bios_measurements | grep -c EventNum
120
Null Bytes laut ls, und trotzdem 120 Events darin. securityfs gibt für diese Datei einfach keine Größe an. Was in den 120 Einträgen steckt, sortiert sich so:
Da steht der Secure-Boot-Zustand meiner Maschine als 00 im Log, und gehasht wandert genau dieser Wert in PCR 7. Das ist die Brücke zwischen dem Firmware-Setup und dem Chip: was ihr im BIOS umschaltet, wird gemessen und landet im TPM. Schaltet Secure Boot ein, und PCR 7 ändert sich. Alles, was gegen PCR 7 versiegelt war, geht danach nicht mehr auf. Wer den Zusammenhang einmal so gesehen hat, versteht auch, warum die Wahl der PCRs weiter oben ein Zielkonflikt ist und keine Geschmacksfrage.
Eine Nebenbemerkung, weil sie so schön zeigt, wie Secure-Boot-PKI in der Praxis funktioniert: im Log steckt auch der Platform Key des Boards, ein „Fujitsu ODM Quanta BIOS PK Certificate“, gültig von August 2012 bis August 2022. Es ist also seit Jahren abgelaufen. Die Firmware interessiert sich nicht dafür.
Was offen bleibt
Ob der SLB 9670 auf diesem Board über LPC oder über SPI angebunden ist. Aus dem Betriebssystem heraus nicht entscheidbar.
Warum der Login über PKCS11Provider rund 1,3 Sekunden Aufschlag kostet, ist plausibel erklärt, aber nicht einzeln nachgemessen. Ein strace oder ein Trace über tpm2_ptool würde es belegen.
systemd-cryptenroll mit LUKS2 konnte ich nicht testen, weil hier kein LUKS existiert.
Keylime habe ich nicht aufgesetzt. Die Beschreibung stützt sich auf Dokumentation von SUSE, Red Hat und dem Keylime-Projekt.
Die Bindung des Attestierungsschlüssels an den zertifizierten EK, also TPM2_MakeCredential und TPM2_ActivateCredential, habe ich nicht durchgeführt. Gemessen sind nur Quote und Signaturprüfung.
Wie viel NV-Speicher der SLB 9670 insgesamt hat, habe ich nicht ermittelt. NV_INDEX_MAX beantwortet diese Frage nicht.
Kein vTPM aufgesetzt. Der Abschnitt dazu ist dokumentiert und nicht gemessen.
Ob verschlüsselte TPM-Sessions Bus-Sniffing auf diesem konkreten Chip vollständig verhindern, habe ich nicht überprüft. Dafür bräuchte es einen Logic Analyzer.
Ein TPM-gestütztes Entsperren einer ZFS-Native-Encryption-Wurzel habe ich nicht gebaut.
Wie sich PCR 7 auf diesem Gerät nach dem Aktivieren von Secure Boot verändert. Das wäre ein naheliegender zweiter Teil.
Wenn ich hier etwas falsch dargestellt habe, oder wenn ihr einen der offenen Punkte schon gelöst habt, dann korrigiert mich gerne. Dann lerne ich selbst etwas. Ihr dürft mich dazu jederzeit fragen.
Und weil mich das wirklich interessiert: setzt ihr den TPM-Chip selbst ein, ignoriert ihr ihn bisher, oder nutzt ihr ihn eher zufällig?
Im letzten Beitrag ging es darum, die BIOS-Einstellungen meines Supermicro X12SPi-TF überhaupt erst als Datei in die Hand zu bekommen. Das Ergebnis war eine XML mit 372 Einstellungen, und der Weg dorthin führte über eine Lizenz für 28,17 Euro.
Damit war die halbe Arbeit getan. Eine Konfiguration auslesen zu können ist schön, aber der eigentliche Gewinn liegt darin, sie auch zurückschreiben zu können. Genau das habe ich jetzt gemacht, und zwar zum ersten Mal überhaupt an dieser Maschine: sieben Einstellungen geändert, ohne den Rechner ins Setup zu booten, ohne Tastatur, ohne die Fernkonsole des Management-Controllers.
Vorweg die gute Nachricht für alle, die schon rechnen: die kleine Lizenz deckt das Schreiben mit ab. Ich hatte damit gerechnet, dass Supermicro genau an dieser Stelle noch einmal die Hand aufhält, und das tut es auch, aber nur an einer sehr kleinen Ecke. Von den 372 Einstellungen tragen 21 den Vermerk, dass sie die große Lizenz verlangen. Es sind ausschliesslich Zertifikatseinträge für KMIP-Server und HTTPS-Boot. Nichts davon betrifft normale Setup-Optionen.
Was ich ändern wollte, und warum
Der langweiligste Teil eines solchen Artikels ist die Liste der geänderten Werte. Der interessante Teil ist die Begründung, deshalb fange ich damit an.
Mein Rechner bootet von einer NVMe-SSD. Er hat das noch nie anders gemacht und wird es auch nicht. Trotzdem lädt das BIOS bei jedem Start die Pre-Boot-Netzwerktreiber für vier Netzwerkanschlüsse, jeweils für IPv4 und IPv6, und baut daraus Boot-Einträge, die niemand benutzt. Dazu kommen die Option-ROMs von drei leeren Steckplätzen.
Ein Option-ROM ist ein kleines Stück Firmware auf einer Steckkarte, das beim Start ins BIOS geladen wird, damit die Karte schon vor dem Betriebssystem funktioniert. Für eine Netzwerkkarte heisst das Netzwerk-Boot, für einen Speichercontroller das Booten von daran angeschlossenen Platten. Wer von keinem dieser Geräte bootet, braucht den Code nicht.
Also:
– Network Stack von *Enabled* auf *Disabled*. Damit fällt die komplette UEFI-Netzwerkinitialisierung weg. – Onboard LAN1 Option ROM aus. Der Pre-Boot-Treiber der onboard X550 wird nicht gebraucht. – CPU SLOT6 OPROM aus. Dort steckt meine X710. Dazu gleich mehr, das ist der eigentliche Grund für die Aktion. – CPU SLOT1, SLOT2 und SLOT7 OPROM aus. Alle drei Steckplätze sind leer.
Bei den drei leeren Steckplätzen bin ich ehrlich: der Zeitgewinn ist exakt null. Wo keine Karte steckt, gibt es auch kein Option-ROM zu laden. Ich habe sie trotzdem mitgenommen, weil ich einen dokumentierten Sollzustand haben will und nicht eine Mischung aus bewusst gesetzt und zufällig übrig.
Die siebte Änderung ist die, um die es mir wirklich ging.
Die eine Zeile, die eine Woche Rätselraten beendet hat
Beim Schreiben meiner BIOS-Serie ist mir etwas aufgefallen, das ich mir lange nicht erklären konnte. Mein Prozessor ist ein Xeon Gold 5315Y, Ice Lake-SP. Diese Generation beherrscht Hardware P-States, kurz HWP. Die CPU regelt ihren Takt dabei selbst, in feineren Stufen und deutlich schneller, als das Betriebssystem es könnte.
Nur meldete mein Kernel davon nichts. In /proc/cpuinfo fehlte das hwp-Flag, der Treiber intel_pstate lief im passiven Modus, und die Taktregelung machte der Governor schedutil. Also genau der Zustand, den man auf einer CPU erwartet, die HWP gar nicht kann.
Ich habe eine Weile in Richtung Kernel gesucht. Das war die falsche Richtung. Der Schalter sass im BIOS, ziemlich tief vergraben:
Advanced > CPU Configuration > Advanced Power Management Configuration
> Hardware PM State Control > Hardware P-States [Disable]
Der Auslieferungszustand dieser Option ist tatsächlich *Disable*. Es gibt vier Werte, und der Hilfetext im BIOS beschreibt sie so:
Disable hardware will choose a P-state setting for
the system based on an OS request
Native Mode hardware will choose a P-state setting
based on OS guidance
Native Mode with No Legacy Support hardware will choose a P-state setting
independently without OS guidance
Out of Band Mode hardware autonomously choose a P-state
without OS guidance
Ich habe Native Mode genommen, also die zahmste der drei aktiven Varianten. Der Unterschied zu den beiden anderen ist wichtig: bei *Native Mode* behält das Betriebssystem seinen Einfluss, es wandert nur die Feinsteuerung in die CPU. Bei den beiden anderen wird der Kernel bei der Taktwahl übergangen, und dann kann er dir auch nicht mehr sinnvoll sagen, was die CPU gerade tut.
Was ich bewusst nicht angefasst habe
Diese Liste finde ich wichtiger als die Liste der Änderungen, denn hier hätte ich mir den Rechner unbedienbar machen können.
Das Option-ROM von SLOT4 bleibt an. Dort sitzt die Grafikkarte. Ihr GOP-Modul ist das, was beim Start überhaupt ein Bild auf den Monitor bringt. Wer es abschaltet, sitzt bis zum Laden des Grafiktreibers im Dunkeln, und wenn dabei etwas schiefgeht, sitzt er dauerhaft im Dunkeln.
Onboard Video Option ROM bleibt an. Das ist die Grafik des Management-Controllers, und daran hängt die Fernkonsole. Schaltet man sie ab, bleibt beim Start das Fenster schwarz, über das man aus der Ferne ins Setup kommt. Das ist genau der Rettungsweg, den man sich nicht abschneiden will, wenn man gerade anfängt, das BIOS aus dem laufenden Betrieb heraus umzukonfigurieren.
Beide NVMe-Option-ROMs bleiben an. Das erste trägt das Betriebssystem. Auf das zweite soll irgendwann Windows, und auch wenn der Bootloader auf der ersten Platte das Kommando behält, muss die zweite dem Firmware-Bootmanager sichtbar bleiben.
Legacy USB Support bleibt an. Hier hätte ich vermutlich etwas Startzeit gewinnen können. Ich habe es gelassen, weil ich den Gewinn nicht gemessen habe und das Risiko eine tote Tastatur im Setup wäre. Eine Einstellung, deren Nutzen man nicht beziffern kann, deren Schaden aber konkret ist, ändert man nicht.
Der Weg: eine Teildatei, nicht die ganze
Naheliegend wäre, die ausgelesene XML zu bearbeiten und komplett zurückzuschreiben. Bei 372 Einstellungen und 260 Kilobyte ist das unnötig riskant, und es ist auch nicht der vorgesehene Weg.
Das Werkzeug kennt einen Filter, der genau die Einstellungen ausgibt, die vom Auslieferungszustand abweichen:
Heraus kommt eine kleine Datei mit derselben Struktur wie die grosse, nur eben mit den Menüzweigen, die auch wirklich etwas enthalten. Und genau diese Struktur nimmt das Schreibkommando entgegen. Teildateien sind also kein Trick, sondern der normale Betriebsfall.
Hier der erste Fallstrick, und der hat mich ehrlich geärgert: die eingebaute Hilfe des Werkzeugs beschreibt den Filter als Ziffer.
--filter Sets filter type to: 1 = nondefault
Die Ziffer 1 wird abgewiesen. Das Kommando bricht ab und wirft den Hilfetext aus, der einem gerade die Ziffer empfohlen hat. Akzeptiert wird ausschliesslich das ausgeschriebene Wort nondefault. Wenn du also an dieser Stelle hängst, liegt es nicht an dir.
Meine Änderungsdatei habe ich nicht getippt, sondern mit einem kleinen Python-Skript aus dem Auslesestand erzeugt. Das klingt nach Übertreibung für sieben Werte, hat aber einen handfesten Grund: die Einstellungen müssen im richtigen Menüzweig stehen, und die Menünamen sind lang und fehleranfällig. CPU SLOT2 PCI-E 4.0 X8(IN X16) OPROM vertippt sich schneller, als man denkt, und ein Tippfehler im Namen führt nicht zu einer Fehlermeldung, sondern dazu, dass die Einstellung stillschweigend nicht gesetzt wird.
Das Schreiben selbst ist unspektakulär:
./saa -c ChangeBiosCfg --file change-boot-oprom-hwp.xml
Status: The BIOS configuration is updated for the managed system
Note: You have to reboot or power up the system for the changes to take effect.
Es gibt eine Option --reboot, die den Neustart gleich mit erledigt. Die habe ich weggelassen. Wann ein Rechner neu startet, entscheide ich lieber selbst.
Der zweite Fallstrick, und der ist gemein
Nach dem Schreiben will man natürlich nachsehen, ob es geklappt hat. Also dasselbe Auslesekommando noch einmal, und dann steht da:
Der erste Reflex ist, das Schreibkommando noch einmal laufen zu lassen. Tu das nicht. Das Auslesen liefert die aktive Konfiguration, und die ändert sich erst beim nächsten Start. Deine Änderung liegt so lange in einem Bereich, den das Werkzeug nicht anzeigt. Zwischen dem Schreiben und dem Neustart gibt es damit keine Möglichkeit, die Änderung zu überprüfen, ausser dem Rückgabewert des Kommandos.
Das ist unschön, aber es ist logisch. Die Einstellungen werden erst beim Start aus dem Speicher gelesen, und vorher gibt es schlicht nichts Aktives, das anders wäre.
Nach dem Neustart
Und dann stimmt alles. Die Zahl der Abweichungen vom Auslieferungszustand ist von sechs auf dreizehn gestiegen, also genau um meine sieben:
Quiet Boot Unchecked
Restore on AC Power Loss Stay Off
Power Button Function 4 Seconds Override
Hardware P-States Native Mode
Network Stack Disabled
Re-Size BAR Support Enabled
VGA Priority Offboard
CPU SLOT1 PCI-E 4.0 X8 OPROM Disabled
CPU SLOT2 PCI-E 4.0 X8(IN X16) OPROM Disabled
CPU SLOT6 PCI-E 4.0 X16 OPROM Disabled
CPU SLOT7 PCI-E 4.0 X8 OPROM Disabled
Onboard LAN1 Option ROM Disabled
WHEA Support Disabled
Die Netzwerk-Booteinträge sind verschwunden, übrig bleibt der Bootloader und die eingebaute Shell:
Der Treiber ist damit vom passiven in den aktiven Modus gewechselt. Was dabei kurz irritiert: der Governor heisst jetzt powersave statt schedutil, und das sieht nach einem Rückschritt aus. Ist es nicht. Bei intel_pstate im aktiven Modus ist powersave der Name für den Betrieb, bei dem die Hardware regelt. Wie sie das tut, steuert ein separater Wert:
Die CPU geht im Leerlauf auf 800 MHz und hat den vollen Turbo bis 3600 MHz zur Verfügung. Genau so soll es sein.
Wichtig war mir noch die Gegenprobe, dass ich mir das Netzwerk nicht zerschossen habe. Die Karte, deren Option-ROM ich abgeschaltet habe, ist schliesslich die, über die diese Maschine am Netz hängt:
Unverändert. Das ist auch zu erwarten, denn der Treiber im laufenden Betrieb kommt aus dem Kernel und hat mit dem Option-ROM nichts zu tun. Das Option-ROM ist reiner Startcode. Trotzdem ist das der Punkt, an dem die meisten zögern, deshalb steht die Messung hier.
Ein Punkt ist noch offen, und den will ich nicht verschweigen: der ursprüngliche Anlass für das Abschalten von SLOT6 war eine Meldung auf der Treiberstatus-Seite im Setup, wo meine Netzwerkkarte seit einem Firmware-Update als *Failed* geführt wird. Ob die Meldung jetzt weg ist, kann ich von aussen nicht sehen. Das prüfe ich beim nächsten Setup-Besuch nach.
Gibt es dafür keine Oberfläche?
Diese Frage lag für mich die ganze Zeit im Raum, und die Antwort ist unbefriedigend.
Es gäbe einen herstellerneutralen Weg unter Linux. Der Kernel kennt eine Geräteklasse namens firmware-attributes, über die sich BIOS-Einstellungen als ganz normale Dateien lesen und schreiben lassen. Der Firmware-Updater fwupd kann das seit Version 1.8.4 direkt bedienen. Das wäre die Lösung: ein Kommando, egal welcher Hersteller.
Auf meiner Maschine sieht das so aus:
$ ls /sys/class/firmware-attributes/
ls: cannot access '/sys/class/firmware-attributes/': No such file or directory
$ fwupdmgr get-bios-setting
This system doesn't support firmware settings
Das Hilfsmodul dafür liegt im Kernel, es ist also nicht so, dass die Infrastruktur fehlen würde:
Was fehlt, ist der Treiber des Herstellers. Der Kernel bringt genau drei mit:
drivers/platform/x86/dell/dell-wmi-sysman Dell
drivers/platform/x86/lenovo/think-lmi Lenovo
drivers/platform/x86/hp/hp-bioscfg HP
Supermicro ist nicht dabei. Statt eines Treibers, der diese Kernel-Schnittstelle bedient, gibt es ein eigenes Werkzeug und eine Lizenz. Auf einem Dell oder Lenovo wäre der Inhalt dieses Beitrags ein Einzeiler ohne Zusatzkosten.
Ganz ohne Oberfläche ist man aber nicht. Das Werkzeug bringt einen textbasierten Editor mit, der das Setup im Terminal nachbaut:
./saa -c GetCurrentBiosCfg --tui
Dazu gibt es --compact, das anschliessend nur die geänderten Zeilen herausschreibt. Über eine SSH-Pipe blieb das Fenster bei mir schwarz, es braucht ein echtes Terminal. Ausprobiert habe ich es deshalb noch nicht richtig. Und es gibt das Werkzeug ausserdem als Windows-Version und als Variante für die UEFI-Shell, also für den Fall, dass überhaupt kein Betriebssystem installiert ist.
Eine echte grafische Oberfläche gibt es auch, sie heisst SSM. Die will dann allerdings wieder die grosse Lizenz.
Zurück auf Anfang
Das Wichtigste zum Schluss, und man legt es sich besser vorher zurecht als hinterher. Vor dem Schreiben habe ich den vollständigen Stand weggesichert. Der Rückweg ist dann dasselbe Kommando mit dieser Datei:
Als Notnagel gibt es darunter noch LoadDefaultBiosCfg, das alles auf den Auslieferungszustand zurücksetzt. Das ist aber ein grober Hebel: es wirft auch die sechs Abweichungen weg, die ich absichtlich eingestellt habe, und die stehen dann eben nicht mehr so, wie ich sie haben will. Die Teildatei ist der bessere Weg, der Vollreset die letzte Reserve.
Und weil es hier um Firmware geht, der offensichtliche Hinweis: bei einem Rechner, an den du nicht rankommst, änderst du keine Boot-Einstellungen, ohne dass jemand vor Ort ist oder die Fernkonsole zuverlässig läuft. Ich habe das Option-ROM der Grafik und das des Management-Controllers genau deshalb nicht angefasst.
Was bleibt
Sieben Einstellungen, ein Neustart, kein Setup-Besuch. Das klingt nach wenig, ändert aber die Arbeitsweise. BIOS-Einstellungen waren für mich bisher etwas, das man beim Aufbau einmal einstellt und danach ungern anfasst, weil jede Änderung einen Neustart mit Tastatur und Monitor bedeutet. Jetzt sind sie eine Datei, die ich versionieren, vergleichen und zurückspielen kann.
Der schönste Nebeneffekt war die Sache mit den Hardware P-States. Ich hatte das Verhalten meiner CPU wochenlang für eine Eigenheit des Kernels gehalten und in die falsche Richtung gesucht. Es war eine einzige Zeile in einem Menü, das vier Ebenen tief liegt und das ich beim Durchklicken nie geöffnet hatte. Eine durchsuchbare Datei aller 372 Einstellungen hätte mir das in dreissig Sekunden gezeigt.
Falls du auf demselben Board sitzt: das Auslesen ist der Beitrag davor, das Schreiben braucht keine weitere Lizenz, und die drei Stolperstellen sind der Filter, der nur als Wort funktioniert, die Gegenprobe, die vor dem Neustart nichts zeigt, und die Versuchung, mehr auf einmal zu ändern, als man beim nächsten Start noch reparieren kann.
In meiner Serie BIOS erklärt arbeite ich mich durch das Setup eines Supermicro X12SPi-TF. Die Grundlage dafür war bisher eine Bildschirmaufnahme: ich bin durch alle Menüs gelaufen, habe das Video in Einzelbilder zerlegt und die Werte abgetippt. Das funktioniert, ist aber Handarbeit, und Handarbeit übersieht Dinge.
Was ich eigentlich wollte, ist eine Datei. Eine Liste aller Optionen mit ihrem aktuellen Wert, maschinenlesbar, damit ich sie durchsuchen und mit einem späteren Stand vergleichen kann. Das Board kann das. Es rückt es nur nicht heraus.
Drei Wege, drei Absagen
Der erste Weg führt über Redfish, die HTTP-Schnittstelle des Management-Controllers. Der passende Endpunkt existiert, antwortet aber nicht mit Daten:
GET /redfish/v1/Systems/1/Bios
HTTP 403
"MessageId": "SMC.1.0.OemLicenseNotPassed",
"Message": "Not licensed to perform this request. The following licenses DCMS were needed"
Der zweite Weg ist Supermicros eigenes Kommandozeilenwerkzeug. Es heißt inzwischen SAA, SuperServer Automation Assistant, und liegt dem BIOS-Paket bei. Es kann genau das, was ich suche, und arbeitet dabei nicht über das Netz, sondern direkt über die Firmware:
./saa -c GetCurrentBiosCfg --file bios-current.xml
ExitCode 80
Node product key is not activated.
One of the node product key (SFT-OOB-LIC or SFT-DCMS-SINGLE) should be activated
Der dritte Weg wäre, die UEFI-Variablen selbst zu lesen. Die liegen unter /sys/firmware/efi/efivars/, und tatsächlich gibt es dort Einträge, die nach BIOS-Einstellungen aussehen. Nur sind das undurchsichtige Datenblöcke ohne die Zuordnungstabelle des Boards. Man sieht Bytes, aber man weiß nicht, welches Byte welcher Menüpunkt ist.
Drei unabhängige Wege, dieselbe Sperre. An dieser Stelle habe ich in meinen Notizen etwas geschrieben, das sich später als falsch herausstellte. Dazu komme ich am Ende.
Zwei Lizenzen, und sie sind nicht dasselbe
Lies die beiden Fehlermeldungen oben noch einmal nebeneinander. Sie verlangen nicht das Gleiche. Redfish nennt namentlich DCMS. SAA nennt SFT-OOB-LIC oder SFT-DCMS-SINGLE, also eine von zweien.
Das ist der Punkt, an dem man leicht zu viel Geld ausgibt. Supermicro verkauft für diese Board-Generation zwei Lizenzen. Die kleine heißt Out of Band, kurz OOB. Die große heißt DCMS und kostet etwa das Fünffache. Wer nur die Fehlermeldung von Redfish liest, kauft DCMS. Wer die Fehlermeldung von SAA liest, merkt, dass es für seinen Zweck auch die kleine tut.
Nebenbei taucht dieselbe Lizenz an einer Stelle auf, die ich nicht erwartet hätte. Im Handbuch zum Board stehen bei zwei Sicherheitseinstellungen, nämlich beim Abschalten der vorderen und der hinteren USB-Anschlüsse, die Worte *available for configuration if the SFT-DCMS-SINGLE license is installed*. Es fehlen also nicht nur Management-Schnittstellen. Es fehlen zwei Menüpunkte im Setup selbst.
Warum man den Schlüssel nicht selbst baut
Bei dieser Recherche stößt man unweigerlich auf ein Werkzeug auf GitHub, das Supermicro- Produktschlüssel behandelt. Für die Generationen 9 bis 11 kann es welche erzeugen, denn dort war der Schlüssel ein berechneter Wert über die MAC-Adresse des Management-Controllers.
Für die zwölfte Generation, also mein Board, kann es das nicht, und das Projekt schreibt es selbst deutlich hin: dieses Format lässt sich mit dem Werkzeug prüfen, aber nicht erzeugen. Der Grund ist, dass Supermicro umgestellt hat. Der Schlüssel ist heute eine von Supermicro signierte Datei, und der Management-Controller prüft die Signatur gegen einen öffentlichen Schlüssel in seiner eigenen Firmware. Ohne den privaten Schlüssel des Herstellers entsteht da nichts Gültiges.
Mein Board bestätigt das Format auf Nachfrage:
Node Product Key Format..........JSON
Damit ist die naheliegende Abkürzung nicht moralisch, sondern rechnerisch verschlossen. Man muss die Frage also wirklich beantworten.
Der Kauf, und eine Überraschung beim Erzeugen
Gekauft habe ich im Supermicro eStore. 23,67 Euro netto, 28,17 Euro brutto. Bei der Bestellung wählt man das Mainboard-Modell aus einer Liste, und mein X12SPi-TF steht darin. Das ist erwähnenswert, weil mehrere Händlerbeschreibungen dieser Lizenz nur X10 und X11 nennen. Diese Texte sind veraltet.
Jetzt kommt der Teil, den ich falsch erwartet hatte. Ich dachte, ich kaufe und bekomme einen Schlüssel. So läuft es nicht. Man bekommt zunächst nur eine Zertifikatsnummer und die Aufforderung, den Schlüssel selbst zu erzeugen. Dafür meldet man sich im Store an, wählt die Bestellung aus und gibt an, für welches Gerät der Schlüssel gelten soll: entweder die MAC-Adresse des Management-Controllers oder die Seriennummer des Boards.
Die Bindung an die Hardware entsteht also nicht beim Verkauf, sondern beim Käufer, im Moment des Erzeugens. Das ist konsequent, denn Supermicro weiß beim Verkauf ja gar nicht, in welchem Gerät die Lizenz landen soll. Es heißt aber auch, dass man sich vertippen kann, und dann hat man einen Schlüssel für ein Gerät, das es nicht gibt.
Der Ablauf war zügig. Bestellbestätigung um 14:17, die Freigabe zum Erzeugen um 14:42, der fertige Schlüssel um 14:44, aktiv im Board um 14:46. Unter einer halben Stunde vom Klick bis zur Funktion, und die zugesagte Stunde war damit nicht zu optimistisch.
Der Schlüssel selbst ist eine kleine Textdatei, benannt nach der MAC-Adresse, mit einem JSON-Objekt darin: Lizenzname, Ausstellungsdatum und eine lange Signatur. Mehr ist es nicht.
Eine Kuriosität am Rande: die Mail mit dieser Textdatei trägt einen Ausfuhrhinweis der US-Regierung. Die Ware sei nur für das Bestimmungsland freigegeben und dürfe nicht weiterveräußert oder an Dritte weitergegeben werden. Das gilt hier für eine Datei von wenigen hundert Byte, deren einzige Wirkung darin besteht, in einem Verwaltungscontroller einen Menüpunkt sichtbar zu machen.
Aktivieren
Supermicro nennt vier Wege, den Schlüssel einzuspielen: die Weboberfläche des Management-Controllers, das Werkzeug SUM, die Verwaltungssoftware SSM und Redfish. Die Weboberfläche ist der ruhigste Weg, weil sie eine Bestätigungsseite hat, und bei einem Schlüssel, der genau einmal auf genau ein Gerät passt, will man die haben.
Wer es lieber skriptet, findet die passenden Endpunkte im Management-Controller, und die sind auch ohne Lizenz erreichbar:
POST /redfish/v1/Managers/1/LicenseManager/Actions/LicenseManager.ActivateLicense
POST /redfish/v1/Managers/1/LicenseManager/Actions/LicenseManager.ClearLicense
GET /redfish/v1/Managers/1/LicenseManager/QueryLicense
Die Abfrage danach gibt genau den Inhalt der Datei zurück, die man hochgeladen hat. Der Controller speichert den Schlüssel also unverändert und prüft ihn bei Bedarf.
Das Kommando, auf das es ankommt
Nach der Aktivierung meldet SAA einen anderen Zustand:
Und dasselbe Kommando, das vorher mit ExitCode 80 abgebrochen ist, läuft durch:
./saa -c GetCurrentBiosCfg --file bios-current.xml
File "bios-current.xml" is created.
Heraus kommt eine Datei von 260 Kilobyte mit 60 Menüs und 372 Einstellungen. Zum Vergleich: das offizielle Handbuch beschreibt 180 Optionen. Und die Datei enthält pro Eintrag mehr, als man im Setup sieht, nämlich zusätzlich den Auslieferungszustand und den Hilfetext:
Der Auslieferungszustand ist der eigentliche Gewinn. Damit sehe ich auf einen Blick, welche Einstellungen an dieser Maschine vom Werkszustand abweichen, und das ist genau die Liste, die man nach einem BIOS-Update wiederherstellen will.
Zwei komplette Hauptmenüs standen darin, die ich beim Durchklicken schlicht nie geöffnet hatte. Und ein Untermenü, das ich in meinen Notizen als offene Lücke geführt habe, war vollständig enthalten. So viel zum Thema Handarbeit übersieht Dinge.
Was die Lizenz nicht freischaltet
Jetzt der ehrliche Teil, und der ist mir wichtiger als der Erfolg. Ich hatte vor dem Kauf drei Messungen aufgeschrieben, damit ich hinterher vergleichen kann. Drei von vier Erwartungen sind eingetroffen, und die vierte war die interessante.
Der Redfish-Endpunkt, mit dem alles anfing, antwortet weiterhin mit 403 und verlangt weiterhin DCMS. Die kleine Lizenz öffnet den Weg über SAA und eben nicht den über Redfish. Wer also ausdrücklich die Netzwerkschnittstelle braucht, etwa weil er hunderte Server ohne Betriebssystem konfigurieren will, kommt um die große Lizenz nicht herum.
Das hat eine Nebenwirkung, die ich nicht auf dem Zettel hatte. Der Firmware-Updater fwupd kann inzwischen mit Supermicros Redfish-Schnittstelle sprechen. Er sieht bei mir aber nur zwei von zwölf Firmware-Komponenten, und die beiden BIOS-Einträge fehlen. Der Grund ist, dass er zur Identifikation eines Geräts das Objekt lesen muss, das hinter genau diesem gesperrten Endpunkt liegt. Die Lizenz sperrt hier also nicht das Aktualisieren, sondern das Erkennen, und das Aktualisieren scheitert dann als Folge. Nach der Aktivierung sind es unverändert zwei von zwölf.
Und der dritte Weg, den ich vorher gar nicht gesehen hatte: fwupd sieht den BIOS-Speicher auch ganz direkt am Chipsatz, liest die Version korrekt aus und verweigert trotzdem den Dienst:
Internal SPI Controller (BIOS):
Aktuelle Version: 2.5
Probleme: Device firmware has been locked
Das ist keine Lizenzsache, und daran hat sich erwartungsgemäß nichts geändert. Der Speicher ist auf Chipsatzebene schreibgeschützt, weil das Board mit aktivem Root of Trust läuft. Ein BIOS, das sich aus einem laufenden Betriebssystem heraus überschreiben lässt, wäre genau die Lücke, die dieser Schutz verhindern soll. Der Reflex sagt hier Hersteller blockiert Linux. Tatsächlich blockiert eine Sicherheitsfunktion, die ich selbst haben will.
Mein Denkfehler
Bleibt der Satz, den ich weiter oben angekündigt habe. In meinen Notizen stand nach der dritten Absage sinngemäß: drei unabhängige Wege, dieselbe Sperre, nicht erneut versuchen.
Gemessen hatte ich: ohne Lizenz gibt es keinen Weg. Aufgeschrieben hatte ich: es gibt keinen Weg. Und die dritte Möglichkeit, nämlich die Lizenz einfach zu kaufen, kam in meiner Aufzählung der drei gesperrten Wege überhaupt nicht vor, obwohl das Werkzeug sie mir wörtlich genannt hatte.
Dass drei Wege an derselben Sperre scheitern, beweist, dass es eine Sperre gibt. Es beweist nicht, dass sie unüberwindbar ist. Wenn eine Fehlermeldung den Namen der fehlenden Berechtigung nennt, ist das ein Hinweis und kein Schlusspunkt.
Lohnt sich das?
Für einen einzelnen Rechner zu Hause: nur, wenn man Freude daran hat. Ich hätte die Werte auch weiter abschreiben können, und der Screencast hat mir immerhin eine fünfzehnteilige Serie eingebracht, die aus einer XML-Datei nie entstanden wäre. Man liest eine Datei nicht so aufmerksam wie ein Menü, durch das man sich selbst klicken muss.
Für alles, was mehr als eine Handvoll Maschinen betrifft, sieht es anders aus. Konfiguration auslesen, versionieren, nach einem Update wieder einspielen und im Zweifel gegen einen bekannten Stand vergleichen, das ist bei 28 Euro pro Board keine Diskussion. Ärgerlich finde ich nur, dass man diese Rechnung überhaupt aufmachen muss. Es geht um das Auslesen der eigenen Einstellungen auf der eigenen Hardware.
Wenn du auf demselben Board sitzt und dieselbe Fehlermeldung vor dir hast, ist die Kurzfassung: für die Konfiguration reicht die kleine Lizenz, für Redfish brauchst du die große, und für Firmware-Updates brauchst du bei einem X12 mit Root of Trust vermutlich gar keine.
Seit Ende Juli steht bei mir ein anderer Rechner unter dem Schreibtisch. Kein gekaufter, sondern einer aus Teilen die ohnehin schon da waren: ein Supermicro X12SPi-TF, also ein richtiges Serverboard, dazu ein Xeon Gold 5315Y und 256 GB registrierter ECC-Speicher. Die Grafikkarte ist aus der alten Workstation umgezogen, Gehäuse und Netzteil waren neu. Seitdem macht die Kiste genau das, was vorher eine deutlich ältere Dual-Socket-Maschine gemacht hat, nur leiser und mit mehr Luft nach oben.
Beim Einrichten ist mir dann etwas passiert, das ich so nicht auf dem Zettel hatte. Ich saß im BIOS-Setup, bin die Seiten durchgegangen, und bei einigen Einstellungen dachte ich: kenne ich, habe ich schon hundertmal gesehen. Hätte mich in dem Moment jemand gefragt, was der Schalter denn nun genau tut, wäre ich ins Schwimmen gekommen. Also habe ich nachgeschlagen. Und dann noch mal. Irgendwann stand fest, dass daraus eine kleine Serie werden sollte.
Warum ein Server-BIOS eine andere Hausnummer ist
Ein normales Desktop-Board hat im Setup vielleicht drei Dutzend Schalter, die wirklich etwas bewirken. Der Rest ist Bootreihenfolge, Lüfterkurve und Beleuchtung. Bei diesem Board sieht das anders aus. Das Handbuch beschreibt rund 180 Einstellungen, bei denen man tatsächlich etwas auswählen kann, verteilt auf sieben Hauptmenüs und je nach Zweig bis zu fünf Ebenen tief. Dort stehen Dinge wie Patrol Scrub, Stale AtoS, UMA-Based Clustering oder IIO eDPC Support. Das sind keine Marketingbegriffe, das sind Schalter für Verhalten, das man verstanden haben muss, bevor man daran dreht.
Und genau da liegt für mich der interessante Punkt. Fast alles davon steht auf Auto oder auf dem Herstellerdefault, und das ist in den allermeisten Fällen auch völlig richtig so. Nur ist „steht auf Default“ eben keine Antwort auf die Frage, was eigentlich passiert, wenn man es umstellt. Diese Antwort hätte ich gern. Für jeden Schalter, der auf diesem Board etwas tut.
Wie man auf so einem Board überhaupt ins Setup kommt
Hier fängt der Unterschied zum Desktop schon an. Auf dem Board sitzt ein zweiter, kleiner Computer: der BMC, ein ASPEED AST2600. Der hat seine eigene Netzwerkbuchse, seine eigene IP-Adresse, sein eigenes Betriebssystem, und er läuft auch dann, wenn der eigentliche Rechner aus ist. Solange Strom am Netzteil anliegt, ist der BMC wach. Der BMC bekommt später eine eigene Folge, für heute reicht eine seiner Fähigkeiten: KVM over IP.
Das heisst konkret, ich brauche für das BIOS weder Monitor noch Tastatur am Rechner. Ich rufe im Browser die Weboberfläche des BMC auf, starte dort die Konsole, und sehe das Bild, das die Grafikausgabe gerade produziert. Inklusive POST, inklusive Setup, inklusive Bootloader. Tasten gehen den umgekehrten Weg. Der BMC hängt sich dafür als virtuelle USB-Tastatur und -Maus an den Rechner, und die tauchen unter Linux später auch brav in lsusb auf:
Bus 001 Device 003: ID 0557:9241 ATEN International Co., Ltd SMCI HID KM
Bus 001 Device 004: ID 0b1f:03ee Insyde Software Corp. RNDIS/Ethernet Gadget
Wer schon mal einen Server im Keller stehen hatte und sich gefragt hat, wie man da ohne Bildschirm ins BIOS kommt: so. Und weil das Bild ohnehin durchs Netz geht, kann man es auch gleich aufzeichnen. Genau das habe ich gemacht, und diese Aufnahme ist die Grundlage für alles, was in dieser Serie noch kommt.
Und dann wollte ich die Einstellungen einfach auslesen
Das war der Moment, in dem die Serie ihre eigentliche Rechtfertigung bekommen hat. Meine Idee war naheliegend: statt 200 Screenshots zu sortieren, hole ich mir die komplette Konfiguration als Datei. Moderne Boards können das, dafür gibt es Redfish, eine HTTP-Schnittstelle auf dem BMC. Ein Aufruf, und man hat jede Einstellung mit Ist-Wert und allen möglichen Werten sauber als JSON.
Der Aufruf ging auch durch. Nur nicht so, wie ich wollte:
GET /redfish/v1/Systems/1/Bios
403 Forbidden
MessageId: SMC.1.0.OemLicenseNotPassed
"Not licensed to perform this request. The following licenses DCMS were needed"
Also der Weg über das Kommandozeilenwerkzeug. Supermicro liefert dafür den SuperServer Automation Assistant mit, und der kennt genau den passenden Befehl. In-Band, also lokal auf der Maschine selbst, ohne Umweg über das Netzwerk:
ExitCode = 80
Description = Node product key is not activated.
Error message:
One of the node product key (SFT-OOB-LIC or SFT-DCMS-SINGLE) should be
activated to execute this task.
Damit ist es amtlich. Das Board weigert sich, mir seine eigene Konfiguration herauszugeben, weil ich keine Lizenz gekauft habe. Nicht ändern, wohlgemerkt. Nur lesen. Der dritte Weg über die UEFI-Variablen im Kernel führt auch nicht weiter, da liegen zwar Blobs, aber ohne die Zuordnungstabellen des Boards sind das einfach nur Bytes.
Ich verstehe das Geschäftsmodell durchaus. Wer dreihundert Server ausrollt, will die Konfiguration automatisiert verteilen, und dafür Geld zu verlangen ist legitim. Nur bin ich eben nicht dreihundert Server, ich bin ein Schreibtisch, und das Auslesen dessen was ich selbst eingestellt habe fühlt sich nicht nach einem Premium-Feature an. Der Screencast über die Konsole ist der Weg drumherum, und ehrlich gesagt ist er für diese Serie sogar der bessere: ein Screenshot zeigt den Schalter so, wie er dir im Setup auch begegnet.
Was in der Serie kommt
Ich gehe das BIOS in Themenblöcken durch, nicht Menüseite für Menüseite. Jede Folge nimmt sich einen Bereich vor und beantwortet für die Schalter darin drei Fragen: was tut das, warum steht es bei mir so, und wann würde man es anders setzen. Grob in dieser Reihenfolge:
Boot Feature und Power, also alles rund um Einschalten, Watchdog und das Verhalten nach einem Stromausfall
Die CPU, einmal die Seite mit Kernen, Threads und Prefetchern, einmal die mit AES-NI, TME, SGX und den Sicherheitsfunktionen
Speicher, ECC, Patrol Scrub und die Frage warum mein DDR4-3200 mit 2933 läuft
NUMA und der Uncore-Bereich, der auf einer Single-Socket-Maschine erstaunlich viel Unsinn anzeigt
PCIe in drei Folgen: Slots und Lanes, dann Adressraum und Resizable BAR, dann die Fehlerbehandlung, wo es richtig spannend wird
Virtualisierung mit VT-d, IOMMU und VMD
Storage, Preboot-Netzwerk, Bootreihenfolge und Secure Boot
Zum Schluss der BMC selbst, das TPM und die Ereignisprotokolle
Die Folgen sind bewusst kurz gehalten. Ein Thema, einmal sauber durch, und nicht ein Wälzer den keiner zu Ende liest.
Ein Wort dazu, warum ich das überhaupt aufschreibe
Zwei Gründe. Der erste ist eigennützig: indem ich es aufschreibe, muss ich es verstanden haben. Ein Halbwissen überlebt keinen Absatz, in dem man erklären soll warum etwas so ist. Das ist der beste Lerneffekt den ich kenne.
Der zweite Grund ist etwas nachdenklicher. Dieses Wissen ist am Aussterben, und das meine ich ohne Larmoyanz. Wer heute Rechenleistung braucht, klickt sie in einer Cloud zusammen, und dort gibt es kein BIOS mehr, an das man herankäme. Wer eine Frage hat, fragt eine AI und bekommt eine Antwort, die meistens stimmt. Beides ist bequem und für die allermeisten Zwecke völlig ausreichend. Trotzdem muss es am Ende weiterhin Menschen geben, die wissen was unter der Abstraktion passiert. Wenn eine Maschine nicht bootet, hilft kein Terraform.
Und damit zum wichtigsten Teil: wenn ich mich irre, sag es mir bitte. Ich schreibe diese Serie auch, um dazuzulernen, und eine Korrektur ist dafür der schnellste Weg. Ich trage sie dann im jeweiligen Beitrag nach, mit Datum, und lasse sie nicht stillschweigend verschwinden. Gerade bei den Prozessor-Interna und beim PCIe-Teil wird es hier Leute geben, die tiefer drin stecken als ich.
Nächste Folge: Boot Feature und Power. Also die Frage, warum mein Rechner nach einem Stromausfall absichtlich aus bleibt, und was ein Interrupt aus dem Jahr 1981 heute noch in einem UEFI-Setup zu suchen hat.
Habt ihr auf eurem Board schon mal versucht, die BIOS-Konfiguration maschinell auszulesen, und seid dabei auch gegen eine Lizenz gelaufen? Erzählt es mir gerne, ihr dürft mich jederzeit fragen.
