Kernel

Alan Cox levele szerint a napokban megjelent 2.6.9-es Linux kernel komoly biztonsági hibákat javít, így a korábbi Linux kernelt használóknak erősen ajánlott frissíteni.A probléma az, hogy a 2.6.9-nél korábbi 2.6-os, 2.4-es és talán 2.2-es kernelek terminal alrendszerei is kihasználható, versenyhelyzet típusú hibát tartalmaznak.

Két konkrét hibát említ Alan a levelében. Az egyik esetében a helyi felhasználó rendszer crash-t okozhat, míg a másik esetben akár külső támadást is kaphat linuxos rendszerünk. A 2.4-es kernelhez készültek patchek, amelyet Jason Baron a linux-kernel listára postázott. A 2.2-es kernel egyelőre patch nélkül van.

Alan levele itt.

Kijött a végleges 2.6.9-es Linux kernel, ami a 2.6.9-final verzióhoz képest UML update-et és egyéb - minimális mértékű - javításokat tartalmaz. Részletek Linus levelében. Közvetlen linkek a magyar tükörre: tarball, patch, changelog.

Mingo elkészítette az exec-shield (korábbi cikkeink) patch legújabb, a 2.6.9-es kernelhez használható verzióját.A patch nem más, mint azoknak a exec-shield foltoknak az összegyúrása, amelyet a Fedora Core 2/Core 3-ban használtak fel. A patch ezen verziója képes használni NX technológiát (és a PAE-t) ha az jelen van a gépben, ha a számítógépben levő processzor nem NX-képes, akkor egyszerűen használja a régi szegmens-határ metódust.

Az anyag letölthető innen.

Nem, nem elírás. A 2.6.9 végén ott egy -final extraverzió. Hivatalos bejelentés még nincs, szóval ez még lehet, hogy csak egy kiadásra jelölt verzó.A changelog szerint elég sok fontos javítás van benne az -rc3-hoz képest.

Igaz még nem tudni, hogy ez lesz-e a végleges 2.6.9 és azt sem, hogy 2.6.9-final lesz-e a neve, de már vannak olyanok, akiknek nem tetszik ez az elnevezés.

Az anyag letölthető linux-2.6.9-final.tar.bz2

Egy kis tanmese (forrás: LKML):

``Egy repülőgép-gyártó vállalt felfedezte, hogy olcsóbban lehet repülni, ha a repülőben kevesebb üzemanyag van. A repülőnek így kevesebb a súlya, kevesebbet fogyaszt, tehát pénzt spórol. Néhány esetben azonban előfordulhat, hogy az üzemanyag kevésnek bizonyul, és a repülő lezuhanhat. Ezt megelőzendő, a vállalat mérnökei kifejlesztettek egy speciális OOF (out-of-fuel) mechanizmust. Vész esetén a mechanizmus kiválaszt egy utast, és kidobja a repülőből (ha szükséges, akkor megismétli az eljárást). Nagy mennyiségű elmélet és lelkes publikáció született abból a célból, hogy megoldja a kidobásra jelölt ``helyes kiválasztásának'' problémáját. Az áldozat kiválasztása legyen random? Vagy válasszuk a legnehezebb személyt? Vagy a legöregebbet? Az utasok fizethetnek azért, hogy ne kerüljenek sorra, így a legszegényebbnek kell lennie az áldozatnak? Vagy amikor a legnehezebb személyt kell kiválasztani, akkor kivételt kell tenni abban az esetben, ha az a pilóta? Vagy az első osztályon utazókat kivételes esetnek kell kezelni? Az OOF mechanizmus elkészült, hébe-hóba aktiválódik olyankor is, mikor éppen nincs is üzemanyag-hiány. A mérnökök jelenleg azt vizsgálják, hogy pontosan hogyan történhetett ez az üzemzavar.''Thomas Habets egy oom_pardon patchel állt elő az LKML-en. Azt kérdezte a kernelfejlesztőktől, hogy mit szólnának ahhoz, ha lenne egy olyan sysctl amelyik azt csinálná, hogy ``az isten szerelmére, soha ne öld meg ezeket a processzeket, ha OOM van. Ha semmi mást nem tudsz megölni, legyen inkább (kernel)pánik.''

Példaként a /usr/bin/vlock és usr/X11R6/bin/xlock programokat hozta fel. Mint mondta, szerinte nagyon kellemetlen meglepetés az, amikor azért találja a gépét lezáratlanul, mert az OOM kinyírta az /usr/bin/vlock-ot.

Ezt kiküszöbölendő, készített egy patchet. A /proc/sys/vm/ alatt található egy olyan kapcsoló amellyel a VM alrendszer tudtára lehet hozni, hogy mely programok tabuk a processz kilövöldözéskor.

Példa:

echo "/usr/bin/vlock /usr/X11R6/bin/xlock" > /proc/sys/vm/oom_pardon

Ezzel a VM alrendszer tudomására hoztuk, hogy ha törik, ha szakad a vlock és xlock programoknak működniük kell, és ha olyan memóriahiányos állapot áll be, hogy az OOM killer ezeket a programokat akarná lelőni, akkor inkább pánikoljon el a rendszer.

A fejlesztőknek tetszett az ötlet, néhányan javaslatokat tettek a kód jobbá tételére.

Andrea Arcangeli -a Novell kernelhackere- elmondta, hogy már korábban kifejlesztettek egy hasonló működésű patchet a saját kernelük számára. A neve protect-pids. Mint mondta, az OOM killer-ben nem lehet megbízni mondjuk szerver környezetben, ahol a legnagyobb task az éppen az, aminek minden körülmények közt működnie kell. Hasznos lehet ez az elgondolás ott, ahol néhány ``trusted'' alkalmazást kell megvédeni...

A thread itt.

Vincent Roy és Makan Pourzandi az Ericcson (szerintem az Ericsson-t így kell írni, de a cikkben Ericcson van) Canada munkatársai nekifogtak, hogy megmérjék a 2.6.7-es Linux kernel natív IPsec implementációjának teljesítményét.A cikkben egy kis IPsec ismertető után egy minimális konfigurációt láthatunk, majd a cikk végén egy táblázatban összefoglalva elolvashatjuk a Netio benchmark szoftver által jelzett eredményeket.

Az eredmények azt mutatjék, hogy az IPsec használata kb. felére csökkenti a hálózati sebességet mind TCP mind UDP adatátvitel esetén. A mérések szerint a leggyengébb eredmény sem volt rosszabb, mint 4.53 MB/sec, ami a mérést végzők szerint a legtöbb alkalmazásnak elegendő.

A cikket elolvashatod itt.

Linus kiadta a 2.6.9-es kernel negyedik kiadásra jelölt verzióját. Linus azt tervezi, hogy a végleges 2.6.9-et kb. egy héten belül kiadja, ezért arra kérte a fejlesztőket, hogy ha van függőben levő foltjuk, akkor azt tartsák kicsit vissza.A patchben architektúra frissítések, ACPI update-ek találhatók a kisebb javítások mellett.

Az anyag letölthető patch-2.6.9-rc4.bz2

A változások listája Linus levelében itt.

Szeptember közepén volt szó itt HUP-on a Serge Hallyn-féle BSD Jail linuxos implementációjáról. Serge azóta frissítette a patchet, és elküldte a Andrew Mortonnak, kérve őt, hogy azt olvassza be a mainline kernelbe.Andrew átnézte a kódot, és azt válaszolta a szerzőnek, hogy nem emlékszik arra, hogy valaki is kért volna ilyen funkciót. Kérte Serge-t, hogy indokolja meg, hogy miért kellene beolvasztania a patchet. Emellett Mortonnak kifogása volt a szerző kódolási stílusával szemben is.

Serge azzal indokolta a beolvasztási kérelmét, hogy ezzel a patchcsel a Linux a FreeBSD jail(8) és a Solaris zonák funkcióihoz hasonló megoldáshoz juthat, ami ráadásul szerény módon van megvalósítva, és nem zavarja azokat a felhasználókat akiket nem érdekel. Felsorolta a patch előnyeit...

James Morris LSM fejlesztő szerint a patch hasznos lehet azoknak, akik FreeBSD-ről vagy Solarisról szeretnének migrálni Linuxra. Chris Wright szerint is hasznos a patch, mert jól demonstrálja az LSM bizonyos képességeit.

Andrew továbbra is kötötte az ebet a karóhoz, azt mondván, hogy még mindig nem látja, hogy miért kellene a patchnek a Linux kernel szerves részévé válnia. Szerinte a kódnak feltétlenül karbantartottnak kell lennie ahhoz, hogy a kernel részévé válhasson, viszont ehhez (ahogy korábban írta) megfelelő felhasználói bázisának kell lennie. Szerinte a patch valóban jól demonstrálja a LSM képességeit, de ez nem jelenti azt, hogy a kernel.org-on jobb helye lenne, mint mondjuk a bsdjail.sourceforge.net oldalon.

Alan Cox azt írta, hogy a javítások és kódtisztítások elvégzése után szívesen látná az anyagot a biztonsági moduljaik (gondolom a Red Hat-ra célzott) közt, mert egyszerűen implementált.

Egyelőre a döntés Andrew Morton kezében van. A KernelTrap összegyűjtötte a legfontosabb leveleket a témában.

A Montavista a beágyazott, valósidejű operációs rendszerek szakértője. A cég egyik munkatársa, Sven-Thorsten Dietrich egy négy részből álló patchet küldött a minap az LKML-re. A patchset nem más, mint a 2.6-os Linux kernelhez készült RT (real-time - valós idejű) kiegészítés.

A patch célja, hogy tovább csökkentse a Linux kernel megszakítási (interrupt) latency-jét, és hogy drámaian redukálja a task preemption latency-t a 2.6-os kernel sorozatban.

A patchnek a beágyazott, valósidejű operációs rendszerek piacán van nagy jelentősége. Hol lehet szükség erre a technológiára? Számos helyen:A nagy teljesítményű multimédia alkalmazások nagyon gyors, taszk szintű vezérlő függvényeket igényelnek. Az Audio-Video iparág például HDTV-hez kapcsolódó technológiákat épít Linuxra. A mobil telefonok, PDA-k, MP3 lejátszók egyre komplexebbek lesznek, amelyek egyre nagyobb számú szálak (threads) futtatását igénylik. Ezek a szálak nagy mennyiségű protokollt támogatnak (pl. IP, Bluetooth, 802.11, GSM, CDMA, stb.) Például a celluláris protokollok erősen határidő-érzékeny (deadline-sensitive) feldolgozást igényelnek. De ilyen terület lehet például a GPS adatfeldolgozás is, amely rendkívül erős, valósidejű taszkokat és garantált kHz-es frekvenciájú interrupt feldolgozást igényel. Jó példa az ilyen jellegű felhasználásra, mondjuk a veszélyes helyen levő, távvezérelt, Linux-alapú GPS megfigyelő-berendezés (pl. a vulkánok belsejét megfigyelő eszközök), amely élő adatközvetítést végez IP-n keresztül.

A Linux-alapú rendszereket egyre inkább alkalmazzák olyan valósidejű vezérlést igénylő környezetekben is, mint például a radar feldolgozás, gyár automatizálási rendszerek, orvosi technológia és hangszer ipar... Ezekben a berendezésekben számtalanszor van szükség olyan garantált taszk reakcióidőre, amelyet a jelenlegi 2.6-os Linux kernel technológiával nem lehet megoldani. Ezt a hiányosságot hivatott kiküszöbölni ez a patchset.

Bővebben Sven-Thorsten Dietrich levelében itt.

Marcelo majd egy hónap szünet után újabb 2.4-es -pre kernelt adott ki. A 2.4.28-pre4 patch driver frissítéseket (pcnet, e1000, gdth, prism54), hálózati kód frissítést, gcc3.4 warning javításokat, stb. tartalmaz. A patch az egy hónapos kihagyáshoz képest kicsi. Marcelo azt szeretné, hogy a 2.4-es sorozatban mostantól kezdve csak minimális változások lennének, és a 2.4 békében nyugodna.A patch letölthető patch-2.4.28-pre4.bz2

Változások listája Marcelo levelében itt.