Patching en direct du noyau Linux sur Ubuntu 20.04 LTS

Qu'est-il arrivé à la promesse de patcher en direct les noyaux Linux ? Cet article examine son historique, ses problèmes et les moyens les moins chers et les plus simples de le faire sur Ubuntu Focal Fossa (20.04 LTS).

Présentation

L'application de correctifs en direct consiste à mettre à jour un programme sans arrêter le système sur lequel il s'exécute. Cela a d'abord été fait avec de la soudure et du fil, plus tard, avec des ciseaux et de la colle - ce n'est pas nouveau. Aujourd'hui, les noyaux Linux correctifs en direct sont beaucoup moins collants.

Dans cet article, je vais vous expliquer ce que c'est, comment ça marche (en termes non techniques) et d'où ça vient. Je terminerai en montrant comment automatiser les mises à jour de sécurité du noyau sur Ubuntu 20.04 LTS (Focal Fossa) avec Canonical Livepatch Service et KernelCare.

Qu'est-ce que la correction en direct ?

Dans un logiciel, un correctif est un petit morceau de code de rectification. Le patching consiste à réparer ou à améliorer une petite partie d'un programme sans perturber le fonctionnement ou les spécifications de l'ensemble. Patcher en direct (ou à chaud) signifie modifier un programme en cours d'exécution sans l'arrêter.

Imaginez que vous êtes pris au piège dans une voiture en mouvement et que vous devez réparer une ampoule. Pas trop mal, me direz-vous, si c'est à l'intérieur, un peu plus délicat à l'extérieur. Imaginez maintenant réparer un arbre à cames, remplacer une tige de piston ou sceller un bloc fissuré.

Cela s'apparente à ce que le patch en direct essaie de faire sur le noyau Linux. C'est essayer de réparer les parties de quelque chose en mouvement, sans le changer ni le casser, mais surtout, sans l'arrêter. Le noyau est la seule partie d'un système Linux qui nécessite un arrêt et un redémarrage pour appliquer une mise à jour. Lorsqu'un fournisseur publie une mise à jour du noyau, les administrateurs système n'ont d'autre choix que de planifier le redémarrage d'un serveur.

Qu'y a-t-il de si mal à redémarrer ?

Un redémarrage signifie différentes choses pour différentes personnes, selon qu'elles sont sur le système ou en charge. De nombreux administrateurs système considèrent les redémarrages réguliers comme un signe de bonne santé, comme des intestins réguliers. Tout comme beaucoup ne le font pas, résistant à toute interruption des applications dans lesquelles ils ont investi et qui génèrent des revenus, des applications comme celles-ci, par exemple.

serveurs Web, avec des utilisateurs occupés et actifs sur de nombreux fuseaux horaires
jeux multijoueurs en ligne
diffusion vidéo en direct ou enregistrée à la carte
minage de crypto-monnaie
services de vidéosurveillance et d'enregistrement à distance 24h/24 et 7j/7

Pour moi, la raison la plus pertinente est la crainte que le système ne soit plus le même par la suite et que les applications critiques (lucratives) ne démarrent pas. Je pense que c'est cela, et non les visions d'utilisateurs déchaînés, qui pousse de nombreux administrateurs système à reporter les mises à jour du noyau, même les plus importantes, les mises à jour de sécurité.

(Ici, je ne parle que des mises à jour . mises à niveau du noyau sont autre chose. Les mises à niveau sont des noyaux entièrement nouveaux. Les correctifs sont des mises à jour de parties du noyau, généralement des correctifs de bogues qui ne peuvent pas attendre car ils ont des implications sur la sécurité ou d'autres implications de grande envergure.)

Lorsqu'un fournisseur Linux publie un correctif du noyau, c'est généralement pour résoudre un problème de sécurité. La note d'information associée dira quelque chose comme "Installez dès que possible." Sur la même page se trouvera une version de "Si vous ne le faites pas, vous serez vulnérable aux exploits que nous avons corrigés et que tout le monde connaît maintenant à propos. Bonne journée.

Ces notes rédigées avec rigueur mettent en évidence le dilemme à l'origine de l'avènement des correctifs en direct :devez-vous garder les utilisateurs "douloureux mais en sécurité" ou "serrés mais exposés" ? Le patching en direct promet d'être l'île paradisiaque entre Rock et Hard Place. L'application de correctifs en direct promet d'aider à maintenir vos serveurs en sécurité et aux derniers niveaux de sécurité, sans affecter les temps d'arrêt et sans affecter les services.

L'île paradisiaque ? Quel est le problème ?

Bien que le code source du logiciel de correctifs en direct soit disponible gratuitement, les correctifs ne le sont pas. La douce promesse du patching en direct s'impose quand il faut écrire ses propres patchs. Votre tension artérielle diminue avec moins d'administration, mais grimpe à nouveau en manipulant un code complexe du noyau.

Bien qu'il soit techniquement possible de créer ses propres patchs, cela demande beaucoup de travail et beaucoup de connaissances spécialisées. Et c'est risqué - un patch mal écrit peut planter un système. (Ce message sur la page github de kpatch ressemble à quelque chose du manuel d'utilisation d'un marteau à vapeur :"AVERTISSEMENT :À utiliser avec prudence ! Des plantages du noyau, des redémarrages spontanés et une perte de données peuvent survenir !")

Les fournisseurs de Linux savent à quel point il est difficile d'appliquer correctement des correctifs en direct et ont développé des offres de services rentables pour tirer parti de ce fait. Chaque distribution Linux majeure a une approche de correctifs en direct qui est gratuite à installer, mais pas à utiliser. Les patchs, sans lesquels toute l'idée est inutile, doivent être payés.

Pourtant, les avantages des correctifs du noyau en direct sont si convaincants que ces modèles commerciaux prospèrent dans l'écosystème de logiciels principalement libres et open source de Linux. Pour moi, c'est un signe que la technologie a une signification et un rôle important dans l'avenir des systèmes basés sur Linux.

Fonctionnement des patchs en direct

Toujours pris au piège dans cette voiture imaginaire, maintenant en train de dévaler vers un tas imaginaire de cartons (espérons-le) vides, comment répareriez-vous les freins ? Construire un cric roulant temporaire sur lequel effectuer les travaux ? Penchez-vous sur trois roues, attendez qu'une s'arrête, enlevez-la, répétez jusqu'à ce que vous ayez terminé ?

Les programmeurs du noyau Linux ont dû utiliser le même type de réflexion pour s'attaquer au problème des correctifs en direct. Je sens le même type d'appareil conceptuel (suspendre, permuter, utiliser des structures de support temporaires) à l'œuvre dans leurs solutions. Mon analogie brute de changement de frein ci-dessus illustre deux stratégies opposées mises en œuvre par les fournisseurs de logiciels de correctifs en direct.

Arrêtez tout et effectuez toutes les corrections en une seule fois.
Attendez que les composants individuels s'arrêtent, puis échangez-les. Répétez jusqu'à ce que vous ayez terminé.

Cette division explique pourquoi chaque fournisseur a proposé différentes approches pour résoudre le même problème. Ce qu'ils partagent, cependant, c'est l'utilisation du framework de module de noyau chargeable de Linux. Le logiciel qui orchestre et implémente le processus de correction est un module du noyau Linux. Cela signifie qu'il est facile d'ajouter une fonctionnalité de correctif aux noyaux compatibles et tout aussi facile de la supprimer.

Avant de nous laisser emporter, je dois mentionner les mises en garde.

Il existe une limite à la portée et à l'échelle des correctifs logiciels que vous pouvez appliquer aux systèmes en cours d'exécution. D'une part, les noyaux personnalisés, optimisés ou non standard rendent difficile, voire impossible, la mise à jour dynamique d'un noyau. D'autre part, le patch en direct ne peut pas remapper les données ou la mémoire entre les patchs ; il ne peut modifier que les définitions de fonctions.

Ces lacunes n'ont pas empêché Ksplice de devenir le premier dans le domaine des correctifs en direct Linux. Il fonctionne en comparant l'ancien et le nouveau code source à partir duquel il crée un patch binaire. Il gèle le système, détermine quelles fonctions doivent être modifiées et modifie leurs en-têtes. Lorsqu'elles sont appelées, les fonctions sont détournées vers les nouvelles versions. Si le patch est bien écrit, le contrôle se déroule comme si de rien n'était.

Un événement sismique (décrit dans la section suivante) a vu Kpatch de Red Hat et Kgraft de SUSE rejoindre la scène avec leurs propres interprétations sur les problèmes fondamentaux de la correction en direct.

Kpatch compare l'ancien et le nouveau code source pour créer des correctifs. Comme Ksplice, il fonctionne en redirigeant les appels de fonction à l'aide du framework ftrace du noyau pour basculer les fonctions modifiées en une seule fois.

Kgraft fonctionne différemment. Il utilise deux ensembles de fonctions simultanés, anciens et nouveaux, avec un module d'orchestrateur qui décide quand rediriger les fonctions en fonction de l'endroit où l'exécution a atteint. Il est impossible de prédire où se trouve un pointeur de programme dans une fonction à un moment donné, de sorte que la transition est progressive et non instantanée.

Les origines du patch en direct

Comment l'idée de réparer un logiciel sans que personne ne s'en aperçoive s'est-elle retrouvée dans ce monolithe en constante évolution de l'effort humain, le noyau Linux ?

Bien que le concept remonte aux premiers jours du calcul programmable, pour nos besoins, la piste commence en 2001 lorsque Hewlett Packard brevète un moyen de mettre à jour dynamiquement le logiciel pour compenser les fonctionnalités matérielles manquantes. Un an plus tard, Microsoft présente une idée pour mettre à jour un système (Windows) sans interruption.

Ni l'un ni l'autre ne mentionne Linux, mais les applications sont vastes, chacune décrivant comment résoudre les problèmes logiciels ou matériels sur un ordinateur sans perturber les processus qui y sont exécutés. (Si l'idée ne vous semble pas particulièrement utile, peut-être que deux mots vous feront réfléchir à nouveau :Meltdown et Spectre.)

En 2008, Jeff Arnold annonce Ksplice, un logiciel pour patcher les noyaux Linux sans les redémarrer. C'est le premier du genre pour Linux. Et nous devons remercier un hacker inconnu et anonyme.

Pour voir pourquoi, laissez-moi vous ramener à l'époque des étudiants du MIT de Jeff. Il est membre d'un groupe de bénévoles administrant des serveurs pour la communauté étudiante. L'un des serveurs a besoin d'un correctif de sécurité. Il ne veut pas donner un coup de pied à ses utilisateurs, alors il laisse tomber pendant quelques jours.

Pendant ces quelques jours, avant qu'il ne puisse le mettre à jour, quelqu'un pirate le système. La seule façon de le remettre en ligne est de le réinstaller complètement à partir de zéro. Supposons que ses collègues le remarquent. Même en supposant qu'ils ne souffrent pas, j'imagine que Jeff passe le reste du semestre à rôtir lentement sur les cendres de la dérision des étudiants.

Si l'histoire est apocryphe, alors considérez-la comme une fable, un rappel que le patch en direct est l'enfant de la sécurité, pas de la commodité. Et comme toutes les bonnes fables, il y a une fin heureuse.

L'incident incite Jeff à étudier comment installer les correctifs du noyau Linux sans délai et sans interruption. Il fait de ce problème le sujet de sa thèse de maîtrise en 2006. La solution se présente sous la forme d'un logiciel appelé Ksplice. Avec un collègue, il rédige un article le décrivant, intitulé "Ksplice :mises à jour automatiques du noyau sans redémarrage".

Jeff et trois de ses collègues étudiants forment une entreprise et, en mai 2009, ils remportent le prix du concours d'entrepreneuriat de 100 000 $ du MIT. Ils lancent un service commercial en 2010. Un an plus tard, dans le genre de fermeture karmique dont rêvent tous les développeurs de logiciels, Oracle rachète Ksplice Inc.

Karma est loin de l'esprit des utilisateurs et des clients de ce nouvel utilitaire incroyablement utile. Pour eux, c'est le début d'une longue et épuisante série de cauchemars. Oracle assimile complètement Ksplice, ce qui rend l'outil gratuit uniquement pour les clients de leurs propres versions de Linux financées par des frais de support.

Ce choc sismique incite SUSE et Red Hat à développer leurs propres solutions, sans dire à l'autre leurs intentions ou leurs architectures de solutions. Ils ont travaillé isolément de 2011 à 2014, publiant leurs propres approches distinctes à quelques semaines d'intervalle. Et en mai 2014, CloudLinux, producteurs d'une variante Linux bien connue dans les sphères de l'hébergement Web, lance un service commercial de correctifs en direct du noyau Linux sous le nom de KernelCare.

Dans le même temps, un ABI de patch en direct fait son chemin dans la ligne principale du noyau, voyant le jour dans la version 4.0 sous le nom de Livepatch. En octobre 2016, Canonical, les créateurs d'Ubuntu, l'utilisent comme base d'un service commercial sous le nom sans vergogne approprié de "Canonical Livepatch Service". Canonical le publie d'abord pour 16.04 LTS, puis 14.04 LTS, les deux nécessitant une configuration sur la ligne de commande. Dans 18.04 LTS, il est devenu plus visible, plus facile à utiliser et mieux intégré à l'expérience de bureau Ubuntu et il est maintenant disponible pour 20.04 LTS.

Comment procéder :mises à jour de sécurité automatisées du noyau sur Ubuntu 20.04 LTS

Il est maintenant temps de le voir en action. Il existe deux solutions de correctifs en direct pour Ubuntu, abordées dans les deux sections suivantes.

Installation du service Canonical Livepatch (CLS)

CLS est gratuit pour les particuliers non commerçants, jusqu'à trois machines. Il nécessite une inscription, mais vous pouvez utiliser un compte Ubuntu One si vous en avez un. Si vous souhaitez l'installer sur plus de trois machines, vous devrez acheter un contrat de service d'assistance de type entreprise.

Avant de commencer

Assurez-vous que votre système est à jour et sauvegardé.
Inscrivez-vous pour un compte Livepatch ou Ubuntu One.
Pour le serveur 20.04 LTS, obtenez une clé et notez-la. (Ce n'est pas nécessaire sur l'édition Desktop.)

Installer Livepatch sur le bureau Ubuntu 20.04 LTS

Ubuntu 20.04 LTS Desktop a un paramètre d'interface graphique pour activer le CLS. Vous pouvez le faire soit pendant la configuration post-installation, soit plus tard, en ouvrant les logiciels et les mises à jour et en accédant à l'onglet Livepatch.

Sur une nouvelle installation d'Ubuntu

Après le premier redémarrage d'une nouvelle installation, faites attention au deuxième écran de la fenêtre de dialogue "Quoi de neuf dans Ubuntu". Cela vous permet de configurer Livepatch.

Cliquez sur "Configurer Livepatch…"
Sur l'écran "Ubuntu Single Sign-On Account", connectez-vous avec votre compte Livepatch ou Ubuntu One.
Si vous utilisez l'interface graphique d'installation en mode texte, sous "Featured Server Snaps", sélectionnez canonical-livepatch.

Sur une installation Ubuntu existante

Ouvrez "Logiciels et mises à jour" et accédez à l'onglet "Livepatch".
Connectez-vous.
Une fois connecté, cliquez sur Continuer lorsque la fenêtre contextuelle s'affiche pour confirmer que vous êtes connecté.
C'est tout. Le livepatch est configuré sur votre bureau Ubuntu 20.04.

Erreurs dans Ubuntu 20.04 avec Livepatch

Vous pouvez rencontrer l'erreur suivante lors de l'activation de Livepatch sur 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

Pour corriger l'erreur, tapez les commandes suivantes dans le terminal :

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

Installation de Livepatch sur le serveur Ubuntu 20.04 LTS

Il s'agit de l'approche de la ligne de commande pour les versions de serveur standard sans système de fenêtrage installé. Il fonctionne également sur les versions 16.04 LTS, 14.04 LTS et 18.04 LTS.

Ouvrez un terminal et saisissez ces deux commandes :

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

Conseils

La deuxième commande renvoie un jeton machine. Cela ne sert à rien et il n'est pas nécessaire de l'enregistrer.
Gardez une trace des machines que vous enregistrez. Si vous perdez la trace ou si vous vous débarrassez d'une machine ou d'une machine virtuelle avant de vous désinscrire, vous jetez en fait l'une de vos trois licences gratuites. (Il y a de l'aide ici.)
Pour désenregistrer un serveur, utilisez cette commande :

sudo canonical-livepatch disable <your key>

Pour vérifier l'état du service, utilisez cette commande :

sudo canonical-livepatch status --verbose

Installer KernelCare

KernelCare utilise une configuration en ligne de commande ; il n'y a pas d'interface graphique. Il prend en charge une plus large gamme de systèmes d'exploitation, notamment CentOS, RHEL, Oracle Linux, Debian, Ubuntu et autres. Il prend également en charge l'ancienne ligne de noyau 2.6.32.

Contrairement à CLS, il est entièrement automatisé et vérifiera les versions de correctifs toutes les quatre heures, en les installant sans supervision, le cas échéant. Si vous avez besoin de remplacer cette capacité ou de lier des serveurs à des correctifs à date fixe, il existe un utilitaire de ligne de commande (kcarectl) qui vous permet de faire cela et d'autres choses.

KernelCare est gratuit pour les organisations à but non lucratif, ou il y a un essai gratuit de 30 jours pour le reste d'entre nous. (Si vous êtes un utilisateur de Ksplice, vous pouvez essayer le script de migration de Ksplice vers KernelCare en deux étapes.)

Avant de commencer

Assurez-vous que votre système est à jour et sauvegardé.
Obtenez une clé d'essai gratuite ici.

Installation de KernelCare sur le bureau et le serveur Ubuntu 20.04 LTS

Ouvrez un terminal et saisissez ces deux commandes :

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

Ces commandes fonctionnent également sur les versions 16.04 LTS, 14.04 LTS et 18.04 LTS.

Conseils

Pour désenregistrer un serveur, utilisez cette commande :

sudo kcarectl --unregister

Pour vérifier l'état du service, utilisez cette commande :

sudo kcarectl --info

Conclusion

Les correctifs en direct sur Linux étaient bien trop utiles pour rester gratuits pendant longtemps.

Avec la version 20.04 LTS d'Ubuntu, il est plus facile de profiter des avantages des correctifs de sécurité en direct des noyaux Linux, et c'est gratuit pour un maximum de trois hôtes. Après cela, des frais annuels par serveur s'appliquent.

Si vous utilisez de nombreuses versions de Linux, mais que vous ne souhaitez pas apprendre différents produits ou souscrire à différents contrats de support, jetez un œil à KernelCare. C'est environ cinq fois moins cher en s'abonnant à l'année, et ils proposent des abonnements mensuels flexibles.