Documenti trapelati rivelano che Google aveva pianificato e poi eliminato una funzione di sicurezza fondamentale del Pixel 11 per GrapheneOS

GrapheneOS, il fork di Android ottimizzato per la privacy e fornito in esclusiva sugli smartphone Pixel di Google da anni, afferma di non poter supportare adeguatamente la nuova serie Pixel 11. Dopo una settimana trascorsa a tentare di forzare il porting, il team ha scoperto che il chip Tensor G6 del Pixel 11 non dispone del supporto hardware per una funzionalità denominata Memory Tagging Extension, o MTE, una caratteristica di sicurezza presente in tutti i chip Pixel a partire dal modello Pixel 8 del 2023.

Ecco, in sostanza, come funziona MTE: la memoria del Suo telefono è un’enorme griglia composta da piccole caselle di archiviazione. Molti exploit funzionano ingannando un’applicazione affinché legga o scriva in una casella sbagliata, una a cui non avrebbe dovuto accedere. L’MTE impedisce che ciò accada apponendo un’etichetta invisibile su ogni blocco di memoria da 16 byte e su ogni puntatore autorizzato ad accedervi. Se le etichette non corrispondono quando un programma tenta di leggere o scrivere, il chip interviene bruscamente, terminando il processo invece di lasciare passare silenziosamente l’exploit. GrapheneOS utilizza l’MTE in tutto il proprio sistema operativo e sostiene che questa tecnologia elimini intere categorie di tentativi di hacking remoto prima ancora che possano avere inizio. Il team sostiene che sembri che Google abbia rimosso l’MTE dal Pixel 11 per risparmiare; Google non ha rilasciato commenti. GrapheneOS sta ora consigliando agli utenti di evitare il Pixel 11 e di acquistare invece un Pixel 8, 9 o 10 se desiderano utilizzare GrapheneOS.

Un articolo di ricerca redatto da ricercatori dell’Università del Texas ad Austin, dell’Università della California a Berkeley, di Google e di Ampere Computing (arXiv:2601.11786) ci offre un’idea dei costi di implementazione dell’MTE su hardware reale, indicandoci al contempo il risparmio che un’azienda ottiene rinunciandovi.

Le «sticky note» stesse sono piuttosto piccole: 4 bit ogni 16 byte di memoria, ovvero circa il 3,125% di overhead. Il regolamento di ARM non specifica dove i produttori di chip debbano memorizzare queste «sticky note», ma solo che devono esistere da qualche parte. Ecco perché le aziende adottano approcci diversi. Il progetto di riferimento di ARM stesso riserva un blocco dedicato di RAM ed esegue due operazioni separate di recupero dalla memoria in caso di cache miss, una per i dati e una per la relativa nota adesiva. Ampere, che produce chip per server, invece appone le note sui bit normalmente utilizzati per la correzione degli errori e recupera i dati e la nota insieme in un unico ciclo. Nessuno dei due approcci è più corretto dell’altro; ARM ha integrato tale flessibilità appositamente.

Il costo maggiore non è rappresentato dal 3,125% in più di memoria necessaria sul chip, bensì dal lavoro aggiuntivo che il chip deve svolgere ad ogni accesso alla memoria. Ogni volta che il vostro telefono accede alla memoria, deve verificare quel piccolo tag, il che richiede circuiti di confronto dedicati. L’assegnazione casuale dei tag, in modo che gli hacker non possano prevederli, richiede un generatore di numeri casuali integrato nel chip; tuttavia, è difficile realizzarne uno veloce con entropia sufficiente senza scendere a compromessi. Alcune istruzioni speciali per la scrittura dei tag necessitano di un percorso dedicato all’interno del chip, anziché riutilizzare il percorso normale.

Immaginate un core di CPU out-of-order come una cucina in cui diversi cuochi lavorano contemporaneamente su diverse parti di un ordine, non necessariamente nell’ordine in cui è stato ricevuto, purché nulla dipenda da qualcosa che non è ancora pronto. È così che normalmente un moderno core out-of-order mantiene la propria velocità: non rimane in attesa, ma lavora su tutto ciò che può mentre le fasi più lente recuperano il ritardo.

La modalità SYNC rigorosa di MTE complica una parte di quella cucina: la scrittura in memoria. Normalmente, un core può scrivere dati in memoria e continuare a lavorare sulle istruzioni successive mentre la scrittura viene completata in background. Tuttavia, in modalità SYNC di MTE, ogni scrittura richiede innanzitutto che il proprio piccolo tag venga controllato e confermato come valido; finché tale controllo non viene superato, al core non è consentito passare alla scrittura successiva. Non è che l’intera cucina si blocchi: la preparazione (letture, calcoli, ramificazioni, ecc.) prosegue senza problemi in modo fuori ordine. È specificamente la fase di «posare il piatto pronto» che ora deve avvenire una alla volta, in ordine, in attesa di una verifica del tag ogni singola volta. Il codice che scrive ripetutamente in memoria in un ciclo stretto ne risente costantemente, ed è proprio per questo che alcuni benchmark hanno registrato un rallentamento fino a 6,64 volte. Il codice che si occupa principalmente di letture, calcoli o ramificazioni se ne accorge a malapena, poiché la parte della pipeline che ha subito un rallentamento non è quella su cui fa affidamento.

Anche nella modalità leggera di MTE, il normale core «Big» ha comunque registrato rallentamenti fino a 1,82 volte superiori, e questa è esattamente la modalità attualmente utilizzata dalla funzione Advanced Protection di Google. Nel frattempo, sia il chip per server di Ampere che il nuovo M5 di Apple hanno percepito a malapena l’attivazione dell’MTE, registrando in media solo un sovraccarico del 2–3%, con un rallentamento nel caso peggiore del 10%. Questo divario dimostra che tali rallentamenti non sono una sorta di legge fisica inevitabile; essi riflettono piuttosto quanto bene (o male) gli ingegneri di un determinato chip abbiano implementato la funzionalità. E, conoscendo Tensor, non ci aspettiamo granché da esso.

Cercate gli stessi elementi nel bootloader del Pixel 11 e non otterrete nulla. Non c’è traccia alcuna. Si tratta di una differenza piuttosto significativa: se Google avesse semplicemente premuto un pulsante per disattivare l’MTE, ci si aspetterebbe comunque di trovare quei nomi di funzioni e quei messaggi presenti nel codice, anche se inutilizzati. La loro totale assenza suggerisce che il codice sia stato rimosso completamente, non semplicemente disattivato. Ciò conferma esattamente quanto affermato da GrapheneOS dopo aver rinunciato al proprio porting.

Inoltre, GrapheneOS sta finalizzando un accordo con Motorola per portare il sistema operativo su uno smartphone non Pixel per la prima volta, mentre Qualcomm ha iniziato ad aggiungere il supporto MTE ai propri chip di ultima generazione, tra cui lo Snapdragon 8 Elite Gen 5.

NotebookCheck ha appreso che Motorola sta lavorando a uno smartphone di punta con nome in codice interno "Wukong", basato sul prossimo chip di punta di Qualcomm, lo Snapdragon 8 Elite Extreme Gen 6 (SM8975), che dovrebbe essere presentato in anteprima allo Snapdragon Summit il 22 settembre. Al momento, è l’unico dispositivo Motorola progettato attorno a quel chip. Se Wukong dovesse rivelarsi lo smartphone di lancio di GrapheneOS con Motorola, sarebbe il primo dispositivo a combinare un supporto MTE adeguato, un chip di punta di Qualcomm e il supporto a GrapheneOS, caratteristiche che attualmente non è possibile ottenere su un Pixel 11, indipendentemente dalla cifra spesa.

È opportuno fare la consueta avvertenza: in questa fase iniziale di sviluppo, le specifiche e persino il nome in codice “Wukong” provengono da materiale interno e potrebbero ancora subire modifiche prima che venga reso ufficiale. Motorola non ha confermato l’esistenza del telefono.

Per l’utente medio che acquista un Pixel 11, non ritengo che la perdita dell’MTE sia il disastro che questa notizia potrebbe far sembrare.

L’MTE è probabilistico, non una garanzia assoluta. C'è una probabilità su 16 che un determinato accesso fuori limite sfugga completamente al controllo dei tag, e una ricerca citata nello stesso articolo (TikTag) ha violato la riservatezza dei tag su hardware Pixel reale utilizzando l’esecuzione speculativa, il che significa che anche la protezione che offre non è, nella pratica, così affidabile come suggerisce il rapporto «15/16». Inoltre, cosa fondamentale, quasi nessuno degli exploit di cui un possessore medio di smartphone debba effettivamente preoccuparsi consiste, in primo luogo, in bug relativi alla sicurezza della memoria. Phishing, autorizzazioni di app dannose, SIM swapping, stalkerware e appropriazione di account: nulla di tutto ciò rientra nella protezione offerta da MTE. Persino lo stesso GrapheneOS ammette che la copertura per le app di terze parti è facoltativa e viene utilizzata raramente; Signal non la attiva.

È proprio nel modello di minaccia per cui GrapheneOS è stato progettato che l’MTE dimostra il proprio valore: costose catene di exploit «zero-click» che dipendono dall’affidabilità, del tipo venduto per milioni di dollari e utilizzato quasi esclusivamente contro giornalisti, dissidenti e obiettivi governativi, non contro il consumatore medio. Si tratta di un caso d’uso reale e importante. È semplicemente un ambito ristretto. Un telefono che si blocca invece di essere compromesso silenziosamente è davvero fondamentale se si è un bersaglio ad alto rischio sorvegliato da un attore statale. È molto meno rilevante se il rischio effettivo consiste nel perdere il telefono in un bar o nel cliccare su un link dannoso contenuto in un messaggio. Adottare buone pratiche di OPSEC, utilizzare password uniche, evitare codici QR casuali e non disseminare le proprie informazioni personali su ogni sito web che le richieda garantiscono, per la maggior parte delle persone, una protezione più concreta nel mondo reale di quanto potrà mai fare qualsiasi funzione di sicurezza della memoria a livello di chip.

Nulla di tutto ciò rende irrilevante la regressione a livello di chip del Pixel 11. La base di utenti di GrapheneOS è proprio quella fascia di pubblico per cui la questione è più rilevante, e la perdita del supporto per un’intera generazione di Pixel rappresenta un duro colpo per quel progetto. Ma vale la pena ammettere onestamente che l’MTE appare molto più come una misura di mitigazione di alto valore per le imprese o gli utenti ad alto rischio, che per caso è approdata nei chip destinati al mercato consumer, piuttosto che come una funzionalità di cui l’utente medio che acquista un Pixel 11 noterà mai l’assenza. E c’è una certa ironia nel modo in cui Google è arrivata a questo punto: è stata proprio l’azienda a portare l’MTE nel mainstream, integrandolo in Tensor prima di quasi chiunque altro nel mondo Android, finanziandone la ricerca e costruendo attorno ad esso un’intera modalità di sicurezza. Ora i suoi stessi documenti interni suggeriscono che abbia integrato l’MTE nel suo prossimo chip, ne abbia redatto una descrizione dettagliata e poi l’abbia silenziosamente eliminato prima del lancio. Nessuno ha superato Google dal punto di vista ingegneristico in questa vicenda. È stata la stessa Google a superarsi, eliminando la funzionalità.