linux-3.0.35_CVE-2019-10220

INSTALLATION du source du noyau :

• Si vous installez les sources complètes, placez l'archive tar du noyau dans un répertoire où vous avez les permissions (par exemple votre répertoire personnel) et décompressez-le :

  root@kitploit:~

   gzip -cd linux-3.X.tar.gz | tar xvf -
  

  ou bzip2 -dc linux-3.X.tar.bz2 | tar xvf -

  Remplacez "XX" par le numéro de version du noyau le plus récent.

  N'utilisez PAS la zone /usr/src/linux ! Cette zone contient un ensemble (généralement incomplet) d'en-têtes du noyau utilisé par les fichiers d'en-tête des bibliothèques. Ils doivent correspondre à la bibliothèque, et ne doivent pas être perturbés par ce qu'est le noyau-du-jour.

• Vous pouvez également effectuer une mise à niveau entre les versions 3.x par patching. Les patches sont distribués au format traditionnel gzip et au format plus récent bzip2. Pour installer par patching, obtenez tous les fichiers de patch plus récents, entrez dans le répertoire de plus haut niveau des sources du noyau (linux-3.x) et exécutez :

  root@kitploit:~

   gzip -cd ../patch-3.x.gz | patch -p1
  

  ou bzip2 -dc ../patch-3.x.bz2 | patch -p1

  (répétez xx pour toutes les versions supérieures à la version de votre arbre source actuel, dans_l'ordre) et tout devrait être ok. Vous voudrez peut-être supprimer les fichiers de sauvegarde (xxx~ ou xxx.orig), et vous assurer qu'il n'y a pas de patches échoués (xxx# ou xxx.rej). S'il y en a, soit vous soit moi avons commis une erreur.

  Contrairement aux patches pour les noyaux 3.x, les patches pour les noyaux 3.x.y (également appelés noyaux -stable) ne sont pas incrémentiels mais s'appliquent directement au noyau de base 3.x. Veuillez lire Documentation/applying-patches.txt pour plus d'informations.

  Alternativement, le script patch-kernel peut être utilisé pour automatiser ce processus. Il détermine la version actuelle du noyau et applique tous les patches trouvés.

  root@kitploit:~

   linux/scripts/patch-kernel linux
  

  Le premier argument de la commande ci-dessus est l'emplacement du source du noyau. Les patches sont appliqués depuis le répertoire courant, mais un répertoire alternatif peut être spécifié comme second argument.

• Si vous effectuez une mise à niveau entre les versions en utilisant les patches de la série stable (par exemple, patch-3.x.y), notez que ces "dot-releases" ne sont pas incrémentiels et doivent être appliqués à l'arbre de base 3.x. Par exemple, si votre noyau de base est 3.0 et que vous voulez appliquer le patch 3.0.3, vous n'appliquez pas et ne devez surtout pas appliquer d'abord les patches 3.0.1 et 3.0.2. De même, si vous utilisez la version de noyau 3.0.2 et que vous voulez passer à 3.0.3, vous devez d'abord annuler le patch 3.0.2 (c'est-à-dire patch -R) avant d'appliquer le patch 3.0.3. Vous pouvez en lire plus à ce sujet dans Documentation/applying-patches.txt

• Assurez-vous de n'avoir aucun fichier .o obsolète ni dépendances qui traînent :

  root@kitploit:~

   cd linux
   make mrproper
  

  Vous devriez maintenant avoir les sources correctement installées.

CONFIGURATION LOGICIELLE REQUISE

La compilation et l'exécution des noyaux 3.x nécessitent des versions à jour de divers logiciels. Consultez Documentation/Changes pour les numéros de version minimum requis et comment obtenir des mises à jour de ces logiciels. Attention, l'utilisation de versions trop anciennes de ces logiciels peut provoquer des erreurs indirectes très difficiles à localiser, ne supposez donc pas que vous pouvez simplement mettre à jour les packages lorsque des problèmes évidents surviennent lors de la construction ou du fonctionnement.

RÉPERTOIRE DE CONSTRUCTION pour le noyau :

Lors de la compilation du noyau, tous les fichiers de sortie seront par défaut stockés avec les sources du noyau. L'utilisation de l'option "make O=output/dir" vous permet de spécifier un emplacement alternatif pour les fichiers de sortie (y compris .config). Exemple : source du noyau : /usr/src/linux-3.N répertoire de construction : /home/name/build/kernel

Pour configurer et construire le noyau, utilisez : cd /usr/src/linux-3.N make O=/home/name/build/kernel menuconfig make O=/home/name/build/kernel sudo make O=/home/name/build/kernel modules_install install

Veuillez noter : Si l'option 'O=output/dir' est utilisée, elle doit l'être pour toutes les invocations de make.

CONFIGURATION du noyau :

Ne sautez pas cette étape même si vous ne faites que mettre à niveau une version mineure. De nouvelles options de configuration sont ajoutées dans chaque version, et des problèmes étranges apparaîtront si les fichiers de configuration ne sont pas configurés comme prévu. Si vous souhaitez conserver votre configuration existante pour une nouvelle version avec un minimum de travail, utilisez "make oldconfig", qui ne vous posera que les questions pour les nouvelles options.

• Les commandes de configuration alternatives sont : "make config" Interface texte pure. "make menuconfig" Menus couleur basés sur texte, listes radio & dialogues. "make nconfig" Menus couleur basés sur texte améliorés. "make xconfig" Outil de configuration basé sur X windows (Qt). "make gconfig" Outil de configuration basé sur X windows (Gtk). "make oldconfig" Répond par défaut à toutes les questions en fonction du contenu de votre fichier ./.config existant et interroge sur les nouveaux symboles de configuration. "make silentoldconfig" Comme ci-dessus, mais évite d'encombrer l'écran avec des questions déjà répondues. Met également à jour les dépendances. "make defconfig" Crée un fichier ./.config en utilisant les valeurs de symboles par défaut provenant de arch/$ARCH/defconfig ou arch/$ARCH/configs/${PLATFORM}_defconfig, selon l'architecture. "make ${PLATFORM}_defconfig" Crée un fichier ./.config en utilisant les valeurs de symboles par défaut de arch/$ARCH/configs/${PLATFORM}_defconfig. Utilisez "make help" pour obtenir une liste de toutes les plateformes disponibles de votre architecture. "make allyesconfig" Crée un fichier ./.config en définissant les valeurs de symboles à 'y' autant que possible. "make allmodconfig" Crée un fichier ./.config en définissant les valeurs de symboles à 'm' autant que possible. "make allnoconfig" Crée un fichier ./.config en définissant les valeurs de symboles à 'n' autant que possible. "make randconfig" Crée un fichier ./.config en définissant les valeurs de symboles à des valeurs aléatoires.

  Vous pouvez trouver plus d'informations sur l'utilisation des outils de configuration du noyau Linux dans Documentation/kbuild/kconfig.txt.

  NOTES sur "make config" :

  • avoir des pilotes inutiles rendra le noyau plus gros, et peut dans certaines circonstances entraîner des problèmes : la détection d'une carte contrôleur inexistante peut perturber vos autres contrôleurs
  • compiler le noyau avec "Type de processeur" réglé sur plus haut que 386 donnera un noyau qui NE fonctionne PAS sur un 386. Le noyau le détectera au démarrage et abandonnera.
  • Un noyau avec l'émulation mathématique compilée utilisera quand même le coprocesseur si présent : l'émulation mathématique ne sera jamais utilisée dans ce cas. Le noyau sera légèrement plus gros, mais fonctionnera sur différentes machines, qu'elles aient ou non un coprocesseur mathématique.
  • Les détails de configuration "kernel hacking" donnent généralement un noyau plus gros ou plus lent (ou les deux), et peuvent même rendre le noyau moins stable en configurant certaines routines pour essayer activement de casser du code défectueux afin de trouver des problèmes du noyau (kmalloc()). Ainsi, vous devriez probablement répondre 'n' aux questions concernant les fonctionnalités "développement", "expérimental", ou "débogage".

COMPILATION du noyau :

• Assurez-vous d'avoir au moins gcc 3.2 disponible. Pour plus d'informations, référez-vous à Documentation/Changes.

  Veuillez noter que vous pouvez toujours exécuter des programmes utilisateur a.out avec ce noyau.

• Effectuez un "make" pour créer une image de noyau compressée. Il est également possible de faire "make install" si vous avez lilo installé pour correspondre aux makefiles du noyau, mais vous voudrez peut-être vérifier votre configuration lilo particulière d'abord.

  Pour effectuer l'installation réelle, vous devez être root, mais aucune des étapes normales de construction ne devrait le nécessiter. Ne prenez pas le nom de root en vain.

• Si vous avez configuré certaines parties du noyau comme `modules', vous devrez également faire "make modules_install".

• Sortie verbeuse de compilation/construction du noyau :

  Normalement, le système de construction du noyau fonctionne en mode assez silencieux (mais pas totalement silencieux). Cependant, parfois vous ou d'autres développeurs du noyau avez besoin de voir les commandes de compilation, d'édition de liens ou autres exactement comme elles sont exécutées. Pour cela, utilisez le mode de construction "verbeux". Cela se fait en insérant "V=1" dans la commande "make". Par exemple :

  make V=1 all

  Pour que le système de construction indique également la raison de la reconstruction de chaque cible, utilisez "V=2". La valeur par défaut est "V=0".

• Gardez un noyau de secours à portée de main au cas où quelque chose tournerait mal. C'est particulièrement vrai pour les versions de développement, car chaque nouvelle version contient du nouveau code qui n'a pas été débogué. Assurez-vous de conserver une sauvegarde des modules correspondant à ce noyau, également. Si vous installez un nouveau noyau avec le même numéro de version que votre noyau de travail, faites une sauvegarde de votre répertoire de modules avant de faire un "make modules_install". Alternativement, avant de compiler, utilisez l'option de configuration du noyau "LOCALVERSION" pour ajouter un suffixe unique à la version normale du noyau. LOCALVERSION peut être défini dans le menu "General Setup".

• Pour démarrer votre nouveau noyau, vous devrez copier l'image du noyau (par exemple .../linux/arch/i386/boot/bzImage après compilation) à l'endroit où se trouve votre noyau amorçable habituel.

• Le démarrage d'un noyau directement depuis une disquette sans l'assistance d'un chargeur d'amorçage tel que LILO n'est plus supporté.

  Si vous démarrez Linux depuis le disque dur, il y a des chances que vous utilisiez LILO qui utilise l'image du noyau spécifiée dans le fichier /etc/lilo.conf. L' image du noyau est généralement /vmlinuz, /boot/vmlinuz, /bzImage ou /boot/bzImage. Pour utiliser le nouveau noyau, sauvegardez une copie de l'ancienne image et copiez la nouvelle image par-dessus l'ancienne. Ensuite, vous DEVEZ REEXECUTER LILO pour mettre à jour la carte de chargement !! Si vous ne le faites pas, vous ne pourrez pas démarrer la nouvelle image du noyau.

  La réinstallation de LILO est généralement une question d'exécution de /sbin/lilo. Vous pouvez souhaiter éditer /etc/lilo.conf pour spécifier une entrée pour votre ancienne image du noyau (par exemple, /vmlinux.old) au cas où la nouvelle ne fonctionnerait pas. Consultez la documentation LILO pour plus d'informations.

  Après avoir réinstallé LILO, tout devrait être prêt. Éteignez le système, redémarrez, et profitez !

  Si vous avez besoin de changer le périphérique racine par défaut, le mode vidéo, la taille du disque RAM, etc. dans l'image du noyau, utilisez le programme 'rdev' (ou alternativement les options de démarrage LILO quand c'est approprié). Pas besoin de recompiler le noyau pour changer ces paramètres.

• Redémarrez avec le nouveau noyau et profitez.

SI QUELQUE CHOSE NE VA PAS :

• Si vous avez des problèmes qui semblent être dus à des bugs du noyau, veuillez vérifier le fichier MAINTAINERS pour voir s'il y a une personne particulière associée avec la partie du noyau avec laquelle vous avez des problèmes. S'il n'y a personne listé là, alors la deuxième meilleure chose est de m'envoyer un mail à ([email protected]), et éventuellement à toute autre liste de diffusion pertinente ou au groupe de discussion.

• Dans tous les rapports de bugs, s'il vous plaît dites de quel noyau vous parlez, comment reproduire le problème, et quelle est votre configuration (utilisez votre bon sens). Si le problème est nouveau, dites-le moi, et si le problème est ancien, essayez de me dire quand vous l'avez remarqué pour la première fois.

• Si le bug entraîne un message comme

  unable to handle kernel paging request at address C0000010 Oops: 0002 EIP: 0010:XXXXXXXX eax: xxxxxxxx ebx: xxxxxxxx ecx: xxxxxxxx edx: xxxxxxxx esi: xxxxxxxx edi: xxxxxxxx ebp: xxxxxxxx ds: xxxx es: xxxx fs: xxxx gs: xxxx Pid: xx, process nr: xx xx xx xx xx xx xx xx xx xx xx

  ou des informations de débogage similaires du noyau sur votre écran ou dans votre journal système, veuillez le dupliquer exactement. Le dump peut sembler incompréhensible pour vous, mais il contient des informations qui peuvent aider à déboguer le problème. Le texte au-dessus du dump est également important : il dit quelque chose sur pourquoi le noyau a dumpé du code (dans l'exemple ci-dessus c'est dû à un mauvais pointeur du noyau). Plus d'informations sur la façon de donner un sens au dump se trouvent dans Documentation/oops-tracing.txt

• Si vous avez compilé le noyau avec CONFIG_KALLSYMS, vous pouvez envoyer le dump tel quel, sinon vous devrez utiliser le programme "ksymoops" pour donner un sens au dump (mais compiler avec CONFIG_KALLSYMS est généralement préféré). Cet utilitaire peut être téléchargé depuis ftp://ftp..kernel.org/pub/linux/utils/kernel/ksymoops/ . Alternativement, vous pouvez effectuer la recherche du dump à la main :

• Dans les dumps de débogage comme ci-dessus, il est extrêmement utile de pouvoir rechercher ce que signifie la valeur EIP. La valeur hexadécimale en tant que telle ne m'aide pas beaucoup, ni personne d'autre : elle dépendra de votre configuration particulière du noyau. Ce que vous devez faire est de prendre la valeur hexadécimale de la ligne EIP (ignorez le "0010:"), et de la rechercher dans le namelist du noyau pour voir quelle fonction du noyau contient l'adresse incriminée.

  Pour trouver le nom de la fonction du noyau, vous aurez besoin de trouver le binaire système associé au noyau qui a présenté le symptôme. C'est le fichier 'linux/vmlinux'. Pour extraire le namelist et le faire correspondre à l'EIP du crash du noyau, faites :

  root@kitploit:~

   nm vmlinux | sort | less
  

  Cela vous donnera une liste d'adresses du noyau triées par ordre croissant, à partir de laquelle il est simple de trouver la fonction qui contient l' adresse incriminée. Notez que l'adresse donnée par les messages de débogage du noyau ne correspondra pas nécessairement exactement aux adresses des fonctions (en fait, c'est très peu probable), donc vous ne pouvez pas simplement 'grep' la liste : la liste vous donnera cependant le point de départ de chaque fonction du noyau, donc en recherchant la fonction qui a une adresse de départ inférieure à celle que vous cherchez mais qui est suivie par une fonction avec une adresse plus élevée, vous trouverez celle que vous voulez. En fait, il peut être bon d'inclure un peu de "contexte" dans votre rapport de problème, en donnant quelques lignes autour de celle qui vous intéresse.

  Si pour une raison quelconque vous ne pouvez pas faire ce qui précède (vous avez une image de noyau pré-compilée ou similaire), me dire autant que possible sur votre configuration aidera. Veuillez lire le document REPORTING-BUGS pour les détails.

• Alternativement, vous pouvez utiliser gdb sur un noyau en fonctionnement. (lecture seule ; c'est-à-dire que vous ne pouvez pas modifier les valeurs ou définir des points d'arrêt.) Pour ce faire, compilez d'abord le noyau avec -g ; éditez arch/i386/Makefile de manière appropriée, puis faites un "make clean". Vous aurez également besoin d'activer CONFIG_PROC_FS (via "make config").

  Après avoir redémarré avec le nouveau noyau, faites "gdb vmlinux /proc/kcore". Vous pouvez maintenant utiliser toutes les commandes gdb habituelles. La commande pour rechercher le point où votre système a planté est "l *0xXXXXXXXX". (Remplacez les XXX par la valeur EIP.)

  gdb'ing un noyau non en fonctionnement échoue actuellement car gdb (à tort) ignore le décalage de départ pour lequel le noyau est compilé.