Linux

Gondoltam, kipróbálom megint a 2.6.0-os szériát, hátha kijavították már az SCSI drivert és egyéb régi problémákat, ami miatt az utolsó kísérletem meghiúsult.Ezúttal az SCSI rendben volt, viszont a matroxfb modulok betöltése után eltűnt a kép a konzolról, és piros kását kaptam helyette. Miután modul helyett fixen belefordítottam a kernelbe, legalább a konzol megmaradt, de az fbset már nem működött, így nem lehetett text módba kapcsolni, de felbontást váltani se.

Plusz poén, hogy a tty azt hitte magárol hogy 80x30, pedig csak 80x25 látszott belőle. Miután panaszaimat megírtam a matroxfb maintaniernek, Petr Vandrovec-nek, sokkoló választ kaptam. Egy James Simmons nevű kernel(vissza)fejlesztő úgy döntött, hogy javítja az FBDEV/FBCON layer hibáit. Szerinte 3 dolog okoz problémákat az fbdev-ben: a hardveres kurzor (ezért kidobta az egészet), a szöveges mód (ezért kidobta) és a hardveresen gyorsított FONT renderelés (nem találjátok ki: ezt is kidobta!). Ezen kívül az fbset utilt is dobta, szerinte ui. elég ha az stty-vel beállítható a szöveges felbontás, a refresh rate és a bpp (color depth) meg ki a f@szt érdekel?

Saját bevallása szerint is ettől lett broken többek közt a HUP-on sokak által imádott nvidia támogatása is, de ami engem inkább zavart, az hogy a matroxfb sem működik többet.

Petr Vandrovec ezért készített egy patch-et, ami reverseli James

(vissza)fejlesztéseit, így ismét használhatók a matrox kártyák:

ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/matroxfb-2.6.0-test7.gz

a patch test7-hez készült, de simán ráment a test8-ra is.

A patch jól sikerült, így már minden a régi.

A'rpi

Randy Hron küldött a kernel listára egy levelet, amelyben arról számol be, hogy szerinte 50%-os I/O visszafejlődés tapasztalható a 2.6.0-test kernelekben a 2.6.0-test5 óta. A feltevéseit tesztekkel is alátámasztotta.A tesztek alatt az 50%-os visszaesés a AIM7 job/minute mérésekben jelentkezett. A méréseket egy 4 utas P3 Xeon gépen végezte, és a tesztek alatt arra a következtetésre jutott, hogy a I/O regresszió nem függ a filerendszer típusától.

Feltette a kérdést, hogy vajon nem az I/O vagy az I/O scheduler okozza-e a teljesítményesést. Nick Piggin, az anticipatory I/O ütemező fejlesztője azt válaszolta, hogy szerinte ez I/O ütemező probléma, és azon gondolkozik, hogy hogyan lehetne javítani. Andrew Morton - a 2.6.0 jelenlegi karbantartója - szerint érdemes lenne megismételni a méréseket a régi ``deadline'' I/O ütemezővel is.

Egy későbbi levelében Nick azt kérte, hogy akinek van ideje, az tesztelje a 2.6.0-test5-ben levő as-iosched.c-t a későbbi kernelekben.

(megjegyzés: egy egyszerű notebookon is jelentkeznek a problémák, szemmel láthatóan kisebb a diszk teljesítmény)

A thread itt kezdődik.

Portoltam Molnár Ingo exec-shield patchét a napokban megjelent 2.6.0-test8 kernelhez.

A stuffot letöltheted innen: exec-shield-2.6.0-test8

Az alábbi programokkal lett tesztelve:

libsafe-2.0-16.tgz, paxtest-0.9.3.tar.gz

Az exec-shield telepítése itt. Az exec-shield-hez kapcsolódó HUP cikkek itt.

Az eredmények:===========================================

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# echo "2" > /proc/sys/kernel/exec-shield

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# cat /proc/sys/kernel/exec-shield

2

===========================================

libsafe-2.0-16 (exec-shield teljes védelem):

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./canary-exploit

This program tries to use printf("%n") to overwrite the

return address on the stack.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./exploit-non-exec-stack

This program demonstrates how a (stack) buffer overflow

can attack linux kernels with *non-executable* stacks.

This is variation on return-int-libc attack.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t1

This program tries to use strcpy() to overflow the buffer.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t1w

This program tries to use strcpy() to overflow the buffer.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t3

This program will exec() a new program. The new program will

overflow the buffer using strcpy().

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t3w

This program will exec() a new program. The new program will

overflow the buffer using strcpy().

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t4

This program will fork() child process, and the child

will overflow the buffer using strcpy().

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

parent process terminating

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t4w

This program will fork() child process, and the child

will overflow the buffer using strcpy().

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

parent process terminating

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t5

This program tries to use strcat() to overflow the buffer.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

---------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# ./t6

This program tries to use scanf() to overflow the buffer.

If you get a /bin/sh prompt, then the exploit has worked.

Press any key to continue...

Szegmens hiba

---------------------------------------------------------------------

*************************************************

*************************************************

===========================================

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# echo "2" > /proc/sys/kernel/exec-shield

gmicsko03:/home/trey/devel/exploit/libsafe-2.0-16/exploits# cat /proc/sys/kernel/exec-shield

2

===========================================

paxtest-0.9.3 (exec-shield bekapcsolva):

--------------------------------------------------------------------

gmicsko03:/home/trey/devel/exploit/paxtest-0.9.3# ./paxtest

PaXtest - Copyright(c) 2003 by Peter Busser

Released under the GNU Public Licence version 2 or later

It may take a while for the tests to complete

Test results:

PaXtest - Copyright(c) 2003 by Peter Busser

Released under the GNU Public Licence version 2 or later

Executable anonymous mapping : Killed

Executable bss : Killed

Executable data : Killed

Executable heap : Killed

Executable stack : Killed

Executable anonymous mapping (mprotect) : Killed

Executable bss (mprotect) : Vulnerable

Executable data (mprotect) : Vulnerable

Executable heap (mprotect) : Vulnerable

Executable shared library bss (mprotect) : Vulnerable

Executable shared library data (mprotect): Vulnerable

Executable stack (mprotect) : Vulnerable

Anonymous mapping randomisation test : 16 bits (guessed)

Heap randomisation test (ET_EXEC) : 13 bits (guessed)

Heap randomisation test (ET_DYN) : 13 bits (guessed)

Main executable randomisation (ET_EXEC) : No randomisation

Main executable randomisation (ET_DYN) : 12 bits (guessed)

Shared library randomisation test : 12 bits (guessed)

Stack randomisation test (SEGMEXEC) : 17 bits (guessed)

Stack randomisation test (PAGEEXEC) : 17 bits (guessed)

Return to function (strcpy) : Killed

Return to function (memcpy) : Executable shared library bss : Killed

Executable shared library data : Killed

Writable text segments : Vulnerable

gmicsko03:/home/trey/devel/exploit/paxtest-0.9.3#

Benchmarking BSD and Linux

A legjobb a Linux 2.6, második a FreeBSD 5.1. A NetBSD átlagos, az OpenBSD pedig katasztrófa.



Egy nagyon érdekes tanulmány bukkant fel az Interneten a minap. A tanulmány célja az volt, hogy kivizsgálja a napjaink Unix alapú (és Unix-szerű) operációs rendszereinek a hálózatos skálázhatóságát egy általános célú PC hardveren.

A vizsgálódás arra irányult, hogy hogyan lehet egy webszervert úgy létrehozni, hogy az a legskálázhatóbb legyen. Melyik operációs rendszert kell ahhoz választani, hogy túl lehessen élni akár a Slashdot Effektust is.

Lássuk:A tesztekben az alábbi operációs rendszerek vettek részt:

Linus kiadta a nyolcadik test kiadást a 2.6.0 kernelsorozatból. Mint írja, kicsit több lett a változás, mint szerette volna (a test8 és test9 a stablilizáció jegyében kerül kiadásra), de a változások többnyire egészen kicsik. Mi változott?- megjavult a /proc/PID/stat oops

- workaround került a kernelbe az AMD Athlon prefetch bughoz, amely esetenként ál ``page fault'' hibához vezethet

- javításra került a ServerWorks chipset PIO (programmed IO) autotuning

- javításra kerül néhány CPU frekvencia kalkulációt végző kód

- működik az NFS O_DIRECT

Letölthető patch-2.6.0-test8.bz2, FULL

Linus levele a változások listájával itt.

Repulonep értesített arról, hogy mostantól online elérhető Kadlecsik József szerdai (október 15-i) iptables előadásának archív felvétele.Akik lemaradtak az érdekes előadásról, azoknak lehetősége van most letölteni a stuffot.

Az netfilter/iptables előadás archivuma itt:

streaming.niif.hu/archive/ipszilon1

A IIF korábbi előadásai is elérhetőek:

Software Technology Forum - Software Security (angol, magyar nyelven)

NetworkShop 2003 Conference (magyar nyelven)

Roman Zippel bejelentése szerint elérhető az iSCSI első publikus, linuxos implementációja a 2.4-es stabil kernelhez. Az anyag egész használható, noha még nem teljesít minden olyan kívánalmat, amelyet az iSCSI specifikáció leír.

Az iSCSI jelentése ``Internet Small Computer System Interface''. Azaz SCSI protokol az IP felett. Segítségével a szerverek képesek lesznek nagy távolságokból is elérni a háttértárakat, így növelhető a megbízhatóság és a katasztrófahelyzetek kezelésének hatékonysága. Az iSCSI protokol egy IETF-definiált protokol az IP storage-okhoz.Az elgondolás a következő. A távol elhelyezett diszk alrendszer (storage) egy speciális ``storage router'' (pl. Cisco SN 5428-2) segítségével kapcsolódik az IP alapú hálózathoz. A másik oldalon az operációs rendszer egy iSCSI driverrel kommunikál. Ez a driver egy olyan iSCSI protokol initiator-ként működik (az SCSI egy kliens-szerver architektúra. a SCSI klienseket nevezzük ``initiator''-nak.), amely az SCSI kéréseket és válaszokat továbbítja a hálózaton keresztül. A driver az operációs rendszer és a TCP/IP réteg között helyezkedik el. A TCP/IP réteg alatt találjuk a hálózati csatolót, amely szintén az IP alapú hálózathoz csatlakozik. Lásd az ábrát.

A driver 2.4.16-os vagy későbbi 2.4-es kernellel működik. A driver a GPL licenc alatt érhető el.

Bővebb infó, és driver letöltés:

www.ardistech.com/iscsi

Roman levele itt.

Mint ismeretes, szeptember elején eltávolításra került a 2.4-es kernelből a régi OOM killer, és helyére az Andrea Arcangeli által alkotott új megoldás került.

2.4.23-pre VM visszafejlődés? Marcelo Tosatti - a 2.4-es Linux kernel jelenlegi karbantartója - ezzel a címmel küldött levelet az LKML-re, amelyben az alábbiakat írta:

Olyan levelet kapott, amelyben a felhasználó azt írta, hogy egy ``gzip -dc file | less" (280MB-os file) parancsot futtatott és a ``less'' parancsot kilőtte (kill) az OOM killer. A felhasználónak nem volt swap-je. Marcelo arra kérte, hogy állítson be némi swap területet. A felhasználó megfogadta a tanácsot, és megoldódott a problémája. De közben felmerült egy másik probléma is:

A 2.4.22-es kernel a ``less'' parancsot egyszerűen ``kill''-elte, viszont a 2.4.23-pre kernel az alábbit művelte:>> And yes, the app was killed:

> >

> > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

> > VM: killing process named

> > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

> > VM: killing process gpm

> > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

> > VM: killing process sendmail

> > __alloc_pages: 0-order allocation failed (gfp=0x1d2/0)

> > VM: killing process less

Vagyis ahelyett, hogy a kernel a csak a ``less'' parancsot ölte volna meg, elkezdte kilődözni a többi programot is. Ráadásul úgy, hogy nem a legtöbb memóriát felhasználó processzt lőtte ki először (ahogy az logikus lett volna, és ahogy a régi OOM killer tette), hanem olyan kisméretű programokat vett előbbre, mint a ``gpm'', ``sendmail'', stb.

Marcelo ekkor azt kérdezte, hogy most mi helyzet. Vissza kell térni a régi OOM killerhez?

Erre Tvrtko A. UrAiulin egy patchet küldött, amely lehetővé teszi, hogy az OOM killer-t fordítási időben lehessen kiválasztani. Ezzel lehetővé válik az, hogy igény szerint használható legyen vagy a régi OOM killer vagy az -AA féle újabb implementáció.

A thread itt kezdődik.

Simon Derr és társa egy CPUset névre hallgató patchet készített a Linux kernelhez. A CPUset-ek pehelysúlyú objektumok a Linux kernelben, melyek segítségével a felhasználók több partícióra oszthatják a több processzoros gépeiket (SMP) úgy, hogy végrehajtási területeket jelölnek ki azokon. A patch egy virtualizációs réteget képez a kernelben, amely segítségével felosztható a gép a CPU-k hatáskörébe.A szerzőket az motiválta a patch elkészítésekor, hogy a gép teljes mértékben adminisztrálható legyen a CPU-kra nézve. Magyarul: a CPUset-ek erős börtönök (jail), a bennük futó processzek kizárólag csak ezekben a börtönökben futhatnak, és nincs módjuk arra, hogy ebből a börtönből kiszabadulva másik processzorra költözhessenek. Vagyis lehetőség van arra, hogy egy processzt egy bizonyos CPU-khoz rendelt börtönben futtassunk, és csakis abban.

Bővebben itt.

A ``szabad világ vezetője'' (Leader of the Free World) címmel jelent meg egy hosszú (6 oldalas) írás Linus Torvalds-ról a Wired magazin oldalain. Megtalálod itt.