jaj kis baratom, az ilyen 'ezt mondtad, bizonyitsd be' trukkok nalam nem mukodnek am ;).
> PaxTeam 1. állítása
> Meg lehet oldani, hogy az ISR hívásakor a CPU a szokásos kód és verem állapotok helyett 48 byte tetszőleges adatot tegyen a verembe
eloszor is citation needed (nem tudsz, tehat hazudtal, hogy ezt irtam). masodszor az exploit altal kivaltott GPF soran lementett regiszterek jo nagy reszerol pontosan tudjuk, hogy mit tartalmaznak, tehat kontrollaltak (cs/rip/ss/rsp/rflags/error code mind mind jol predikalhato vagy akar direkt megvalaszthato biteket tartalmaznak).
> PaxTeam 2. állítása
> Befolyásolni lehet, hogy milyen érték kerüljön a GP aktiválódásakor rcx regiszterekbe,
eloszor is az rcx egy regiszter, nem tobb. amugy meg man ptrace/execve/sigreturn.
> valamint megoldja, hogy az rax (és a többi, syscall handler által módosított regiszter) értéke helyett a syscall
> hívás előtti userland értékek kerüljenek lementésre
citation needed. avagy megint nem ertetted meg mit irtam (vagy szandekosan hazudsz). az rax tudvalevoleg (itt most nem rolad van szo ;) (sys)call clobbered regiszter, azaz megvaltozik az erteke a hivas soran, konkretan az amd64-en hasznalt ABI-k visszateresi erteknek hasznaljak. ebbol mindjart kovetkezik, hogy pontosan lehet tudni, milyen erteke lehet sysret-kor (adott syscall visszateresi erteke). a tobbi regiszter allapota pedig kernel fuggo, de tipikusan rendesek es visszaallitjak a userland kontextust, amennyire lehet. nem hit kerdese, olvasd el a relevans kernel kodot (pl. arch/x86/kernel/entry_64.S linuxnal).
> PaxTeam 3. állítása
> Pusztán kerneladat átírásával, kód injektálás nélkül el tudja érni, hogy a GP handler futása a módosítást követően
> megszakadjon, és egy másik kódra adódjon a vezérlés, még mielőtt bármit is csinálna a GP handler.
ugy altalaban lovesed sincs a ret2libc/ROP exploit technikarol, mi? ;) raadasul ennel a kernel bugnal meg csak erre sincs szukseg.