Recompiler son noyau OpenBSD
Philippe THIERRY
Dans la plupart des systèmes open-source, personnaliser son
noyau fait partie des apprentissages nécessaire pour
maîtriser le système. On constate d'ailleurs que
des Mailing List entières existent sur ce sujet, et la
communauté du système en question est
prête à vous aider.
OpenBSD ne possède pas cette philosophie de customisation. En effet,
l'utilisation du noyau GENERIC et considérée
comme suffisante pour une utilisation standard, et la modification du
noyau fourni serait un risque pris pour bien peu d'avantages (mis
à part peut-être l'apprentissage, bien que la
modification d'un noyau OpenBSD est loin d'être aussi
compéhencible est agréable qu'un noyau comme
Linux).
Dans ce cas, pourquoi recompiler un noyau ? Après tout, si
les Mailing List ne vous aident pas et que les utilisateurs vous
déconceillent toute modification, quelle est donc
l'utilité d'une recompilation ?
Il y a en fait plusieurs possibilités. Tout d'abord,
recompiler un noyau ne signifie pas forcément le customiser. Ce dernier terme
définissant la modification en profondeur du noyau, pour en
retirer des fonctionnalités et en ajouter d'autres.
Cependant, les cas suivant peuvent impliquer une recompilation du noyau
GENERIC :
- L'ajout d'un patch de sécurité au
noyau lui-même. En conséquence, le noyau doit
être recompilé pour assimiler le patch. Par
contre, la modification des options n'est pas nécessaire.
- En cas de travail sur le noyau lui-même. Dans ce
cas là, il est considéré que la
personne est suffisement au fait du fonctionnement interne de celui-ci
pour savoir que faire.
- Enfin, il peut s'agir d'une volonté de
réduction de la consommation mémoire du noyau,
qui dans ses dernières version utilise environ 5 Mo en RAM.
Ce dernier cas n'a de sens que d'en l'emploi d'OpenBSD sur un
très vieux système, au ressources très
limité.
De ces trois cas, on retiendra surtout le premier, étant le
plus fréquent. On exposera cependant le fonctionnement du
fichier de configuration du noyau GENERIC, afin de bien comprendre le
fonctionnement des sources.
Il faut bien entendu un compilateur, gcc étant fourni parmis
les paquets supplémentaire dans chaque version d'OpenBSD. Au
moment de la rédaction de cette documentation, OpenBSD en
est à la version 3.7. Il s'agit donc des versions de gcc 3.3
et 3.4.
De même il est nécéssaire d'avoir
installé gmake (en version 3.8, toujours dans OpenBSD 3.7).
Pour finir, il faut installer les sources du noyau. Il s'agit du
fichier sys.tar.gz, présent dans la racine du cdrom ou dans
le répertoire OpenBSD/3.7 d'un des nombreux miroirs ftp.
Comme d'habitude, ce dernier s'installe dans le répertoire
/usr/src du système, avec la commande suivante :
cd /usr/src && tar -xzvpf sys.tar.gz
Les sources du noyau sont répartie en répertoire
pour chaque type de controlleur. Normalement, il n'est pas
nécessaire d'aller mettre les mains dans ces divers
répertoires. On constate également un
répertoire conf, qui contient le fichier de configuration du
noyau pour les options indépendantes du matériel,
un répertoire arch/,
contenant les informations dépendant du matériel
et un fichier Makefile, pour la compilation.
Il faut savoir qu'aucun utilitaire de configuration n'est fourni. Il
sera donc nécessaire de modifier les fichiers de
configuration du noyau à la main, ce qui implique une grande
connaissance du matériel sur lequel est installé
OpenBSD. Il est déconseillé aux personnes n'ayant
pas l'habitude d'un travail de ce type de chercher à
modifier le noyau.
Avant toute chose, assurez vous de bien faire une sauvegarde de votre
noyau courant, par exemple en faisant une copie de /bsd vers /bsd.backup. Cela vous permettra
ensuite de pouvoir réutiliser ce noyau en cas de
problème avec le nouveau (je rappelle que le gestionnaire
d'amorçage d'OpenBSD permet le choix du noyau au
démarrage de la machine).
Ensuite, il va faloir vous munir de patience, car la mise en place des
modifications risque d'être longue.
Comme vu précédement, ce fichier
présente les options du noyau ne faisant pas
référence au matériel. Ainsi, on y
trouvera aucune information sur les pilotes ou la gestion de la
mémoire ou du processeur. On trouvera surtout les options de
support réseau et systèmes de fichiers.
En théorie, vous n'aurez pas à modifier le
contenu de ce fichier. En effet, il s'agit ici des supports de base du
noyau, et le fait qu'ils soient indépendant du
matériel les rendent communs à tous les noyaux
OpenBSD de tous les matériels.
Dans le cas où vous souhaitez modifier ce fichier, faite une
copie et travaillez dessus :
# cp GENERIC OBSDTEST
Le fichier GENERIC possède une structure précise
:
Chaque ligne correspond à une option. Voici la structure
générale du fichier :
...
typenom# commentaire
...
Les lignes peuvent être de deux types :
- Les lignes d'options : elles activent le support des
options du noyau concernant très majoritairement les
systèmes de fichiers, les protocoles réseau et la
cryptographie. En voici quelques exemples :
option SYSVSEM # System V-like semaphores
option SYSVSHM # System V-like memory sharing
...
option INET6 # IPv6 (needs INET)
option IPSEC # IPsec
On peut voir ici les deux types d'options. Les premières
correspondent à la gestion de la mémoire et
l'ordonnancement des processus (sémaphores).
Les deux dernières correspondent aux supports des protocole
réseaux IPv6 et IPsec. On sconstate donc qu'il s'agit de
support de protocoles de fonctionnements, réseaux ou
systèmes, parfaitement indépendant du
matériel.
- Les lignes de pseudo-device : elles actives le support des
pseudo périphériques liés à
ces options, comme pflog par exemple (device de gestion des journaux de
pf) :
pseudo-device pf # packet filter
pseudo-device pflog # pf log if
Il s'agit là de gestion de devices
materiel-indépendants.
Pour désactiver une option ou un pseudo-device, un # en
début de ligne est suffisant, mettant la ligne en
commentaire. Il faut cependant bien faire attention lors de la mise en
place des commentaires. Des options telles que inet sont
très probablement nécessaires à
l'utilisation de la machine. Les lignes ne doivent être
modifiées que si vous êtes parfaitement certain de
ce que vous faites.
Dans ce fichier sont regroupées toutes les informations
liées d'une manière ou d'une autre à
l'architecture de la machine. Ce fichier fait plusieurs centaines de
lignes. De la même manière que pour le fichier
précédent, il faut travailler sur une copie en
cas de modification :
# cp GENERIC OBSDTEST
On retrouve dans ce fichier quelques options, la listes des materiels
gérés, ainsi que leur
périphériques parent
et parfois d'autres information telles que leur IRQ.
Ce fichier est très complexe. Il est également hardament conseillé de
n'y toucher que si vous êtes parfaitement sûr de ce
que vous faites. On y retrouve également quelques options,
mais surtout l'integralité des matériels
gérés par le noyau. Contrairement au
système Linux, le nom des périphérique
n'est pas dépendant de sa fonction, mais du constructeur.
Ainsi, il est plus difficile de reconnaître
précisément chaque
périphérique dans ce fichier. Il s'agit
là aussi d'une difficulté importante :
Si l'on connaît bien son système et la
façon dont le noyau OpenBSD gère celui-ci, il est
cependant plus aisé d'y faire des modifications.
En fin de fichier, on retrouve également quelques
pseudo-devices, en général nécessaire
à un bon fonctionnement. On retrouve également le
support RAID, qui n'est pas activé par défaut.
Regardons maintenant d'un peu plus près ce fichier :
- Le fichier commence par définir le type de
machine, ici de type i386. Cette ligne n'est bien entendu pas
modifiable si vous souhaitez que le noyau fonctionne.
La deuxième est plus intéressante. Elle inclus le
fichier vu précédement en tête de
celui-ci. Si des modifications y ont été faites,
il faut alors la remplacer par l'adresse du fichier
travaillé :
include "../../../conf/OBSDTEST"
- On retrouve en suite une liste de CPU compatible i386, puis
quelques options comme la compatibilité avec d'autres OS et
les options de débogage.
- On arrive enfin à la liste des pilotes :
cpu0 at mainbus?
bios0 at mainbus0
...
pci* at mainbus0
La lecture devient plus complexe. Tout d'abord, il faut savoir que le ? correspond à un
caractère. Il peut ainsi être remplacé
par n'importe quel caractère alphanumérique.
Ensuite, le *
correspond à une chaîne alphanumérique
de taille variable. En conséquence, voici la signification
des lignes précédentes :
- La première conserne le premier CPU (unique
dans la plupart de PC) La ligne indique qu'il peut se trouver sur
n'importe quel bus principal. En effet, dans le cas de machines
biporcesseurs, chaque processeur possède son bus. Il faut
alors définir un processeur primaire et un secondaire, de
même un bus primaire et un secondaire. Cette ligne permet de
croiser processeurs et bus primaires et secondaires.
- La deuxième ligne définit le bios
comme placé sur le bus primaire.
- Enfin, la dernière ligne place tous les
controleurs PCI (pci0, pci1...) sur le premier bus principal, unique
sur une machine monoprocesseur.
On peut ainsi considérer la liste des pilotes comme une
suite d'adresses, ou à chaque matériel et
associé sa position (via son parent), et les options qui
doivent parfois lui être fournies.
On constate donc que la compréhention de ce fichier est
complexe, et ses modifications délicates. Je rappelle encore
une fois que la modification du noyau OpenBSD n'est pas
conseillé sauf exception et qu'il faut faire très
attention lors d'éventuelles modifications.
Patcher le noyau est beaucoup plus simple que de le personnaliser. Les
sources du noyau sont configurées pour le noyau
générique. Ainsi, une fois les sources
décompressées, il suffit d'appliquer le patch,
puis de compiler.
L'application du patch se fait via la commande patch.
L'utilisation classique de la commande est celle-ci :
# cd /usr/src/
# patch -p0 < correctif.patch
Dans ce cas là, le patch ira corriger les fichiers contenu
dans le sous répertoire sys/ contenant le noyau.
L'option -p?
définit la modification des adresses du patch. Ainsi, si
vous êtes déjà dans le
répertoire sys/,
vous pouvez le retirer en utilisant l'option -p1,
et ainsi de suite.
Lors de l'exécution de la commande, toute une serie
d'information va défiler. Il s'agit des informations sur les
divers fichiers à corriger, et les corrections
effectuées. Une fois l'exécution
terminée, il ne reste plus qu'à compiler le
noyau.
Tout d'abord, il faut préparer le noyau pour la compilation.
Pour cela, on utilise la commande config, qui va lire les fichiers de
configuration et préparer les sources en
conséquences. Si vous n'avez fait que patcher le noyau,
alors vous devez taper :
# config GENERIC
Dans le cas d'une personnalisation, vous devez lire vos fichiers et non
ceux fournis avec les sources :
# config OBSDTEST
Dans ce dernier cas, il se peut que vous ayez une erreur
d'écriture qui soit détectée. En
effet, comme les fichers de configuration sont modifiés
à la main, des erreurs peuvent être faites. config
renvoie la ligne où l'erreur a été
commise. Il ne reste plus qu'à la corriger.
Une fois la configuration terminée, il faut compiler le
noyau. Pour cela, on tape successivement :
# make dep
# make
Ces commandes vont se charger de gérer les
dépendances entre fichier pour l'ordonnancement de la
compilation, puis effectivement compiler le noyau.
Le fichier binaire de celui-ci est alors créé.
Pour pouvoir utiliser le nouveau noyau au démarrage, il faut
copier le binaire fraichement créé vers /bsd. En redémarrant,
le système boote par défaut sur ce noyau. Il est
possible de s'en assurer avec la commande uname :
# uname -v
OBSDTEST#0
Il ne reste plus qu'a tester les capacités du nouveau noyau.
Dans le cas d'un kernel-panic, il est toujours possible de
démarrer sur l'ancien noyau en utilisant le fichier /bsd-backup,
créé auparavant, puis de corriger l'erreur
fournie lors du plantage.
Recompiler son noyau OpenBSD
This document was generated using the
LaTeX2HTML
translator Version 2002-2 (1.70)
Copyright © 1993, 1994, 1995, 1996,
Nikos
Drakos, Computer Based Learning Unit, University of Leeds.
Copyright © 1997, 1998, 1999,
Ross Moore,
Mathematics Department, Macquarie University, Sydney.
The command line arguments were:
latex2html -split 0
-nonavigation -nofootnode -html_version 4.0
Documents/tex/OpenBSD-Kernel/openbsd-kernel.tex
The translation was initiated by Philippe Thierry on
2005-06-19
Philippe Thierry
2005-06-19