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 chiarisce sia per cosa è utile il live patching sia cosa non può fare.

Offre tempo aggiuntivo. Non elimina la necessità del riavvio. Un server sottoposto a live patching per sei mesi continua ad avviarsi con la vecchia immagine del kernel presente sul disco, e tutte le patch restano soltanto in memoria.

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

Come funziona il live patching del kernel?

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

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

La presenza di una riga con CONFIG_LIVEPATCH=y indica che il kernel in esecuzione è stato compilato includendo questo componente. Senza di esso, nessun servizio di live patching può operare su quel sistema.

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 questo punto di chiamata come hook. Quando viene applicata una patch, il componente di live patching registra un gestore ftrace per la funzione di destinazione e il gestore trasferisce l'esecuzione alla funzione sostitutiva. La documentazione del kernel lo spiega chiaramente: "Il live patching deve in genere reindirizzare il codice all'inizio dell'entry point della funzione, prima che i parametri della funzione o lo stack vengano modificati in qualsiasi modo."

Da questa frase derivano due conseguenze, entrambe importanti per le sezioni successive. È possibile applicare una patch solo a una funzione che ftrace può intercettare; una funzione compilata senza quella chiamata all'entry point non può essere sottoposta a patch. Inoltre, l'unità di patching è sempre una funzione completa, mai una singola riga al suo interno.

La parte più complessa consiste nel modificare in sicurezza un sistema in esecuzione. Se il codice precedente è 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 consistenza per task, descritto nella documentazione del kernel come un modello ibrido: "usa la consistenza per task di kGraft e il passaggio con barriera delle syscall, combinati con il passaggio basato sullo stack trace di kpatch." I task passano al nuovo codice uno alla volta, solo quando il kernel può dimostrare che il task non si trova in quel momento 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 sono elencate in /sys/kernel/livepatch, con una directory per ogni patch e l'elenco delle funzioni sottoposte a patch all'interno.

ls /sys/kernel/livepatch/

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

Cosa non può correggere il live kernel patching

Vengono applicati patch ai corpi delle funzioni. Tutto il resto rimane invariato.

• 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 lo dichiara esplicitamente per il caso equivalente: "Patches which modify statically allocated data are not directly supported." Le variabili shadow e le callback consentono di aggirare il problema, 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 cambino insieme. Inoltre, il modello di coerenza sposta le attività invece di congelare l'intera macchina in un singolo istante.
• Codice di inizializzazione. Le funzioni contrassegnate con __init sono già state eseguite e liberate quando il server è operativo. Non rimane quindi nulla da reindirizzare.
• Nuove versioni del kernel e nuove funzionalità. Il live patching consente di avanzare all'interno di una serie del kernel, passando a un livello di patch successivo. Non consente mai di passare da una serie all'altra e non aggiunge funzionalità. Se ti serve una funzionalità di una serie più recente, come le modifiche introdotte in Linux 7.1, devi installare quel kernel e avviarlo.
• Userspace. Canonical definisce direttamente il confine: "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 aggiornato tramite live patching affiancato a un OpenSSL obsoleto non equivale a un server aggiornato. Mantieni quindi unattended upgrades per la gestione dei pacchetti userspace sullo stesso server.

Esiste anche un limite legato alla gravità delle vulnerabilità nel servizio Ubuntu. Canonical afferma che applica patch alle vulnerabilità del kernel con valutazione critica o alta secondo il Common Vulnerability Scoring System (CVSS) e secondo i livelli di priorità Ubuntu. Un identificativo CVE (common vulnerabilities and exposures) indica una singola vulnerabilità, mentre CVSS è il punteggio associato. Una CVE del kernel con gravità media viene corretta nel pacchetto presente sul disco, ma non tramite live patching. La correzione raggiunge quindi il kernel in esecuzione al riavvio successivo, e non prima.

Quali sono le opzioni per applicare patch al kernel in tempo reale?

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

Canonical Livepatch è distribuito tramite Ubuntu Pro. Ubuntu Pro è gratuito per uso personale e, secondo la formulazione di Canonical, "è 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 concessa per serie di kernel e per flavour e include i kernel general availability (GA) delle release long term support (LTS) supportate, oltre ai relativi kernel hardware enablement (HWE), per flavour come generic, aws, azure, gcp, oracle, ibm e lowlatency. Verifica il tuo kernel rispetto all'elenco dei kernel pubblicato da Canonical prima di farci affidamento.

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

kpatch e kGraft sono i progetti originari. kGraft è nato da SUSE, kpatch da Red Hat e il nucleo per il live patching presente oggi in Linux upstream è il risultato della fusione delle due idee. kpatch è in fase di dismissione: il README dichiara che, a partire da Linux 6.19, "il progetto kpatch è deprecato e in modalità di manutenzione", con kpatch-build sostituito da klp-build nel kernel upstream. Su RHEL e sulle relative rebuild, lo strumento da utilizzare è il servizio fornito dalla distribuzione, non la compilazione manuale delle 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 seguenti richiedono un accesso di rete in uscita funzionante, perché il client comunica con i server Canonical per associare il sistema all’account 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 attuali. Usa sudo pro attach --no-auto-enable se preferisci scegliere manualmente i servizi.

Se Livepatch non è già attivo:

sudo pro enable livepatch
sudo canonical-livepatch status

Il servizio viene eseguito dallo snap canonical-livepatch, quindi snapd deve funzionare affinché l’abilitazione vada a buon fine. pro status stampa una tabella dei servizi con l’indicazione dell’abilitazione 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 si avvia un kernel non supportato da Livepatch. patch state indica se le patch applicabili a quel kernel sono state effettivamente caricate. Un kernel coperto senza patch applicate indica un problema del client. Un kernel non coperto indica un problema del kernel, che nessuna impostazione del client può risolvere.

Come stabilire se è necessario riavviare il sistema?

Il live patching elimina l'urgenza, quindi la necessità di un riavvio non è più evidente. È necessario verificare esplicitamente se esiste.

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 pacchetto ha richiesto un riavvio dall'ultimo avvio della macchina. Nelle versioni recenti di Ubuntu, /var/run è un link simbolico a /run, quindi entrambi i percorsi fanno riferimento allo stesso file.

Questo indicatore risiede in un tmpfs e viene azzerato a ogni avvio. Perciò va verificato 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. Un linux-image presente nell'elenco e più recente di quello indicato da uname -r significa che la macchina esegue un kernel obsoleto, indipendentemente dallo stato di Livepatch. Questo è il controllo più importante, perché il live patching è progettato per mantenere sicuro il kernel in esecuzione, non per aggiornarlo.

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

sudo needrestart -r l

La coppia di flag -r l significa "elenca soltanto", quindi visualizza i risultati senza apportare modifiche.

Perché il riavvio non scompare mai

Il kernel su disco non cambia. Le patch live vengono caricate nel kernel in esecuzione e non vengono mai scritte nell'immagine di boot. Di conseguenza, dopo un riavvio viene avviato il kernel indicato da linux-image dal bootloader, quindi il client Livepatch riapplica le patch ancora applicabili. Nell'intervallo tra questi due momenti il sistema esegue codice non aggiornato. Questo è un ulteriore motivo per avviare un kernel aggiornato anziché uno obsoleto.

La copertura è specifica per ogni serie di kernel, e le serie vengono ritirate. Quando la serie in esecuzione non è più inclusa nell'elenco supportato, la riga kernel state non mostra più la copertura. L'unica soluzione è installare un kernel più recente. Questo richiede un riavvio. In una release LTS, la nuova serie viene in genere resa disponibile come kernel hardware enablement incluso in una point release come 26.04.1, quindi il sostituto è già presente nell'archivio. Manca soltanto un boot pianificato.

Le correzioni del kernel con gravità media e bassa non vengono mai applicate live. Restano nel pacchetto su disco e diventano disponibili soltanto dopo l'avvio del nuovo kernel.

I kernel in esecuzione per periodi prolungati accumulano inoltre uno stato che il patching non ripulisce. Vale la pena citare la posizione ufficiale di Canonical, perché è quella corretta: Livepatch «non sostituisce il riavvio. È uno strumento che offre un maggiore controllo impedendo i riavvii non pianificati». La parola importante è non pianificati. Il riavvio resta necessario. Sei tu a scegliere quando eseguirlo.

Come programmare un riavvio con ripristino del sistema

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 online.

• Verifica che il provider metta a disposizione una console seriale o una vista VNC (virtual network computing) nel pannello di controllo e aprila subito, non durante l'interruzione del servizio.
• Controlla lo spazio disponibile con df -h /boot. Un /boot pieno può impedire al pacchetto del kernel di scrivere il relativo initramfs (initial RAM filesystem), lasciando nel bootloader una voce che punta a un'immagine incompleta.
• Mantieni installato almeno un kernel precedente sicuramente funzionante. GRUB lo elenca nella sezione "Advanced options for Ubuntu"; avviarlo è il metodo di ripristino più rapido quando un nuovo kernel non funziona.
• Individua la modalità rescue 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 puoi essere 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 lo annulla. Quando la macchina torna online, verifica entrambe le condizioni:

uname -r
sudo canonical-livepatch status

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

Perché è ancora necessario rimuovere i kernel obsoleti

Il live patching peggiora questo problema invece di risolverlo, perché elimina la necessità di riavviare il sistema mentre continuano a essere installati pacchetti linux-image. Ogni kernel installa un'immagine di boot, un initramfs, un albero di 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 possono riempirla.

Una /boot piena impedisce quindi l'installazione del kernel successivo. 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 server che non viene mai riavviato non sono sempre idonei, perché il gestore dei pacchetti non rimuove un kernel che potrebbe essere ancora in esecuzione.

Verifica quindi quali kernel sono installati, conserva quello in esecuzione e un fallback noto come funzionante, quindi rimuovi gli altri usando la procedura sicura per rimuovere i kernel obsoleti su Ubuntu. Non rimuovere mai il kernel attualmente indicato da uname -r.

FAQ

Il live patching del kernel 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 boot, quindi il linux-image su disco rimane alla versione con cui è stato avviato il sistema. 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 un riavvio di manutenzione con la frequenza che preferisci, invece di aspettare che te ne venga imposto uno.

Come posso verificare se il live patching del kernel 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 anche controllare direttamente il lato kernel con ls /sys/kernel/livepatch/, che elenca una directory per ogni patch caricata. Un elenco vuoto significa che in questo 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", che diventano 50 per i membri ufficiali della Ubuntu Community, ad agosto 2026. Per l'uso commerciale è necessario un abbonamento a pagamento. Collega una macchina con sudo pro attach TOKEN usando un token 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 di due motivi. La correzione potrebbe avere una gravità inferiore alla soglia prevista, perché Canonical applica live patch alle "vulnerabilità del kernel con valutazioni di priorità Ubuntu e Common Vulnerability Scoring System (CVSS) critiche e alte", lasciando le altre al pacchetto installato su disco. In alternativa, la correzione potrebbe non essere esprimibile come modifica al corpo di una funzione, ad esempio quando il codice upstream ha modificato una struttura dati, operazione che il live patching non può eseguire in sicurezza su oggetti già allocati. In entrambi i casi, la soluzione è la stessa: installare il pacchetto del kernel aggiornato e avviare il sistema con quel kernel.

Che cosa non copre mai il live patching del kernel?

Lo userspace. Canonical è esplicita: Livepatch "non applica patch alle librerie userspace come OpenSSL o glibc, perché questa responsabilità spetta a unattended-upgrades o a 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à eseguito il proprio codice e sono state liberate dalla memoria quando il server è operativo.