( PaXTeam | 2015. 02. 26., cs – 22:14 )

> Annó olyasmit tanultam, hogy egyetlen programnak van joga kondicionálatlan végtelen ciklusban pörögni, a kernelnek.

eloszor is ha kernelrol beszelunk (tehat a kontextus valami vedett modban futo kernel kod meg kulonbozo userland programok alatta), akkor a kernel nem 'program'. ha MS-DOS-ra gondolsz, akkor ott valoban minden egy privilegium szinten volt, tehat nem volt ildomos lefoglalni a procit. kernel/userland felosztasnal semmi elvi gond nincs, ha egy userland processz porogni akar. a gyakorlatban energiat zabal, ezert tovabbra sem ildomos.

masodszor a freeze() nem kondicionalatlan vegtelen ciklus, de lasd alabb.

> Meg olyasmit is, hogy a függvények visszatérési értékét vizsgálni szokás. T'om ez volt már vagy 20 éve és azóta sokat változott a világ.

szokas akkor, ha van ertelme. az adott esetben nincs ;).

> Hogy miért gány a fenti megoldás: A pause visszatérési értéke -1, ha a hívó processz vagy szál terminálásra kerül vagy az adott szignált kezelő
> függvény visszatér. Bizony, ebben az esetben is visszatérhet a pause, ami aztán vizsgálat nélkül pörög tovább.

az a helyzet, hogy a pid 1 egyszalu program, nem lehet megolni (a kernel direkt szuri a SIGKILL-t), a freeze() pedig egy signal handlerbol hivodik, es (by design) nem ter vissza. mindebbol az kovetkezik, hogy a pause a gyakorlatban nem fog az eletben visszaterni, a pid 1-et orok alvasba kenyszeriti (a procin valo porges helyett). ha megis sikerulne valamiert felebreszteni a processzt (lusta vagyok megnezni, melyik szignalt kezeli az adott helyzetben), akkor is max az tortenik, hogy megy egyet a ciklus es megint elalszik (MS-DOS vilagban ez egy cli/hlt ciklus lett volna kb.). pontosan ez a celja az egesznek, hogy a processz eletben maradjon es lehessen post mortem debuggolni anelkul, hogy a processzor porogne rajta. ez minden, csak nem "kondicionálatlan végtelen ciklus". ha az admin nem ezt akarja, akkor megvan ra a lehetosege, hogy ne ez tortenjen.

> Pedig ezeregy dolgot lehetett volna csinálni. pl. vizsgálhatná, hogy a crasht kiváltó állapot fennállását, vagy az azt kiváltó okot.

meselj, hogy lehetne mindezt megcsinalni a gyakorlatban? tegyek be a systemd-be a gdb-t meg az exploitable plugint? el tudod kepzelni, mekkora konspiraciot kialtananak a systemd utalok? ;)

> Vagy ne adj isten újra lehetne indítani az egészet. Oh, wait...

leirtam, hogyan lehet ezt trivialisan megcsinalni. oh wait...

> Szoftver tervezésnél ugye szokás foglalkozni a egy adott állapot kezelésével és annak kihatásaival. Itt azonban szimplán emo lesz a kód és befordult.
> Ezt még csak el lehet nézni az én szintemen álló, hello.c-nél, de itt egy kibaszott init rendszerről van szó. Ha mást nem is, de annyit kutya kötelessége
> lenne tenni, hogy szól a tőle függő processzeknek, hogy "Béláim! Túltoltuk!".

azt vagod, hogy a crash() akkor hivodik meg a gyakorlatban, amikor kb. fatalis memoria korrupcios hiba keletkezik a pid 1-ben? szemely szerint en mar azt is soknak tartom, amit a mostani kod csinal, nem hogy meg elkezdjen mindenfele processzekkel kommunikalni. te sem sok rendszert terveztel, az biztos...

> Az eredetileg közölt cikkben is ez okozta a problémát, hogy a nagy befordultsága miatt vidáman bezombultak a tőle függő processzek.

es mindez admin hiba volt.

> Az általad közölt CrashShell (https://github.com/systemd/systemd/blob/e410b07d2aa64a653bc0e93b77856af…)
> "ez ellen nem véd", mert ugyan indít egy shellt, de utána ugyanúgy freezebe megy.

azt ugye erted, hogy a pid 1-tol nem normalis az, hogy fatalis hibat tartalmaz. tehat ha megis bekovetkezik, akkor az kb. a vilag vege allapot (a kernel is elpanikol, ha a pid 1 kilep ugye). a systemd fejlesztok erre az allapotra irtak kodot, ami kepes rebootolni is meg post-mortem debuggolast is lehetove tenni. az admin feladata eldonteni, hogy melyiket szeretne. az RTFM hianya meg nem a systemd fejlesztoinek a problemaja. meg ugy altalaban is.

ugy altalaban meg eleg ciki, ahogy a sok okostojas itt porgott a pause-on alapulo vegtelen cikluson anelkul, hogy a leghalvanyabb fingja lett volna arrol, hogy mi a kontextus, mi a kod celja, es milyen alternativakat kinalt a rendszer a problema elkerulesere. neked is eleg lett volna annyit mondanod, hogy bocsi, balfasz voltam, es azelott nyilatkoztam, hogy elolvastam volna a kodot. de nem, neked tovabbra is all a fasz es mondod az okosat. de hajra hupperek, toljatok csak tovabb a hulyeseget.