Läckta dokument visar att Google planerade och sedan strök en viktig säkerhetsfunktion för Pixel 11 i GrapheneOS

GrapheneOS, den integritetsförstärkta Android-forken som i flera år har levererats exklusivt på Googles Pixel-telefoner, säger att den inte kan stödja den nya Pixel 11-serien på rätt sätt. Efter en vecka av försök att tvinga fram en portning upptäckte teamet att Tensor G6-chipet i Pixel 11 saknar hårdvarustöd för något som kallas Memory Tagging Extension, eller MTE, en säkerhetsfunktion som alla Pixel-chip har haft sedan Pixel 8 år 2023.

Så här fungerar MTE i korthet: telefonens minne är ett enormt rutnät av små lagringsrutor. Många säkerhetsluckor utnyttjas genom att lura en app att läsa från eller skriva till fel ruta, en som den inte skulle ha rört. MTE förhindrar detta genom att sätta en osynlig lapp på varje 16-byte-block i minnet och på varje pekare som har behörighet att komma åt det. Om lapparna inte stämmer överens när ett program försöker läsa eller skriva, slår chipet på bromsarna och avbryter processen istället för att tyst låta säkerhetsluckan passera. GrapheneOS använder MTE i hela sitt operativsystem och hävdar att det sätter stopp för hela kategorier av fjärrhackningsförsök innan de ens hinner börja. Teamet säger att det verkar som om Google har tagit bort MTE från Pixel 11 för att spara pengar; Google har inte kommenterat saken. GrapheneOS uppmanar nu användare att hoppa över Pixel 11 och istället köpa en Pixel 8, 9 eller 10 om de vill köra GrapheneOS.

En forskningsrapport av forskare från UT Austin, UC Berkeley, Google och Ampere Computing (arXiv:2601.11786) ger oss en uppfattning om vad det kostar att implementera MTE i verklig hårdvara, vilket också visar vad ett företag sparar genom att hoppa över det.

Själva ”klisterlapparna” är ganska små: 4 bitar för varje 16 byte minne, eller cirka 3,125 % overhead. ARMs regelverk anger inte var chipstillverkarna måste lagra dessa ”klisterlappar”, bara att de måste finnas någonstans. Det är därför företagen gör det på olika sätt. ARMs egen referensdesign avsätter en särskild del av RAM-minnet och utför två separata minneshämtningar vid en cachemiss, en för data och en för den tillhörande anteckningen. Ampere, som tillverkar serverchip, lägger istället anteckningarna på bitar som normalt används för felkorrigering och hämtar data och anteckningen tillsammans i ett enda steg. Ingen av metoderna är mer korrekt; ARM byggde in den flexibiliteten medvetet.

Den största kostnaden är inte de extra 3,125 % minne som behövs på chipet, utan det extra arbete som chipet måste utföra vid varje minnesåtkomst. Varje gång din telefon använder minnet måste den kontrollera den lilla etiketten, vilket kräver särskilda jämförelsekretsar. Att tilldela taggar slumpmässigt så att angripare inte kan förutsäga dem kräver en slumptalsgenerator inbyggd i chipet, och en snabb sådan med tillräcklig entropi är svår att bygga utan att ta genvägar. Några speciella instruktioner för att skriva taggar behöver en egen väg genom chipet istället för att återanvända den normala vägen.

Tänk på en out-of-order-processorkärna som ett kök där flera kockar arbetar samtidigt med olika delar av en beställning, inte nödvändigtvis i den ordning beställningen kom in, så länge inget är beroende av något som ännu inte är klart. Det är normalt så en modern out-of-order-kärna håller sig snabb: den väntar inte, utan arbetar med vad den kan medan långsammare steg hinner ikapp.

MTE:s strikta SYNC-läge sätter käppar i hjulet för en del av det där köket: skrivning till minnet. Normalt kan en kärna skriva data till minnet och fortsätta arbeta med de kommande instruktionerna medan skrivningen avslutas i bakgrunden. Men i MTE:s SYNC-läge måste varje skrivning först få sin lilla tagg kontrollerad och bekräftad som giltig, och tills den kontrollen är klar får kärnan inte gå vidare till nästa skrivning. Det är inte så att hela köket stannar upp: matlagningen (läsningar, beräkningar, förgreningar osv.) fortsätter utan problem i oordning. Det är specifikt steget ”ställa ner den färdiga tallriken” som nu måste ske ett i taget, i ordning, samtidigt som man varje gång väntar på en taggkontroll. Kod som skriver till minnet upprepade gånger i en tät slinga märker detta hela tiden, vilket är precis anledningen till att vissa prestandatester saktade ner med upp till 6,64 gånger. Kod som främst läser, beräknar eller förgrenar märker knappt något, eftersom den del av pipelinen som blev långsammare inte är den del som den är beroende av.

Även i MTE:s lättviktsläge upplevde den vanliga ”Big”-kärnan fortfarande avmattningar på upp till 1,82 gånger, och detta är exakt det läge som Googles egen Advanced Protection-funktion använder idag. Samtidigt märkte varken Ampere-serverchipet eller Apples nya M5 knappt att MTE var aktiverat, med en genomsnittlig overhead på endast 2–3 % och en försämring på högst 10 % i värsta fall. Denna skillnad bevisar att dessa fördröjningar inte är någon oundviklig fysikalisk lag; de speglar hur väl (eller dåligt) ingenjörerna bakom en viss chip har implementerat funktionen. Och med tanke på Tensor förväntar vi oss inte mycket av den.

Sök efter samma saker i Pixel 11:s bootloader så hittar du ingenting. Inte ett enda spår. Det är en ganska betydande skillnad: om Google bara hade tryckt på en knapp för att stänga av MTE, skulle man fortfarande förvänta sig att hitta dessa funktionsnamn och meddelanden kvar i koden, bara oanvända. Deras totala frånvaro tyder på att koden har tagits bort helt, inte bara stängts av. Det stöder exakt vad GrapheneOS sa efter att ha gett upp sin portning.

I ett annat sammanhang håller GrapheneOS på att slutföra ett avtal med Motorola för att för första gången lansera operativsystemet på en telefon som inte är en Pixel, medan Qualcomm har börjat lägga till MTE-stöd i sina senaste chip, däribland Snapdragon 8 Elite Gen 5.

NotebookCheck har fått veta att Motorola arbetar med en flaggskeppstelefon med det interna kodnamnet ”Wukong”, byggd kring Qualcomms nästa flaggskeppschip, Snapdragon 8 Elite Extreme Gen 6 (SM8975), som ska presenteras i sin helhet vid Snapdragon Summit den 22 september. För närvarande är det den enda Motorola-enheten som planeras kring det chipet. Om Wukong blir den telefon med vilken GrapheneOS lanseras tillsammans med Motorola, kommer den att vara den första telefonen som kombinerar fullständigt MTE-stöd, en flaggskeppschip från Qualcomm och stöd för GrapheneOS – något som man för närvarande inte kan få på en Pixel 11, oavsett hur mycket man betalar.

Det vanliga förbehållet gäller: så här tidigt i utvecklingen kommer specifikationerna och till och med kodnamnet ”Wukong” från internt material och kan fortfarande ändras innan något blir officiellt. Motorola har inte bekräftat att telefonen existerar.

För den genomsnittliga personen som köper en Pixel 11 tror jag inte att förlusten av MTE är den katastrof som den här artikeln kan få det att låta som.

MTE är probabilistiskt, inte en absolut garanti. Det finns en chans på 1 av 16 att en viss åtkomst utanför gränserna helt undgår taggkontrollen, och forskning som citeras i samma artikel (TikTag) bröt taggens sekretess på riktig Pixel-hårdvara med hjälp av spekulativ exekvering, vilket innebär att inte ens det skydd den erbjuder är så tillförlitligt i praktiken som ”15/16” antyder. Och, vilket är avgörande, nästan inga av de säkerhetsluckor som en vanlig telefonägare faktiskt behöver oroa sig för är minnessäkerhetsfel från början. Nätfiske, skadliga appbehörigheter, SIM-byten, stalkerware och kontoövertaganden – inget av detta berör det som MTE skyddar mot. Till och med GrapheneOS självt medger att täckningen för tredjepartsappar är valfri och sällan används; Signal aktiverar den inte.

Där MTE verkligen gör nytta är i den hotmodell som GrapheneOS själv är byggt för: dyra, tillförlitlighetsberoende ”zero-click”-exploitkedjor, den typ som säljs för miljoner dollar och används nästan uteslutande mot journalister, dissidenter och statliga mål, inte den genomsnittlige konsumenten. Det är ett verkligt och viktigt användningsfall. Det är bara ett smalt sådant. En telefon som kraschar istället för att i smyg tas över är verkligen en stor sak om du är ett högriskmål som övervakas av en statlig aktör. Det är betydligt mindre relevant om din faktiska risk är att tappa bort telefonen på en bar eller klicka på en skadlig länk i ett sms. Att iaktta god OPSEC, använda unika lösenord, undvika slumpmässiga QR-koder och inte sprida ut sina personuppgifter på varje webbplats som ber om dem ger för de flesta människor ett bättre skydd i verkligheten än vad någon minnessäkerhetsfunktion på kisel-nivå någonsin kommer att göra.

Inget av detta innebär att Pixel 11:s kiselregression är en icke-nyhet. GrapheneOS:s användarbas är precis den grupp för vilken detta är viktigast, och att förlora en hel generation av Pixel-stöd är ett rejält bakslag för det projektet. Men det är värt att vara ärlig och konstatera att MTE i mycket högre grad framstår som en värdefull säkerhetsåtgärd för företag eller högriskanvändare som råkade hamna i konsumentkretsar än som en funktion vars avsaknad den genomsnittliga personen som köper en Pixel 11 någonsin kommer att märka. Och det finns en viss ironi i hur Google hamnade här: det var företaget som från början drev MTE in i mainstream, genom att leverera det i Tensor innan nästan någon annan inom Android, finansiera forskning kring det och bygga ett helt säkerhetsläge kring det. Nu tyder dess egna interna dokument på att företaget byggde in MTE i sin nästa chip, beskrev det i detalj och sedan tyst tog bort det före lanseringen. Ingen överträffade Google tekniskt i det här fallet. Företaget överträffade sig självt så pass att funktionen helt enkelt försvann.