8.10. Compilation d'un noyau

Les noyaux fournis par Debian intègrent le plus grand nombre possible de fonctionnalités ainsi qu'un maximum de pilotes, afin de couvrir le plus grand spectre de configurations matérielles existantes. C'est pourquoi certains utilisateurs préfèrent recompiler le noyau pour n'y inclure que le strict nécessaire. Il existe deux raisons à ce choix. Premièrement, cela peut être pour optimiser la consommation de mémoire, puisque le code du noyau, même s'il n'est jamais utilisé, occupe de la mémoire pour rien (et ne « descend » jamais sur l'espace d'échange, donc c'est de vraie mémoire vive qu'il s'agit), ce qui peut diminuer les performances globales du système. Il peut également s'agir de limiter le risque de failles de sécurité (le code compilé portant alors sur une fraction plus faible du code existant).

La recompilation du noyau est aussi nécessaire si l'on souhaite employer certaines fonctionnalités non intégrées dans sa version standard mais disponibles sous forme de correctifs, ou patches.

POUR ALLER PLUS LOIN Le Manuel du noyau Debian

L'équipe en charge du noyau dans Debian maintient le « Manuel du noyau Debian » (également disponible dans le paquet debian-kernel-handbook), qui contient une mine d'informations à propos de la plupart des tâches liées au noyau et à la manière dont les paquets Debian du noyau sont traités. C'est le premier endroit où chercher des informations qui manqueraient à la présente section.

→ https://kernel-team.pages.debian.net/kernel-handbook/

8.10.1. Introduction et prérequis

Comme on peut s'y attendre, Debian gère le noyau sous forme de paquet, ce qui n'est pas la manière traditionnelle de le compiler et de l'installer. Les noyaux restant sous le contrôle du système de paquetage, ils peuvent être rapidement supprimés ou déployés sur plusieurs machines. De plus, les scripts associés à ces paquets permettent également une meilleure interaction avec le chargeur de démarrage et le générateur d'images de démarrage (initrd).

Les sources amont du noyau Linux contiennent tout ce qui est requis pour construire un paquet Debian du noyau. Vous aurez simplement besoin d'installer le paquet build-essential, qui contient les outils de compilation standards pour générer un paquet Debian. Par ailleurs, la configuration du noyau nécessitera le paquet libncurses5-dev. Enfin, le paquet fakeroot permettra de créer le paquet Debian sans utiliser les droits de l'administrateur.

8.10.2. Récupérer les sources

Comme tout ce qui peut être utile sur un système Debian, les sources du noyau Linux sont disponibles en paquets. Pour les récupérer, il faudra donc installer un paquet linux-source-version. Une requête apt search ^linux-source permet d'obtenir la liste des différentes versions du noyau empaquetées par Debian. Les dernières versions en date sont vraisemblablement disponibles dans la distribution Unstable : on peut les y récupérer sans grands risques (surtout si votre APT est configuré conformément aux instructions de la Section 6.2.6, « Travailler avec plusieurs distributions »). Il est à noter que les codes sources contenus dans ces paquets ne correspondent pas exactement à ceux que publient Linus Torvalds et les développeurs du noyau : Debian applique en effet un certain nombre de patches — comme toutes les distributions. Ces modifications incluent des correctifs (dont certains concernent des failles de sécurité) ou des fonctionnalités qui sont en attente d'intégration dans une version ultérieure du noyau, ainsi que quelques fonctionnalités spécifiques à Debian.

Dans la suite de cette section, c'est le noyau 4.19 qui sera systématiquement retenu. Vous pourrez bien entendu adapter ces exemples à la version particulière du noyau qui vous intéresse.

Ainsi donc, le paquet linux-source-4.19 a été installé. Il contient le fichier /usr/src/linux-source-4.19.tar.xz, une archive compressée des sources du noyau. Il faut décompacter ces fichiers dans un nouveau répertoire (et non pas directement dans /usr/src/, car il n'y a pas besoin de droits particuliers pour compiler un noyau Linux) : ~/kernel/ conviendra.

$ mkdir ~/kernel; cd ~/kernel
$ tar -xaf /usr/src/linux-source-4.19.tar.xz

CULTURE Emplacement des sources du noyau

Traditionnellement, les sources du noyau Linux ont toujours été placées sous /usr/src/linux/, nécessitant donc les droits root pour la compilation. Comme vous le savez, il faut pourtant éviter de travailler inutilement avec les droits de l'administrateur. Il existe bien un groupe src qui permet à ses membres de travailler dans ce répertoire, mais on évitera malgré tout de recourir à /usr/src/. En conservant les sources du noyau dans un répertoire personnel, vous optez pour la sécurité à tout point de vue : pas de fichiers inconnus du système de paquetage dans /usr/, ni de risque d'induire en erreur les programmes qui scrutent /usr/src/linux/ pour obtenir des informations sur le noyau employé.

8.10.3. Configuration du noyau

La prochaine étape consiste à configurer le noyau conformément à ses besoins. Le mode opératoire dépend des objectifs.

Si l'on recompile une version plus récente du noyau (éventuellement dotée d'un patch supplémentaire), le plus probable est qu'on veuille rester aussi près que possible de la configuration standard proposée par Debian. Dans ce cas, et au lieu de tout reconfigurer depuis zéro, il est bon de copier le fichier /boot/config-version (la version est celle du noyau employé actuellement — uname -r vous la révélera au besoin) en .config dans le répertoire des sources du noyau .

$ cp /boot/config-4.19.0-5-amd64 ~/kernel/linux-source-4.19/.config

Si vous ne souhaitez pas changer la configuration, vous pouvez en rester là et sauter directement à la Section 8.10.4, « Compilation et génération du paquet ». Dans le cas contraire, ou si vous avez décidé de tout reconfigurer depuis zéro, il faudra prendre le temps de configurer votre noyau. Pour cela, il propose différentes interfaces, qu'on invoque depuis le répertoire des sources par la commande make suivie d'un argument.

make menuconfig compile et exécute une interface évoluée en mode texte (c'est ici que le paquet libncurses5-dev est requis) qui propose de naviguer dans une structure hiérarchique présentant les options proposées. Une pression sur la touche Espace change la valeur de l'option sélectionnée et Entrée valide le bouton sélectionné en bas de l'écran : Select permet de rentrer dans le sous-menu sélectionné, Exit remonte d'un cran dans la hiérarchie, et Help produit des informations plus détaillées sur le rôle de l'option sélectionnée. Les flèches permettent de se positionner dans la liste des options et des boutons. Pour quitter le configurateur, il faut sélectionner Exit depuis le menu principal. Le programme propose alors de sauvegarder les changements : acceptez si vous êtes satisfaits de vos choix.

Les autres interfaces ont un fonctionnement similaire, mais inscrit dans des interfaces graphiques plus modernes : make xconfig emploie la boîte à outils Qt et make gconfig recourt à GTK+. La première a besoin de libqt4-dev tandis que la seconde requiert libglade2-dev et libgtk2.0-dev.

Lorsque l'on utilise une de ces interfaces de configuration, il est généralement conseillé de partir d'une configuration par défaut raisonnable. Le noyau fournit de telles configurations dans arch/architecture/configs/*_defconfig et il est possible de les mettre en place avec une commande telle que make x86_64_defconfig (pour un PC 64 bits) ou make i386_defconfig (pour un PC 32 bits).

ASTUCE Que faire d'un .config obsolète ?

Lorsque l'on fournit un fichier .config qui provient d'une autre version du noyau (généralement plus ancienne), ce fichier doit être mis à jour. Cela se fait avec make oldconfig, qui va poser interactivement les questions portant sur les nouvelles options de configuration. Pour utiliser les réponses par défaut à toutes ces questions, on préfèrera make olddefconfig. Pour finir, la commande make oldnoconfig répondra par la négative à toutes ces nouvelles questions.

8.10.4. Compilation et génération du paquet

ATTENTION Nettoyer avant de recommencer

Si vous avez déjà construit un noyau dans le répertoire et si vous voulez tout reconstruire depuis zéro (par exemple après avoir changé la configuration du noyau de manière substantielle), il faudra lancer make clean, qui supprimera les fichiers compilés. make distclean fait un ménage encore plus poussé et supprime tous les fichiers générés, y compris votre .config ; faites-en une sauvegarde au préalable. Si vous copiez la configuration à partir de /boot/, vous devez modifier l'option relative aux clés de confiance du système, fournir une chaîne vide est suffisant: CONFIG_SYSTEM_TRUSTED_KEYS = "".

Une fois que la configuration du noyau est prête, la commande make deb-pkg va créer jusqu'à 5 paquets Debian : linux-image-version, qui contient le noyau lui-même et les modules associés ; linux-headers-version, qui contient les fichiers d'en-tête nécessaires pour construire des modules externes ; linux-firmware-image-version, qui contient des fichiers de microcode requis par certains pilotes de périphériques (ce paquet peut être absent lorsque vous compilez le noyau depuis les sources fournies par Debian) ; linux-image-version-dbg, qui contient les symboles de débogage pour l'image du noyau et ses modules ; linux-libc-dev, qui contient les fichiers d'en-têtes requis pour certaines bibliothèques de code en espace utilisateur, telles que la bibliothèque C standard de GNU (glibc).

La version est construite à partir de la version amont (définie par les variables VERSION, PATCHLEVEL, SUBLEVEL et EXTRAVERSION dans le fichier Makefile), du paramètre de configuration LOCALVERSION et de la variable d'environnement LOCALVERSION. La version du paquet réutilise la même chaîne de version, avec une révision qui est régulièrement incrémentée (et stockée dans le fichier .version), sauf si elle est explicitement surchargée par la variable d'environnement KDEB_PKGVERSION.

$ make deb-pkg LOCALVERSION=-falcot KDEB_PKGVERSION=$(make kernelversion)-1
[...]
$ ls ../*.deb
../linux-headers-4.19.37-falcot_4.19.37-1_amd64.deb
../linux-image-4.19.37-falcot_4.19.37-1_amd64.deb
../linux-libc-dev_4.19.37-1_amd64.deb

8.10.5. Compilation de modules externes

Certains modules sont gérés en dehors du noyau Linux officiel. Pour les utiliser, il faut les compiler de concert avec le noyau correspondant. Debian fournit, via des paquets dédiés, les sources d'un certain nombre de modules externes, tels que vpb-driver-source (modules supplémentaires pour le matériel de téléphonie Voicetronix) ou leds-alix-source (pilote pour les cartes PCEngines ALIX 2/3).

Debian fournit un grand nombre de modules externes, la commande apt-cache rdepends module-assistant$ permet d'en obtenir la liste. De toute façon, cette liste n'apporte rien puisqu'il n'y a pas de raison particulière de compiler des modules externes sauf quand on sait qu'on en a besoin — auquel cas la documentation du périphérique vous renseignera.

Examinons par exemple le paquet dahdi-source : après installation, un fichier .tar.bz2 des sources du module est stocké dans /usr/src/. Nous pourrions extraire cette archive et construire le module à la main, mais en pratique il est d'usage d'automatiser tout cela avec DKMS. La plupart des modules proposent l'intégration avec DKMS dans un paquet dont le nom finit par -dkms. Dans notre cas, il suffit d'installer le paquet dahdi-dkms pour que le module soit compilé pour le noyau courant, à condition que le paquet linux-headers-* correspondant au noyau courant soit aussi installé. Par exemple, si l'on utilise linux-image-amd64, il faut également installer linux-headers-amd64.

$ sudo apt install dahdi-dkms

[...]
Setting up xtables-addons-dkms (2.12-0.1) ...
Loading new xtables-addons-2.12 DKMS files...
Building for 4.19.0-5-amd64
Building initial module for 4.19.0-5-amd64
Done.

dahdi_dummy.ko:
Running module version sanity check.
 - Original module
   - No original module exists within this kernel
 - Installation
   - Installing to /lib/modules/4.19.0-5-amd64/updates/dkms/
[...]
DKMS: install completed.
$ sudo dkms status
dahdi, DEB_VERSION, 4.19.0-5-amd64, x86_64: installed
$ sudo modinfo dahdi_dummy
filename:       /lib/modules/4.19.0-5-amd64/updates/dkms/dahdi_dummy.ko
license:        GPL v2
author:         Robert Pleh <robert.pleh@hermes.si>
description:    Timing-Only Driver
[...]

ALTERNATIVE module-assistant

Avant l'apparition de DKMS, la solution la plus simple pour construire et déployer des modules du noyau était module-assistant. Cette solution est toujours disponible, en particulier pour les paquets qui ne proposent pas (encore) une intégration avec DKMS : avec une simple commande telle que module-assistant auto-install dahdi (ou même sa version raccourcie, m-a a-i dahdi), les modules sont construits pour le noyau courant, puis empaquetés dans un nouveau paquet Debian, qui est lui-même installé à la volée.

8.10.6. Emploi d'un patch sur le noyau

Certaines fonctionnalités ne sont pas intégrées au noyau standard faute de stabilité ou d'accord des mainteneurs du noyau. Dans ce cas, il arrive qu'elles soient diffusées sous la forme de correctif (ou patch), que chacun est alors libre d'appliquer sur les sources du noyau.

Debian fournit parfois certains de ces patches par le biais des paquets linux-patch-*, mais ils ne font souvent pas parti des distributions stables (parfois pour la même raison qu'ils ne sont pas intégrés en amont dans la version officielle du noyau). Ces paquets installent des fichiers dans le répertoire /usr/src/kernel-patches/.

Pour appliquer un ou plusieurs des patches installés, il faudra utiliser la commande patch sur le répertoire de sources, puis lancer la compilation du noyau comme précédemment.

$ cd ~/kernel/linux-source-4.9
$ make clean
$ zcat /usr/src/kernel-patches/diffs/grsecurity2/grsecurity-3.1-4.9.11-201702181444.patch.gz | patch -p1

Attention, un patch ne fonctionnant pas forcément avec toutes les versions des noyaux, il est possible que patch échoue à l'appliquer sur les sources du noyau. Un message vous en informera alors : dans ce cas, référez-vous à la documentation disponible dans le paquet Debian du patch (dans le répertoire /usr/share/doc/linux-patch-*/). Il est probable que le mainteneur indique pour quelles versions du noyau il a été prévu.