Live kernel patching ou reboot sur votre VPS ?

Ce que fait le live kernel patching sur un VPS

Le live kernel patching applique les correctifs de sécurité du kernel sur une machine en fonctionnement, sans reboot et sans interrompre les connexions. Une copie corrigée d’une fonction est chargée comme kernel module, puis chaque appel à l’ancienne fonction est redirigé vers la nouvelle copie pendant que le serveur continue de traiter le trafic. Ce mécanisme explique à la fois ce que le live patching permet de faire et ce qu’il ne peut pas faire.

Il vous fait gagner du temps. Il ne supprime pas la nécessité d’un reboot. Un serveur qui a bénéficié du live patching pendant six mois a toujours démarré sur l’ancienne image du kernel présente sur le disque, et chacun de ces correctifs existe uniquement en mémoire.

Le live patching est souvent présenté comme une fonctionnalité d’une offre managed. Sur un serveur unmanaged, vous pouvez l’activer vous-même avec deux commandes. Il est donc utile de le savoir avant de payer la différence entre un VPS managed et un VPS unmanaged.

Comment fonctionne le live patching du kernel ?

Le kernel intègre un composant de live patching, compilé avec CONFIG_LIVEPATCH. Vérifiez sa présence dans le kernel en cours d’exécution :

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

Une ligne contenant CONFIG_LIVEPATCH=y signifie que le kernel utilisé a été compilé avec ce composant. Sans lui, aucun service de live patching ne peut intervenir sur cette machine.

La redirection utilise ftrace, le function tracer du kernel. La plupart des fonctions du kernel sont compilées avec une instruction d’appel au tout début de la fonction, avant toute modification des arguments ou de la pile. Ftrace utilise ce point d’appel comme hook. Lorsqu’un patch est appliqué, le composant de live patching enregistre un gestionnaire ftrace sur la fonction cible. Ce gestionnaire redirige alors l’exécution vers la fonction de remplacement. La documentation du kernel l’explique clairement : « Le live patching doit généralement rediriger le code au tout début de l’entrée de la fonction, avant que les paramètres de la fonction ou la pile ne soient modifiés de quelque manière que ce soit. »

Cette phrase entraîne deux conséquences, qui seront importantes par la suite. Seule une fonction que ftrace peut intercepter peut être patchée. Une fonction compilée sans cet appel d’entrée ne peut donc pas être patchée. De plus, l’unité de patching est toujours une fonction entière, jamais une seule ligne à l’intérieur de celle-ci.

La partie la plus complexe consiste à modifier un système en fonctionnement sans compromettre sa sécurité. Si l’ancien code s’exécute encore sur la pile d’un CPU au moment où vous remplacez la fonction, vous obtenez un mélange de comportements anciens et nouveaux. Le kernel Linux amont gère ce cas avec un modèle de cohérence par tâche, décrit dans la documentation du kernel comme un modèle hybride : « il combine la cohérence par tâche et le changement par barrière des appels système de kGraft avec le changement fondé sur la trace de pile de kpatch ». Les tâches passent au nouveau code une par une, uniquement lorsque le kernel peut établir qu’une tâche ne se trouve pas actuellement dans une fonction patchée. Tant que toutes les tâches n’ont pas effectué cette transition, le patch est en cours d’application.

Vous pouvez vérifier vous-même le résultat. Les patchs appliqués apparaissent sous /sys/kernel/livepatch, avec un répertoire par patch. Les fonctions patchées sont listées à l’intérieur.

ls /sys/kernel/livepatch/

Une liste vide signifie qu’aucun live patch n’est chargé en mémoire. Sur un serveur neuf, il s’agit de l’état initial normal.

Ce que le live kernel patching ne peut pas corriger

Les corps des fonctions sont corrigés. Rien d’autre ne l’est.

• Structures de données modifiées. Si le correctif upstream ajoute un champ à une structure ou modifie la signification d’un champ existant, il n’existe aucun moyen sûr de réécrire les objets déjà alloués et utilisés. Le projet kpatch décrit directement le cas équivalent : « Les correctifs qui modifient des données allouées statiquement ne sont pas pris en charge directement. » Les shadow variables et les callbacks offrent une solution de contournement, mais ils doivent être écrits manuellement pour chaque correctif et ne sont pas automatiques.
• Correctifs répartis sur plusieurs fonctions. Un correctif qui modifie l’ordre de prise des locks dans un groupe de fonctions doit modifier toutes ces fonctions ensemble. Le modèle de cohérence bascule entre les tâches au lieu de figer toute la machine à un instant donné.
• Code d’initialisation. Les fonctions marquées __init se sont déjà exécutées et ont été libérées au moment où votre serveur est démarré. Il ne reste donc rien vers quoi rediriger l’exécution.
• Nouvelles versions du kernel et nouvelles fonctionnalités. Le live patching vous fait progresser au sein d’une même série de kernel, d’un niveau de correctif au suivant. Il ne vous fait jamais passer à une autre série et n’ajoute jamais de fonctionnalité. Si vous voulez une fonctionnalité d’une série plus récente, par exemple les changements intégrés à Linux 7.1, vous installez ce kernel et vous démarrez dessus.
• Userspace. Canonical définit lui-même cette limite : « Canonical Livepatch ne corrige pas les bibliothèques du userspace comme OpenSSL ou glibc, car cette responsabilité incombe à unattended-upgrades ou à un outil de gestion des systèmes. » Un kernel corrigé en live à côté d’un OpenSSL obsolète ne constitue pas un serveur corrigé. Laissez donc unattended-upgrades gérer les paquets du userspace sur le même serveur.

Le service Ubuntu présente également une limite liée à la gravité des vulnérabilités. Canonical indique qu’il « corrige les vulnérabilités du kernel ayant un niveau critique ou élevé selon le Common Vulnerability Scoring System (CVSS) et les niveaux de priorité Ubuntu ». Un identifiant CVE (common vulnerabilities and exposures) désigne une vulnérabilité, et CVSS correspond au score qui lui est associé. Une CVE du kernel classée moyenne est corrigée dans le paquet présent sur le disque, mais ne fait pas l’objet d’un live patching. Elle atteint donc votre kernel en cours d’exécution au prochain redémarrage, et pas avant.

Quelles sont les options de live patching du kernel ?

Il existe trois lignées couramment utilisées. Elles s’appuient toutes sur les mêmes mécanismes du kernel.

Canonical Livepatch est fourni avec Ubuntu Pro. Ubuntu Pro est gratuit pour un usage personnel. Canonical précise que le service « is and always will be free for personal use on up to 5 physical machines », avec une limite portée à 50 machines pour les membres officiels de la communauté Ubuntu. Il s’agit de la limite documentée en août 2026. L’usage commercial nécessite un abonnement payant. La couverture est accordée par série de kernel et par flavour. Elle couvre les kernels general availability (GA) des versions long term support (LTS) prises en charge, ainsi que leurs kernels hardware enablement (HWE), pour des flavours comme generic, aws, azure, gcp, oracle, ibm et lowlatency. Vérifiez votre kernel dans la liste publiée par Canonical avant de vous y fier.

KernelCare, de TuxCare, est un agent commercial qui prend en charge de nombreuses distributions, notamment celles qui ne proposent aucun service first-party. Son installation documentée utilise un script du fournisseur, curl -s -L https://kernelcare.com/installer | bash, suivi de /usr/bin/kcarectl --register KEY pour une licence fondée sur une clé. L’agent recherche ensuite les nouveaux patchs selon son propre calendrier, et /usr/bin/kcarectl --update force une vérification. Lisez le programme d’installation avant de l’envoyer vers un shell sur un serveur important.

kpatch et kGraft sont les ancêtres. kGraft vient de SUSE et kpatch de Red Hat. Le cœur du live patching du kernel Linux upstream actuel est issu de la fusion de ces deux approches. kpatch lui-même est en voie d’abandon : son README indique qu’à partir de Linux 6.19, « the kpatch project is deprecated and in maintenance mode », et que kpatch-build est remplacé par klp-build dans le kernel upstream. Sur RHEL et ses rebuilds, utilisez le service fourni par la distribution plutôt que de construire les patchs manuellement.

Faites votre choix selon ce que votre distribution prend en charge et ce que votre licence autorise. Le résultat au niveau du kernel est identique dans tous les cas.

Comment activer Canonical Livepatch sur Ubuntu

Commencez par obtenir un token depuis la page de votre compte Ubuntu Pro. Les deux commandes ci-dessous nécessitent un accès réseau sortant fonctionnel, car le client communique avec les serveurs de Canonical pour rattacher le système au compte et récupérer les patches.

sudo pro attach TOKEN
sudo pro status

L’exécution de sudo pro attach sans token lance un parcours dans le navigateur et affiche un code à saisir sur le site de Canonical. Le rattachement active automatiquement les services recommandés, notamment Livepatch sur une version LTS actuelle. Utilisez sudo pro attach --no-auto-enable si vous préférez sélectionner vous-même les services.

Si Livepatch n’est pas déjà activé :

sudo pro enable livepatch
sudo canonical-livepatch status

Le service s’exécute depuis le snap canonical-livepatch. snapd doit donc fonctionner pour que l’activation aboutisse. pro status affiche un tableau des services avec leur entitlement et leur état. canonical-livepatch status affiche le détail par kernel. La documentation de Canonical présente une sortie de cette forme :

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

Deux lignes donnent la réponse. kernel state indique si la série que vous utilisez est prise en charge par le service. C’est cette ligne qui passe à l’état incorrect lorsque vous démarrez sur un kernel que Livepatch ne prend pas en charge. patch state indique si les patches applicables à ce kernel sont effectivement chargés. Un kernel pris en charge sans patch appliqué signale un problème côté client. Un kernel non pris en charge signale un problème côté kernel, et aucun réglage du client ne peut le corriger.

Comment savoir si un redémarrage est nécessaire ?

Le live patching supprime l’urgence. Un redémarrage nécessaire devient donc moins évident. Vous devez le vérifier.

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

Le gestionnaire de paquets crée /var/run/reboot-required lorsqu’un paquet installé nécessite un redémarrage pour prendre effet. L’installation d’un nouveau paquet linux-image le crée toujours. Le fichier .pkgs répertorie les paquets concernés. Si la première commande renvoie No such file or directory, aucun paquet n’a demandé de redémarrage depuis le dernier démarrage de la machine. Sur les versions récentes d’Ubuntu, /var/run est un lien symbolique vers /run. Les deux chemins donnent donc accès au même fichier.

Ce marqueur se trouve dans un tmpfs et est réinitialisé à chaque démarrage. Vérifiez-le donc par rapport au noyau lui-même :

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

uname -r affiche le noyau en cours d’exécution. La deuxième commande affiche les paquets du noyau installés sur le disque. La présence d’un paquet linux-image dans cette liste, plus récent que la version indiquée par uname -r, signifie que la machine utilise un ancien noyau, quel que soit l’état de Livepatch. C’est le contrôle important : le live patching vise à sécuriser le noyau en cours d’exécution, pas à le maintenir à jour.

Pour la partie espace utilisateur de cette même vérification, needrestart est installé par défaut sur Ubuntu Server. Il répertorie les services en cours d’exécution qui utilisent encore des fichiers de bibliothèque supprimés.

sudo needrestart -r l

La paire d’options -r l signifie « afficher uniquement ». Elle ne modifie donc rien.

Pourquoi le redémarrage reste nécessaire

Le kernel présent sur le disque n’est pas modifié. Les live patches sont chargés dans le kernel en cours d’exécution, mais ne sont jamais écrits dans l’image de boot. Après un redémarrage, vous utilisez donc le kernel sélectionné par le bootloader dans linux-image, puis le client Livepatch réapplique les patches encore compatibles. Entre ces deux étapes, le code s’exécute sans patches. C’est une raison supplémentaire de démarrer sur un kernel à jour plutôt que sur un ancien.

La couverture dépend de la série de kernels, et certaines séries arrivent en fin de support. Lorsque la série en cours n’est plus prise en charge, la ligne kernel state ne signale plus aucune couverture. La seule solution consiste alors à utiliser un kernel plus récent. Cela nécessite un redémarrage. Sur une version LTS, la nouvelle série vous parvient généralement sous la forme d’un kernel hardware enablement intégré à une version intermédiaire telle que 26.04.1. Le kernel de remplacement se trouve donc déjà dans l’archive. Il ne reste qu’à planifier un boot.

Les correctifs de kernel de sévérité moyenne ou faible ne sont jamais appliqués à chaud. Ils restent dans le package présent sur le disque et ne sont pris en compte qu’au démarrage du kernel corrigé.

Les kernels qui restent actifs longtemps accumulent aussi un état que le patching ne nettoie pas. La position de Canonical mérite d’être citée, car elle est claire : Livepatch « ne remplace pas le redémarrage. C’est un outil qui vous donne davantage de contrôle en évitant les redémarrages non planifiés. » Le mot important est non planifiés. Vous devez toujours redémarrer. Vous choisissez le moment.

Planifier un redémarrage avec retour en ligne

Le redémarrage d’un VPS est sans retour si vous ne pouvez pas accéder à la console. Avant de saisir reboot, vérifiez que vous pourrez vous reconnecter si la machine ne redémarre pas correctement.

• Vérifiez que votre fournisseur propose une console série ou une vue VNC (virtual network computing) dans le panneau de contrôle. Ouvrez-la maintenant, pas pendant la panne.
• Vérifiez l’espace disponible avec df -h /boot. Un /boot complet peut faire échouer l’installation du paquet du kernel lors de l’écriture de son initramfs (initial RAM filesystem). L’entrée du bootloader peut alors pointer vers une image incomplète.
• Conservez au moins un ancien kernel connu comme fonctionnel. GRUB l’affiche sous « Advanced options for Ubuntu ». Le démarrer est le moyen de récupération le plus rapide si le nouveau kernel échoue.
• Repérez le rescue mode de votre fournisseur avant d’en avoir besoin. Si la console affiche une invite initramfs après le redémarrage, c’est à cet endroit que la réparation doit être effectuée.

Planifiez ensuite le redémarrage à un moment où vous êtes disponible :

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

Cette commande planifie le redémarrage dans cinq minutes et envoie un message aux utilisateurs connectés. sudo shutdown -c l’annule. Lorsque la machine revient en ligne, vérifiez ces deux éléments :

uname -r
sudo canonical-livepatch status

uname -r doit maintenant indiquer le kernel le plus récent, et la sortie d’état doit indiquer que la nouvelle série est couverte. Si la machine ne revient pas du tout, le problème se situe presque toujours dans le boot path, et non dans le réseau. Utilisez alors la procédure de récupération du guide consacré à un VPS qui ne démarre plus après une mise à jour du kernel.

Pourquoi les anciens kernels doivent tout de même être supprimés

Le live patching aggrave ce problème au lieu de le résoudre, car il réduit la nécessité de redémarrer alors que les paquets linux-image continuent de s’installer. Chaque kernel installe une image de boot, un initramfs, une arborescence de modules et, généralement, un paquet de headers. Sur un petit VPS doté d’une partition /boot séparée de quelques centaines de mégaoctets, trois ou quatre kernels suffisent à la remplir.

Un /boot plein bloque ensuite l’installation du kernel suivant. C’est ainsi qu’une machine peut ne plus pouvoir installer précisément la mise à jour dont elle a besoin. La commande apt autoremove supprime les anciens kernels dès qu’ils peuvent l’être. Cependant, sur une machine qui ne redémarre jamais, ils ne sont pas toujours éligibles, car le gestionnaire de paquets ne supprime pas un kernel que vous êtes peut-être encore en train d’utiliser.

Vérifiez donc les kernels installés, conservez le kernel en cours d’exécution ainsi qu’un kernel de secours connu comme fonctionnel, puis supprimez les autres en suivant la procédure sûre pour supprimer les anciens kernels sur Ubuntu. Ne supprimez jamais le kernel indiqué actuellement par uname -r.

FAQ

Le patching à chaud du kernel signifie-t-il que je n’ai jamais besoin de redémarrer mon VPS ?

Non. Les live patches sont chargés dans le kernel en cours d’exécution, mais ils ne sont pas écrits dans l’image de démarrage. La linux-image présente sur disque reste donc celle de la version avec laquelle vous avez démarré. Canonical l’indique clairement : Livepatch « ne remplace pas le redémarrage. C’est un outil qui vous donne davantage de contrôle en évitant les redémarrages non planifiés. » La couverture prend également fin lorsque votre série de kernel arrive en fin de vie. Les correctifs de gravité moyenne du kernel ne sont jamais appliqués à chaud. Planifiez plutôt un redémarrage de maintenance selon une fréquence définie, au lieu d’attendre qu’un redémarrage vous soit imposé.

Comment vérifier que le patching à chaud du kernel applique réellement les correctifs ?

Exécutez sudo canonical-livepatch status et lisez deux lignes. kernel state indique si votre série de kernel en cours d’exécution est couverte par le service. patch state indique si les correctifs correspondant à ce kernel sont chargés. Vous pouvez également vérifier directement le côté kernel avec ls /sys/kernel/livepatch/. Cette commande affiche un répertoire pour chaque correctif chargé. Une liste vide signifie qu’aucun correctif n’est actuellement appliqué en mémoire, quel que soit le résultat indiqué par le client.

Ubuntu Pro est-il gratuit sur un VPS personnel ?

Oui, dans la limite prévue par la documentation. Canonical indique qu’Ubuntu Pro « est et restera toujours gratuit pour un usage personnel sur un maximum de 5 machines physiques ». Cette limite passe à 50 machines pour les membres officiels de la communauté Ubuntu, en août 2026. L’usage commercial nécessite un abonnement payant. Vous associez une machine avec sudo pro attach TOKEN à l’aide d’un token obtenu sur la page de votre compte Ubuntu Pro, puis vous activez le service avec sudo pro enable livepatch.

Pourquoi un CVE du kernel est-il toujours indiqué comme non corrigé après l’exécution de Livepatch ?

Deux raisons sont généralement possibles. Le correctif peut être inférieur au seuil de gravité. Canonical applique à chaud les « vulnérabilités du kernel ayant une évaluation CVSS (Common Vulnerability Scoring System) et une priorité Ubuntu critiques ou élevées », puis laisse les autres correctifs au package présent sur disque. Le correctif peut aussi ne pas pouvoir être exprimé comme une modification du corps d’une fonction. C’est notamment le cas lorsque le projet amont a modifié une structure de données, ce que le live patching ne peut pas faire de manière sûre sur des objets déjà alloués. Dans les deux cas, la solution est la même : installez le package du kernel mis à jour et démarrez sur cette version.

Que ne couvre absolument pas le patching à chaud du kernel ?

L’espace utilisateur. Canonical précise que Livepatch « ne corrige pas les bibliothèques de l’espace utilisateur comme OpenSSL ou glibc, car cette tâche relève de unattended-upgrades ou d’un outil de gestion des systèmes ». Il ne peut pas non plus fournir une nouvelle version du kernel ni une nouvelle fonctionnalité, puisqu’il remplace uniquement les corps de fonctions dans la série que vous utilisez déjà. Enfin, il ne peut pas corriger les fonctions __init, qui se sont déjà exécutées et ont été libérées de la mémoire lorsque le serveur est opérationnel.