Uit gelekte documenten blijkt dat Google een belangrijke beveiligingsfunctie voor de Pixel 11 voor GrapheneOS had gepland, maar deze vervolgens heeft geschrapt

GrapheneOS, de op privacy gerichte Android-fork die al jaren exclusief op de Pixel-telefoons van Google wordt geleverd, zegt dat het de nieuwe Pixel 11-serie niet naar behoren kan ondersteunen. Na een week lang te hebben geprobeerd een port met geweld te realiseren, ontdekte het team dat de Tensor G6-chip van de Pixel 11 geen hardware-ondersteuning biedt voor de zogenaamde Memory Tagging Extension, of MTE, een beveiligingsfunctie die elke Pixel-chip sinds de Pixel 8 in 2023 heeft gehad.

Dit is in grote lijnen wat MTE doet: het geheugen van uw telefoon bestaat uit een enorm raster van kleine opslagvakjes. Veel beveiligingslekken werken door een app te misleiden, zodat deze uit het verkeerde vakje leest of ernaar schrijft – een vakje dat het eigenlijk niet mocht aanraken. MTE voorkomt dit door een onzichtbaar notitiebriefje te plakken op elk geheugenblok van 16 bytes en op elke pointer die toegang daartoe mag hebben. Als de notitiebriefjes niet overeenkomen wanneer een programma probeert te lezen of te schrijven, trekt de chip hard aan de rem en wordt het proces beëindigd, in plaats van de exploit stilletjes door te laten gaan. GrapheneOS maakt in het gehele besturingssysteem gebruik van MTE en stelt dat hierdoor hele categorieën van hackpogingen op afstand worden onschadelijk gemaakt nog voordat ze überhaupt van start kunnen gaan. Het team zegt dat het erop lijkt dat Google MTE uit de Pixel 11 heeft verwijderd om geld te besparen; Google heeft hier geen commentaar op gegeven. GrapheneOS raadt mensen nu aan de Pixel 11 over te slaan en in plaats daarvan een Pixel 8, 9 of 10 aan te schaffen als zij GrapheneOS willen gebruiken.

Een onderzoeksartikel van onderzoekers van UT Austin, UC Berkeley, Google en Ampere Computing (arXiv:2601.11786) geeft ons een idee van wat de implementatie van MTE in echte hardware kost, wat ons tevens laat zien wat een bedrijf bespaart door hiervan af te zien.

De ‘sticky notes’ zelf zijn vrij klein: 4 bits per 16 bytes geheugen, ofwel ongeveer 3,125% overhead. In de richtlijnen van ARM staat niet vermeld waar chipfabrikanten deze ‘sticky notes’ moeten opslaan, alleen dat ze ergens moeten bestaan. Daarom pakken bedrijven dit op verschillende manieren aan. Het eigen referentieontwerp van ARM reserveert een specifiek deel van het RAM-geheugen en voert bij een cachemiss twee afzonderlijke geheugenopvragingen uit: één voor de gegevens en één voor de bijbehorende sticky note. Ampere, dat serverchips produceert, koppelt de sticky notes daarentegen aan bits die normaal gesproken worden gebruikt voor foutcorrectie en haalt de gegevens en de sticky note in één keer op. Geen van beide benaderingen is correcter; ARM heeft die flexibiliteit bewust ingebouwd.

De grootste kostenpost is niet de extra 3,125% geheugen die op de chip nodig is, maar het extra werk dat de chip bij elke geheugentoegang moet verrichten. Telkens wanneer uw telefoon het geheugen benadert, moet het dat kleine label controleren, wat speciale vergelijkingsschakelingen vereist. Om tags willekeurig toe te wijzen zodat aanvallers deze niet kunnen voorspellen, is een in de chip ingebouwde random number generator nodig; en een snelle generator met voldoende entropie is moeilijk te bouwen zonder concessies te doen. Enkele speciale instructies voor het schrijven van tags hebben een eigen pad door de chip nodig in plaats van het normale pad te hergebruiken.

Stelt u zich een out-of-order CPU-kern voor als een keuken met meerdere koks die tegelijkertijd aan verschillende onderdelen van een bestelling werken, niet noodzakelijkerwijs in de volgorde waarin de bestelling binnenkwam, zolang niets afhankelijk is van iets dat nog niet klaar is. Dat is normaal gesproken hoe een moderne out-of-order-kern snel blijft: hij wacht niet af, maar werkt aan wat hij kan terwijl tragere stappen hun achterstand inhalen.

De strikte SYNC-modus van MTE gooit roet in het eten voor één onderdeel van die keuken: het schrijven naar het geheugen. Normaal gesproken kan een kern gegevens naar het geheugen schrijven en doorgaan met de volgende instructies terwijl dat schrijfproces op de achtergrond wordt voltooid. Maar in de MTE SYNC-modus moet bij elke schrijfbewerking eerst het bijbehorende label worden gecontroleerd en als geldig worden bevestigd, en zolang die controle niet is afgerond, mag de kern niet doorgaan naar de volgende schrijfbewerking. Het is niet zo dat de hele keuken tot stilstand komt: het koken (lezen, rekenen, vertakken, enz.) gaat prima door in willekeurige volgorde. Het is specifiek de stap „het afgewerkte bord neerzetten“ die nu één voor één, in volgorde, moet plaatsvinden, terwijl elke keer op een tagcontrole moet worden gewacht. Code die herhaaldelijk in een strakke lus naar het geheugen schrijft, ondervindt hier voortdurend hinder van, en dat is precies de reden waarom sommige benchmarks tot wel 6,64 keer trager werden. Code die voornamelijk leest, berekent of vertakt, merkt hier nauwelijks iets van, omdat het deel van de pijplijn dat trager is geworden, niet het deel is waarop deze code steunt.

Zelfs in de lichtgewichtmodus van MTE ondervond de reguliere „Big“-kern nog steeds vertragingen tot 1,82x, en dit is precies de modus die Google’s eigen Advanced Protection-functie momenteel gebruikt. Ondertussen merkten zowel de serverchip van Ampere als de nieuwe M5 van Apple nauwelijks dat MTE was ingeschakeld, met gemiddeld slechts 2–3% overhead en een vertraging van maximaal 10% in het slechtste geval. Dit verschil bewijst dat deze vertragingen geen onvermijdelijke natuurkundige wet zijn; ze weerspiegelen hoe goed (of slecht) de ingenieurs van een bepaalde chip de functie hebben geïmplementeerd. En gezien wat we van Tensor weten, verwachten we er niet veel van.

Zoekt u naar dezelfde zaken in de bootloader van de Pixel 11, dan vindt u niets. Geen enkel spoor. Dat is een veelzeggend verschil: als Google alleen maar een schakelaar had omgezet om MTE uit te schakelen, zou u nog steeds verwachten dat die functienamen en berichten in de code aanwezig zouden zijn, zij het ongebruikt. Hun totale afwezigheid suggereert dat de code volledig is verwijderd, en niet alleen is uitgeschakeld. Dat bevestigt precies wat GrapheneOS zei nadat het de port had opgegeven.

Los daarvan legt GrapheneOS de laatste hand aan een overeenkomst met Motorola om het besturingssysteem voor het eerst op een niet-Pixel-telefoon beschikbaar te maken, terwijl Qualcomm is begonnen met het toevoegen van MTE-ondersteuning aan zijn nieuwste chips, waaronder de Snapdragon 8 Elite Gen 5.

NotebookCheck heeft vernomen dat Motorola werkt aan een vlaggenschip-telefoon met de interne codenaam „Wukong“, gebouwd rond de volgende vlaggenschip-chip van Qualcomm, de Snapdragon 8 Elite Extreme Gen 6 (SM8975), die op 22 september tijdens de Snapdragon Summit volledig zal worden onthuld. Op dit moment is dit het enige Motorola-toestel dat rond die chip is gepland. Mocht de Wukong uiteindelijk de lanceringstelefoon van GrapheneOS bij Motorola worden, dan wordt het de eerste telefoon die volwaardige MTE-ondersteuning, een vlaggenschipchip van Qualcomm en ondersteuning voor GrapheneOS combineert – iets wat u momenteel niet kunt krijgen op een Pixel 11, hoeveel u er ook aan uitgeeft.

De gebruikelijke kanttekening is hier op zijn plaats: in dit vroege stadium van de ontwikkeling zijn de specificaties en zelfs de codenaam „Wukong“ afkomstig uit intern materiaal en kunnen deze nog veranderen voordat er iets officieel is. Motorola heeft het bestaan van de telefoon nog niet bevestigd.

Voor de gemiddelde koper van een Pixel 11 denk ik niet dat het verlies van MTE de ramp is die dit artikel misschien doet vermoeden.

MTE is probabilistisch, geen harde garantie. Er is een kans van 1 op 16 dat een bepaalde toegang buiten de toegestane grenzen volledig aan de tagcontrole ontsnapt, en onderzoek dat in hetzelfde artikel wordt aangehaald (TikTag) heeft de geheimhouding van tags op echte Pixel-hardware doorbroken met behulp van speculatieve uitvoering, wat betekent dat zelfs de bescherming die het biedt in de praktijk niet zo betrouwbaar is als „15/16“ suggereert. En, wat cruciaal is: bijna geen van de kwetsbaarheden waar een gemiddelde telefoonbezitter zich daadwerkelijk zorgen over hoeft te maken, betreft in de eerste plaats geheugenveiligheidsfouten. Phishing, schadelijke app-machtigingen, sim-swapping, stalkerware en het overnemen van accounts: geen van deze zaken valt onder de bescherming die MTE biedt. Zelfs GrapheneOS geeft toe dat de dekking voor apps van derden opt-in is en zelden wordt gebruikt; Signal schakelt deze functie niet in.

Waar MTE zijn waarde daadwerkelijk bewijst, is in het bedreigingsmodel waarvoor GrapheneOS zelf is ontworpen: dure, op betrouwbaarheid gebaseerde zero-click-exploitketens, het soort dat voor miljoenen dollars wordt verkocht en vrijwel uitsluitend wordt ingezet tegen journalisten, dissidenten en overheidsdoelen, niet tegen de gemiddelde consument. Dat is een reëel en belangrijk gebruiksscenario. Het is alleen een beperkt scenario. Een telefoon die crasht in plaats van stilletjes te worden gehackt, is echt van groot belang als u een doelwit met een hoog risico bent dat door een staatsactor wordt geschaduwd. Het is een stuk minder relevant als uw daadwerkelijke risico bestaat uit het kwijtraken van uw telefoon in een café of het klikken op een schadelijke link in een sms. Het naleven van goede OPSEC, het gebruik van unieke wachtwoorden, het vermijden van willekeurige QR-codes en het niet verspreiden van uw persoonlijke gegevens over elke website die erom vraagt, bieden voor de meeste mensen in de praktijk meer bescherming dan welke geheugenbeveiligingsfunctie op chipniveau dan ook ooit zal doen.

Dat neemt niet weg dat de achteruitgang in de chiptechnologie van de Pixel 11 een belangrijk onderwerp is. Het gebruikersbestand van GrapheneOS bestaat precies uit de groep voor wie dit het belangrijkst is, en het verlies van ondersteuning voor een hele generatie Pixel-toestellen is een serieuze tegenslag voor dat project. Maar het is eerlijk om te zeggen dat MTE veel meer lijkt op een hoogwaardige beveiligingsmaatregel voor ondernemingen of gebruikers met een hoog risico die toevallig in consumentenchips terecht is gekomen, dan op een functie waarvan de gemiddelde koper van een Pixel 11 het ontbreken ooit zal opmerken. En er schuilt enige ironie in de manier waarop Google in deze situatie terecht is gekomen: het was juist dit bedrijf dat MTE in de eerste plaats naar de mainstream heeft gebracht, door het in Tensor te integreren nog voordat bijna iedereen in de Android-wereld dat deed, door onderzoek hiernaar te financieren en door er een volledige beveiligingsmodus omheen te bouwen. Nu wijzen zijn eigen interne documenten erop dat het MTE in zijn volgende chip heeft ingebouwd, er gedetailleerd verslag van heeft gedaan en het vervolgens stilletjes heeft geschrapt vóór de lancering. Niemand heeft Google op dit punt technisch overtroffen. Het heeft zichzelf technisch gezien deze functie ontnomen.