Portál AbcLinuxu, 6. května 2025 00:29
Aktuální verze jádra: 2.6.34-rc3. Citáty týdne: Linus Torvalds, Andrew Morton, Andy Lutomirski. Směrem k rozumnějšímu execve(). Koncovka BKL. Zakázání IRQF_DISABLED.
Současné vývojové jádro je 2.6.34-rc3 vydané 30. března. Každopádně máme ze zaneřáděného -rc2 -rc3, které by mělo být v mnohem lepším stavu. Regrese opraveny a zkrácený log je dost krátký na to, aby ho stálo za to posílat do lkml. Testery, kteří používají SELinux a ext3, bude zajímat následující oznámení; regrese v předchozích jádrech mohla na takových systémech zanechat poškozené bezpečnostní značky [security labels]. Zkrácený changelog je v oznámení, všechny detaily můžete nalézt v kompletním changelogu.
Během minulého týdne nevyšly žádné stabilní aktualizace. Revidují se ale ne méně než čtyři aktualizace: 2.6.27.46 (45 patchů), 2.6.31.13 (89 patchů), 2.6.32.11 (116 patchů), 2.6.33.2 (156 patchů). Vydání všech těchto aktualizací lze očekávat 1. dubna nebo později.
napsal Jonathan Corbet, 30. února
Současné linuxové systémy umožňují procesům mnoha způsoby nastavit své prostředí. Z různých důvodů vývojáři často chtějí ještě větší flexibilitu; konkrétně by většinou ve jménu bezpečnosti rádi běžícímu procesu odebrali některé možnosti (přístup k souborovému systému, přístup k síti, kvalifikace). Problém je v tom, že takové změny mohou ve skutečnosti bezpečnost zhoršit; jak bylo mnohokrát k vidění, privilegované programy lze přinutit k tomu, aby dělaly nešťastné věci, když běží v neočekávaném prostředí.
Jak poznamenává Andy Lutomirski, jedna možná reakce na tento problém je zakázat i sémantiku setuid. Systémové volání execve() má však mnoho možností, jak změnit práva procesu, aniž by to zahrnovalo setuid programy; to platí obzvláště v přítomnosti bezpečnostních modulů. Andy tedy navrhl jiný přístup: Zbavit se execve(). Za tímto účelem navrhuje novou volbu pro prctl() (PR_RESTRICT_ME), kterou by bylo možné přidat restrikce k běžícímu procesu; první by byla, že tento proces nesmí volat execve(). Zakázání execve() by bylo povinné předtím, než by bylo možné přidat další omezení.
Program běžící v omezeném režimu by nicméně mohl i tak chtít spustit jiné programy; software v Linuxu často takovým způsobem pracuje. Aby této potřebě vyhověl, přidal Andy nové systémové volání pojmenované execve_nosecurity(). Tato varianta execve() spustí zadaný program, ale nebude přitom dělat naprosto žádné změny související s bezpečností. Takže žádné setuid, žádné změny SELinuxového typu atd. Konečný výsledek tohoto volání se funkcionalitou bude podobat jednoduchému namapování do adresového prostoru volajícího a přímému spuštění. S execve_nosecurity() není možné zvýšit práva spuštěním jiného programu, takže by odstranění kvalifikací běžícího procesu mělo být bezpečnější.
Tento patch by měl řešit mnoho obav, které vývojáři měli z omezování privilegií. Těžko to ale říci s jistotou, protože zatím bylo jenom málo reakcí.
napsal Jonathan Corbet, 30. února
Odstranění velkého jaderného zámku (BKL, big kernel lock) je již mnoho let jedním z vývojových cílů jádra. BKL vytváří problémy se škálovatelností a poskytuje opravdu podivnou sémantiku zamykání; obojího by bylo hezké se zbavit. Skutečné odstranění byl nicméně dlouhodobý proces; je to nudná práce, která vyžaduje poměrně hluboké znalosti upravovaného kódu. Relativně málo lidí se do této práce chce pustit, takže BKL přežil mnohem déle, než by se komu mohlo líbit.
Jeden vývojář, který odstranění BKL věnoval významné množství času, je Arnd Bergmann; Arnd právě zaslal sérii patchů, která slibuje úplné – téměř – odstranění BKL.
Za tímto účelem bylo provedeno mnoho významných změn. Blokový subsystém a subsystém tty získávají mutexy na úrovni subsystému, které nahrazují používání BKL; to je relativně složitá práce, protože sémantika zamykání poskytovaná mutexem je trochu jiná. Velká snaha byla věnována auditu a dokumentaci ioctl() a llseek(), které BKL stále potřebují; žádná jiná funkce ze struktury file_operations již BKL nepotřebuje. Kód, který stále vyžaduje BKL, je explicitně označen v konfiguračním systému jádra, což umožňuje vytvořit jádra bez BKL. Tato sada patchů také obsahuje významnou sérii od Jana Bluncka, který odstranil BKL z velké části vrstvy VFS.
Co zbývá, jsou z větší části nepoužívané moduly s ovladači. Arnd použil výraz „z větší části nepoužívané“ velice zeširoka – na BKL například stále závisí subsystém USB. BKL stále používá 148 modulů, ovladače z toho tvoří většinu. To může vypadat jako mnoho, ale je to obrovský krok správným směrem. Mnoho z nás možná bude mít jádra bez BKL dříve, než jsme si mysleli.
napsal Jonathan (io, parametry), 30. února
Obsluhy přerušení běží asynchronně v reakci na signál od hardwaru. Vzhledem k tomu, že vyruší CPU z toho, co dělalo předtím, očekává se od nich, že budou velmi rychlé; ve většině případů by měly hardwaru jenom říci, aby byl zticha, připravit práci, která bude následovat, a zmizet z cesty. Historicky to nebylo tak jednoduché, takže v počátcích Linuxu se obsluhy dělily na „rychlé“ a „pomalé“. A nyní se zdá, že toto dělení by mohlo již v 2.6.35 zmizet.
Hlavní rozdíl mezi rychlou a pomalou obsluhou spočívá v následujícím: Rychlé obsluhy běží se zakázáním ostatních obsluh přerušení, zatímco v pomalých je obsluha jiných přerušení povolena. Pomalou obsluhu tedy lze přerušit jinou obsluhou, kdežto rychlou ne. V ideálním světě by pomalé obsluhy neexistovaly; svou práci by odvedly rychle a nezabíraly by si CPU, takže by nebyl důvod je přerušovat. V reálném světě, ve kterém existuje problematický hardware, pomalé procesory a vývojáři různících se schopností, jsou ale pomalé obsluhy fakt, se kterým je nutné počítat. Povaha některého hardwaru (například staré IDE řadiče) neumožňuje vyhnout se spoustě práce přímo v obsluze přerušení. Zároveň s tím jiné typy zařízení musí mít opravdu rychlé reakce na přerušení, aby se předešlo ztrátě dat; klasický příklad jsou mnohé sériové porty, které jsou schopny do bufferu uložit přesně jeden znak. Pomalé práci s IDE nesmělo být dovoleno zpozdit zpracovávání sériové linky; obsluha přerušení od IDE tedy musela být pomalá.
Postupem času se však situace změnila. Hardware je chytřejší a lépe zvládá zpoždění při reakci na přerušení. CPU se zrychlila a tak i relativně pomalý hardware dokáže odvést spoustu práce rychle. Potřeby realtime stromu (a dalších pracovních zátěží citlivých na latence) motivovaly přepracování těch nejhorších škodičů, co se doby obsluhy týče. A vylepšení jaderných mechanismů pro odloženou práci zjednodušilo přesun práce pryč z obsluhy. Potřeba dělení obsluh přerušení na dva typy se tedy ztrácí.
Současně s tím narůstají problémy s dichotomií pomalá/rychlá. Neexistuje způsob, jak se zakázanými přerušeními obsloužit přerušení na sdílených linkách (k nalezení na jakémkoliv systému s PCI sběrnicí), protože jakákoliv jiná obsluha pro zařízení na stejné lince by mohla přerušení povolit. Umožnit obsluhám přerušení, aby se přerušovaly navzájem, vede k horšímu chování při práci s cache a navíc nelze předvídat, za jakou dobu se obsluha dokončí. Aktuální diskuzi nicméně zahájil tento patch od Andiho Kleena, který chtěl řešit další problém: Hluboce vnořené obsluhy přerušení mohou způsobit přetečení zásobníku přerušení [interrupt stack] v CPU – což je situace, od které nelze očekávat dobré věci.
Andiho řešení je monitorovat zásobník přerušení v jaderném kódu pro obsluhu přerušení. Když bude zásobník více než z poloviny zaplněn, vnitřní kód již nepovolí přerušení před voláním pomalých obsluh. Efektivně se tedy bude k pomalým obsluhám chovat tak, jako by byly rychlé, dokud bude v daném zásobníku málo místa. Patch řeší problém, který již byl pozorován, ale narazil na nějaké potíže; konkrétně Thomas Gleixner nijak neváhal a dal najevo svůj odpor. Autor článku se zde pokusí jeho argumenty popsat s použitím slušnějších výrazů; podle Thomase patch implementuje řešení, které je přinejlepším nespolehlivé, které hrozí vytvořením významných latencí v systému a které ignoruje skutečný problém.
Skutečný problém je podle Tomhase fakt, že pomalé obsluhy vůbec existují. Byl by radši, kdyby všechny obsluhy přerušení běžely se zakázanými přerušeními a svou práci odváděly rychle. Jakákoliv delší obsluha by měla být přemístěna do vlastního vlákna. Shrnuto:
Linus původně tento nápad poslal k čertu s tím, že svět, ve kterém budou jenom rychlé obsluhy, není reálný:
Je nicméně třeba podotknout, že tento postoj se časem posunul. Linus (a další) vyjádřil mnoho obav z toho, když budou všechny obsluhy běžet se zakázaným přerušením:
Obsluhy u některých zařízení prostě musí odvést spoustu práce a není snadné to změnit. Embedded systémy například mívají podivný hardware a pomalé procesory.
Některé obsluhy nebudou fungovat správně, když nebude obsluha přerušení povolena. V minulosti některé ovladače například čekaly, až uplyne nějaký čas (podle změn v proměnné jiffies). Tato podivná praktika okamžitě selže, když se zakáží přerušení: Přerušení časovače bude blokováno a jiffies se nebude měnit.
Některý hardware má prostě striktní požadavky na latenci a nemůže čekat, až jiná obsluha přerušení dodělá svoji práci.
Když se na všechny tyto obavy podíváme, můžeme si položit otázku, jestli systém, který zakazuje přerušení u všech obsluh, vůbec může fungovat dobře. Je tedy vhodné upozornit na jednu věc: jakýkoliv systém, na kterém je povolený kontrolor zamykání lockdep, má takové obsluhy přerušení již několik let. Mnoho vývojářů a testerů provozuje jádra s povoleným lockdep a taková jádra jsou také k dispozici i v některých dobrodružnějších distribucích (například Rawhide). Pro tento způsob práce tedy již máme poměrně dobré pokrytí testováním.
Další věc, která se během několika minulých let udála, je začlenění kódu pro dynamický tik, který zakazuje tikání hodin, když je systém nečinný. Tikání hodin tedy není pro obsluhy přerušení povoleno, takže jakákoliv obsluha přerušení, která očekává, že se jiffies změní, dříve či později spadne do nedůstojné nekonečné smyčky. Uživatelé si takového chování obyčejně všimnou, takže většina ovladačů, která se takto chovala, je již dlouho opravena.
A nakonec vývojáři v realtime stromě strávili spoustu času vyhledáváním zdrojů latence; nadměrné množství času stráveného obsluhou přerušení je jeden z nejhorších, takže ovladače, které řídí zajímavý hardware, byly většinou opraveny. Přidání obsluhy přerušení ve vláknech opravování ovladačů zjednodušilo; většinu kódu lze jednoduše přesunout do samostatného vlákna bez jakékoliv změny.
Vzhledem k tomu všemu si Ingo Molnár byl dostatečně jist, aby řekl:
Poté, co toto slyšel od hlavních vývojářů, a po vlastním výzkumu nakonec Linus přestal tomuto návrhu oponovat a začal mluvit o tom, jak to implementovat. Thomas poté zaslal patch s implementací. S tímto patchem se z IRQF_DISABLED stává no-op; očekává se, že bude úplně odstraněn v 2.6.36.
Ohledně této změny stále panují obavy, obzvláště s ohledem na pomalý hardware v embedded systémech. V některých z těchto případů lze problém vyřešit obsluhou přerušení ve vláknech, vývojáři se ale obávají, že obsluhy ve vláknech k reakci na přerušení přidávají příliš velkou latenci. Zlepšení této situace je úkol do budoucna; do té doby mohou přerušení obsluhy povolit samy. K tomuto účelu je preferována funkce local_irq_enable_in_hardirq(); používána je například v IDE vrstvě.
Vzhledem k tomu, že všechny technické překážky byly podle všeho překonány, je tu slušná šance, že si patch najde cestu do jádra v začleňovacím okně 2.6.35.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.