d9ed1bc2ff
Die Geraeteschicht — Abbild, zwei Wurzeln, Selbstprueflauf, Ruecksprung — verlaesst die Ablage der ersten Appliance und wird ein eigenes Erzeugnis mit eigenem Takt und eigenem Nachweis. Drei Gruende, nach Gewicht: Der Cyber Resilience Act verpflichtet fuer das gesamte Produkt einschliesslich der Betriebssystemschicht — vier gewachsene Basissysteme waeren vier Stuecklisten und vier Schwachstellenprozesse, eine gemeinsame Basis ist ein Dossier. Der Ruecksprung wird nur einmal richtig gebaut, weil er nur geprueft wird wenn ihn jemand braucht. Und eine abgegrenzte Aufgabe laesst sich ausschreiben, was unmittelbar auf das groesste benannte Risiko des Hauses einzahlt. Der Einwand der Vertraeglichkeitsmatrix wird durch den Nutzlast-Vertrag entkraeftet statt weggeredet: Die Nutzlast liegt in der Wurzel und wird mit ihr getauscht. Eine Fassung, ein Rueckweg, keine Matrix. Das OS kennt kein Produkt — Regel 1. Alle Namen sind entkoppelt, die Statusseite ist auf die Standardbibliothek umgestellt, weil jede Abhaengigkeit im Grund-OS eine Verpflichtung ueber die Produktlebensdauer ist. Nichts davon ist gelaufen. Der Inhalt gilt als Bauplan. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
5.8 KiB
ADR-0011 — systemd-boot trägt den Rücksprung, der Selbstprüflauf entscheidet ihn
Stand: Angenommen, 17.08.2026 · Entscheidet: CIO Thomas Reitz
Setzt um: ADR-0004 (A/B-Wurzel) · Betrifft: Abbildbau, Updatekanal, offene Frage O-8
Nachweis steht aus — die Punkte unter „Was am Gerät zu bestätigen ist"
Worum es geht
ADR-0004 verspricht einen Rücksprung, der mehr kann als „bootet nicht": Nach dem Umschalten
bekommt die neue Fassung eine begrenzte Zahl von Versuchen, gilt erst nach einem bestandenen
Selbstprüflauf als bestätigt, und läuft der Zähler ab, kehrt das Gerät von selbst zur
vorherigen Wurzel zurück.
Das ist eine Zusage über Zähler, Schwellen und Zustände — also über Mechanik, die entweder korrekt ist oder still versagt. Und sie versagt an einer unangenehmen Stelle: Ein Rücksprung, der nicht funktioniert, fällt erst auf, wenn man ihn braucht.
Diese Entscheidung legt fest, womit er gebaut wird.
Die Entscheidung
Der Startvorgang läuft über systemd-boot mit dessen Automatic Boot Assessment. Der
Selbstprüflauf hängt vor boot-complete.target.
Der Grund ist, dass genau diese Mechanik dort bereits existiert und gepflegt wird:
| Was ADR-0004 verlangt | Was systemd-boot mitbringt |
|---|---|
| begrenzte Zahl von Startversuchen | Zähler im Dateinamen des Starteintrags — …+3.conf |
| Herunterzählen bei jedem Versuch | erledigt der Startverwalter selbst, vor dem Kern |
| Bestätigung erst nach bestandener Prüfung | systemd-bless-boot löscht den Zähler — und läuft erst nach boot-complete.target |
| Rückfall nach erschöpften Versuchen | erschöpfte Einträge werden ans Ende sortiert |
Unser Anteil daran ist eine einzige Unit: der Selbstprüflauf, der vor boot-complete.target
laufen muss und von ihm benötigt wird. Fällt er durch, wird das Ziel nie erreicht, der Zähler
nie gelöscht — und der dritte Fehlversuch stuft die Fassung ab.
Der eigentliche Gewinn ist, was wir dadurch nicht bauen. Ein selbstgeschriebener Startzähler in einer Umgebungsvariablen des Startverwalters ist erfahrungsgemäß genau die Stelle, an der Rücksprünge versagen: Er wird bei einem unsauberen Abschalten nicht zurückgesetzt, er verzählt sich bei einem Neustart aus der laufenden Sitzung, und niemand merkt es, weil der Normalbetrieb davon nichts sieht. Bei einem Produkt, dessen Verkaufsargument der funktionierende Rückweg ist, ist geerbte und gepflegte Mechanik mehr wert als eigener Code.
Was daraus für den Aufbau folgt
Kern und Startabbild liegen auf dem EFI-Bereich. systemd-boot liest keine Linux-Dateisysteme; was es starten soll, muss auf dem EFI-Bereich liegen. Je Wurzel ein eigenes Verzeichnis, also zwei Sätze aus Kern und Startabbild. Das ist der Grund, warum der EFI-Bereich in ADR-0004 mit einem Gigabyte großzügiger bemessen ist als üblich.
Der Selbstprüflauf wächst mit dem Produkt. Heute prüft er, was es gibt: richtige Wurzel eingehängt, Bestandsbereich vorhanden, Dienste gestartet. Später kommen die Punkte aus ADR-0004 dazu — Datenbank antwortet, jede Aufgabenklasse ist bedienbar, der Wissensspeicher ist erreichbar. Die Verdrahtung ändert sich dabei nicht, nur die Prüfliste. Das ist der Grund, ihn früh zu bauen.
Und er braucht einen Prüfschalter. Ein Rücksprung, den man nicht auslösen kann, ist nicht prüfbar. Deshalb bringt der Selbstprüflauf einen ausdrücklichen Weg mit, absichtlich durchzufallen — sonst lässt sich die Abnahmebedingung nicht messen.
Was am Gerät zu bestätigen ist, bevor diese Entscheidung als belegt gilt
Vier Punkte, und keiner davon lässt sich herleiten:
Greift der Rückfall wirklich? Drei Fehlversuche auf Wurzel B müssen das Gerät ohne Zutun nach A bringen. Das ist die Abnahmebedingung, alles andere ist Vorarbeit.
Trägt die signierte Startkette? Ubuntu startet regulär über GRUB mit vorgelagertem Prüfglied. Ob systemd-boot dort mit eingeschaltetem Secure Boot sauber läuft, ist am Gerät zu prüfen. Fällt das negativ aus, ist der zweite Weg aus der Bewertung unten zu nehmen — die übrige Bauweise bleibt.
Überlebt der Tresorschlüssel den Fassungswechsel? Bindet er an den Sicherheitsbaustein, hängt er an einer Messung des Startzustands — und der ändert sich mit dem Startverwalter. Das ist die offene Frage O-8, und sie wird durch diese Entscheidung berührt, nicht gelöst.
Verhält sich ein erschöpfter Eintrag wie erwartet? Dass abgestufte Einträge ans Ende sortiert werden, ist dokumentiert. Wie sich das mit einem ausdrücklich gesetzten Vorgabeeintrag verträgt, gehört nachgesehen und nicht angenommen.
Bis diese vier Punkte gemessen sind, gilt für diese Entscheidung dieselbe Regel wie für alles andere in diesem Produkt: Sie ist begründet, nicht belegt.
Die verworfene Alternative
GRUB mit eigenem Zähler. Ubuntus Standardweg bliebe unangetastet, die signierte Kette
funktioniert nachweislich, und die Mechanik wäre über GRUB_DEFAULT=saved und einen Zähler in der
Umgebungsdatei des Startverwalters aufgebaut.
Der Vorzug ist real und war der Grund, überhaupt abzuwägen: Bei eingeschaltetem Secure Boot ist das der Weg, der garantiert läuft.
Dagegen steht, dass der Zähler dann unser Code ist — und zwar Code, der bei jedem unsauberen Abschalten, jedem Neustart aus der laufenden Sitzung und jedem Stromausfall das Richtige tun muss. Getestet wird er nur, wenn jemand einen Rücksprung auslöst, also fast nie. Ein stiller Fehler darin zeigt sich zum ersten Mal an dem Tag, an dem ein Kunde ihn braucht.
Fällt die Secure-Boot-Prüfung negativ aus, wird diese Alternative wieder aufgenommen — dann allerdings mit der ausdrücklichen Auflage, den Zähler gegen unsauberes Abschalten zu prüfen, nicht nur gegen den Normalfall.