Ich stieg in den ARM64-Bootpfad hinab, um einer ganz anderen Frage nachzugehen, und kam wieder herauf, gezwungen, ein Wort zu zerlegen, das ich mein ganzes Berufsleben lang ungeprüft benutzt hatte. Das Wort ist Vertrauen. Wir sagen, ein System „vertraue“ einem Signaturschlüssel, „vertraue“ seiner Boot-Kette, „vertraue“ der Zufallszahl, die es gerade gezogen hat. Ich hatte in diesem Wort immer nur eine Sache gehört — einen einzigen Akt des Sich-Verlassens. Als ich las, wie ein moderner sicherer Kernel seine Garantien tatsächlich „herstellt“, fand ich drei. Drei Maschinen, die den Namen teilen und sonst fast nichts. Und die Achse, die sie trennt, ist am Ende ihr Verhältnis zur Vergangenheit: eine weigert sich zu erinnern, eine lebt ganz von dem, woran sie sich erinnert, und eine verteilt ihren Einsatz so breit über die Gegenwart, dass Erinnerung nie ins Spiel kommen muss.

Nehmen wir sie in der Reihenfolge, in der ich ihnen begegnet bin.

Mischen: Vertrauen als logisches ODER

Die erste tauchte dort auf, wo ein Kernel seine eigene Anordnung randomisiert. KASLR — Kernel Address Space Layout Randomization — lädt den Kernel an einen unvorhersehbaren Offset, damit ein Angreifer nicht annehmen kann, wo eine Funktion liegt. Dafür braucht er Entropie, und hier hatte ich eine schlicht falsche Überzeugung: Ich dachte, ARM64 habe, anders als x86, keinen Hardware-Zufallszahlenbefehl und müsse daher dem Seed vertrauen, den der Bootloader reicht. Ich erwähne den Irrtum, weil sich genau dort, wo ich falsch lag, die interessante Struktur versteckte.

ARMv8.5-A fügte einen solchen Befehl hinzu — RNDR, sogar aus dem unprivilegierten Userspace lesbar.1 Doch je genauer ich hinsah, desto weniger verhielt sich der Kernel wie etwas, das von einer einzigen Quelle abhängt. Er zieht Entropie aus allem Verfügbaren: dem v8.5-Hardware-Generator, einem Firmware-Aufruf (der SMCCC-TRNG-Schnittstelle), dem UEFI-EFI_RNG_PROTOCOL, oder einem Seed, den der Device Tree mitführt — und ist so gebaut, dass das Ergebnis unvorhersehbar ist, sobald auch nur eine dieser Quellen wirklich unvorhersehbar ist.2 Das ist keine Kette, die am schwächsten Glied reißt. Es ist eher ein logisches ODER. Ein Angreifer gewinnt nicht, indem er eine Quelle kompromittiert; er muss beweisen, dass alle zugleich schlecht waren.

Festzuhalten ist hier: Diese Art von Vertrauen hat kein Gedächtnis. Sie zeichnet nichts über die Vergangenheit auf. Sie gelingt in der Gegenwart, sobald ein einziger ehrlicher Beitragender existiert, und ist gleichgültig gegen das Versagen der übrigen. Redundanz — aber nicht die Abstimmungsart, die Fehler durch Mittelung auslöscht. Die Art, bei der ein Überlebender genügt.

Verketten: Vertrauen als sich anhäufende Vergangenheit

Die zweite Gestalt ist in fast jeder Hinsicht das Gegenteil. Arms Confidential Compute Architecture (CCA) erlaubt es, eine Last — einen „Realm“ — auszuführen, die selbst der darunterliegende Hypervisor nicht lesen kann. Um einem entfernten Gegenüber zu beweisen, dass ein Realm wirklich unter echtem Schutz läuft, gibt CCA ein Attestierungs-Token aus, und das Token ist verschachtelt: ein Plattform-Token, signiert mit einem hardwaregehaltenen Plattformschlüssel, umhüllt ein Realm-Token, das mit einem separaten Realm-Schlüssel signiert ist, und beide werden verbunden, indem ein Hash des öffentlichen Realm-Schlüssels in den Nachweis der Plattform eingebettet wird.3

Diese Verschachtelung ist eine Kette und verhält sich wie eine. Die Behauptung des Realms ist nur so gut wie die Plattform-Behauptung darunter; zerbricht das Plattform-Glied, ist die Realm-Signatur darüber wertlos. Wo Mischen das Risiko so streut, dass eine gute Quelle rettet, konzentriert Verketten es so, dass ein schlechtes Glied alles darüber verdirbt. Und anders als Mischen ist dieses Vertrauen Gedächtnis. Das Token ist ein kumulativer Datensatz — eine gemessene Geschichte davon, welche Firmware was geladen hat, Schritt für Schritt vorwärtsgehasht. Vertrauen als Provenienz: eine Geschichte über die Vergangenheit, die man ganz glaubt oder gar nicht.

Halten: Vertrauen als Invariante, die sich nie erinnert

Die dritte Gestalt hätte ich beinahe übersehen, weil ich sie immer wieder unter die ersten beiden einzuordnen versuchte. Unter einem Realm erzwingt die Hardware die Isolation zwischen „Welten“ durch einen Granule Protection Check: jeder physische Speicherzugriff wird stromabwärts der gewöhnlichen Adressübersetzung gegen eine Tabelle geprüft, die festhält, welcher Welt dieses Speicher-Granule gehört.4 Die Monitor-Firmware führt ein eigenes Verzeichnis über den Zustand jedes Granules und verweigert jeden Übergang, der eine einzige Regel bräche — ein Granule gehört zu jedem Zeitpunkt genau einer Welt. Wird Speicher von einem Realm an die gewöhnliche Welt zurückgegeben, so wird sein Inhalt während der Übergabe gelöscht, und während der Übergabe darf niemand ihn beobachten.5

Man beachte, was das nicht ist. Es ist keine gemischte Wette und keine gemessene Geschichte. Nichts wird hier signiert; nichts wird für spätere Prüfung aufgezeichnet. Die Garantie ist eine in jedem Augenblick wahre Eigenschaft — eine Invariante, aufrechterhalten von einer Zustandsmaschine, die kein Interesse an der Vergangenheit hat und keine Geschichte über sie führt. Sicherheit kommt nicht daher, sich richtig zu erinnern, sondern daher, nie auch nur einmal in einen verbotenen Zustand eintreten zu dürfen. Wenn Mischen heißt „eine von uns ist ehrlich“ und Verketten „hier ist alles, was geschehen ist“, dann heißt diese dritte Art: „Die Bücher stimmen, jetzt in diesem Augenblick, und müssen immer stimmen.“

Warum ein Wort, und was es kostet, es zu behalten

Also: Mischen, Verketten, Halten. Parallele Redundanz, serielle Provenienz und eine kontinuierlich gehaltene Invariante. Drei Maschinen, die wir unbekümmert mit einem Namen belegen, weil sie von außen alle dasselbe Produkt liefern — darauf kann ich mich verlassen — während sie im Inneren so verschieden sind wie eine Lotterie, ein Stammbaum und ein Naturgesetz.

Als die drei einmal auseinandergefallen waren, sah ich sie überall, und ich glaube, das ist der eigentliche Gewinn, mehr als jedes Kernel-Detail. Die doppelte Buchführung ist die „Halten“-Art: sie vertraut nichts über die Vergangenheit und verbietet einfach, dass die Bücher je aus dem Gleichgewicht geraten. Eine notariell beglaubigte Verwahrkette oder ein Lieferketten-Herkunftsnachweis ist die „Verketten“-Art — kumulativ und nur so stark wie ihr schwächstes attestiertes Glied. Eine Geschworenenbank, ein Ensemble verrauschter Sensoren oder drei Freunde zu fragen, ob eine Idee dumm ist, ist die „Mischen“-Art, und sie hat die Eigenschaft, die man vergisst: Sie schützt nur, solange die Fehler nicht alle derselbe Fehler sind. Ich habe früher argumentiert, dass ein Raum voll gleichgesinnter Köpfe nur gefälschte Redundanz ergibt; der Entropie-Fall ist die ehrliche Version, denn das Kombinieren von Quellen braucht nur eine gute, nicht lauter unabhängige.

Die praktische Lehre, die ich mitnehme, ist eher eine Gewohnheit als eine Tatsache: Wenn ein einziges Wort die ganze Sicherheitsgeschichte eines Systems trägt — „Vertrauen“, aber auch „Gedächtnis“, „Identität“, „Eigentum“ —, dann verbirgt dieses Wort wahrscheinlich mehr als eine Maschine, und die Maschinen unterscheiden sich wahrscheinlich darin, wie sie mit der Zeit umgehen. Der Kernel lehrte mich weniger eine neue Tatsache über Vertrauen, als dass er mir nicht erlaubte, das Wort weiter faul zu gebrauchen.

Was ich noch nicht beantworten kann, ist, ob die drei wirklich irreduzibel sind oder bloß die drei, die die Hardware zufällig billig macht. Gibt es eine vierte Gestalt des Sicher-Seins, die keine heutige Maschine implementiert, weil sie zu teuer ist — ein Vertrauen, das weder gemischt noch verkettet noch als Invariante gehalten wird? Ich weiß es nicht. Aber ich glaube nicht mehr, dass „vertrau mir“ je eine einzige Bitte ist. Es ist immer eine von mindestens dreien, und es lohnt sich zu wissen, welche.

Gestützt auf meine eigenen Lesenotizen aus einem monatelangen Streifzug durch den ARM64-Linux-Bootpfad und seine Confidential-Computing-Erweiterungen, entlang der Kernel-Interna-Serie von Takahashi Hirokazu.6 Die Quellen unten tragen die belastbaren technischen Aussagen; die Dreiteilung und die Analogien sind meine.

  1. Arm. “RNDR, Random Number (AArch64 System Register).” The Armv8.5-A optional RNG extension; the register is available at EL0. Accessed 2026-07-02. ↩

  2. Biesheuvel, Ard. “KASLR in the arm64 Linux kernel” (Work of Ard, 2016); and “arm64: implement support for KASLR” (LWN.net). On drawing KASLR entropy from v8.5-RNG, the SMCCC RNG interface, EFI_RNG_PROTOCOL, and the device-tree kaslr-seed. Accessed 2026-07-02. ↩

  3. “Arm’s Confidential Compute Architecture Reference Attestation Token” (IETF draft-ffm-rats-cca-token); and Arm, “Get Started with CCA Attestation.” On the nested platform/realm token, bound by a hash of the realm attestation key. Accessed 2026-07-02. ↩

  4. “Realm Management Extension (RME)” (Trusted Firmware-A documentation); and Arm, “Granule Protection Checks.” Isolation between physical address spaces is enforced by the Granule Protection Check in the MMU, downstream of address translation, against a Granule Protection Table held in Root memory. Accessed 2026-07-02. ↩

  5. “Realm Management Monitor Specification” (TF-RMM); and “Enabling Realms with the Arm Confidential Compute Architecture” (USENIX ;login:). On the Granule Status Table and the requirement that a granule be wiped before it is undelegated, and be unobservable while in the DELEGATED state. Accessed 2026-07-02. ↩

  6. Takahashi, Hirokazu. “新Linuxカーネル解読室 — Linuxの起動 〜ARM64編〜” (VA Linux Systems Japan, kernel-internals blog series). Accessed 2026-07-02. ↩