Live patching del kernel o riavvio del VPS?

Cosa fa il live patching del kernel su un VPS

Il live patching del kernel applica le correzioni di sicurezza del kernel a una macchina in esecuzione, senza riavvio e senza interrompere le connessioni. Una copia corretta di una funzione viene caricata come modulo del kernel e ogni chiamata alla funzione precedente viene reindirizzata alla nuova copia, mentre il server continua a gestire il traffico. Questo meccanismo spiega sia per quali attività sia utile il live patching sia quali limiti abbia.

Consente di guadagnare tempo. Non elimina la necessità del riavvio. Un server sottoposto a live patching per sei mesi utilizza ancora la vecchia immagine del kernel presente sul disco e tutte le patch applicate risiedono soltanto in memoria.

Il live patching viene spesso presentato come una funzionalità dei piani gestiti. Su un server non gestito puoi abilitarlo autonomamente con due comandi. È utile saperlo prima di pagare la differenza tra un VPS gestito e uno non gestito.

Come funziona il live patching del kernel?

Il kernel include un componente integrato per il live patching, compilato con CONFIG_LIVEPATCH. Verifica che sia presente nel kernel in esecuzione:

grep CONFIG_LIVEPATCH /boot/config-$(uname -r)

Una riga con CONFIG_LIVEPATCH=y indica che il kernel in esecuzione è stato compilato includendo questo componente. In sua assenza, nessun servizio di live patching può operare su quel computer.

Il reindirizzamento usa ftrace, il function tracer del kernel. La maggior parte delle funzioni del kernel viene compilata con un'istruzione di chiamata all'inizio della funzione, prima che vengano modificati gli argomenti o lo stack. Ftrace usa quel punto di chiamata come hook. Quando viene applicata una patch, il componente di live patching registra un gestore ftrace sulla funzione di destinazione e il gestore trasferisce l'esecuzione alla funzione sostitutiva. La documentazione del kernel lo spiega in modo diretto: "Il live patching deve in genere reindirizzare il codice all'inizio della funzione, prima che i parametri della funzione o lo stack vengano modificati in qualsiasi modo."

Da questa frase derivano due conseguenze, entrambe importanti nelle sezioni successive. È possibile applicare una patch solo a una funzione che ftrace può agganciare. Una funzione compilata senza quella chiamata iniziale non può essere sottoposta a patch. Inoltre, l'unità di patching è sempre una funzione intera, mai una singola riga al suo interno.

La parte più complessa consiste nel cambiare il codice in sicurezza su un sistema in esecuzione. Se il vecchio codice è ancora presente nello stack di una CPU quando si sostituisce la funzione, si ottiene una combinazione di comportamenti vecchi e nuovi. Linux upstream gestisce questo caso con un modello di coerenza per task, descritto nella documentazione del kernel come un approccio ibrido: "usa la coerenza per task e il cambio della barriera delle syscall di kGraft, combinati con il cambio del backtrace di kpatch." I task passano al nuovo codice uno alla volta, soltanto quando il kernel può verificare che il task non si trovi attualmente all'interno di una funzione sottoposta a patch. Finché tutti i task non sono passati al nuovo codice, la patch si trova in transizione.

Puoi verificare direttamente il risultato. Le patch applicate compaiono in /sys/kernel/livepatch, con una directory per ogni patch e l'elenco delle funzioni sottoposte a patch al suo interno.

ls /sys/kernel/livepatch/

Un elenco vuoto indica che non è stata caricata alcuna live patch in memoria. Su un server appena installato, questo è lo stato iniziale normale.

Cosa non può correggere il live patching del kernel

Vengono applicati patch ai corpi delle funzioni. Tutto il resto non viene modificato.

• Strutture dati modificate. Se la correzione upstream aggiunge un campo a una struct o cambia il significato di un campo esistente, non esiste un modo sicuro per riscrivere gli oggetti già allocati e in uso. Il progetto kpatch descrive direttamente il caso equivalente: "Patches which modify statically allocated data are not directly supported." Le shadow variables e le callback possono servire come soluzione alternativa, ma devono essere scritte manualmente per ogni patch e non vengono generate automaticamente.
• Correzioni distribuite contemporaneamente su più funzioni. Una correzione che modifica l'ordine di acquisizione dei lock in un gruppo di funzioni richiede che tutte vengano modificate insieme. Inoltre, il modello di coerenza trasferisce le attività invece di bloccare l'intera macchina in un unico istante.
• Codice di inizializzazione. Le funzioni contrassegnate con __init sono già state eseguite e liberate quando il server è operativo. Non resta quindi nulla a cui reindirizzare le chiamate.
• Nuove versioni del kernel e nuove funzionalità. Il live patching sposta il kernel tra diversi livelli di patch all'interno della stessa serie. Non consente mai di passare da una serie all'altra e non aggiunge funzionalità. Se ti serve una caratteristica di una serie più recente, ad esempio le modifiche introdotte in Linux 7.1, devi installare quel kernel e avviarlo.
• Userspace. Canonical definisce esplicitamente il limite: "Canonical Livepatch does not patch userspace libraries like OpenSSL or glibc, because that is the responsibility of unattended-upgrades or a systems management tool." Un kernel sottoposto a live patching affiancato a una versione obsoleta di OpenSSL non equivale a un server aggiornato. Devi quindi lasciare che unattended upgrades gestisca i pacchetti userspace sullo stesso host.

Esiste anche un limite legato alla gravità delle vulnerabilità nel servizio Ubuntu. Canonical afferma che il servizio "patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings." Un identificatore CVE (common vulnerabilities and exposures) identifica una singola vulnerabilità, mentre CVSS è il punteggio associato. Una CVE del kernel con livello di gravità medium viene corretta nel pacchetto presente sul disco, ma non tramite live patching. Raggiunge quindi il kernel in esecuzione al successivo riavvio, non prima.

Quali sono le opzioni per applicare patch live al kernel?

Esistono tre linee evolutive comunemente utilizzate e tutte sfruttano gli stessi meccanismi del kernel.

Canonical Livepatch viene distribuito tramite Ubuntu Pro. Ubuntu Pro è gratuito per uso personale e Canonical specifica che «è e sarà sempre gratuito per uso personale su un massimo di 5 macchine fisiche», con un limite che sale a 50 macchine per i membri ufficiali della Ubuntu Community. Questo è il limite documentato ad agosto 2026. Per l'uso commerciale è necessario un abbonamento a pagamento. La copertura viene assegnata per serie di kernel e per flavour e include i kernel general availability (GA) delle release supportate long term support (LTS), oltre ai relativi kernel hardware enablement (HWE), per flavour come generic, aws, azure, gcp, oracle, ibm e lowlatency. Prima di fare affidamento sul servizio, confronta il tuo kernel con l'elenco dei kernel pubblicato da Canonical.

KernelCare, di TuxCare, è un agent commerciale che supporta molte distribuzioni, comprese quelle che non dispongono di un servizio proprietario. L'installazione documentata consiste in uno script del fornitore, curl -s -L https://kernelcare.com/installer | bash, seguito da /usr/bin/kcarectl --register KEY per una licenza basata su una chiave. L'agent controlla quindi la disponibilità di nuove patch secondo una propria pianificazione; /usr/bin/kcarectl --update forza un controllo. Leggi il programma di installazione prima di inoltrarlo a una shell su un server importante.

kpatch e kGraft sono gli antenati di queste soluzioni. kGraft è nato in SUSE, kpatch in Red Hat e il nucleo del live patching presente oggi in Linux upstream è il risultato della fusione delle due idee. kpatch è in fase di dismissione: il relativo README specifica che, a partire da Linux 6.19, «il progetto kpatch è deprecato e in modalità di manutenzione»; nel kernel upstream, kpatch-build viene sostuito da klp-build. Su RHEL e sulle relative ricostruzioni, lo strumento da utilizzare è il servizio fornito dalla distribuzione, invece di creare manualmente le patch.

Scegli in base al supporto offerto dalla tua distribuzione e a ciò che consente la tua licenza. Il risultato a livello di kernel è lo stesso in tutti i casi.

Come abilitare Canonical Livepatch su Ubuntu

Prima procurati un token dalla pagina del tuo account Ubuntu Pro. Entrambi i comandi riportati di seguito richiedono un accesso di rete in uscita funzionante, perché il client comunica con i server Canonical per eseguire l'associazione e scaricare le patch.

sudo pro attach TOKEN
sudo pro status

L'esecuzione di sudo pro attach senza token avvia invece una procedura tramite browser e stampa un codice da inserire sul sito Canonical. L'associazione abilita automaticamente i servizi consigliati, tra cui Livepatch nelle versioni LTS correnti. Usa sudo pro attach --no-auto-enable se preferisci scegliere autonomamente i servizi.

Se Livepatch non è già abilitato:

sudo pro enable livepatch
sudo canonical-livepatch status

Il servizio viene eseguito dallo snap canonical-livepatch, quindi snapd deve funzionare affinché la procedura di abilitazione termini correttamente. pro status stampa una tabella dei servizi con l'indicazione dell'entitlement e dello stato. canonical-livepatch status stampa i dettagli per ogni kernel. La documentazione Canonical mostra un output di questo tipo:

last check: 52 seconds ago
kernel: 5.4.0-216.236-generic
server check-in: succeeded
kernel state: ✓ kernel series 5.4 is covered by Livepatch
patch state: ✓ all applicable livepatch kernel modules applied
patch version: 113.1

La risposta è contenuta in due righe. kernel state indica se la serie in esecuzione è coperta dal servizio. È la riga che segnala un problema quando avvii un kernel non supportato da Livepatch. patch state indica se le patch applicabili a quel kernel sono state effettivamente caricate. Un kernel coperto per il quale non è stata applicata alcuna patch indica un problema del client. Un kernel non coperto indica un problema del kernel, che nessuna impostazione del client può risolvere.

Come verificare se è in attesa un riavvio?

Il live patching elimina l'urgenza, quindi un riavvio in sospeso non è più immediatamente evidente. È necessario cercarne l'indicazione.

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

Il gestore dei pacchetti crea /var/run/reboot-required quando un pacchetto installato richiede un riavvio per rendere effettive le modifiche, e un nuovo pacchetto linux-image lo crea sempre. Il file .pkgs elenca i pacchetti che lo hanno richiesto. Se il primo comando restituisce No such file or directory, nessun componente ha richiesto un riavvio dall'ultimo avvio della macchina. Nelle versioni correnti di Ubuntu, /var/run è un collegamento simbolico a /run, quindi entrambi i percorsi raggiungono lo stesso file.

Questo indicatore risiede in un tmpfs e viene azzerato a ogni avvio. Perciò è necessario verificarlo anche rispetto al kernel in esecuzione:

uname -r
dpkg -l 'linux-image-*' | grep ^ii

uname -r stampa il kernel in esecuzione. Il secondo comando stampa i pacchetti del kernel installati sul disco. Una voce linux-image presente nell'elenco e più recente di quella indicata da uname -r significa che la macchina esegue un kernel obsoleto, indipendentemente dallo stato di Livepatch. Questo è il controllo rilevante, perché il live patching è progettato per mantenere sicuro il kernel in esecuzione, non per mantenerlo aggiornato.

Per la parte userspace della stessa verifica, needrestart è installato per impostazione predefinita su Ubuntu Server ed elenca i servizi in esecuzione che mantengono ancora aperti file di libreria eliminati.

sudo needrestart -r l

La coppia di flag -r l significa "solo elenco": il comando visualizza le informazioni senza modificare nulla.

Perché la richiesta di riavvio non scompare mai

Il kernel sul disco non cambia. Le patch live vengono caricate nel kernel in esecuzione e non vengono mai scritte nell'immagine di boot. Dopo un riavvio viene quindi avviato il linux-image selezionato dal bootloader, dopodiché il client Livepatch riapplica le patch ancora applicabili. Tra questi due momenti il sistema esegue codice non corretto dalle patch. Questo è un ulteriore motivo per avviare un kernel aggiornato invece di uno obsoleto.

La copertura è specifica per serie di kernel, e le serie vengono ritirate. Quando la serie in esecuzione non è più inclusa nell'elenco supportato, la riga kernel state non riporta più la copertura. L'unica soluzione è installare un kernel più recente. Questo richiede un riavvio.

Le correzioni del kernel con severità media e bassa non vengono mai applicate tramite live patching. Restano nel pacchetto sul disco e diventano effettive soltanto dopo l'avvio del kernel che le contiene.

I kernel mantenuti in esecuzione a lungo accumulano inoltre stato che il patching non ripulisce. Vale la pena riportare la posizione ufficiale di Canonical, perché è quella più corretta: Livepatch «non sostituisce il riavvio. È uno strumento che offre un maggiore controllo impedendo i riavvii non pianificati». Il termine decisivo è non pianificati. Il riavvio resta necessario. Sei tu a scegliere quando eseguirlo.

Come programmare un riavvio con ripristino del servizio

Il riavvio di una VPS è un’operazione a senso unico se non è possibile accedere alla console. Prima di eseguire reboot, assicurati di poter accedere nuovamente al sistema se la macchina non torna disponibile.

• Verifica che il provider renda disponibile una console seriale o una visualizzazione VNC (virtual network computing) nel pannello di controllo, quindi aprila subito e non durante l’interruzione del servizio.
• Controlla lo spazio libero con df -h /boot. Un /boot pieno impedisce al pacchetto del kernel di scrivere il relativo initramfs (initramfs iniziale), lasciando eventualmente una voce del bootloader che punta a un’immagine non completata.
• Mantieni installato almeno un kernel precedente sicuramente funzionante. GRUB lo elenca in "Advanced options for Ubuntu"; avviarlo è il metodo di ripristino più rapido quando un nuovo kernel non funziona.
• Individua la modalità di ripristino del provider prima di averne bisogno. Se dopo il riavvio la console mostra un prompt initramfs, la riparazione deve essere eseguita da lì.

Esegui quindi il riavvio in un momento in cui sei disponibile:

sudo shutdown -r +5 "Kernel update, back in a moment"

Questo programma il riavvio tra cinque minuti e invia un messaggio agli utenti connessi. sudo shutdown -c annulla l’operazione. Quando la macchina torna disponibile, verifica entrambi gli aspetti:

uname -r
sudo canonical-livepatch status

uname -r dovrebbe ora mostrare il kernel più recente, mentre l’output dello stato dovrebbe indicare che la nuova serie è coperta. Se la macchina non torna affatto disponibile, il problema è quasi sempre nel percorso di avvio e non nella rete. In questo caso, segui la procedura indicata nella guida a una VPS che non si avvia dopo un aggiornamento del kernel.

Perché è ancora necessario rimuovere i kernel obsoleti

Il live patching peggiora questo problema anziché risolverlo, perché elimina la necessità di riavviare il sistema mentre continuano a essere installati pacchetti linux-image. Ogni kernel installa un'immagine di avvio, un initramfs, un albero dei moduli e, in genere, un pacchetto di header. Su un piccolo VPS con una partizione /boot separata di poche centinaia di megabyte, tre o quattro kernel sono sufficienti a riempirla.

Un /boot pieno impedisce quindi la successiva installazione del kernel. In questo modo il sistema può non riuscire a installare proprio l'aggiornamento di cui ha bisogno. Il percorso apt autoremove rimuove i kernel obsoleti quando diventano idonei, ma su un sistema che non viene mai riavviato non sono sempre idonei. Il gestore dei pacchetti non rimuove infatti un kernel che potrebbe essere ancora in esecuzione.

Controlla quindi quali kernel sono installati, conserva il kernel in esecuzione e un fallback verificato, quindi rimuovi gli altri seguendo la procedura sicura per rimuovere i kernel obsoleti su Ubuntu. Non rimuovere mai il kernel indicato attualmente da uname -r.

FAQ

Il live kernel patching significa che non devo mai riavviare il mio VPS?

No. Le patch live vengono caricate nel kernel in esecuzione e non vengono scritte nell'immagine di avvio, quindi il linux-image su disco mantiene la versione con cui è stato eseguito l'avvio. Canonical lo dichiara esplicitamente: Livepatch «non sostituisce il riavvio. È uno strumento che offre un maggiore controllo impedendo i riavvii non pianificati». La copertura termina inoltre quando la serie del kernel viene ritirata e le correzioni del kernel con gravità media non vengono mai applicate tramite live patch. Pianifica invece un riavvio di manutenzione con la frequenza che preferisci, senza aspettare che venga imposto.

Come posso verificare se il live kernel patching sta applicando effettivamente le patch?

Esegui sudo canonical-livepatch status e leggi due righe. kernel state indica se la serie del kernel in esecuzione è coperta dal servizio, mentre patch state indica se le patch per quel kernel sono state caricate. Puoi controllare direttamente anche il lato kernel con ls /sys/kernel/livepatch/, che elenca una directory per ogni patch caricata. Un elenco vuoto significa che in quel momento non è stata applicata alcuna patch in memoria, indipendentemente da quanto riportato dal client.

Ubuntu Pro è gratuito su un VPS personale?

Sì, entro un limite documentato. Canonical specifica che Ubuntu Pro «è e sarà sempre gratuito per uso personale su un massimo di 5 macchine fisiche», limite che sale a 50 macchine per i membri ufficiali della Ubuntu Community, ad agosto 2026. Per l'uso commerciale è necessario un abbonamento a pagamento. Collega la macchina con sudo pro attach TOKEN usando un token ottenuto dalla pagina del tuo account Ubuntu Pro, quindi abilita il servizio con sudo pro enable livepatch.

Perché una CVE del kernel risulta ancora non corretta dopo l'esecuzione di Livepatch?

Di solito per uno dei due motivi seguenti. La correzione potrebbe essere al di sotto della soglia di gravità, perché Canonical applica live patch alle «vulnerabilità del kernel con valutazioni critiche e alte secondo il Common Vulnerability Scoring System (CVSS) e le priorità Ubuntu», lasciando le altre al pacchetto presente su disco. In alternativa, la correzione potrebbe non essere esprimibile come modifica del corpo di una funzione, ad esempio quando il progetto upstream ha modificato una struttura dati; il live patching non può farlo in sicurezza sugli oggetti già allocati. In entrambi i casi la soluzione è la stessa: installa il pacchetto del kernel aggiornato ed esegui l'avvio con quel kernel.

Che cosa non copre affatto il live kernel patching?

Lo userspace. Canonical è esplicita: Livepatch «non applica patch alle librerie userspace come OpenSSL o glibc, perché questa attività è responsabilità di unattended-upgrades o di uno strumento di gestione dei sistemi». Inoltre non può fornire una nuova versione del kernel né una nuova funzionalità, perché sostituisce soltanto i corpi delle funzioni all'interno della serie già in esecuzione. Non può infine applicare patch alle funzioni __init, che hanno già completato l'esecuzione e sono state liberate dalla memoria quando il server è operativo.