Chrome si aggiorna senza riavvio: come funziona il dynamic patching

Riavviare Chrome per installare un aggiornamento potrebbe diventare un’operazione molto meno frequente. E ciò nonostante Google abbia dichiarato di aver avviato una sperimentazione per passare a due aggiornamenti di sicurezza a settimana, in modo da poter correggere le vulnerabilità del browser più rapidamente.

I tecnici dell’azienda di Mountain View stanno sviluppando un sistema chiamato “dynamic patching“, pensato per applicare una parte consistente delle correzioni sostituendo durante l’esecuzione i singoli processi del browser, senza chiudere tutte le finestre e interrompere la sessione dell’utente.

I primi dettagli sull’installazione degli aggiornamenti Chrome senza riavvio del browser

La formulazione utilizzata da Google è importante: Chrome rimpiazzerà sequenzialmente i processi figli in background, come Renderer e GPU Process, avviandone nuove istanze basate sui binari aggiornati. Non si tratta quindi, almeno in base alle informazioni pubblicate finora, di modificare direttamente le istruzioni macchina già caricate in memoria. Il browser terminerà determinati processi e li ricreerà usando la nuova versione installata sul disco.

L’idea sfrutta una caratteristica fondamentale di Chromium: Chrome non funziona come un unico grande programma monolitico. L’interfaccia, le pagine web, la grafica, la rete, l’audio e numerosi servizi sono distribuiti tra processi separati. Tale organizzazione, nata per aumentare stabilità e sicurezza, può ora diventare anche il fondamento di un aggiornamento progressivo.

Google non ha ancora pubblicato una specifica completa, i dettagli tecnici o il codice definitivo del dynamic patching. La società precisa che la funzione si trova ancora in fase di ricerca e sviluppo.

Dynamic patching non significa riscrivere Chrome in memoria

Il termine dynamic patching può ricordare il live patching dei kernel, dove una funzione vulnerabile può essere sostituita mentre il sistema continua a funzionare oppure le funzionalità di hotpatching (applicazione degli aggiornamenti in memoria) che, a partire da Windows Server 2025 e Windows 11 Enterprise, Microsoft sta iniziando ad adottare. Lato Windows, una delle soluzioni più note che utilizza questo sistema di aggiornamento è 0patch.

Nel caso di Chrome, la descrizione – come già evidenziato – indica un approccio diverso. Dopo aver scaricato una correzione, il browser di Google potrebbe mantenere attivo il Browser Process principale e sostituire gradualmente gli altri componenti.

Google parla espressamente di “updated binaries“, non di funzioni modificate dentro il processo esistente: il dynamic patching di Chrome appare quindi più vicino a una sostituzione controllata dei componenti che a una patch applicata direttamente alla memoria del programma.

Cosa accade allo stato contenuto nel renderer

Un renderer non contiene soltanto il codice di Chrome. Al suo interno risiedono anche dati temporanei della pagina:

• DOM costruito da Blink
• heap JavaScript di V8
• timer e callback
• moduli WebAssembly
• canvas
• stato WebGL o WebGPU
• connessioni WebSocket
• sessioni WebRTC
• editor web e modifiche non salvate

Quando il processo termina, tali informazioni normalmente vengono perse. Chrome può ricostruire una pagina caricando nuovamente l’URL, ma non può recuperare automaticamente ogni oggetto JavaScript e ogni stato residente in memoria.

Il Browser Process mantiene comunque una rappresentazione autonoma della sessione: ogni scheda dispone di informazioni sulla cronologia di navigazione, sugli URL visitati, sulla struttura dei frame e su altri dati utili al ripristino. Tale stato permette a Chrome di ricreare una pagina dopo un crash o dopo il riavvio dell’applicazione.

Google conferma un secondo progetto complementare: Chrome salverà localmente una quantità maggiore di stato per rendere il ripristino più trasparente anche nelle situazioni complesse.

Perché Google vuole ridurre il tempo tra patch e riavvio

La motivazione principale riguarda il cosiddetto “patch gap“: una correzione di sicurezza può essere già disponibile sull’unità, ma il processo vulnerabile continua a eseguire il vecchio codice fino al riavvio.

Nel frattempo, gli aggressori possono confrontare le modifiche pubblicate nel codice Chromium, individuare la funzione corretta e costruire un exploit capace di colpire anche le installazioni non ancora sottoposte a riavvio. Si parla in questo caso di attacchi N-day: la vulnerabilità è nota e il fix esiste, ma molti sistemi restano temporaneamente esposti.

Google considera il tempo trascorso in attesa del riavvio una componente significativa del rischio. L’aumento della frequenza degli aggiornamenti rende il problema ancora più evidente: distribuire patch rapidamente serve a poco se la vecchia versione di Chrome rimane attiva per giorni.

Il dynamic patching prova a spostare la responsabilità dall’utente al browser: Chrome non dovrebbe limitarsi a mostrare il pulsante “Riavvia per aggiornare“; dovrebbe applicare automaticamente almeno le correzioni compatibili, sostituendo i processi nei quali risiede il codice vulnerabile.