Un vilain piratage dans le noyau Linux qui est en ligne depuis plus de trois ans a été dénoncé. En raison d’un buggy X.Org Server/xf86-video-modesetting DDX, le noyau Linux a imposé un comportement différent selon qu’un processus démarre par”X”et désactive à son tour la prise en charge de la configuration du mode atomique.
Le chercheur en sécurité Linux Jason Donenfeld (qui est également bien connu pour avoir inventé WireGuard), est tombé sur ce vilain hack de code dans le noyau.
Donenfeld a commenté ce week-end sur la liste de diffusion du noyau :
Ceci rétablit 26b1d3b527e7 (“drm/atomic : retirez les jouets atomiques de X”), un bidon de type rootkit qui n’a rien à faire à l’intérieur d’un noyau à usage général. C’est le type de hack de débogage que j’utiliserai momentanément mais que je ne commettrai jamais, ou une sorte d’astuce de malware babbies-first-process-hider.
La trame de fond est qu’un certain code de l’espace utilisateur–xorg-server–a un DDX de réglage de mode qui n’est pas vraiment codé correctement. Comme personne ne voulait plus maintenir X11, plutôt que de corriger le code bogué, le noyau a été ajusté pour éviter d’avoir à toucher à X11. Une déception, mais assez juste : si le noyau ne veut plus prendre en charge certaines API de l’espace utilisateur, la bonne chose à faire est de prendre des dispositions pour un repli gracieux où l’espace utilisateur pense qu’il n’est pas disponible de manière gérable.
Cependant, la *façon* de procéder consiste simplement à vérifier `current->comm[0]==’X’`, et à le désactiver uniquement dans ce cas. Cela signifie donc que ce n’est *pas* simplement une question que le noyau ne veuille plus prendre en charge une API d’espace utilisateur particulière, mais plutôt que le noyau ne veuille pas prendre en charge xorg-server, en théorie, mais en fait, il s’avère que ce sont tous les processus qui commencer par’X’.
Jouer à des jeux avec current->comm comme celui-ci est évidemment faux, et c’est assez choquant que cela ait jamais été validé.
Le s’engager sur ce noyau avec la vérification du premier caractère”X”a été effectué en septembre 2019. L’argument dans ce noyau Linux à l’époque était :
Le ddx-modesetting a une idée totalement erronée du fonctionnement de l’atomique :
-ne désactive pas les anciens connecteurs, en supposant qu’ils se désactivent automatiquement comme avec l’ancien setcrtc
-suppose que ASYNC_FLIP est câblé pour l’ioctl atomique
-pas un seul appel à TEST_ONLY[En d’autres termes] l’implémentation est une traduction 1:1 des ioctl hérités en atomique, ce qui est a) cassé b) inutile.
Nous avons déjà des bogues dans i915 et amdgpu-DC où cela nous empêche d’activer des fonctionnalités intéressantes.
Si quelqu’un se soucie de l’atome dans X, nous pouvons facilement ajouter un nouveau niveau atomique (req->value==2) pour que X récupère les jouets brillants.
Depuis que ces versions cassées de-modesetting ont été expédiées, il n’y a vraiment aucun autre moyen de sortir de cette impasse.
La”bonne”nouvelle est que depuis lors du côté de l’espace utilisateur en 2019, le code xf86-video-modesetting est allé de l’avant et a désactivé le support atomique par défaut. Donc, techniquement, si vous exécutez une pile X.Org mise à jour au cours des trois dernières années, ce hack du noyau n’est plus nécessaire puisque l’espace utilisateur évite alors l’API atomique.
Nous verrons si Linus Torvalds est d’accord avec la suppression de ce hack, car après tout, il va à l’encontre de son principe de”ne pas casser l’espace utilisateur”en régressant ensuite le système s’il s’en tient à une pile de serveurs X.Org obsolète et voulant fonctionner avec une future version du noyau. Nous verrons, mais surprenant qu’il ait fallu trois ans pour que ce code sale soit critiqué.
