5.6.2006 07:56
hwsoft | skóre: 19
Rozbalit Rozbalit vše Re: Jaderné noviny - 24. 5. 2006
Portál AbcLinuxu, 18. května 2024 00:01
Aktuální verze jádra: 2.6.16.18. Citát týdne: Linus Torvalds. Linux Device Driver Kit. Vysvětlení Secmark. Virtualizace: a co teď? Nová obecná IRQ vrstva. Poskvrnění z uživatelského prostoru.
Aktuální verze jádra je 2.6.16.18, vydaná 22. května s jedinou opravou; problém v kódu netfilteru SNMP NAT umožňoval vzdálený DoS. 20. května vyšla 2.6.16.17 s větší várkou oprav.
Aktuální předverze zůstává 2.6.17-rc4. V hlavním git repozitáři se však hromadí opravy a vypadá to, že -rc5 vyjde brzy.
Aktuální -mm strom je 2.6.17-rc4-mm3. Mezi nedávné změny patří velká sada SATA patchů, souborový systém S/390, filtrování paketů Secmark, nová sada patchů pro migraci stránek, nový rámec pro podporu hardwarového generátoru náhodných čísel, konsolidační patch pro zápis/čtení ve struktuře file_operations (mezitím odstraněno - až do opravení několika problémů) a patche se jmenným prostorem UTS (vizte níže). Příští -mm bude obsahovat také genirq patche (vizte níže).
Pánové, vývojář jádra, který nechápe, že uživatelský prostor je důležitý, by se měl přestat tvářit jako vývojář jádra a jít si radši hrát s nějakým hobby systémem typu Hurd. Tam můžete tvrdit, že "na uživatelském prostoru nezáleží".
Greg Kroah-Hartman se rozhodl, že je načase skoncovat s tím, jak se lidi Linuxu posmívají kvůli absenci řádné sady nástrojů pro vývoj ovladačů zařízení. Takže vytvořil první linuxový DDK. Součástí je čerstvé jádro 2.6.16.18, kompletní LDD3 a kopie veškeré jaderné dokumentace. Obraz CD lze stáhnout z kernel.org.
Secmark patche od Jamese Morrise už jsou v oběhu několik týdnů. Jde o nový mechanismus pro filtrování síťových paketů přes SELinux. Uvažoval jsem [Jonathan Corbet] o sepsání článku na toto téma, ale ukázalo se, že James to udělal dříve.
Jde o oddělení označování a vykonávání. Konkrétně: iptables se použijí k vybrání a označení paketů a SELinux pak s pomocí značení na paketech vykoná bezpečnostní opatření. Využijí se tak možnosti souborů pravidel pro iptables, ale také pružnost filtrování a mocné komponenty jako třeba sledování spojení. Zároveň však zůstane na SELinuxu, aby se postaral o prosazení bezpečnostní politiky. Pravidla pro povolení přístupu mohou být smysluplně analyzována v rámci celkové analýzy pravidel SELinuxu.
V článku naleznete detailní popis činnosti Secmarku spolu s návodem k použití.
Serge Hallyn nedávno poslal novou verzi patche s jmennými prostory UTS. Tento kód, který je malou částí konceptu "odlehčené virtualizace" nebo kontejnerů", umožňuje, aby se různé kousky informací o systému (v podstatě jde o věci, které vám řekne uname) lišily u různých skupin procesů na stejném systému. Možná se to nezdá jako velká věc, ale coby součást technologie, které se dostalo schválení od několika projektů pracujících v této oblasti, vám to může přiblížit, jak by mohl být řešen celý širší problém.
Andrew Morton odpověděl zprávou, ve které chválí způsob provedení, ale klade i jednu zásadní otázku:
Obecně si myslím, že celý přístup, který virtualizuje OS, aby mohl provozovat několik nezávislých instancí uživatelského prostoru, je dobrý. Jde o rozšíření a posílení věcí, které už Linux dělá, a posouvá nás dále po cestě, po které jdeme už léta. Bude-li to provedeno správně, je dokonce možné, že by tyto funkce mohly vylepšit samotné jádro - lepší vrstvení, oddělení atd. [...]
To všechno vede k otázce "co teď?".
Obavy pramení z toho, že by vývojáři začlenili velké množství netriviálního kódu, zkomplikovali nemálo interních jaderných rozhraní, a stále neměli výsledek užitečný pro lidi pracující na kontejnerech. Skutečnost, že se vývojáři pracující v této oblasti dokázali shodnout na jmenných prostorech UTS, je povzbudivá, ale není to žádná záruka shody na komplikovanějších změnách. Existuje reálná možnost neurovnatelného sporu, který by celý probíhající proces vykolejil.
Na druhou stranu by bylo dost náročné udržovat až do dokončení celý kód kontejnerů mimo jádro. Některé ze změn jsou relativně obsáhlé a agresívní. Spravovat je mimo jádro by nebylo zrovna zábavné. Stejně jako začleňování celé věci někdy v budoucnu, až by se dost vývojářů shodlo, že jsou hotovi.
Projekty zabývající se virtualizací a kontejnery potřebují několik funkcí:
Je také potřeba možnost virtualizovat pohled na souborový systém prostřednictvím jmenných prostorů, ale tuto funkci má Linux již několik let. Některé z pokročilejších funkcí kontejnerů - například checkpointing za běhu a migrace procesů - budou vyžadovat další sadu háčků [hooks] hluboko v jádře.
Skoro všechny kontejnerové koncepty potřebují pro zajištění použitelné izolace většinu položek z uvedeného seznamu. Takže je nutné nalézt způsob, jak tyto funkce dostat do jádra, aniž by se v půli cesty narazilo na neshodu, která by vše zablokovala - samozřejmě za předpokladu, že bude podpora kontejnerů obecně považována za žádoucí.
Andrey Savochkin navrhl postup, který by mohl být dobrým krokem kupředu: nejprve implementovat síťové jmenné prostory. Jde o jednu z nejkomplexnějších funkcí a je potřeba ji implementovat tak, aby voněla i vytříbenému vkusu vývojářů síťového subsystému. Během této práce bude nutné vyřešit několik ošemetných záležitostí - například virtualizaci přístupu k /proc a sysfs. Protože je to možná nejtěžší část problému, bude to také místo, kde je největší pravděpodobnost výraznějších neshod.
Vývojáři se často zaměří nejdříve na lehčí otázky, aby pak mohli získané znalosti uplatnit při řešení těžších částí problému. V tomto případě by však mohlo dávat smysl začínat s tím nejtěžším. Nebude-li nalezeno všeobecně přijatelné řešení, může se nechat podpora kontejnerů plavat dříve, než bude začleněno velké množství jiného kódu. Pokud by však zainteresovaní vývojáři dokázali implementovat něco, co by všechny potěšilo (nebo alespoň smrtelně neurazilo), měli by se už dostat přes každou pozdější překážku. V takovém případě by mohly být jednotlivé kousky skládanky bez obav postupně začleňovány.
Linuxové jádro má za standardním API ukrytou obecnou vrstvu pro práci s hardwarovými přerušeními. Je s tím jen jeden problém: ne všechny architektury tuto vrstvu používají. Hlavně ARM se neúčastní. Práce s přerušeními je ve světě ARM komplikovaná záležitost závislá na druhu subarchitektury a vůbec nepasuje do stávajícího "obecného" kódu, takže se ARM drží svého vlastního kódu - i když se některé části s obecným subsystémem překrývají. I pro architektury, které jej používat mohou, má současný IRQ subsystém stále zřetelnější nedostatky.
Pokus o změnu situace lze spatřovat v sadě patchů genirq od Thomase Gleixnera a Ingo Molnara. Tyto patche se pokoušejí vzít ponaučení z optimální práce s přerušeními na všech architekturách, přimíchat manýry padesáti (ano, padesáti) subarchitektur ARM a vytvořit nový, opravdu obecný a také schopnější IRQ subsystém. Je to velká sada patchů, která přepracovává množství velmi důležitého nízkoúrovňového kódu. Před začleněním do hlavního jádra se můžeme těšit na zajímavé diskuze.
Po menším úklidu se patch pouští do skutečné práce vytvořením nové struktury irq_chip. Ta je založena na staré struktuře hw_interrupt_type, ale obsahuje poněkud delší seznam nízkoúrovňových operací. Pro následující věci teď může jádro žádat specifický řadič přerušení:
Mnohé z těchto metod dříve existovaly, ale funkce mask(), mask_ack(), unmask(), set_type() a set_wake() jsou nové. S touto sadou funkcí může jaderný kód spravovat řadičové čipy přerušení citlivěji.
O úroveň výše má nyní stávající struktura irq_desc, která uchovává jaderné informace o všech specifických přerušeních, nový ukazatel na příbuznou strukturu irq_chip. Nová je také metoda handle_irq() ukazující na funkci, která se o dané přerušení ve skutečnosti stará. To je možná nejzásadnější změna od současného systému, který využívá jedinou funkci (__do_IRQ()), která zpracovává všechna přerušení. Jde o uznání faktu, že ne všechna přerušení jsou si rovna, takže nemá cenu se pokoušet se s nimi vypořádat v jediné velké funkci.
Největším rozdílem mezi přerušeními je tzv. "typ průběhu" [flow type] - kombinace způsobu, jakým je přerušení signalizováno, a jak jej systém zpracovává. Genirq patche definují následující typy průběhu:
Stávající IRQ kód se snaží všechny uvedené případy řešit jednou velkou rutinou. Nový kód místo toho vytváří několik obslužných funkcí podle různých průběhů a pak nastaví tu správnou jako handle_irq() metodu v popisovači přerušení. Výsledkem je kód, který může být optimalizován pro specifické potřeby a kratší trasu kódem v systému přerušení jako celku. Má-li konkrétní hardwarová platforma zvláštnosti, se kterými stávající obsluhovače nepočítají, je relativně snadné vytvořit obsluhovač nový.
Na úrovni jaderného API jsou změny poměrně malé; ovladače většinou není nutné měnit. Je tu však několik nových možností. Jednou z nich jsou nové parametry, které je možné předat funkci request_irq():
Tento dodatek se v API ve skutečnosti objevil už v 2.6.16, ale pouze architektura ARM pro něj měla podporu. S genirq podporují tyto parametry všechny architektury a příslušný obsluhovač průběhu bude volen interně. Jsou-li však přerušení sdílená, musí se všichni uživatelé shodnout na tom, jak bude spouštění řešeno.
Typ průběhu IRQ lze také změnit přímo pomocí:
int set_irq_type(unsigned int irq, unsigned int type);
Kde type by mělo být jedno z IRQ_TYPE_EDGE_RISING, IRQ_TYPE_EDGE_FALLING, IRQ_TYPE_EDGE_BOTH, IRQ_TYPE_LEVEL_HIGH, IRQ_TYPE_LEVEL_LOW, IRQ_TYPE_SIMPLE nebo IRQ_TYPE_PERCPU. Volání této funkce má stejný účinek jako určení typy spouštění pomocí request_irq(), ale nabízí více možností. Kromě toho však nekontroluje kompatibilitu s jinými uživateli sdíleného přerušení, takže je tu jistý prostor pro zmatky.
Některá zařízení umí generovat přerušení, která by měla systém probudit z uspání. Příkladem je funkce Wake-on-LAN u síťových adaptérů; dalším je probuzení prostřednictvím klávesnice. Jaderný kód může toto chování povolit nebo zakázat v řadiči přerušení:
int set_irq_wake(unsigned int irq, unsigned int on);
Pokud čipový řadič tuto funkci nepodporuje, bude vrácen chybový kód.
Dosud se o těchto věcech příliš nediskutovalo. Největší námitkou je zatím tvrzení, že samostatné obsluhovače průběhu jsou zbytečně komplikovaným přídavkem. Rozhodnutí o začlenění genirg závisí pravděpodobně na tom, jestli budou vývojáři ARM ochotni se vzdát své vlastní implementace a přejít na novou, obecnou verzi. Bez toho by kód genirq, který obsahuje hodně práce zaměřené konkrétně na potřeby ARM, nebyl moc obecným řešením. Mezitím si genirq našlo cestu do -mm.
Jádro už dlouho používá termín "poskvrnění" [tainting] jako způsob upozornění, že se stalo něco, co mohlo ovlivnit stabilitu systému. Dojde-li k OOPS, bude výsledný výpis obsahovat informaci o stavu poskvrnění. Vývojáři pak mohou tuto informaci využít, aby se mohli zeptat, co se to vlastně dělo. Poskvrnění bylo původně přidáno kvůli signalizaci použití binárních modulů, ale od té doby se jeho využití rozšířilo i na další věci. Mezi události, které poskvrní jádro, teď patří násilné odstranění modulu, nahrání modulu bez správné (nebo odpovídající) informace o verzi nebo provoz SMP jádra na procesorech, které nejsou pro SMP uzpůsobeny. Výjimky při kontrole stroje a jisté druhy chyb při správě paměti také poskvrní jádro.
Nedávný patch od Teda Ts'o rozšiřuje koncept poskvrnění zajímavým způsobem. Přidává nový soubor (/proc/sys/kernel/tainted); pokud do tohoto souboru uživatelský prostor zapíše, bude jádro označeno jako poskvrněné novou značkou "U". Účelem je podle Teda ošetřit případy kdy uživatelský prostor provádí něco nepěkného, co by mohlo jádro kompromitovat. Bylo nutné se ještě trochu vyptávat, než vyšla najevo celá pravda:
Problém je, že Real-Time Specification for Java (RTSJ) **vyžaduje**, aby JVM poskytovalo třídy s funkcemi, které umožní přímý přístup k fyzické paměti; veškeré fyzické paměti. Test na splnění podmínek RTJS to dokonce kontroluje; vyžaduje, aby člověk testu poskytl adresu několika stovek megabajtů fyzické paměti k otestování. A ta naprosto nejúžasnější věc je, že ten zákazník, který chce RTJS kvůli splnění podmínek pro státní zakázky, by také rád SELinux.
Představa nasazení SELinuxu na systému, ve kterém si Java může hrabat ve fyzické paměti, vyžaduje vskutku nemalou dávku kognitivní disonance. Ale Zákazník Má Vždycky Pravdu, takže Ted pracuje na tom, aby to fungovalo. Avšak ne zcela dobrovolně:
Byl jsem tak otrávený, že mě RTJS specifikace nutí něco takového dělat, že jsem si chtěl pojistit, aby tím bylo jádro označeno jako poskvrněné. Lidi by to varovalo, že se mohlo stát něco libovolně ujetého, a že je stabilita systému vydána napospas kompetentnosti programátorů javových aplikací.
Neozval se nikdo s tím, že by jádro nemělo být v takovém případě označeno jako poskvrněné. Naopak by možná bylo možné začlenit patch, který by v takovém případě nechal jádro vydávat hororové skřeky.
Vypadá to, že panuje všeobecná shoda o smysluplnosti tohoto patche; nepochybně existuje spousta situací, ve kterých by činnost uživatelského prostoru mohla ovlivnit stabilitu systému. Objevil se požadavek na uložení zprávy z logu společně se značkou o poskvrnění, aby byl později zřejmý důvod její přítomnosti. Bylo také poukázáno na to, že některé distribuce používají značku "U" v jiných situacích (k označení přítomnosti "nepodporovaných" modulů) - i když není jasné, jestli tomu tak skutečně je. Střety kvůli využití značek by skutečně mohly způsobit zmatky, takže Dave Jones navrhl, aby alespoň byly všechny značky signalizující poskvrnění používané v kódu nezařazeném do jádra v hlavním jádře dokumentovány. Zůstává však otázkou, jestli nějaké takové značky vůbec existují.
Problém je, že Real-Time Specification for Java (RTSJ) **vyžaduje**, aby JVM poskytovalo třídy s funkcemi, které umožní přímý přístup k fyzické paměti; veškeré fyzické paměti.To je ten pokrok
- moderní OS zabrání programu hrabat se libovolně v paměti a ještě modernější mu to zase dovolí. Abych někde sehnal instalačky s nejnovějším DOSem.
.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.