Google Pixel 11: Für wen das Sicherheitsdrama wirklich relevant ist und was ein mysteriöses Motorola-Phone damit zu tun hat

GrapheneOS sorgte am letzten August-Wochenende für Unruhe unter Pixel 11 Usern beziehungsweise der Google-Community. Mit einem länglichen X-Post (wir berichteten) warnten die Entwickler aufgrund eines gestrichenen Tensor G6 Sicherheitsfeatures vor dem Kauf der Pixel 11 Familie und betonten, das alternative Betriebssystem nicht für die Pixel 11 Familie fertigstellen zu können. Wir wollen im Folgenden klären, wie ARM's MTE-Feature funktioniert, warum Google es vermutlich im Zuge der Tensor G6 Entwicklung gestrichen hat und was das für Pixel 11 Nutzer und Nutzerinnen im Alltag bedeutet beziehungsweise für wen das tatsächlich relevant sein kann. Im Zuge der Recherche für diesen Artikel stolperten wir auch über ein mysteriöses neues Motorola-Flaggschiff.

Was ist MTE?

Im Grunde funktioniert MTE wie folgt: Der Speicher Ihres Smartphones besteht aus einem riesigen Raster aus kleinen Speicherzellen. Viele Sicherheitslücken nutzen die Tatsache aus, dass eine App dazu gebracht wird, aus der falschen Speicherzelle zu lesen oder in diese zu schreiben – also aus einer, auf die sie eigentlich keinen Zugriff haben sollte. MTE verhindert dies, indem es auf jeden 16-Byte-Speicherblock und auf jeden Zeiger, der darauf zugreifen darf, eine unsichtbare Notiz anbringt. Wenn diese "Sticky Notes" nicht übereinstimmen, wenn ein Programm versucht, Daten zu lesen oder zu schreiben, zieht der Chip eine Notbremse und beendet den Prozess, anstatt den Exploit stillschweigend durchzulassen. GrapheneOS setzt MTE im gesamten Betriebssystem ein und argumentiert, dass dadurch ganze Kategorien von Hacking-Versuchen aus der Ferne bereits im Keim erstickt werden, bevor sie überhaupt beginnen können. Das Team sagt, es sehe so aus, als habe Google MTE aus dem Pixel 11 entfernt, um Geld zu sparen. Google hat sich bis dato nicht zu diesem Vorwurf geäußert. GrapheneOS rät den Nutzern nun, das Pixel 11 (hier bei Amazon erhältlich) zu meiden und stattdessen ein Pixel 8, 9 oder Pixel 10 zu kaufen. Vor allem, wenn sie in Zukunft einmal GrapheneOS nutzen möchten.

Eine Forschungsarbeit von Wissenschaftlern der UT Austin, der UC Berkeley, von Google und Ampere Computing (arXiv:2601.11786) vermittelt uns einen Eindruck davon, welche Kosten die Implementierung von MTE in realer Hardware verursacht, und zeigt gleichzeitig auf, welche Einsparungen ein Unternehmen erzielt, wenn es darauf verzichtet.

Die „Sticky Notes“ selbst sind recht klein: 4 Bit pro 16 Byte Speicher, was einem Overhead von etwa 3,125 % entspricht. Das Regelwerk von ARM legt nicht fest, wo Chiphersteller diese „Sticky Notes“ speichern müssen, sondern lediglich, dass sie irgendwo vorhanden sein müssen. Aus diesem Grund gehen die Unternehmen unterschiedlich vor. Das ARM-eigene Referenzdesign reserviert einen dedizierten RAM-Bereich und führt bei einem Cache-Fehler zwei separate Speicherabrufe durch – einen für die Daten und einen für die zugehörige Notiz. Ampere, ein Hersteller von Serverchips, bündelt die Notizen stattdessen mit Bits, die normalerweise zur Fehlerkorrektur verwendet werden, und ruft die Daten und die Notiz gemeinsam in einem einzigen Vorgang ab. Keiner der beiden Ansätze ist besser oder schlechter, ARM hat diese Flexibilität bewusst eingebaut.

Der größere Aufwand entsteht nicht durch die zusätzlichen 3,125 % Speicher, die auf dem Chip benötigt werden, sondern durch die zusätzliche Arbeit, die der Chip bei jedem Speicherzugriff leisten muss. Jedes Mal, wenn das Smartphone auf den Speicher zugreift, muss es dieses kleine Tag überprüfen, was einen eigenen Vergleichsschaltkreis erfordert. Um Tags zufällig zuzuweisen, sodass Angreifer sie nicht vorhersagen können, ist ein in den Chip integrierter Zufallszahlengenerator erforderlich und ein schneller Generator mit ausreichender Entropie lässt sich nur schwer realisieren, ohne Abstriche zu machen. Einige spezielle Befehle zum Schreiben von Tags benötigen einen eigenen Pfad durch den Chip, anstatt den normalen Pfad wiederzuverwenden.
 

MTE für Dummys

Stellen Sie sich einen Out-of-Order-CPU-Kern wie eine Küche vor, in der mehrere Köche gleichzeitig an verschiedenen Teilen einer Bestellung arbeiten: Nicht unbedingt in der Reihenfolge, in der die Bestellung eingegangen ist, solange nichts von etwas abhängt, das noch nicht fertig ist. So bleibt ein moderner Out-of-Order-Kern normalerweise schnell: Er wartet nicht untätig herum, sondern bearbeitet alles, was er kann, während langsamere Schritte aufholen. Der strenge SYNC-Modus von MTE macht in einem wichtigen Teil dieser Küche allerdings einen Strich durch die Rechnung: beim Schreiben in den Speicher. Normalerweise kann ein Kern Daten in den Speicher schreiben und gleichzeitig an den nächsten Befehlen weiterarbeiten, während der Schreibvorgang im Hintergrund abgeschlossen wird. 

Im MTE-SYNC-Modus muss jedoch bei jedem Schreibvorgang zunächst das zugehörige kleine Tag überprüft und als gültig bestätigt werden. Solange diese Überprüfung nicht abgeschlossen ist, darf der Kern nicht zum nächsten Schreibvorgang übergehen. Es ist nicht so, dass die gesamte Küche zum Stillstand kommt: Das Kochen (Lesevorgänge, Berechnungen, Verzweigungen usw.) läuft weiterhin problemlos außer der Reihenfolge. Es ist speziell der Schritt „den fertigen Teller abstellen“, der nun nacheinander und der Reihe nach erfolgen muss, während jedes Mal auf eine Tag-Prüfung gewartet werden muss. Code etwa, der in einer engen Schleife wiederholt in den Speicher schreibt, spürt dies ständig. Genau deshalb verlangsamten sich einige Benchmarks um das bis zu 6,64-Fache. Code, der hauptsächlich liest, berechnet oder verzweigt, bemerkt dies kaum, da der Teil der Pipeline, der langsamer geworden ist, nicht der Teil ist, auf den er sich stützt.

Selbst im Lightweight-Modus von MTE verzeichnete der reguläre „Big“-Kern noch Verlangsamungen von bis zu 1,82x und genau diesen Modus nutzt Googles eigene „Advanced Protection“-Funktion derzeit. Demgegenüber spüren sowohl der Server-Chip von Ampere als auch Apples neuer M5 die Aktivierung von MTE kaum – mit einem durchschnittlichen Overhead von nur 2–3 % und einer Verlangsamung von höchstens 10 % im schlimmsten Fall. Diese Diskrepanz beweist, dass der durch MTE verursachte Geschwindigkeitseinbruch kein unvermeidbares physikalisches Gesetz ist. Er spiegelt vielmehr wider, wie gut (oder schlecht) die Ingenieure eines bestimmten Chips die Funktion implementiert haben. Und wie wir die Tensor-SoCs historisch kennen, erwarten wir keine großen Wunder und vermuten, dass der Performance-Einbruch durch MTE wohl zu groß war.
 

Wenn im Bootloader des Pixel 11 nach denselben Elementen gesucht wird, wurde dagegen nichts gefunden, nicht die geringste Spur. Das ist ein recht aussagekräftiger Unterschied: Hätte Google lediglich einen Schalter umgelegt, um MTE zu deaktivieren, würde man erwarten, diese Funktionsnamen und Meldungen im Code dennoch zu finden wenn auch ungenutzt. Ihr völliges Fehlen deutet eher darauf hin, dass der Code vollständig entfernt und nicht nur deaktiviert wurde. Dies bestätigt genau das, was GrapheneOS nach dem Abbruch seiner Portierung auf die Pixel 11 Reihe erklärt hat.
 

Unabhängig vom Google-Drama steht GrapheneOS kurz vor dem Abschluss einer Vereinbarung mit Motorola, um das Betriebssystem erstmals auf einem Nicht-Pixel-Smartphone zu etablieren, während auch Qualcomm damit begonnen hat, die neuesten Flaggschiff-Chips, etwa den Snapdragon 8 Elite Gen 5, mit MTE-Unterstützung auszustatten. NotebookCheck hat erfahren, dass Motorola an einem Flaggschiff-Smartphone mit dem internen Codenamen „Wukong“ arbeitet, das auf dem Snapdragon 8 Elite Extreme Gen 6 (SM8975) basieren soll, der am 22. September auf dem Snapdragon Summit vorgestellt werden soll. 

Derzeit ist "Wukong" unserer Recherche nach das einzige Motorola-Gerät, das auf Basis dieses Chips geplant ist. Sollten sich die Hinweise bewahrheiten, wäre dieses Motorola-Flaggschiff das erste Smartphone, das eine vollwertige MTE-Unterstützung, einen Qualcomm-Flaggschiff-Chip und GrapheneOS-Unterstützung miteinander vereint - beim Pixel 11 Pro wäre das aus heutiger Sicht nicht möglich. Wie immer bei unbestätigten Hinweisen die Warnung: In dieser frühen Entwicklungsphase stammen die Spezifikationen und sogar der Codename „Wukong“ aus internen Unterlagen und können sich noch ändern, Motorola hat die Existenz des Smartphones noch nicht bestätigt.

Für den Durchschnittsnutzer, der ein Pixel 11 oder Pixel 11 Pro erwirbt, ist der Verlust von MTE unserer Meinung nach nicht die Katastrophe, als die sie von GrapheneOS dargestellt wird. MTE ist probabilistisch (auf Wahrscheinlichkeit beruhend) und keine feste Garantie. Es besteht eine Wahrscheinlichkeit von 1 zu 16, dass ein bestimmter Zugriff außerhalb des zulässigen Bereichs die Tag-Prüfung vollständig umgeht. Laut "ARM MTE Performance in Practicee" (TikTag) wurde die Tag-Vertraulichkeit auf echter Pixel-Hardware mithilfe spekulativer Ausführung umgangen, was bedeutet, dass selbst der gebotene Schutz in der Praxis nicht so zuverlässig ist, wie „15/16“ vermuten lässt. Und – was entscheidend ist – fast keiner der Exploits, um die sich ein durchschnittlicher Smartphone-Besitzer tatsächlich Sorgen machen muss, ist überhaupt ein Speicher-Sicherheitsfehler. Phishing, bösartige App-Berechtigungen, SIM-Swapping, Stalkerware und Kontoübernahmen – nichts davon fällt unter den Schutzbereich von MTE. Selbst GrapheneOS räumt ein, dass die Abdeckung für Apps von Drittanbietern nur auf Wunsch aktiviert wird und selten genutzt wird. Signal etwa schaltet sie nicht ein.

Wo MTE tatsächlich sehr nützlich ist, sind jene Bedrohungsmodelle, für die GrapheneOS ursprünglich konzipiert wurde: teure, auf Zuverlässigkeit angewiesene Zero-Click-Exploit-Ketten – jene Art, die für Millionen von Dollar verkauft und fast ausschließlich gegen Journalisten, Dissidenten und staatliche Ziele eingesetzt werden, nicht gegen den Durchschnittsverbraucher. Das ist ein realer und wichtiger Anwendungsfall. Er ist nur auf wenige Menschen begrenzt. Ein Smartphone, das abstürzt, anstatt heimlich kompromittiert zu werden, ist eine wirklich große Errungenschaft, wenn Sie ein Hochrisikoziel sind, das von einem staatlichen Akteur überwacht wird. Es ist weitaus weniger relevant, wenn Ihr tatsächliches Risiko darin besteht, Ihr Smartphone in einer Bar zu verlieren oder auf einen schädlichen Link in einer SMS zu klicken. Gute OPSEC (operative Sicherheit) zu praktizieren, etwa einzigartige Passwörter zu verwenden, zufällige QR-Codes zu meiden und Ihre persönlichen Daten nicht auf jeder Website zu verstreuen, die danach fragt, leistet für die meisten Menschen im Alltag mehr Schutz als es jede Speichersicherheitsfunktion auf Siliziumebene jemals tun wird.

Nichts davon macht die Silizium-Regression des Pixel 11 zu einer Nichtigkeit. Die Nutzerbasis von GrapheneOS ist genau die Zielgruppe, für die dies am wichtigsten ist, und der Verlust der Unterstützung für eine ganze Generation von Pixel-Geräten ist ein echter Rückschlag für dieses Projekt. Man sollte jedoch ehrlich sein: MTE wirkt viel eher wie eine hochwertige Schutzmaßnahme für Unternehmen oder Nutzer mit hohem Risiko, die zufällig in Verbraucher-Chips gelandet ist, als wie eine Funktion, deren Fehlen der durchschnittliche Käufer eines Pixel 11 jemals bemerken wird. Und es liegt eine gewisse Ironie darin, dass Google jenes Unternehmen war, das MTE überhaupt erst in den Mainstream gebracht hat, indem es die Technologie in Tensor integrierte, noch bevor fast alle anderen Android-Anbieter dies taten, die Forschung dazu finanzierte und einen ganzen Sicherheitsmodus darum herum aufbaute. Nun deuten die vorliegenden Hinweise darauf, dass Google MTE in den Tensor G6 integriert, detailliert dokumentiert und dann vor der Markteinführung stillschweigend gestrichen hat.