Portál AbcLinuxu, 16. května 2024 23:34
Jaderné noviny - 9. 8. 2006
Články
-
Jaderné noviny - 9. 8. 2006
Aktuální verze jádra: 2.6.17.8. Citát týdne: Dave Jones. Pohyb ve vývojářské komunitě. Grand Unified Flow Cache. Připojení Linuxu k hypervisorům. Kód nejistého původu.
Aktuální verze jádra: 2.6.17.8
link
Aktuální verze jádra je 2.6.17.8, vydaná 6. srpna. Tentokrát obsahuje poměrně velký počet důležitých oprav, i když ani v jednom případě nešlo o CVE problém.
Aktuální předverze je 2.6.18-rc4, vydaná 6. srpna. Linus k ní napsal: Info najdete v diffu (a v připojené krátké verzi changelogu): hodně malých oprav v různých oblastech - většinou jde o ovladače. Vstupní vrstva, infiniband, usb, síť, zvuk, vlb. Aktualizace cpufreq a architektur. Několik vylepšení auditových pravidel od Ala & Amy. V síťovacím kódu je také nový mechanismus pro upozorňování na události a funkce (netdev_alloc_skb()) pro alokaci paketových bufferů způsobem, který si rozumí s NUMA. Vizte také dlouhý changelog.
Aktuální verze -mm stromu je 2.6.18-rc3-mm2. Mezi nedávné změny patří návrat subsystému CacheFS, plná podpora Compact
Flash v kódu libata, velká aktualizace x86-64, několik úprav správy paměti a podpora vektorovaného asynchronního I/O.
Citát týdne: Dave Jones
link
1. zákon o hackování jádra od Davej: Je-li počet iterací, kterými patch projde, vyšší než počet řádků diffu, pravděpodobně nestojí za tu námahu.
-- Dave Jones
Pohyb ve vývojářské komunitě
link
Když Linus oznámil vydání jádra 2.6.18-rc4, přihodil i něco informací navrch:
Po většinu následujících tří týdnů budu převážně off-line (dovolená a pohřeb). Ačkoliv doufám, že budu moci občas aktualizovat svůj strom, požádal jsem Grega KH, aby spravoval git strom a začleňoval užitečné opravy.
Pak bleskurychle zmizel ze scény, aniž by dal -rc4 na kernel.org - opomenutí, které o pár hodin později napravil Greg. Zatímco vývoj jádra bude pokračovat jako obvykle, je pravděpodobné, že se v následujících týdnech dočkáme méně -rc verzí a téměř jistě nevyjde ani finální 2.6.18.
Andrew Morton mezitím využil oznámení o 2.6.18-rc3-mm1 k předání vlastních zpráv:
Pro ty, které to zajímá... nedávno jsem se nechal zaměstnat u Google.
Tuto změnu zjevně učinil především kvůli nalezení pracovního prostředí, které mu více vyhovuje; z hlediska vývoje jádra se neočekávají žádné změny.
A konečně, Greg Kroah-Hartman oznámil změnu podpory 2.6.16:
Adrian [Bunk] převezme jadernou větev 2.6.16-stable a bude ji spravovat, jak dlouho bude chtít.
Bude se držet -stable pravidel zdokumentovaných v souboru Documentation/stable_kernel_rules.txt, ale postará se o strom 2.6.16 o hodně delší dobu, než je stávající stable tým ochoten mu věnovat (my jsme se přesunuli k verzi 2.6.17).
Adrian oznámil své rozhodnutí spravovat toto jádro dlouhodobě už v počátcích vývojového cyklu 2.6.16. Bude zajímavé sledovat, jak se situace vyvine; příprava důležitých patchů pro 2.6.16 bude čím dál těžší úměrně s tím, jak se bude hlavní jádro vzdalovat. Dlouhodobý úspěch projektu může záviset na tom, jestli distributoři takové jádro využijí - a pomohou tak s jeho údržbou.
Grand Unified Flow Cache
link
Grand Unified Flow Cache [velká sjednocená průtoková keš] je jednou z položek, které se objevují na programech prezentací síťovacích summitů; síťaři asi vědí, co to znamená, ale jsou poněkud laxní, co se vysvětlování toho nápadu týče. Tento koncept se vynořil v souvislosti s diskuzí o síťových kanálech a bylo učiněno množství náznaků, které mi - neb se nebojím vyvozovat mnohé z mála [Jonathan Corbet] - přiblížily význam toho termínu. Kdyby byla implementována, GUFC by znamenala významné změny pro celý síťový stack.
Koncept síťových kanálů vyžaduje, aby jádro dokázalo rychle určit cíl každého paketu a hodit jej do správného kanálu. Ještě lepší by bylo, kdyby tuto klasifikaci provedl chytrý síťový adaptér při přijetí paketu, takže by z této části akce bylo jádro úplně vynecháno. Jedním ze způsobů, jak tuto klasifikaci provést, by bylo vytvořit z každého paketu tuple [sada údajů] a ten pak použít jako vyhledávací klíč v nějaké rychlé datové struktuře. Jakmile je v této struktuře (průtokové keši) tuple paketu nalezen, je o jeho osudu rozhodnuto a může být rychle vyprovozen tam, kam má jít.
Tento tuple, jak jej popisoval Rusty Russell, by tvořilo sedm parametrů:
- Zdrojová IP adresa.
- Cílová IP adresa.
- Bit indikující, jestli jde o lokální zdroj.
- Bit indikující, jestli jde o lokální cíl.
- Číslo IP protokolu.
- Zdrojový port.
- Cílový port.
Tato čísla jsou dohromady dostatečná k určení spojení, ke kterému každý paket patří. Rychlé vyhledání příchozího paketu by tedy mělo zjistit rozumný cíl (například síťový kanál) bez dalšího zpracovávání.
Funkce jako netfilter však tento pěkný obrázek kazí. Netfilter je v rámci jádra nastaven tak, že je každý paket strčen do příslušného řetězce. Když musí každý paket projít stejnou trasou, je výhoda GUFC pryč. Rusty problém popisuje takto:
Chybou (?) netfilteru je, že je úplně obecný: uvidíš všechny pakety, dělej si s nimi, co chceš. Kdybychom místo toho vyžadovali, aby byla všechna pravidla typu "ukaž mi všechny pakety, které odpovídají tomuto tuple", měli bychom možnost to zkombinovat do jediného vyhledání společně s routováním atd.
Takže řešením by bylo změnit API netfilteru tak, aby lépe spolupracovalo s GUFC. Pravidla by mohla být psána podle vzoru výše uvedeného tuple (s povolenou hvězdičkovou konvencí) a pouze pakety, které by odpovídaly tuplům, by musely projít (pomalou) trasou přes netfilter. To by umožnilo paketům, které filtrovací kód nezajímají, celý mechanismus obejít - a takové rozhodnutí by mohlo být učiněno na základě jediného vyhledávání.
Často by však bylo možné rozhodnout i filtrování paketu přímo na základě tuplu - jak jednou paket tuplu odpovídá, není nutné jej vyhodnocovat ještě s ohledem na pravidlo. Takže když by například kód pro sledování spojení povolil založení nového spojení a tuple popisující takové spojení by byl přidán do keše, nebylo by už pro toto spojení potřeba žádného filtrování. Kdyby netfilter a průtoková keš fungovaly dohromady, šlo by v mnoha případech eliminovat režii spojenou se zpracováním každého paketu.
Jeden ze způsobů, jak zařídit, aby to fungovalo, by bylo mít sadu zpětných volání, která by byla volána pro každý tuple přidaný do průtokové keše. A modul jako netfilter by mohl tuple prohlédnout s ohledem na aktuální sadu pravidel a dát jádru vědět, jestli potřebuje zkoumat pakety, které tuplu odpovídají. Pak by mohly být pakety nasměrovány k příslušným filtrům bez nutnosti využívat v keši tuplů hvězdičkovou konvenci.
Celé to má jedno malé mínus:
Samozřejmě to znamená přepsání všech uživatelských nástrojů a dokumentace a vytvoření zcela nové infrastruktury pro sledování spojení a NAT. Ale jestli je to potřeba, tak ať.
Rustyho nikdy dříve podobné překážky nezastavily, takže na to všechno možná opravdu dojde.
Ale asi ne moc brzy. Zůstává hodně otázek, na které je potřeba odpovědět před vážným pokusem o implementaci. Jednou z nich je to, jestli by výkon byl skutečně takový, jak lidi doufají; takové plány mohou o dost zpomalit, jakmile se započítají všechny detaily, které provázejí skutečné nasazení. Aktualizace pravidel by mohla být obtížná; administrátor, který právě změnil pravidla filtrování paketů, nebude chtít trpělivě čekat, až se všechna nová pravidla propracují do keše. Není tak docela jasné, jak přinutit hardware, aby pomáhal s procesem klasifikace. A tak dále. Ale zdá se, že je tu dost zajímavých nápadů, což dříve či později povede k dobrým výsledkům.
Připojení Linuxu k hypervisorům
link
Paravirtualizace spočívá ve spuštění hostovaného operačního systému v rámci hostitelského systému, přičemž host byl portován na virtuální architekturu, která je téměř jako hardware, na kterém ve skutečnosti běží. Tato technika umožňuje spouštění plných hostovaných systémů poměrně efektivním způsobem. Nejznámější svobodnou implementací paravirtualizace zůstává Xen; mezi proprietárními to je VMware. Oba z těchto projektů by rády dostaly alespoň části svého kódu do jádra. Vývojáři však nechtějí začleňovat velkou hromadů háčků [hooks] specifických pro jediné řešení.
Jedním z pokusů o vyřešení tohoto problému je rozhraní VMI, které navrhuje VMware. VMI funguje na základě izolace všech operací, které by mohly vyžadovat zásah hypervisora, do speciální sady funkčních volání. Implementace těchto funkcí není zabudovaná v jádře; místo toho jádro při bootu natáhne "hypervisor ROM", která potřebné funkce poskytne. Binární rozhraní mezi jádrem a tímto natahovatelným segmentem je tesáno do kamene, což znamená, že jádra sestavená pro dnešní implementace budou fungovat stejně dobře i se zítřejšími. Tento design zároveň umožňuje, aby jediný binární obraz jádra fungoval s různými hypervisory, nebo - se správnou ROM - v nativním režimu přímo na holém hardwaru.
Pevné ABI a možnost natahovat do jádra "binární kusance" [blobs] se však mnoha vývojářům jádra nelíbí. Vypadá to jako další způsob, jak do jádra dostat proprietární kód, což je věc, kterou vývojáři nemají příliš v lásce. Kromě toho, jak říká Rusty Russell:
Správa ABI není naše silná stránka. A bylo by to vyloženě mizerné, kdybychom měli spravovat ABI, i když 99 % z nás by používalo nativní režim, takže bychom si chyb ani nevšimli.
Z tohoto a dalších důvodů nebyla dosavadní cesta VMI do jádra moc uhlazená. To však neodradilo Zachary Amsdena z VMware od snahy o protlačení rozhraní pro binární kód.
Proslýchalo se cosi o vývoji alternativního rozhraní pro hypervisory (nazývaném "paravirt_ops"). Raná implementace paravirt_ops byla do LKML poslána 7. srpna, což obrysy trochu objasnilo. Ukázalo se, že paravirt_ops je další struktura plná ukazatelů na funkce - stejně jako mnohé jiné operační struktury používané v jádře. V tomto případě jsou operacemi různé funkce, které většinou vyžadují reakci hypervisora. Jsou mezi nimi věci jako vypínání přerušení, změna kontrolních registrů procesu, změna mapování paměti atd.
Jako příklad poslouží jedna z funkcí v paravirt_ops:
void (fastcall *irq_disable)(void);
Patch také definuje malou funkci, kterou má využívat jádro:
static inline void raw_local_irq_disable(void)
{
paravirt_ops.irq_disable();
}
Dokud jádro používá pro vypínání přerušení pouze tuto funkci, použije se implementace, kterou poskytl hypervisor.
Patch obsahuje sadu operací pro nativní (nevirtualizované) systémy, což způsobí, že se jádro bude chovat jako dříve - či spíše to tak bude, až budou opraveny zbývající chyby. Takové jádro však může být o něco pomalejší, protože mnoho operací, které byly prováděny in-line kódem assembleru, jsou teď zajištěny nepřímým voláním funkce. Pro zmírnění nejhorších dopadů na výkon obsahuje patch paravirt_ops samopatchovací mechanismus k opravení některých volání funkcí - především těch, které se týkají přerušení.
Rozhraní vypadá dost jako VMI; obě umožňují náhradu důležitých nízkoúrovňových operací verzemi z hypervisoru. Rozdíl je v tom, že paravirt_ops je rozhraní založené na zdrojových kódech - nedává žádné záruky binárního rozhraní. Předpokládá se, že toto rozhraní se bude postupem času měnit stejně jako většina interních jaderných rozhraní. A vzhledem k tomu, že jde o relativně novou oblast, je možné, že paravirt_ops bude jistou dobu ještě více vrtkavé než bývá zvykem. V současné době také neexistuje možnost natahování operací za běhu, takže budou jádra muset být kompilována, aby fungovala s konkrétním hypervisorem.
Na první pohled tedy vypadá paravirt_ops jako konkurent VMI - je na vybranou mezi otevřeným, změnitelným jaderným rozhraním a binárním kódem s pevným ABI. Skutečnost se však má tak, že na paravirt_ops pracuje různorodá skupina vývojářů, včetně zástupců z Xen a, ano, VMware. Části kódu VMI si našly cestu do prvního vydání paravirt_ops. Všichni velcí hráči jsou za tímto vývojem - fakt, který velmi usnadní cestu do jádra.
Tak proč pořád chtějí vývojáři VMware binární rozhraní? Vypadá to, že zvažují vytvoření vrstvy spojující paravirt_ops s binárním rozhraním VMI. Tak by byli zcela zodpovědni za správu vlastního ABI, zatímco vývojáři jádra by se mohli po libosti vrtat v paravirt_ops. Někteří ze účastněných vývojářů by byli klidnější, kdyby bylo rozhraní VMI propojeno tímto způsobem - přesto zůstává určitá nedůvěra vůči možnosti linkování ne-GPL binárních modulů.
Vývojáři paravirt_ops by kód rádi dostali do jádra 2.6.19. To se zdá dost smělé vzhledem k tomu, že čas pro začleňování přijde za několik týdnů a v tuto dobu paravirt_ops ještě ani nepobylo v -mm. Jedná se však o funkci, která zcela zmizí, není-li zvolena při konfiguraci, takže to začlenění není tak docela vyloučeno.
Kód nejistého původu
link
Nedávno byla poslána sada patchů k začlenění do hlavního jádra. Tyto patche využívají (nedokumentovaný) "SMAPI" BIOS z notebooků Thinkpad pro podporu několika užitečných funkcí Thinkpadů. Vypadá to jako kód, který bývá vítán; zlepšování podpory hardwaru se obecně považuje za dobrou věc.
Je tu však jeden problém. Kód byl podepsán takto:
Signed-off-by: Shem Multinymous <multinymous@gmail.com>
Několik vývojářů rychle poukázalo na to, že taková informace je k ničemu, a že kódu podepsanému zjevným pseudonymem je těžko věřit dost na to, aby mohl do jádra. "Pan Multinymous" chtěl začlenění dosáhnout následujícími prohlášeními:
Tímto stvrzuji, že patch byl vyvinut výhradně na základě veřejných specifikací, sledování chování hardwaru pomocí metody pokus - omyl a specifikací, které mi byly zpřístupněny v čistém prostoru bez jakýchkoliv podmínek s tím spojených. Takže tento patch je stejně ryzí jako původní ovladač hdaps, který opravuje (a patrně ryzejší než mnoho jiných ovladačů), a ani jediný řádek není odvozenou prací z kódu $JINÝ_OS.
Autor kódu však odmítá prozradit svou identitu, takže ostatní vývojáři odmítají uvažovat o začlenění kódu. Pat by mohl rozlousknout Pavel Machek, který se nabídl, že kód podepíše. Jestli to bude stačit, to pravděpodobně rozhodne Linus, až se vrátí z cest.
Když se ví o SCO, není potřeba být ani moc paranoidní, aby si člověk představil, že by někdo mohl chtít jádro sabotovat pokusem o začlenění ilegálního kódu. Kdyby byl skutečný původ kódu odhalen po jeho rozšíření, mohlo by to z toho být spousta potíží pro vývojáře, distributory a možná i uživatele. Takže je dobře, že vývojáři odolávají pokušení začlenit kód od anonymních přispěvatelů. Epizoda se SCO světu ukázala, jak čistý kód jádra je; rádi bychom, aby takový zůstal.
To je všechno pěkné, ale těžko se vyhnout nepříjemnému pocitu, že kdyby byl tento kód poslán někým s normálně znějícím jménem, nebyl by tolik zkoumán. Kód přeci přichází ze všech koutů světa a nikdo nemá zdroje ani chuť k ověřování, zda ta jména patří skutečným lidem, kteří mají právo daným kódem přispět. Z toho důvodu jsou lidé, kteří posílají kód dokazující velké znalosti nedokumentovaného hardwaru, často tázáni, kde ty znalosti získali. Ověřování odpovědí však může být složité. Obranyschopnost je slabá, ale těžko si představit, jak ji posílit, aniž by byl proces úplně zadušen.
Anketa
Související články
Odkazy a zdroje
Další články z této rubriky
Diskuse k tomuto článku
22.8.2006 11:02
tomaso
Ad anketa
22.8.2006 14:06
ajikdpoe | skóre: 23
| blog:
dvh
Re: Jaderné noviny - 9. 8. 2006
28.8.2006 16:56
zde | skóre: 9
| blog:
Linuch
| Brno
Re: Jaderné noviny - 9. 8. 2006
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
22.8.2006 09:49
vogo | skóre: 34
| blog: "Skládat papír"
Proto bych se v pripade neprekladani primlouval za "ta tuple".
Radek
22.8.2006 13:52