Windows Hotpatch: cosa succede se qualcuno modifica una funzione già patchata

Installare gli aggiornamenti di sicurezza di Windows senza riavviare il computer sta diventando progressivamente possibile grazie alla tecnologia hotpatching, che permette di modificare il codice eseguibile direttamente in memoria mentre il sistema operativo continua a funzionare. La tecnica, battezzata Windows Hotpatch e inizialmente destinata soprattutto agli ambienti server, è oggi disponibile anche su determinate configurazioni di Windows 11 Enterprise e sulle altre edizioni aziendali supportate. Esiste però un problema poco conosciuto: cosa succede quando un altro programma ha già modificato una funzione che Windows Update deve correggere?

Da oltre 20 anni Windows prevede accorgimenti specifici per sostituire porzioni di codice durante l’esecuzione, senza interrompere i processi interessati. Nel tempo Microsoft ha perfezionato tali meccanismi per le architetture x86, x64 e ARM64; l’obiettivo rimane lo stesso, ossia ridurre i riavvii necessari per applicare correzioni importanti, specialmente sui sistemi che devono garantire un’elevata disponibilità.

Come funziona Windows Hotpatch e perché non serve riavviare

Quando Windows Update installa una correzione che interessa una DLL di sistema o un componente del kernel, normalmente deve sostituire o aggiornare i relativi file. Se il sistema sta già utilizzando il codice interessato, spesso occorre un riavvio per caricare le nuove versioni dei componenti e completare l’operazione.

La tecnologia di hotpatching modifica il percorso di esecuzione delle funzioni già caricate in memoria senza attendere che tutti i componenti interessati “ripartano”. Quando un’applicazione o un componente di Windows richiama una funzione corretta tramite hotpatch, il processore può raggiungere una nuova implementazione che contiene la modifica di sicurezza.

Il meccanismo sfrutta particolari punti di intervento predisposti nel codice eseguibile: in quelle posizioni, il sistema può sostituire determinate istruzioni con istruzioni di salto, trasferendo l’esecuzione verso la versione aggiornata della funzione. Le operazioni in questione richiedono ovviamente codice preparato per supportare la sostituzione, verifiche preliminari e condizioni precise affinché la modifica non comprometta l’esecuzione.

Una hotpatch può rendere operativa una correzione nelle immagini eseguibili caricate in memoria, senza richiedere il riavvio normalmente necessario per completare la sostituzione dei componenti. La successiva installazione di un aggiornamento cumulativo permette poi di riallineare il sistema alla nuova versione intervenendo sui binari a livello di file system.

Il problema del doppio hotpatching: quando due programmi modificano la stessa funzione

Il programma di distribuzione degli aggiornamenti hotpatch prevede, in condizioni ordinarie, 4 aggiornamenti cumulativi di riferimento all’anno che richiedono un riavvio e 8 aggiornamenti intermedi applicabili senza riavviare il sistema. È una modalità particolarmente interessante per aziende e amministratori IT, che possono così ridurre al minimo indispensabile il numero dei riavvii, ma che introduce problemi delicati quando software differenti cercano di intervenire sulle medesime istruzioni macchina.

A spiegare il rischio è Raymond Chen, storico sviluppatore Microsoft, in un approfondimento pubblicato sul suo blog The Old New Thing.

Il ragionamento di Chen mette in luce un principio fondamentale: lo spazio riservato all’hotpatching di Windows non è un’area utilizzabile liberamente dalle applicazioni.  Quando qualcuno lo occupa senza rispettare le regole previste, un aggiornamento apparentemente innocuo può trasformarsi in un problema di stabilità.

Immaginiamo una funzione di sistema chiamata da numerose applicazioni: Windows Update deve applicare una correzione di sicurezza e dispone di un punto di intervento predisposto per deviare l’esecuzione verso la nuova implementazione.

Prima che arrivi l’aggiornamento, però, un programma di terze parti modifica proprio quella funzione. Potrebbe trattarsi di uno strumento di monitoraggio, un prodotto di sicurezza, un software di compatibilità o un’applicazione che intercetta chiamate a determinate API.

Cosa succede a basso livello e perché la sequenza di azioni è cruciale

La tecnica utilizzata potrebbe essere frutto del function hooking, cioè dell’intercettazione di una chiamata a funzione per eseguire codice aggiuntivo, modificare i parametri oppure sostituire il comportamento originale. Un esempio è il cosiddetto API hooking svolto da Windhawk.

Una variante è il detouring, che consiste tipicamente nel modificare il codice iniziale della funzione introducendo un salto verso un’altra routine.

Supponiamo quindi che la funzione originale si trovi all’indirizzo A. Il programma esterno modifica le istruzioni iniziali affinché l’esecuzione venga trasferita alla propria routine B. Successivamente arriva Windows Update, che deve applicare una hotpatch e indirizzare le chiamate alla nuova routine C.

Il problema è evidente: due soggetti differenti pretendono di controllare lo stesso punto di ingresso.

Un aggiornamento che sovrascrivesse semplicemente il salto verso B con quello verso C potrebbe interrompere il funzionamento del software che aveva installato il primo hook. Viceversa, se il programma esterno riscrivesse nuovamente la funzione dopo l’aggiornamento, potrebbe aggirare la correzione di sicurezza appena introdotta.

Non è di solito possibile risolvere il conflitto concatenando i due interventi: l’ordine delle modifiche può influire sui registri utilizzati, sulla gestione dello stack, sui parametri e sulle istruzioni originali trasferite altrove. Senza un coordinamento esplicito, la composizione delle due modifiche non offre garanzie.

Per Microsoft il secondo programma non dovrebbe nemmeno intervenire

La risposta Chen alla domanda sul doppio hotpatching è piuttosto netta: il progetto dell’hotpatching di Windows presuppone un solo soggetto autorizzato a utilizzare lo spazio riservato, ossia il meccanismo di aggiornamento del sistema operativo.

Microsoft non ha progettato l’area sfruttata da Windows Hotpatch come un’interfaccia pubblica attraverso la quale programmi indipendenti possano modificare e concatenare liberamente le funzioni di sistema.

Quando Windows Update riceve una correzione e il componente interessato risulta idoneo all’applicazione senza riavvio, il sistema sfrutta le aree predisposte per sostituire il comportamento delle funzioni interessate. Non deve negoziare con altri programmi che abbiano deciso autonomamente di usare lo stesso spazio.

Chen paragona questa situazione a un veicolo parcheggiato in una zona riservata ai mezzi di emergenza: finché nessuno deve utilizzarla, l’occupazione sembra innocua. Il problema compare quando arriva chi ha effettivamente bisogno di quello spazio, avendone titolo.

Windows può restare con una patch applicata soltanto a metà

Se una funzione presenta istruzioni differenti da quelle attese perché un altro programma le ha già alterate, Windows Hotpatch può considerare il relativo file non idoneo all’hotpatching. Secondo la lettura del codice effettuata da Chen, quando il sistema rileva un intervento estraneo può rinunciare all’applicazione della hotpatch e richiedere un riavvio per completare l’aggiornamento attraverso il percorso ordinario.

Chen, tuttavia, descrive tale comportamento come una conclusione ricavata dall’esame dell’implementazione, non come una garanzia universale e documentata per qualunque genere di modifica esterna.

Il caso più delicato compare quando il controllo preliminare non basta: Chen richiama infatti l’attenzione su una possibile race condition, ossia una condizione di gara tra operazioni concorrenti che accedono alle stesse risorse.

Supponiamo che Windows Update controlli le funzioni interessate e verifichi che nessuna di esse consta di alterazioni anomale; la fase di prescansione termina quindi correttamente e il sistema può iniziare ad applicare le correzioni.

Subito dopo, un programma esterno modifica una delle funzioni già controllate. Quando Windows Update raggiunge quella funzione, scopre che le istruzioni non corrispondono più alla configurazione attesa. In questo caso, alcune funzioni potrebbero aver già ricevuto la hotpatch, mentre altre attendono ancora l’intervento.

Si arriva così a uno scenario particolarmente difficile da gestire: un’immagine eseguibile caricata in memoria con un insieme incompleto di modifiche, dove alcune funzioni utilizzano la versione corretta e altre conservano un comportamento differente.

Qualche nota finale

La riflessione di Raymond Chen chiarisce uno degli aspetti meno evidenti dell’hotpatching: per applicare una correzione senza interrompere il sistema non basta disporre di istruzioni macchina sostituibili. Serve anche la certezza che nessun altro componente abbia alterato il punto nel quale l’aggiornamento con Windows Hotpatch deve intervenire.

In condizioni favorevoli, Windows può riconoscere eventuali conflitti con software di terze parti, pure presente sulla macchina, e rinunciare alla hotpatch. Se invece le modifiche si sovrappongono durante l’applicazione dell’aggiornamento, la situazione diventa molto più delicata, perché non sempre è possibile completare o annullare l’operazione in sicurezza.

Gli aggiornamenti senza riavvio sono quindi un’ottima idea, come abbiamo più volte sottolineato, ma non eliminano la complessità della manutenzione software: la spostano dalla sostituzione dei file alla gestione delle istruzioni in esecuzione e dello stato già presente in memoria.

Per i produttori di software che intercettano le API di Windows, rispettare i confini previsti dal sistema operativo non è soltanto una buona pratica di compatibilità. Può diventare una condizione necessaria affinché una futura correzione di sicurezza raggiunga effettivamente il codice che dovrebbe proteggere.

Windows Hotpatch anche sulle edizioni Pro di Windows 11?

L’auspicio è che Microsoft possa estendere progressivamente i vantaggi di Windows Hotpatch anche alle edizioni Pro di Windows 11, oggi escluse dal programma ordinario, così da ridurre la frequenza dei riavvii anche sui computer dei professionisti, delle piccole imprese e degli utenti più evoluti. Del resto, se la tecnologia è sufficientemente matura per gli ambienti aziendali, sarebbe interessante renderla accessibile a una platea molto più ampia.

Un ulteriore passo avanti potrebbe riguardare la gestione degli aggiornamenti cumulativi di riferimento, che attualmente impongono comunque riavvii periodici.

Microsoft potrebbe valutare un modello più flessibile, capace di mantenere attive più a lungo le correzioni applicate dinamicamente in memoria, rinviando il consolidamento definitivo delle modifiche a un momento scelto dall’utente. Il sistema potrebbe mostrare promemoria progressivi, segnalando quando il riavvio diventa necessario, senza imporre interruzioni immediate dell’attività.

Naturalmente, una simile evoluzione richiederebbe garanzie precise: mantenere un numero crescente di modifiche dinamiche potrebbe complicare la gestione delle dipendenze tra componenti, la compatibilità e le procedure di ripristino.