-mal kezdődő folyamatokat 
Egy csúnya hacket hívtak ki a Linux kernelen belül, amely több mint három éve a fővonalon volt. A hibás X.Org Server/xf86-video-modeseting DDX miatt a Linux kernel eltérő viselkedést ír elő arra vonatkozóan, hogy egy folyamat”X”-el indul-e, és viszont letiltja az atomi módbeállítás támogatását.
Jason Donenfeld, a Linux biztonsági kutatója (aki a WireGuard kidolgozásáról is közismert) rábukkant erre a csúnya kódfeltörésre a kernelen belül.
Donenfeld ezen a hétvégén megjegyzést fűzött a a kernel levelezőlistájához:
Ez visszaállítja a 26b1d3b527e7-et (“drm/atomic: Vedd el az atomos játékokat X-től”), egy rootkit-szerű gubacsot, amelynek semmi dolga egy általános célú kernelben. Ez az a típusú hibakereső hack, amelyet pillanatnyilag fogok használni, de soha nem követem el, vagy egyfajta „baba-first-process-hider” malware-trükk.
A háttértörténet az, hogy néhány felhasználói terület kódja – az xorg-server – rendelkezik egy módbeállító DDX-szel, amely nincs igazán jól kódolva. Mivel már senki sem akarta karbantartani az X11-et, ahelyett, hogy kijavította volna a hibás kódot, a kernelt úgy módosították, hogy ne kelljen megérinteni az X11-et. Egy balhé, de elég tisztességes: ha a kernel nem akar többé támogatni néhány userspace API-t, a helyes dolog, ha gondoskodunk egy kecses tartalékról, ahol a userspace úgy gondolja, hogy nem elérhető kezelhető módon.
Azonban az *mód*, hogy ez csak annyi, hogy bejelöli a `current->comm[0]==’X’` paramétert, és csak erre az esetre tiltja le. Tehát ez azt jelenti, hogy *nem* egyszerűen arról van szó, hogy a kernel nem akar többé támogatni egy adott felhasználói felület API-t, hanem inkább arról van szó, hogy elméletileg a kernel nem akarja támogatni az xorg-servert, de valójában ez minden olyan folyamat,”X”-szel kezdődik.
Az ilyen aktuális->comm-mal játszani nyilvánvalóan helytelen, és elég megdöbbentő, hogy ezt valaha is elkövették.
A commit ehhez a kernelhez az”X”első karakterellenőrzéssel 2019 szeptemberében történt. Az érv abban az időben a Linux kernel véglegesítésében a következő volt:
A-modeseting ddx teljesen elromlott az atomic működésével kapcsolatban:
-nem tiltja le a régi csatlakozókat, feltételezve, hogy automatikusan letiltásra kerülnek, mint az örökölt setcrtc
esetén-feltételezi, hogy az ASYNC_FLIP át van kötve az atomic ioctl
-hoz-egyetlen TEST_ONLY hívás sem[Más szavakkal] a megvalósítás a legacy ioctls 1:1 arányú fordítása atomra, ami a) hibás b) értelmetlen.
Már az i915-ben és az amdgpu-DC-ben is vannak hibák, amelyek miatt ez megakadályozza, hogy tiszta funkciókat engedélyezzünk.
Ha valakit érdekel az atom az X-ben, könnyen hozzáadhatunk egy új atomszintet (req->value==2) X számára, hogy visszaszerezzük a fényes játékokat.
Mióta a-modeseting hibás verzióit szállítják, valójában nincs más mód, hogy kilépjünk ebből a kötöttségből.
A”jó”hír az, hogy azóta A felhasználói tér oldalon 2019-ben az xf86-videómódosítási kód elindult, és alapértelmezés szerint letiltotta az atom támogatását. Tehát technikailag, ha frissített X.Org-vermet futtatunk az elmúlt három évben, erre a kernel-feltörésre már nincs szükség, mivel a felhasználói tér éppen akkor kerüli el az atomic API-t.
Meglátjuk, hogy Linus Torvalds rendben van-e a hack eltávolításával, mivel végül is ellenkezik az elvével, miszerint”nem törik fel a felhasználói teret”azáltal, hogy visszafejlődik a rendszer, ha ragaszkodik egy elavult X.Org Server veremhez, és egy jövőbeli kernelverzióval szeretné futtatni. Meglátjuk, de meglepő módon három évbe telt, mire ezt a piszkos kódot kritizálták.