Linux Kernel Live Patching su Ubuntu 20.04 LTS

Che fine ha fatto la promessa di patch live dei kernel Linux? Questo articolo esamina la sua storia, i suoi problemi e i modi più economici e semplici per farlo su Ubuntu Focal Fossa (20.04 LTS).

introduzione

Live patching è l'atto di aggiornare un programma senza arrestare il sistema su cui è in esecuzione. È stato fatto prima con saldatura e filo, poi con forbici e colla: non è una novità. Oggi, il live patching dei kernel Linux è molto meno appiccicoso.

In questo articolo spiegherò cos'è, come funziona (in termini non tecnici) e da dove viene. Concludo mostrando come automatizzare gli aggiornamenti di sicurezza del kernel su Ubuntu 20.04 LTS (Focal Fossa) con KernelCare.

Cos'è il Live Patching?

Nel software, una patch è un piccolo pezzo di codice di rettifica. L'applicazione di patch ripara o migliora una piccola parte di un programma senza interrompere il funzionamento o le specifiche dell'intero programma. Live (o hot) patching significa cambiare un programma in esecuzione senza fermarlo.

Immagina di essere intrappolato in un'auto in movimento e di dover riparare una lampadina. Non male, si potrebbe dire, se è dentro, un po' più complicato fuori. Ora immagina di riparare un albero a camme, sostituire l'asta di un pistone o sigillare un blocco rotto.

Questo è simile a ciò che il live patching sta cercando di fare sul kernel Linux. È cercare di riparare le parti di qualcosa in movimento, senza modificarlo o romperlo, ma soprattutto senza fermarlo. Il kernel è l'unica parte di un sistema Linux che necessita di un arresto e riavvio per applicare un aggiornamento. Quando un fornitore rilascia un aggiornamento del kernel, gli amministratori di sistema non hanno altra scelta che programmare il riavvio di un server.

Cosa c'è di male nel riavviare?

Un riavvio significa cose diverse per persone diverse, a seconda che si trovino nel sistema o ne siano responsabili. Molti amministratori di sistema considerano i riavvii regolari come un segno di buona salute, come l'intestino regolare. Proprio come molti non lo fanno, resistendo a qualsiasi interruzione delle applicazioni in cui hanno investito e guadagnando denaro da applicazioni come queste, ad esempio.

server web, con utenti impegnati e attivi in molti fusi orari
giochi multigiocatore online
streaming video in diretta o registrato pay-per-view
Estrazione di criptovalute
servizi di videosorveglianza e registrazione da remoto, 24 ore su 24, 7 giorni su 7

Per me, la ragione più riconoscibile è la paura che il sistema non sarà più lo stesso in seguito e che le applicazioni critiche (per fare soldi) non si avvieranno. Penso che sia questo, e non le visioni di utenti infuriati, a spingere molti amministratori di sistema a rimandare gli aggiornamenti del kernel, anche quelli più importanti, gli aggiornamenti di sicurezza.

(Qui sto solo parlando di aggiornamenti. Gli aggiornamenti del kernel sono qualcos'altro. Gli aggiornamenti sono kernel completamente nuovi. Le patch sono aggiornamenti di parti del kernel, di solito correzioni di bug che non vedo l'ora perché hanno implicazioni di sicurezza o altre implicazioni di vasta portata.)

Quando un fornitore di Linux rilascia una patch del kernel, di solito è per risolvere un problema di sicurezza. La nota di avviso associata dirà qualcosa del tipo Installa il prima possibile. Sulla stessa pagina ci sarà una versione di Se non lo fai, sarai vulnerabile agli exploit che abbiamo corretto e che tutti ora conoscono di. Buona giornata.'

Tali note scritte in modo insensibile evidenziano il dilemma che guida l'avvento del live patching: dovresti mantenere gli utenti irritati ma al sicuro o composti ma esposti? Il patching dal vivo promette di essere l'isola paradisiaca tra Rock e Hard Place. Le patch in tempo reale promettono di mantenere i tuoi server al sicuro e ai livelli di sicurezza più recenti, senza influire sui tempi di inattività e senza influire sui servizi.

Isola paradisiaca? Qual è il trucco?

Sebbene il codice sorgente per il software di patch live sia disponibile gratuitamente, le patch non lo sono. La dolce promessa del live patching si inasprisce quando devi scrivere le tue patch. La tua pressione sanguigna si attenua con meno amministrazione, ma sale di nuovo gestendo il complesso codice del kernel.

Sebbene sia tecnicamente possibile creare le proprie patch, ci vuole molto lavoro e molte conoscenze specialistiche. Ed è rischioso: una patch scritta male può mandare in crash un sistema. (Questo messaggio sulla pagina github di kpatch si legge come qualcosa dal manuale dell'operatore di un martello a vapore: ATTENZIONE: usare con cautela! Potrebbero verificarsi arresti anomali del kernel, riavvii spontanei e perdita di dati!)

I fornitori di Linux sanno quanto sia difficile eseguire correttamente le patch in tempo reale e hanno sviluppato offerte di servizi redditizie per trarre vantaggio da questo fatto. Ogni principale distribuzione Linux ha un approccio di patch live che è gratuito da installare, ma non da usare. Le patch, senza le quali l'intera idea è inutile, devono essere pagate.

Tuttavia, i vantaggi delle patch live del kernel sono così convincenti che questi modelli di business prosperano nell'ecosistema software prevalentemente gratuito e open source di Linux. Per me, questo è un segno che la tecnologia ha un significato e un ruolo importante nel futuro dei sistemi basati su Linux.

Come funziona il Live Patching

Ancora intrappolato in quell'auto immaginaria, che ora scende rombando verso una pila immaginaria di (si spera) scatole di cartone vuote, come aggiusteresti i freni? Costruire un martinetto temporaneo su cui eseguire il lavoro? Sporgersi su tre ruote, aspettare che una si fermi, toglierla, ripetere fino al termine?

I programmatori del kernel Linux devono aver usato lo stesso tipo di pensiero nell'affrontare il problema del live patching. Sento lo stesso tipo di apparato concettuale (sospensione, scambio, utilizzo di strutture di supporto temporanee) all'opera nelle loro soluzioni. La mia rozza analogia con il cambio di freno sopra illustra due strategie opposte implementate dai fornitori di software di patch live.

Ferma tutto e fai tutte le correzioni in una volta sola.
Attendi che i singoli componenti si fermino, quindi sostituiscili. Ripeti fino al termine.

Questa divisione spiega perché ogni fornitore ha escogitato approcci diversi per risolvere lo stesso problema. Ciò che condividono, tuttavia, è l'uso del framework del modulo kernel caricabile di Linux. Il software che orchestra e implementa il processo di applicazione delle patch è un modulo del kernel Linux. Ciò significa che è facile aggiungere funzionalità di patching ai kernel compatibili e altrettanto facile rimuoverle.

Prima di lasciarci trasportare, devo menzionare gli avvertimenti.

Esiste un limite all'ambito e alla portata delle patch software che è possibile applicare ai sistemi in esecuzione. Per prima cosa, i kernel personalizzati, ottimizzati o non standard rendono difficile o impossibile applicare live patch a un kernel. Dall'altro, il live patching non può rimappare i dati o la memoria tra le patch; può solo alterare le definizioni delle funzioni.

Queste carenze non hanno impedito a Ksplice di diventare il primo nel campo delle patch live di Linux. Funziona confrontando il vecchio e il nuovo codice sorgente da cui crea una patch binaria. Blocca il sistema, individua quali funzioni devono essere modificate e modifica le loro intestazioni. Quando vengono chiamate, le funzioni deviano alle nuove versioni. Se la patch è ben scritta, il controllo procede come se nulla fosse accaduto.

Un evento sismico (descritto nella sezione successiva) ha visto Kgraft di Red Hat entrare in scena con le proprie interpretazioni sui problemi principali delle patch in tempo reale.

Kpatch confronta il codice sorgente vecchio e nuovo per creare patch. Come Ksplice, funziona reindirizzando le chiamate di funzione utilizzando il framework ftrace del kernel per cambiare le funzioni modificate in una volta sola.

Kgraft funziona in modo diverso. Utilizza due insiemi simultanei di funzioni, vecchio e nuovo, con un modulo dell'orchestratore che decide quando reindirizzare le funzioni a seconda di dove è stata raggiunta l'esecuzione. È impossibile prevedere dove in una funzione si trova un puntatore di programma in qualsiasi momento, quindi la transizione è graduale, non istantanea.

Le origini del Live Patching

In che modo l'idea di aggiustare il software senza che nessuno se ne accorgesse è entrata in quel monolite in continua evoluzione dello sforzo umano, il kernel Linux?

Sebbene il concetto risalga ai primi giorni del calcolo programmabile, per i nostri scopi il percorso inizia nel 2001 quando Microsoft presenta un'idea per aggiornare un sistema (Windows) senza interruzioni.

Nessuno dei due menziona Linux, ma le applicazioni sono ampie e ciascuna descrive come risolvere i problemi software o hardware su un computer senza interrompere i processi in esecuzione su di esso. (Se l'idea non ti sembra particolarmente utile, forse due parole ti faranno ricredere: Spettro.)

Nel 2008, Jeff Arnold annuncia Ksplice, software per patchare i kernel Linux senza riavviarli. È il primo del suo genere per Linux. E dobbiamo ringraziare un hacker sconosciuto e senza nome.

Per capire perché, lascia che ti riporti ai giorni da studente del MIT di Jeff. È membro di un gruppo di volontari che amministra i server per la comunità studentesca. Uno dei server ha bisogno di una patch di sicurezza. Non vuole dare il via ai suoi utenti, quindi lo lascia scorrere per alcuni giorni.

In quei pochi giorni, prima che possa aggiornarlo, qualcuno hackera il sistema. L'unico modo per riportarlo online è reinstallarlo completamente da zero. Supponiamo che i suoi colleghi se ne accorgano. Anche supponendo che non soffrano, immagino che Jeff passi il resto del semestre ad arrostire lentamente sulle ceneri della derisione studentesca.

Se la storia è apocrifa, allora considerala una favola, un promemoria che il live patching è figlio della sicurezza, non della convenienza. E come tutte le belle favole, c'è un lieto fine.

L'incidente ispira Jeff a studiare come installare le patch del kernel Linux senza ritardi e senza interruzioni. Fa di questo problema l'argomento della sua tesi di laurea del 2006. La soluzione si presenta sotto forma di un software chiamato Ksplice. Con un collega, scrive un documento che lo descrive, intitolato Ksplice: aggiornamenti automatici del kernel senza riavvio.

Jeff e tre dei suoi colleghi studenti formano un'azienda e nel maggio 2009 vincono il premio MIT $100K Entrepreneurship Competition. Lanciano un servizio commerciale nel 2010. Un altro anno dopo, nel tipo di chiusura karmica che ogni sviluppatore di software sogna, Oracle acquista Ksplice Inc.

Il karma è lontano dalle menti degli utenti e dei clienti di questa nuova utility incredibilmente utile. Per loro è l'inizio di una lunga ed estenuante serie di incubi. Oracle assimila completamente Ksplice, rendendo lo strumento gratuito solo per i clienti delle proprie versioni di Linux finanziate dal canone di supporto.

Questo shock sismico spinge SUSE e Red Hat a sviluppare le proprie soluzioni, senza rivelare all'altro le proprie intenzioni o le architetture delle soluzioni. Lavorano in isolamento dal 2011 al 2014, rilasciando i propri approcci distinti a poche settimane l'uno dall'altro. E nel maggio 2014, KernelCare.

Allo stesso tempo, un live patching Livepatch. Nell'ottobre 2016, Canonical, i creatori di Ubuntu, lo usano come base per il servizio commerciale sotto il nome spudoratamente appropriato di Canonical Livepatch Service. Canonical lo rilascia prima per 16.04 LTS, poi per 14.04 LTS, entrambi richiedono l'installazione sulla riga di comando. In 18.04 LTS, è diventato più visibile, più facile da usare e meglio integrato nell'esperienza desktop di Ubuntu e ora è disponibile per 20.04 LTS.

Come farlo: aggiornamenti automatici della sicurezza del kernel su Ubuntu 20.04 LTS

Ora è il momento di vederlo in azione. Esistono due soluzioni di patch live per Ubuntu, trattate nelle prossime due sezioni.

Installazione del servizio Canonical Livepatch (CLS)

CLS è gratuito per le persone non commerciali, per un massimo di tre macchine. Richiede la registrazione, ma puoi usare un account Ubuntu One se ne hai uno. Se desideri installarlo su più di tre macchine, dovrai acquistare un contratto di assistenza di tipo aziendale.

Prima che inizi

Assicurati che il tuo sistema sia aggiornato e che sia stato eseguito il backup.
Registrati per un account Ubuntu One.
Per il server 20.04 LTS, prendi una chiave e prendine nota. (Questo non è necessario sull'edizione Desktop.)

Installazione di Livepatch su Ubuntu 20.04 LTS Desktop

Ubuntu 20.04 LTS Desktop ha un'impostazione GUI per attivare il CLS. Puoi farlo durante la configurazione post-installazione o successivamente, aprendo Software e aggiornamenti e andando alla scheda Livepatch.

Su una nuova installazione di Ubuntu

Dopo il primo riavvio di una nuova installazione, fai attenzione alla seconda schermata della finestra di dialogo Novità di Ubuntu. Ciò ti consente di configurare Livepatch.

Fai clic su Imposta Livepatch...
Nella schermata Account Ubuntu Single Sign-On, accedi con il tuo account Livepatch o Ubuntu One.
Se stai utilizzando la GUI di installazione basata su testo, in Featured Server Snaps, seleziona canonical-livepatch.

Su un'installazione Ubuntu esistente

Apri Software e aggiornamenti e vai alla scheda Livepatch.
Accedi.
Dopo aver effettuato l'accesso, fai clic su Continua quando viene visualizzato il popup che conferma l'accesso.
Ecco fatto. La livepatch è configurata sul tuo desktop Ubuntu 20.04.

Errori in Ubuntu 20.04 con Livepatch

Potresti riscontrare il seguente errore quando abiliti Livepatch su Ubuntu 20.04 Focal Fossa:

Failed to enable Livepatch: cannot enable machine: this machine ID is already enabled with a different key or is non-unique. Either "sudo canonical-livepatch disable" on the other machine, or regenerate a unique /etc/machine-id on this machine with "sudo rm /etc/machine-id /var/lib/dbus/machine-id && sudo systemd-machine-id-setup" server response: Conflicting machine-id

Per correggere l'errore, digitare i seguenti comandi nel terminale:

cp /etc/machine-id /etc/machine-id.original 
cp /var/lib/dbus/machine-id /var/lib/dbus/machine-id.original 
nano /etc/machine-id (to remove the existing value) 
systemd-machine-id-setup 
> Initializing machine ID from D-Bus machine ID. 
cat /etc/machine-id

Installazione di Livepatch su Ubuntu 20.04 LTS Server

Questo è l'approccio della riga di comando per le versioni server standard senza un sistema a finestre installato. Funziona anche con le versioni 16.04 LTS, 14.04 LTS e 18.04 LTS.

Apri un terminale e inserisci questi due comandi:

sudo snap install canonical-livepatch
sudo canonical-livepatch enable <your key>

Consigli

Il secondo comando restituisce un token macchina. Non serve a niente e non c'è bisogno di registrarlo.
Tieni traccia delle macchine che stai registrando. Se perdi traccia o elimini una macchina o una VM prima di annullare la registrazione, stai effettivamente buttando via una delle tue tre licenze gratuite. (C'è aiuto qui.)
Per annullare la registrazione di un server, utilizzare questo comando:

sudo canonical-livepatch disable <your key>

Per verificare lo stato del servizio, usa questo comando:

sudo canonical-livepatch status --verbose

Installazione di KernelCare

KernelCare utilizza una configurazione da riga di comando; non c'è interfaccia grafica. Supporta una gamma più ampia di sistemi operativi, inclusi CentOS, RHEL, Oracle Linux, Debian, Ubuntu e altri. Supporta anche la vecchia linea del kernel 2.6.32.

A differenza di CLS, è completamente automatizzato e controllerà le versioni di patch ogni quattro ore, installandole senza supervisione se disponibili. Se hai bisogno di sovrascrivere quella capacità o legare i server a patch a data fissa, c'è un'utilità della riga di comando (kcarectl) che ti consente di fare questo e altre cose.

KernelCare è gratuito per le organizzazioni senza scopo di lucro, oppure c'è una prova gratuita di 30 giorni per il resto di noi. (Se sei un utente Ksplice, potresti voler provare lo script di migrazione in due passaggi da Ksplice a KernelCare.)

Prima che inizi

Assicurati che il tuo sistema sia aggiornato e che sia stato eseguito il backup.
Ottieni una chiave di prova gratuita da qui.

Installazione di KernelCare su desktop e server Ubuntu 20.04 LTS

Apri un terminale e inserisci questi due comandi:

sudo wget -qq -O - https://repo.cloudlinux.com/kernelcare/kernelcare_install.sh | bash
sudo /usr/bin/kcarectl --register KEY

Questi comandi funzionano anche sulle versioni 16.04 LTS, 14.04 LTS e 18.04 LTS.

Consigli

Per annullare la registrazione di un server, utilizzare questo comando:

sudo kcarectl --unregister

Per verificare lo stato del servizio, usa questo comando:

sudo kcarectl --info

Conclusione

Il live patching su Linux era troppo utile per rimanere gratuito a lungo.

Con la versione 20.04 LTS di Ubuntu, è più facile godere dei vantaggi delle patch di sicurezza in tempo reale dei kernel Linux ed è gratuito per un massimo di tre host. Successivamente, si applicano tariffe annuali per server.

Se esegui molte versioni di Linux, ma non vuoi imparare prodotti diversi o sottoscrivere contratti di supporto diversi, dai un'occhiata a KernelCare. È circa cinque volte più economico se si effettua un abbonamento annuale e offrono abbonamenti mensili flessibili.