Google porta Rust nel modem del Pixel 10 per difendere la baseband

Con il Pixel 10, Google ha introdotto nel firmware del modem una componente scritta in Rust, il linguaggio di programmazione progettato per eliminare alla radice una categoria di errori software tra le più pericolose: quelli legati alla gestione della memoria. L'obiettivo è preciso: proteggere il punto in cui il modem interpreta le risposte DNS — il sistema che traduce i nomi dei siti web in indirizzi numerici — da attacchi che sfruttano difetti nella gestione dei dati in arrivo dall'esterno.

Il modem è più vulnerabile di quanto sembri

Nel linguaggio comune, il modem è «il pezzo che prende campo». In realtà è un sottosistema complesso con un proprio firmware, che gestisce la comunicazione con l'operatore telefonico, interpreta protocolli di rete e, nella maggior parte degli smartphone, vive in un perimetro software meno visibile e meno aggiornabile rispetto ad Android. Quando un bug colpisce questo componente, le conseguenze possono andare dal semplice blocco della connessione fino all'esecuzione di codice da remoto, senza che l'utente faccia nulla. Nessun tap, nessun link cliccato: basta essere raggiungibili in rete.

Il problema storico dei firmware di modem è che sono scritti quasi interamente in C e C++, linguaggi potenti ma che lasciano al programmatore la responsabilità di gestire la memoria in modo corretto. Un singolo controllo mancante sui limiti di un blocco di memoria — un cosiddetto buffer overflow — può aprire la strada a un attacco serio. Rust è stato progettato proprio per rendere strutturalmente molto più difficile commettere questo tipo di errori: il compilatore blocca in fase di scrittura del codice interi scenari che in C sarebbero invisibili fino al momento dell'exploit.

Un innesto chirurgico, non una riscrittura

Riscrivere da zero un firmware storico in un linguaggio diverso sarebbe un progetto pluriennale, costoso e ad alto rischio di introdurre nuovi problemi mentre si sistemano i vecchi. Google ha scelto una strada diversa: individuare un punto di ingresso ad alto rischio e intervenire solo lì. Il parser DNS è un candidato naturale — deve interpretare strutture dati che arrivano dall'esterno, su cui non si può riporre alcuna fiducia, ed è esattamente il tipo di codice che tende a diventare fragile nel tempo.

Per farlo funzionare nel firmware del modem, Google ha adattato una libreria open source chiamata hickory-proto, parte del progetto Hickory DNS, modificandola per operare in modalità no_std — cioè senza le funzionalità standard che Rust offre normalmente in un ambiente operativo tradizionale. È un dettaglio tecnico che rivela molto sui vincoli reali di un firmware embedded: memoria limitata, requisiti di risposta in tempo reale, nessuna delle comodità di un sistema operativo convenzionale. Il risultato aggiunge circa 371 KB di codice complessivo al firmware, tra libreria, dipendenze e uno shim — uno strato di collegamento — che integra il nuovo parser nella pipeline esistente.

Un parser DNS più robusto elimina un'intera famiglia di bug che gli attaccanti sfruttano da anni

Questo approccio per «isole funzionali» non è nuovo nel mondo della sicurezza software. Un precedente emblematico è l'introduzione del supporto a Rust nel kernel Linux con la versione 6.1, nel dicembre 2022: non una riscrittura del kernel, ma l'apertura di un percorso realistico di adozione progressiva in aree selezionate. La stessa logica vale qui: si prende una componente con input esterno, parsing complesso e alto impatto potenziale, e la si mette sotto un modello di sicurezza più robusto.

I numeri che convincono le aziende

La scelta del Pixel 10 va letta nel contesto di una strategia più ampia che Google porta avanti da anni su Android. In un aggiornamento pubblico del novembre 2025, l'azienda ha comunicato che le vulnerabilità legate alla gestione della memoria sono scese per la prima volta sotto il 20% del totale delle vulnerabilità della piattaforma, e che la densità di questo tipo di problemi nel codice Rust è stimata circa mille volte inferiore rispetto alle componenti storiche in C e C++. Sono metriche che spostano il dibattito dal piano teorico a quello operativo: quanto cambia il rischio reale quando il codice che fa parsing non può sbagliare così facilmente sui confini della memoria?

Vale però essere chiari sui limiti. Scrivere in Rust non rende il software invulnerabile: restano possibili errori logici, problemi nei punti di contatto tra codice nuovo e codice legacy, e intere superfici di attacco del modem che non passano dal DNS. Rust permette anche l'uso esplicito di porzioni unsafe — sezioni in cui le protezioni vengono temporaneamente disattivate per interagire con l'hardware o ottimizzare le prestazioni — e in un firmware misto questi confini richiedono attenzione costante.

Manutenzione e filiera del software

C'è un secondo livello di responsabilità che tende a restare in secondo piano: usare una libreria open source come hickory-proto significa farsi carico della sua supply chain, cioè seguirne le release, valutare la stabilità delle dipendenze e decidere quando e come portare gli aggiornamenti in un componente delicato come un modem. In un sistema operativo aggiornare una libreria è già un processo complesso; in un firmware di baseband ogni variazione può richiedere cicli di validazione più conservativi. Il costo di questo innesto è quindi più ingegneristico che prestazionale.

Il vero banco di prova è quanto questo approccio regge nel tempo, non al lancio

Nel frattempo, la memory safety ha smesso di essere solo un tema da sviluppatori. A giugno 2025 la NSA e la CISA statunitensi hanno pubblicato un documento istituzionale dedicato ai linguaggi memory-safe, trattandoli come strumento concreto per ridurre intere classi di vulnerabilità. Quando un tema entra nelle linee guida istituzionali, cambia la struttura degli incentivi per l'industria: investire oggi in tecniche che prevengono bug ricorrenti può diventare più conveniente rispetto a inseguire patch e gestire incidenti in futuro.

La pressione che risale la filiera

Per il settore mobile, la questione più rilevante è l'effetto sul mercato dei fornitori. La maggior parte dei produttori di smartphone acquista modem e firmware da grandi vendor specializzati, e il controllo diretto su come quel codice è scritto è tutt'altro che uniforme. Se Google dimostra che Rust può convivere con il codice legacy in un componente real-time, in un ambiente senza librerie standard e senza stravolgere l'architettura esistente, alza l'asticella del «si può fare» anche per chi finora si è affidato solo alle tecniche di difesa tradizionali: test di stress automatizzati, revisioni del codice, protezioni del compilatore e patch reattive.

Per l'utente finale, tutto questo resta invisibile. L'innesto Rust nel modem del Pixel 10 non è una funzione, non appare nelle impostazioni e non garantisce l'invulnerabilità. È più simile alla sostituzione di un componente interno con uno che prende fuoco più difficilmente: nella maggior parte dei giorni non cambia nulla, ma quando un attacco arriva, cambia la probabilità che un singolo errore si trasformi in un incidente serio. Il Pixel 10 diventa così un test di sostenibilità: se l'innesto regge il peso della manutenzione e degli aggiornamenti nel tempo, la domanda successiva non sarà se altri seguiranno, ma quali altri componenti critici meriteranno lo stesso trattamento.