Live kernel patching ou redémarrage de 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 redémarrage ni interruption des connexions. Une version corrigée d’une fonction est chargée comme kernel module, puis chaque appel à l’ancienne fonction est redirigé vers la nouvelle version pendant que le serveur continue de traiter le trafic. Ce mécanisme explique à la fois les cas où le live patching est utile et ses limites.

Il vous fait gagner du temps. Il ne supprime pas la nécessité d’un redémarrage. Un serveur qui a reçu des live patches pendant six mois démarre toujours sur l’ancienne image du kernel présente sur le disque, et chacun de ces patches réside uniquement en mémoire.

Le live patching est souvent présenté comme une fonctionnalité d’un managed plan. Sur un serveur unmanaged, vous pouvez l’activer vous-même avec deux commandes. Cela mérite d’être connu avant de payer la différence entre un VPS managed et un VPS unmanaged.

Comment fonctionne le live kernel patching ?

Le kernel intègre un cœur 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 en cours d’exécution a été compilé avec ce cœur. Sans lui, aucun service de live patching ne peut agir 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 tout au début de la fonction, avant toute modification des arguments ou de la pile. Ftrace utilise cet emplacement d’appel comme hook. Lorsqu’un patch est appliqué, le cœur de live patching enregistre un handler ftrace sur la fonction cible, puis ce handler redirige 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 dès le début de l’entrée de la fonction, avant toute modification des paramètres de la fonction ou de la pile. »

Cette phrase entraîne deux conséquences importantes pour la suite. Seule une fonction sur laquelle ftrace peut poser un hook 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 d’une fonction.

Le point le plus difficile consiste à changer le code sans interrompre un système en production. 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 upstream 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 de barrière des appels système de kGraft avec le changement de trace de pile de kpatch ». Les tâches passent au nouveau code une par une, uniquement lorsque le kernel peut vérifier qu’une tâche ne se trouve pas actuellement dans une fonction patchée. Tant que toutes les tâches n’ont pas changé de code, le patch est en transition.

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

ls /sys/kernel/livepatch/

Une liste vide signifie qu’aucun live patch n’est chargé en mémoire. Sur un serveur fraîchement installé, il s’agit du comportement normal au départ.

Ce que le live patching du kernel ne peut pas corriger

Le live patching modifie le corps des fonctions. Il ne modifie rien d’autre.

• Les structures de données modifiées. Si le correctif upstream ajoute un champ à une structure ou change 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 : « Patches which modify statically allocated data are not directly supported. » Les variables shadow et les callbacks offrent une solution de contournement, mais ils doivent être écrits manuellement pour chaque correctif. Ils ne sont pas automatiques.
• Les correctifs répartis simultanément entre 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 les tâches au lieu de figer toute la machine à un instant unique.
• Le code d’initialisation. Les fonctions marquées __init ont déjà été exécutées et libérées lorsque votre serveur est opérationnel. Il n’y a donc plus rien à rediriger.
• Les nouvelles versions du kernel et les nouvelles fonctionnalités. Le live patching vous fait avancer d’un niveau de correctif à l’intérieur d’une même série de kernel. 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, comme les modifications introduites dans Linux 7.1, vous devez installer ce kernel et démarrer dessus.
• L’espace utilisateur. Canonical définit clairement cette 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 corrigé en direct associé à un OpenSSL obsolète ne constitue pas un serveur corrigé. Laissez donc unattended-upgrades gérer les paquets de l’espace utilisateur sur le même serveur.

Le service d’Ubuntu applique également un seuil de gravité. Canonical indique qu’il « patches kernel vulnerabilities with critical and high Common Vulnerability Scoring System (CVSS) and Ubuntu Priority ratings. » 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 comme 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 noyau ?

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

Canonical Livepatch est fourni avec Ubuntu Pro. Ubuntu Pro est gratuit pour un usage personnel. Selon la formulation de Canonical, il « 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. Un usage commercial nécessite un abonnement payant. La couverture est accordée par série de noyau et par flavour. Elle couvre les noyaux general availability (GA) des versions long term support (LTS) prises en charge, ainsi que leurs noyaux hardware enablement (HWE), pour des flavours comme generic, aws, azure, gcp, oracle, ibm et lowlatency. Vérifiez votre noyau dans la liste des noyaux publiée par Canonical avant de vous y fier.

KernelCare, de TuxCare, est un agent commercial qui prend en charge de nombreuses distributions, y compris celles qui ne disposent d’aucun service fourni par leur éditeur. Son installation documentée utilise le script du fournisseur, curl -s -L https://kernelcare.com/installer | bash, puis /usr/bin/kcarectl --register KEY pour une licence fondée sur une clé. L’agent recherche ensuite les nouveaux correctifs 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 de ces solutions. kGraft vient de SUSE et kpatch de Red Hat. Le cœur du live patching présent aujourd’hui dans le noyau Linux upstream résulte de la fusion de ces deux approches. kpatch lui-même est progressivement abandonné : 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 noyau upstream. Sur RHEL et ses rebuilds, utilisez le service fourni par la distribution plutôt que de construire les correctifs manuellement.

Choisissez votre solution en fonction de la prise en charge offerte par votre distribution et des conditions de votre licence. Le résultat au niveau du noyau 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 2 commandes ci-dessous nécessitent un accès réseau sortant fonctionnel, car le client contacte les serveurs de Canonical pour rattacher la machine au compte et récupérer les correctifs.

sudo pro attach TOKEN
sudo pro status

L’exécution de sudo pro attach sans token lance à la place une procédure dans le navigateur et affiche un code à saisir sur le site de Canonical. Le rattachement active automatiquement les services recommandés. Sur une version LTS actuelle, cela inclut Livepatch. 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 se termine. 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 fournissent 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 d’erreur lorsque vous démarrez un kernel que Livepatch ne prend pas en charge. patch state indique si les correctifs applicables à ce kernel sont réellement chargés. Un kernel pris en charge sans correctif appliqué indique un problème côté client. Un kernel non pris en charge indique un problème lié au 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, et 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 indique quels paquets l’ont demandé. 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.

Cet indicateur se trouve dans un tmpfs et est réinitialisé à chaque démarrage. Vous devez donc le vérifier directement dans le kernel :

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

uname -r affiche le kernel en cours d’exécution. La deuxième commande affiche les paquets de kernel installés sur le disque. La présence d’un linux-image dans cette liste, plus récent que celui indiqué par uname -r, signifie que la machine utilise un ancien kernel, quel que soit l’état de Livepatch. C’est la vérification importante : le live patching est conçu pour sécuriser le kernel en cours d’exécution, pas pour le maintenir à jour.

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

sudo needrestart -r l

La paire d’options -r l signifie « afficher uniquement ». La commande affiche donc des informations sans rien modifier.

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 démarrage. Après un redémarrage, le système utilise donc le linux-image sélectionné par le bootloader, puis le client Livepatch réapplique les patches encore compatibles. Entre ces deux moments, le code s’exécute sans les patches. Cela confirme qu’il vaut mieux démarrer sur un kernel à jour 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 utilisée n’est plus prise en charge, la ligne kernel state n’indique plus la couverture. La seule solution consiste alors à utiliser un kernel plus récent. Cela nécessite un redémarrage.

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

Les kernels qui restent longtemps en fonctionnement accumulent également un état que l’application de patches 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 imprévus. » Le mot important est imprévus. Vous devez toujours redémarrer. Vous choisissez le moment.

Planifier un redémarrage avec retour en ligne

Un redémarrage de 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, puis ouvrez-la maintenant plutôt que pendant la panne.
• Vérifiez l’espace disponible avec df -h /boot. Un /boot plein empêche le paquet du kernel d’écrire son initramfs (initial RAM filesystem), ce qui peut laisser une entrée du bootloader 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 lorsqu’un nouveau kernel échoue.
• Repérez le mode rescue de votre fournisseur avant d’en avoir besoin. Si la console affiche une invite initramfs après le redémarrage, c’est depuis celle-ci que vous effectuerez la réparation.

Redémarrez ensuite à 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 les deux éléments :

uname -r
sudo canonical-livepatch status

uname -r doit maintenant indiquer le kernel le plus récent, et la sortie de status 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 chemin de démarrage, et non au niveau du réseau. La procédure de récupération se trouve dans le guide consacré à un VPS qui ne démarre plus après une mise à jour du kernel.

Pourquoi il faut toujours supprimer les anciens noyaux

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 noyau installe une image de démarrage, 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 noyaux suffisent à la remplir.

Une partition /boot pleine bloque alors l’installation du noyau suivant. La machine peut ainsi ne plus pouvoir appliquer précisément la mise à jour dont elle a besoin. La commande apt autoremove supprime les anciens noyaux lorsqu’ils peuvent l’être. Toutefois, sur un serveur qui ne redémarre jamais, ces noyaux ne sont pas toujours éligibles, car le gestionnaire de paquets ne supprime pas un noyau que vous êtes peut-être encore en train d’utiliser.

Vérifiez donc les noyaux installés, conservez le noyau en cours d’exécution ainsi qu’un noyau de secours connu comme fonctionnel, puis supprimez les autres en suivant la procédure sûre de suppression des anciens noyaux sur Ubuntu. Ne supprimez jamais le noyau que uname -r indique comme étant actuellement utilisé.

FAQ

Le live patching 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 ne sont pas écrits dans l’image de démarrage. Le linux-image présent sur disque reste donc dans la version avec laquelle vous avez démarré. Canonical le précise : Livepatch « ne remplace pas les redémarrages. 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. De plus, les correctifs de gravité moyenne du kernel ne sont jamais appliqués par live patching. Planifiez plutôt un redémarrage de maintenance selon une fréquence choisie, au lieu d’attendre qu’il vous soit imposé.

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

Exécutez sudo canonical-livepatch status et lisez les deux lignes affichées. 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 destinés à ce kernel sont chargés. Vous pouvez aussi vérifier directement le côté kernel avec ls /sys/kernel/livepatch/, qui affiche un répertoire par correctif chargé. Une liste vide signifie qu’aucun correctif n’est actuellement appliqué en mémoire, quel que soit le message du client.

Ubuntu Pro est-il gratuit sur un VPS personnel ?

Oui, dans une limite définie. Canonical indique qu’Ubuntu Pro « est et restera toujours gratuit pour un usage personnel sur jusqu’à 5 machines physiques », avec une limite portée à 50 machines pour les membres officiels de la communauté Ubuntu, en août 2026. L’usage commercial nécessite un abonnement payant. Vous rattachez une machine avec sudo pro attach TOKEN, en utilisant 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 ?

Il y a généralement deux raisons. Le correctif peut être inférieur au seuil de gravité, car Canonical applique les live patches aux « vulnérabilités du kernel présentant des niveaux de priorité Ubuntu et un score CVSS (Common Vulnerability Scoring System) critiques ou élevés », et 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 identique : installez le package du kernel mis à jour, puis démarrez sur ce kernel.

Que ne couvre pas du tout le live patching 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 exécutez déjà. Enfin, il ne peut pas corriger les fonctions __init, qui ont déjà été exécutées et libérées de la mémoire lorsque le serveur est opérationnel.