ptrace: és ez hogy kapcsolódik a mi szituációnkhoz? Meglepődnék, ha ring3-as kóddal debuggolható lenne ring0-ás.
"child to be stopped at the next entry to or exit from a system call"
Ez a legközelebbi, amit elérhetsz vele, de maga a syscall handler (és pláne a GP handler) nem trace-elhető vele. Én legalábbis így tudom, de ha tévedek (nem vagyok ptrace guru), javíts ki nyugodtan.
Igen, valóban asm-el kezd, de ez hol érdekel minket? A lényeg, hogy ami lefut, azt nem tudod befolyásolni (hacsak nem a GPF handlerre irányítod az rsp-t, de ez elég rázós, mert nemcsak a módosított GPR-ek mentődnek, hanem sok minden egyéb is, ami nagy valószínűséggel invalid opcode vagy újabb GP miatti double faulthoz vezet még mielőtt a lényeges kódot végrehajtaná). Az biztos, hogy vissza nem kerül már a vezérlés az adott process-re. Értelmes kernelek GP handlerben kiveszik a ready queue-ból az aktuális processt, majd berakják a terminating queueba, és soha többé nem allokálnak CPU-t neki. Szóval ha valamit akarsz kezdeni vele, azt bizony a GP handlerben kell megtenned, még mielőtt egy új process address-space mappelődne be (ami mellesleg elég valószínű, hogy a sysret hívásakor eleve megtörtént, mert a speckó GPR-ek miatt érvénytelen volt a syscall, és a hibakezelő ág futott le).
nem is kódot tárolsz benne: honnan tudod? Elég ködös a "Place SOMETHING_MALICIOUS in general purpose registers" megfogalmazás. És hogy képzeled a megvalósítást, ha nem kód csak adat van benne? Értem, hogy elméletileg lehetséges lenne, de gyakorlatilag melyik az a kernel adat, aminek
1. a pontos címét ring3-ról előre ki tudod deríteni, hogy a megfelelő értéket rakhasd az rspbe
2. átírva benne sok byteot úgy, hogy abból csak egy része az, amit megadhatsz, a többi random módosítás (akár átlógva más kernel adatstruktúrákra) nem okoz crash-t
3. valamint kódfuttatás nélkül tudod hattatni (ugye mind a GDT, mint a lapozótáblák esetében szükség van a shadow regiszterek és a cache frissítésére, hogy érjen is valamit)
Én továbbra is fenntartom azon álláspontomat, hogy az a tény, hogy a GPF előbb keletkezik, mint a sysret environment helyreállítás, elég ciki az intel mérnökeire nézve, de önmagában nem kihasználható, kell hozzá egy koncepcionálisan elrontott kernel is (futtatható kód mappelési lehetőség), ami ráadásul még fittyet hány a CPU által biztosított jópár védelmi mechanizmusra (IST, NX stb) is.
A ködös megfogalmazások helyett jó lenne látni legalább egy proof of concept-et. Uff, én beszéltem.