Recompiler son kernel: des noyaux aux petits oignons pour son infra

Le durcissement de l’OS est surtout de la soustraction, retirer ce qui écoute et couper les surfaces kernel dont on n’a pas besoin, ce que j’ai détaillé dans durcir l’OS et le kernel Linux . Il reste une marche que cet article-là n’a pas montée et c’est ma préférée: ne pas désactiver une fonction kernel au runtime, mais ne jamais la compiler du tout. Recompiler son propre noyau, c’est la soustraction poussée à sa conclusion logique.

Pourquoi recompiler, au juste

Le défaut d’une distribution est un kernel pour tout le monde, donc un kernel qui embarque à peu près tout: des centaines de pilotes, des systèmes de fichiers exotiques, des sous-systèmes réseau entiers, des options de debug, parce qu’il doit démarrer aussi bien sur le portable d’un étudiant que sur une baie de stockage. Sur une infra, le matériel est connu et stable et tout ce fardeau devient de la surface d’attaque gratuite. Un sous-système qui n’est pas compilé n’a pas de CVE pour vous, pas de module à charger, pas de bug à exploiter; il n’existe tout simplement pas dans le binaire. Compiler le kernel pour son parc, c’est donc trois gains d’un coup, une surface réduite à ce qu’on utilise vraiment, un noyau plus petit et souvent plus rapide parce qu’il porte moins et une maîtrise qui change tout le jour où il faut réagir.

Ce dernier point est le moins intuitif et le plus précieux. Quand on possède la chaîne qui produit son kernel, on n’attend pas le calendrier d’un éditeur pour corriger une faille, on backporte le patch amont et on livre, le jour même s’il le faut. On y reviendra plus bas, parce qu’une entreprise française l’a illustré de façon spectaculaire.

La sauce Debian: un paquet, un dépôt, un pinning

Le noyau se construit proprement en paquet Debian, sans bricolage à la main dans /boot. On part de la config du distributeur, on la taille avec make menuconfig et on sort un .deb versionné:

# depuis l'arbre des sources, config de base reprise de la distrib
make olddefconfig
make menuconfig                  # on retire ce qu'on n'utilise pas
make -j"$(nproc)" bindeb-pkg     # produit linux-image-*.deb, headers inclus

bindeb-pkg ne sort que les paquets binaires, ceux qu’on déploie; deb-pkg construirait en plus les paquets source, inutiles ici. Le .deb ne part pas sur les machines à la main, il entre dans son propre dépôt apt, tenu avec reprepro ou aptly, signé par une clef à soi. Les serveurs pointent sur ce dépôt et un apt pinning dit explicitement de préférer ce noyau à celui de la distribution:

# /etc/apt/preferences.d/kernel-maison
Package: linux-image-* linux-headers-*
Pin: origin depot.interne.example
Pin-Priority: 1001

Une priorité supérieure à 1000 autorise même le downgrade si l’on doit revenir en arrière, ce qui est exactement la propriété qu’on veut sur un noyau. À ce stade, un kernel maison se déploie comme n’importe quel paquet, apt upgrade et se reboot selon un calendrier comme le reste.

À l’échelle: Katello et le contenu qui se promeut

Un dépôt plat suffit à une poignée de machines, pas à un parc avec des environnements. C’est là que l’écosystème The Foreman entre, avec Katello, qui s’appuie sur Pulp pour héberger et versionner les dépôts et sur Candlepin pour les abonnements. Le kernel maison devient un contenu comme un autre, poussé dans une content view, figée en versions et promue le long d’environnements de cycle de vie, Library puis Dev puis Test puis Prod. La promotion est l’acte de confiance: un noyau ne passe en Prod que parce que sa version de content view a traversé Test et l’on peut épingler un environnement entier sur une version précise pendant qu’une autre essuie les plâtres. C’est la version industrielle du pinning, le même principe, avec la traçabilité et le rollback en plus.

Le prix, parce qu’il est réel

Il faut le dire sans détour: ce kiff a un coût et tout le monde ne peut pas se le permettre. Un kernel maison en production exige un pipeline de compilation et surtout de test sur du vrai matériel, parce qu’un noyau qui boote dans une VM peut très bien figer sur la carte réseau précise d’un modèle de serveur. Il exige du canari, une poignée de machines qui prennent le nouveau noyau avant le parc et un chemin de rollback répété pour de vrai, pas supposé. Un mauvais kernel ne rend pas un service indisponible, il brique la machine jusqu’à une intervention et multiplié par un parc c’est une très mauvaise nuit. Si l’on n’a pas les moyens de ce pipeline, la bonne réponse n’est pas de recompiler quand même, c’est de rester sur les noyaux de la distribution et de patcher vite et souvent, ce que défend déjà l’article de durcissement . La recompilation est un gain quand on a la discipline qui va avec, une dette quand on l’improvise.

Oui, je recompile et alors ?

La soustraction ultime n’est pas de désactiver une fonction kernel, c’est de ne jamais la compiler: ce qui n’est pas dans le binaire n’a ni CVE ni module ni bug pour vous.
Un kernel taillé pour un parc connu est plus petit, souvent plus rapide et débarrassé de surfaces entières qu’une distribution embarque pour plaire à tout le monde.
La sauce Debian est propre: bindeb-pkg, un dépôt apt à soi, un pinning et le noyau se déploie comme un paquet et se downgrade si besoin.
À l’échelle, Katello promeut le kernel comme un contenu versionné le long d’environnements, c’est le pinning avec traçabilité et rollback.
Le prix est un pipeline de test sur vrai matériel et du canari; sans lui, on reste sur la distrib et on patche vite, sans honte.

[edit: 2026] L’illustration grandeur nature est arrivée en juillet 2026 avec CVE-2026-53359, surnommée “Januscape”, un use-after-free dans le shadow-paging de KVM x86 qui touchait tous les kernels Linux x86, OVHcloud compris. Contrairement à ce que je croyais me souvenir, ils n’y ont pas échappé, leur parc était exposé comme les autres. Ce que leur pipeline de kernels Debian maison leur a donné, c’est la réactivité: leurs équipes Kernel et Virtualisation ont backporté le patch amont sur leurs noyaux de production et livré un kernel corrigé le soir même de l’alerte, au lieu de dépendre du calendrier d’un tiers sur des dizaines de milliers d’hyperviseurs et près d’un million de VM. Ils ont écarté explicitement l’attente d’un noyau officiel et le live patching, parce que ce dernier exige d’activer une option kernel qui réduit le durcissement. La maîtrise de son noyau n’est pas une immunité, c’est la liberté de réagir à son propre tempo. L’histoire est sur le blog d’OVHcloud .