Généralités sur les interruptions

Une interruption est un événement particulier qui peuvent se produire lors de l’exécution d’un programme. A chaque type d’interruption est associé un numéro appelé vecteur d’interruption, connu du ou des processeur(s). Pour simplifier, les interruptions peuvent provenir de deux sources : le logiciel et le matériel. Les interruptions matérielles sont générées par les périphériques (clavier, souris, cartes, timers, disques durs…) et sont transmises au processeur par l’APIC (Advanced Programmable Interrupt Controller).  Les interruptions logicielles peuvent être quant à elles déclenchées volontairement par une instruction (int) ou de façon accidentelle par une erreur arithmétique, logique, de protection, etc. Dans ce cas, on parle souvent d’exception et de fautes.

Généralement, les interruptions (aussi bien matérielles que logicielles) sont susceptibles de se déclencher à n’importe quel moment dans l’exécution d’un programme, et chaque processeur doit savoir comment traiter chacune d’entre elles. A chaque vecteur d’interruption on associe alors un handler d’interruption, qui est une fonction qui sera appelée automatiquement quand l’interruption sera générée.  On place ces fonctions dans une table, l’IDT, pour Interrupt Descriptor Table. Il est important de noter qu’il y a une IDT par processeur, afin que chacun puisse avoir si besoin un comportement différent pour chaque interruption.

Il existe deux types d’interruptions matérielles, les masquables (les IRQ) et les non masquables (la NMI et la SMI) qu’on ne traitera pas ici en raison de leur grande particularité. Chaque interruption matérielle possède une priorité, qui est gérée par l’APIC. Pour faire simple, ce composant est relié aux périphériques par des lignes d’IRQ (Interrupt Requests) et se charge de faire le médiateur entre tous ces périphériques et le ou les processeur(s). Son rôle est en gros de transformer ces IRQ en demandes d’interruptions avec le vecteur associé.  Comme plusieurs IRQ peuvent intervenir en même temps, l’APIC définit des priorités afin de transmettre les plus urgentes d’abord.

Dans certains cas, le processeur peut ne pas vouloir être dérangé par une interruption. C’est le cas par exemple lorsqu’il est en train de modifier des structures globales en mémoire. Il a alors la possibilité d’ignorer les interruptions qu’il va recevoir de deux manières. La première, que je ne détaillerai pas, est de ne masquer que celles dont la priorité est inférieure à un certain seuil (appelé IRQL sous Windows) en communiquant avec l’APIC. La deuxième est de masquer la totalité des interruptions et c’est celle que nous allons détailler.

Subtilité sur le masquage

C’est le registre EFLAGS et plus précisément son bit IF (bit 9) qui contrôle si les interruptions masquables sont activées ou non. Ce bit est modifiable par l’intermédiaire des instructions cli pour masquage et sti pour démasquage, ou bien en utilisant pushf / popf associés à des masques.

Attention, le masquage des interruptions n’affecte que les interruptions matérielles ! Les interruptions logicielles (ainsi que les interruptions NMI et SMI, très particulières) ne sont pas affectées par ces opérations. Autrement dit, vous aurez beau baisser l’IRQL ou faire un cli, une exception due à une division par zéro ou à un défaut de page pourra toujours survenir.

Problème n°1 : DbgPrint(), c’est le mal

J’ai fait tous mes tests en machine virtuelle. Comme le développement de driver n’est jamais sûr à 100% et que je voulais tout de même avoir quelque chose de fonctionnel, j’ai réalisé un petit script qui charge le driver et le décharge 100 fois de suite, en lançant en plus des programmes divers pour solliciter l’OS un maximum. Le tout étant de prouver que le driver n’explose pas à la première interruption, bien entendu.

Dans mon cas, je devais hooker l’interruption n°14 correspondant au défaut de page (page fault), en insérant du code avant de rappeler le handler par défaut de Windows. Je rappelle que cette exception (logicielle) se produit quand une page virtuelle n’est mappée à aucune adresse physique (soit parce qu’elle a été swappée sur disque, soit parce qu’elle n’existe tout simplement pas). Cela se produit quand on tente d’accéder à une page dont le descripteur PTE a son premier bit (bit P) à 0.

J’ai donc commencé par concevoir un handler minimal qui ne faisait rien à part empiler tous les registres, les dépiler puis appeler le handler de Windows, KiTrap0E. Jusqu’ici, tout fonctionne, sauf que je n’ai pas vraiment de preuve que ma routine est appelée (vu que je n’ai aucune trace).

Je me décide donc à insérer des DbgPrint() dans le code de la routine. Et là, c’est le drame : j’obtiens des traces certes, mais j’en obtiens tellement que la VM freeze ou affiche un écran bleu au bout de quelques secondes. Il faut croire que les défauts de page sont très nombreux sous Windows… Mais pourquoi ça plante maintenant et pas avant ? L’explication est liée au visualisateur de traces (j’utilise DebugView). Lorsque DbgPrint() est appelé, le message est récupéré par le noyau puis par DebugView. Je ne sais pas exactement pourquoi, mais apparemment quand il y a beaucoup de messages de récupérés, DebugView commence à provoquer des défauts de page (probablement à cause du fait qu’il se fait swapper par l’OS). Comme ces défauts de pages sont à leur tour catchés par mon handler, ils entraînent d’autres appels à DbgPrint()… Bref, une belle boucle qui finit par exploser tôt ou tard.

Au final, je renonce donc  à afficher des traces, vu que cela perturbe plus le système qu’autre chose. En plus j’ai ma preuve que mon handler est appelé, vu que ça plante

Problème n°2 : sti, c’est aussi le mal

Le réel but de mon handler est de modifier une structure assez cruciale du noyau sous certaines conditions. Afin d’éviter que cette modification entraîne des problèmes de concurrence, je décide de masquer les interruptions avant le traitement (cli), et de les démasquer ensuite à l’aide de  et sti. Je lance le driver. Pas de crash. Je commence à crier victoire, et au moment ou je lance mon script de déchargement, j’ai le droit à un écran bleu. Je regarde le code de déchargement, il ne fait absolument rien de méchant. Je relance, idem. Je finis par comprendre que ce n’est pas le déchargement du driver qui foire, mais juste le fait de lancer un programme, car cela provoque un défaut de page… C’est donc bien mon handler qui pose problème, mais où ?

Je supprime ma modification de variable globale, ça plante toujours. Pourtant je n’ai plus que cli et sti dans mon handler (en plus de l’appel au handler par défaut). Je retire sti et je constate que ça marche ! C’est donc cette instruction qui est responsable du plantage du driver… mais pourquoi ? En fait, il se trouve que lors des appels au handler de défaut de page, les interruptions sont déjà masquées. C’est dû au fait que l’interruption correspondant au défaut de page possède un descripteur dans l’IDT qui précise que l’IF doit être mis à 0 lors de l’appel du handler (c’est une interrupt gate, selon Intel). Ainsi, lors de l’appel au handler, l’instruction cli ne fait absolument rien (le bit IF d’EFLAGS est déjà à 0)… Le problème, c’est que sti le passe à 1, ce qui autorise les interuptions ! Si jamais le défaut de page s’est produit dans une zone critique de l’OS et qu’une interruption survient précisément à ce moment, le kernel se vautre. Cela ne se produit peut-être pas à tous les coups, mais croyez moi, ça arrive (faites le test pour vous en convaincre).

Comment patcher cela ? Ne pas masquer les interruptions dans un handler de défaut de page, puisqu’elles le sont déjà. La solution, c’est tout simplement de ne rien faire

Conclusion

Morale de l’histoire : utiliser DbgPrint() ou sti dans un handler de défaut de page est une mauvaise idée. Pour déboguer, préférez utiliser des variables globales plutôt que des fonctions à effet de bords incontrôlables. Et ne cherchez pas à masquer (et surtout à démasquer) les interruptions qui le sont déjà . J’espère que ce post vous aura épargné un long moment de galère. En tout cas, j’aurais aimé en lire un du même type plus tôt !

Tout d’abord, téléchargez les derniers drivers d’Aircrack pour profiter de l’injection, puis décompressez-les :

wget http://rt2x00.serialmonkey.com/rt73-cvs-daily.tar.gz
tar -zxvf rt73-cvs-daily.tar.gz
cd rt73-cvs*/Module

Si ce n’est pas déjà fait, blacklistez les anciens modules qui peuvent empêcher rt73 de fonctionner en éditant /etc/modprobe.d/blacklist et en y ajoutant :

blacklist rt73usb
blacklist rt2570
blacklist rt2500usb
blacklist rt2x00lib

Au cas où, déchargez ces modulez éventuels :

sudo modprobe -r rt73usb
sudo modprobe -r rt2570
sudo modprobe -r rt2500usb
sudo modprobe -r rt2x00lib

Puis compilez et installez le module :

make
sudo make install

Si jamais vous obtenez un message du style :

!!! WARNING: Module file much too big (>1MB)
!!! Check your kernel settings or use 'strip'

Alors lancez les commandes :

make
strip -S rt73.ko
sudo make install

Ensuite, copiez le module :

sudo mkdir /lib/modules/$(uname -r)/extra
sudo cp rt73.ko /lib/modules/$(uname -r)/extra/rt73.ko

Puis chargez-le :

sudo depmod -ae
sudo modprobe rt73

Normalement, vous devriez pouvoir activer votre interface :

sudo ifconfig wlan0 up

Notez que désormais l’interface a un nom du style wlan* et non plus en rausb*.

Maintenant, votre connexion Wifi et Aircrack devraient fonctionner à nouveau. Vous devrez très certainement éditer votre /etc/network/interfaces pour remplacer les occurrences de rausb0 par wlan0.

Et voila ! Au besoin, référez-vous au README situé dans l’archive des drivers, il est bien fourni et décrit les configurations classiques (WEP, WPA, WPA2) de la carte.

Sources :

• Forum Ubuntu
• Aircrack, drivers rt73

Compilation du driver

Voici donc la marche à suivre pour compiler et utiliser ces drivers. Tout d’abord, placez-vous en root dans le dossier /usr/src :

sudo -s

cd /usr/src

Assurez-vous d’avoir les outils pour la compilation (GCC et compagnie). Au cas où, installez le paquet build-essential :

aptitude install build-essential

Ensuite, téléchargez le driver, et décompressez-le :

wget http://homepages.tu-darmstadt.de/~p_larbig/wlan/rt73-k2wrlz-2.0.1.tar.bz2

tar jxvf rt73-k2wrlz-2.0.1.tar.bz2

Placez-vous dans le dossier du driver, compilez-le et installez-le :

cd rt73-k2wrlz-2.0.1/Module

make

make install

Si jamais vous obtenez un message d’erreur de ce type à la compilation (après « make ») :

!!! WARNING: Module file much too big (>1MB)
!!! Check your kernel settings or use 'strip'

Dans ce cas (et dans ce cas seulement), il faut utiliser l’utilitaire « strip » et recompiler le driver :

strip -S rt73.ko

make

make install

Une fois que c’est fait, il faut bannir (blacklister) les modules Wifi de base d’Ubuntu en ajoutant ceci à la fin du fichier /etc/modprobe.d/blacklist, si ce n’est pas déjà fait :

blacklist rt73usb
blacklist rt2570
blacklist rt2500usb
blacklist rt2x00lib

Pour être sur que l’ancien driver ne provoque pas de conflit, déchargeons tous les modules susceptibles de causer des problèmes :

modprobe -r rt73usb

modprobe -r rt2570

modprobe -r rt2500usb

modprobe -r rt2x00lib

Testons maintenant le driver ! Allumez votre interface (si vous disposez d’un bouton Wifi sur votre machine), chargez le driver et testez l’interface :

modprobe rt73

ifconfig rausb0 up

Normalement, ça marche ! Au cas où ça ne serait pas le cas, une possibilité est de prendre une version antérieure du driver sur la page http://homepages.tu-darmstadt.de/~p_larbig/wlan/ (allez dans la section « RaLink RT73 USB Enhanced Driver« ) et réeffectuez les étapes précédentes (en adaptant le nom de l’archive).

Utiliser le WPA

Pour ceux qui sont toujours connectés en WEP, permettez-moi de vous rappeler que cette méthode d’encryption est depuis longtemps dépassée car trop facilement crackable ! Avec Aircrack et quelques connaissances, il faut environ 30min pour cracker une clé, et avec la dernière version (et un peut de chance) on peut même atteindre quelques minutes seulement. Si j’ai le temps, je montrerai dans un prochain billet comment utiliser Aircrack pour casser une clé WEP. Mais en attendant, passez donc au WPA !

Pour activer le WPA sur l’interface, ce n’est pas bien compliqué. Tout se passe dans le fichier /etc/network/interfaces. Il faut que vous ajoutiez des lignes de configuration basées sur ce modèle :

auto rausb0
iface rausb0 inet dhcp
        pre-up ifconfig rausb0 up  # a enlever si ca marche pas
        pre-up iwconfig rausb0 essid Livebox-XXXX  # le nom du réseau
        pre-up iwconfig rausb0 mode managed
        pre-up iwpriv rausb0 set AuthMode=WPAPSK
        pre-up iwpriv rausb0 set EncrypType=TKIP
        pre-up iwpriv rausb0 set WPAPSK="XXXXXXXXXXXXXXXXXXXXXXXXXX" # la clé WPA

Cette configuration est celle que j’utilise pour me connecter sur ma livebox en WPA. Adaptez-la si besoin. Et assurez-vous que le WPA est activé sur la borne… Attention toutefois pour les Livebox Inventel : il faut absolument prendre l’option « WPA seulement » et pas « WEP et WPA » dans le menu de configuration, sinon cela ne marche pas. Si votre borne Wifi nécessite l’appui sur une touche pour permettre l’association Wifi de nouveaux périphériques, appuyez dessus sinon vous ne pourrez pas vous connecter (c’est le cas pour les Livebox)

Ensuite, redémarrez les interfaces réseau :

/etc/init.d/networking restart

Et si tout va bien, vous devriez obtenir une adresse IP et vous serez alors connectés ! Si jamais cela ne marche pas, c’est probablement du à une erreur dans la clé, ou bien à un conflit avec une autre interface. En effet, n’essayez pas de vous connecter à la fois en filaire et en Wifi, car au niveau des adresses IP attribuées par le DHCP, il risque d’y avoir des problèmes (elles seront toutes les deux dans le même réseau). Essayez de désactiver votre interface réseau en tapant :

ifconfig eth0 down

Assurez-vous également qu’il n’y a pas de ligne du type « auto eth0″ dans le fichier /etc/network/interfaces, et redémarrez une nouvelle fois les interfaces.

Si vous obtenez un message du style

DHCPACK from 192.168.1.1
bound to 192.168.1.161 -- renewal in 32485 seconds.

alors vous êtes connectés !

Attention, le module installé ne fonctionnera pas avec les outils graphiques du style NetworkManager. Enfin, n’oubliez pas qu’à chaque mise à jour de noyau, il faudra le recompiler (refaire un « make » et « make install » dans le dossier des sources du driver).

Conclusion

J’espère que ce billet vous aura été utile, car trouver toute cette procédure m’aura demandé un certain temps de recherche. Voici quelques pages qui m’ont pas mal servi :

• La page des drivers rt73 sur Arcrack
• Les drivers Ralink supportant l’injection
• La page WPA sur la doc d’Ubuntu-fr (la partie intéressante est à la fin, nommée « Méthode alternative« )