Portál AbcLinuxu, 24. dubna 2024 08:41
Aktuální verze jádra: 2.6.24-rc3. Aktuální verze jádra: 2.6.23.9. Citát týdne: Donnie Berkholz. Přiškrcení množství exportovaných symbolů. kmemcheck - kontrola neinicializované paměti. Aktualizace systémových volání: indirect(), timerfd(), hijack().
Aktuální předverze je (k 28. 11. 2007) i nadále 2.6.24-rc3. Opravy dále velmi rychle proudí do hlavního git repozitáře; 2.6.24-rc4 musí být na spadnutí.
Aktuální verze -mm stromu je 2.6.24-rc3-mm2. Mezi nedávné změny patří nové API timerfd (vizte níže), několik změn ovladačového jádra a aktualizovaná verze bezpečnostního modulu SMACK.
Aktuální stabilní verze řady 2.6 je 2.6.23.9, vydaná 26. listopadu. V této verzi je pár desítek důležitých oprav.
Starší jádra: 2.6.22.14 vyšlo 21. listopadu.
Linuxové jádro by potřebovalo, aby každou změnu doprovázela dokumentace -- část patche by vždy měla mířit do adresáře Documentation/.
Jaderný mechanismus pro nahrávání modulů neposkytuje modulům přístup ke všem částem jádra. Místo toho musí být každý symbol, který je určen pro použití natahovatelnými moduly, výslovně exportován prostřednictvím jedné z variant makra EXPORT_SYMBOL(). Smyslem tohoto omezení je limitovat dosah modulů a poskytnout relativně dobře definované modulové API. V praxi však exportování moc omezováno není, takže jsou modulům k dispozici tisíce symbolů. Natahovatelné moduly mohou přistupovat k mnoha symbolům, jejichž užitečnost je zjevná (třeba printk() nebo kmalloc()), ale dostanou se i k obecným symbolům typu edd, tpm_pm_suspend(), vr41xx_set_irq_trigger() nebo flexcop_dump_reg().
Některým vývojářům dělá přílišné exportování symbolů právem starosti. Chybně exportované symboly mohou vést autory modulů ke špatným rozhraním; například exportování sys_open() vývojáře aktivně ponouká k otevírání souborů přímo v jádře, což téměř nikdy není dobrý nápad. Ale jakmile jsou symboly jednou exportovány, může být těžké je přestat exportovat. Ačkoliv oficiální stanovisko zní, že interní jaderné API se může měnit kdykoliv, pravda je taková, že přinejmenším někteří vývojáři se zdráhají dělat problémy externím modulům, když se tomu dá vyhnout.
Jako aktuální příklad může posloužit init_level4_pgt - nízkoúrovňový symbol exportovaný pouze architekturou x86_64. Aktuální -mm strom ten export odstraňuje, kvůli čemuž přestává fungovat proprietární modul NVIDIA. Andrew Morton to odstranění popisuje jako fikaný způsob, jak zúžit počet testerů, abychom nedostávali tolik hlášení o chybách. Přestože mnoho vývojářů dává hlasitě najevo, že jim nezáleží na binárních modulech, i tak je dost velká pravděpodobnost, že tohle odstranění exportu (symbolu, který by opravdu neměl být globálně přístupný) kvůli zmiňovanému problému neprojde až do hlavního jádra.
Každopádně je už dlouho patrný zájem o pročištění modulárního API, i když se tomu zrovna moc lidí nevěnovalo. Čas od času někdo ukáže na některý ze snadných terčů: symbolů, které jsou exportovány jen proto, aby bylo možné modularizovat další kousky kódu hlavního jádra. Například celá sada symbolů TCP stacku (věci jako __tcp_put_md5sig_pool()), které mají přesně jednoho uživatele: modul IPv6. Omezení těchto jednoúčelových exportů by mohlo výrazně zeštíhlit modulární API, aniž by bylo těžší hlavní jádro modularizovat.
Andi Kleen navrhl patch implementující jmenný prostor pro modulové symboly, který by měl umožnit právě takové zeštíhlení. S tímto patchem mohou být symboly exportovány do specifických "jmenných prostorů", které jsou dostupné pouze schváleným modulům. Termín "jmenný prostor" v tomto případě zrovna moc nesedí; pořád bude jen jeden globální jmenný prostor, v rámci kterého budou muset být všechny exportované symboly unikátní. Tyto "jmenné prostory" jsou spíše speciální zóny, jež obsahují symboly, které nejsou globálně přístupné. Fungují jako pouze-GPL exporty, které omezují dostupnost symbolů určité podskupině modulů.
Pro vytvoření omezeného exportu je běžná deklarace EXPORT_SYMBOL() změněna na:
EXPORT_SYMBOL_NS(namespace, symbol);
Kde namespace je název omezeného jmenného prostoru. Takže když se vrátíme k příkladu s TCP, tak Andiho patch obsahuje množství změn jako:
-EXPORT_SYMBOL(__tcp_put_md5sig_pool);
+EXPORT_SYMBOL_NS(tcp, __tcp_put_md5sig_pool);
Všimněte si, že není žádná _GPL verze; všechny symboly exportované do konkrétního jmenného prostoru jsou automaticky brány jako pouze-GPL.
Druhou částí rovnice je umožnění přístupu ke jmennému prostoru. K tomu slouží:
MODULE_NAMESPACE_ALLOW(namespace, module);
Taková deklarace (jež se musí objevit v modulu, který exportuje symboly do namespace) říká, že daný module může přistupovat k symbolům v určeném jmenném prostoru. Andiho patch vytváří tři jmenné prostory (tcp, tcpcong pro moduly kontrolující zahlcení a udp), čímž z globálního jmenného prostoru odstraňuje asi 30 symbolů.
Řada vývojářů tento patch přivítala, protože v něm vidí krok vpřed ve snaze o racionalizaci API natahovatelných modulů. Je to také bráno jako způsob, jak externím modulům zamezit používání symbolů, které by používat neměly. Kromě toho se tím snižuje počet rozhraní, která musí být udržována stabilní v situacích, kde nejsou změny přípustné (například u enterprise jader). A konečně, jmenné prostory symbolů umožňují trochu exporty organizovat a dokumentovat, kdo je má používat.
Ne všichni však souhlasí. Především Rusty Russell má obavy, že patch věci zbytečně komplikuje a ztíží práci vývojářům externích modulů. Rusty:
Například když dáváš všechny udp funkce do jmenného prostoru "udp", co nám to přinese? Co bude jednodušší spravovat? Všechny ty funkce začínají na "udp_": dělá snad lidem potíže uhádnout, k čemu jsou určené?
Pokud chceš opravdu omezit "veřejná rozhraní", pak by bylo mnohem jednodušší přímo říct, co smějí externí moduly používat.
Herbert Xu to vidí podobně:
Ty symboly jsou exportovány proto, že je potřebují protokoly. Kdyby nebyly každému přístupné, bylo by těžké začít s psaním novým protokolů...
Takže přinejmenším s ohledem na ten síťový kód začínám spíš souhlasit s Rustym: je-li symbol využíván více než jedním modulem z jádra, je dost pravděpodobné, že budeme chtít, aby byl exportován pro všechny.
Ačkoliv se zdá, že tyto hlasy jsou v menšině, mají docela velkou váhu. Nechce se mi tedy hádat, jestli bude patch začleněn, a pokud ano, tak v jaké podobě. Dříve nebo později se však něco v této oblasti stane, protože snaha o pročištění modulárního API jen tak nezmizí.
Používání neinicializované paměti může vést k opravdu nepříjemným chybám. Když máte štěstí, tak jádro slítne a v tracebacku nechá rozluštitelnou stopu, která zaneřádila slab [slab poisoning] (0x5a5a5a5a nebo něco podobného). Jindy se však stane nějaká zakuklenější nepravost a budete nuceni dlouho hledat jednu hloupou chybu. Nebylo by lepší, kdyby jádro prostě umělo detekovat odkazy na neinicializovanou paměť a nahlas v tu chvíle zařvat?
Patch kmemcheck, který nedávno poslal Vegard Nossum, nabízí právě to - i když možná trochu těžkopádným způsobem. Jádro se zapnutou funkcí kmemcheck nebude asi vhodné pro produkční nasazení, ale mělo by dobře umět hledat paměť, která ještě nebyla nastavena na užitečnou hodnotu.
Kmemcheck je poměrně jednoduchý patch; používá následující přístup:
Je zřejmé, že provozování kmemcheck bude mít negativní vliv na výkon. Výpadek stránky při každém přístupu do paměti slabu prostě nemůže být rychlý. Zdvojnásobení velikosti každé alokace si také vezme svoje, včetně vlivu na keš, která bude muset pracovat s dvakrát tak velkým množstvím paměti. Ale když běží jádro v debugovacím režimu, tak se to dá vydržet.
Vegard poslal ukázkový výstup, který ukazuje, jak systém reaguje na čtení z neinicializované paměti. Dá-li se tomu výstupu věřit, tak přistupování k neinicializované paměti není v současných jádrech nic exotického. Pokud se ukáže, že některé z odkazů, na které teď bylo upozorněno, jsou opravdu chyby, tak už se kmemcheck osvědčil, i kdyby si nikdy nenašel cestu do hlavního jádra.
Když se minulý týden diskutovalo o navrhovaném systémovém volání indirect(), stěžovali si někteří vývojáři, že je to opravdu nepěkné rozhraní. Od té doby se diskuze přenesla na rozhraní systémových volání obecně, ale moc nápadů, jak vylepšit indirect(), z toho nevzešlo.
Zatím vede alternativa, kterou navrhoval H. Peter Anvin: raději než k rozšiřování systémového volání používat indirect(), to je lepší prostě vytvořit nové volání s požadovanými parametry. Pak může být většinou stará implementace nahrazena jednoduchým kouskem kódu, který volá novou verzi s výchozími hodnotami u nových parametrů. Je to jednoduchý přístup, který snadno zachovává binární kompatibilitu, aniž by měl za běhu velkou režii. Protože čísel systémových volání je dostatek, mohlo by se takto postupovat ještě dlouho.
Správa zvyšujícího se počtu systémových volání však něco stojí; každé z těch systémových volání je součástí uživatelského API, které už musí fungovat navždy. indirect() nová systémová volání nepřidává. Za předpokladu, že budou parametry přidávány opatrně (s výchozími hodnotami nula), pak by mělo být celkem snadné se vyhnout potížím s API.
Existují však omezení toho, kolik parametrů lze k systémovým voláním přidat; na většině systémů se to pohybuje kolem šesti. Pokud chce nějaké systémové volání více parametrů, musí se pouštět do nepříjemností s nepřímými bloky. Vytváření nových systémových volání s dodatečnými parametry zvýší počet případů, ve kterých bude toto nepřímé zpracování parametrů potřeba. Takže přístup využívaný voláním indirect() bude nakonec stejně v nějaké podobě nasazován.
Klíčovým argumentem je však stále mechanismus sysletů/threadletů. Možnost udělat z kteréhokoliv volání asynchronní volání je velmi lákavá, ale aby to šlo provést, jsou potřeba ještě nějaké další informace - přinejmenším místo, kam výsledek volání uložit. Asynchronní systémová volání v Linuxu jsou, z praktického hlediska, druh nepřímého volání. Navrhované rozhraní indirect() vypadá, že by mohlo být pro asynchronní volání dobře využito - i když přesné API ještě nebylo stanoveno.
V důsledku toho je pravděpodobné, že se indirect() v nějaké podobě nakonec do jádra dostane - přesto je však ještě dost času na to, aby někdo přišel s lepším nápadem.
Když se tu naposled mluvilo o timerfd(), bylo právě vypnuto v jádře 2.6.23 kvůli stížnostem na své rozhraní. Od té doby se toho moc nestalo, takže téměř určitě nebude ani v 2.6.24. Přesto se však na tomto systémovém volání pracovalo a byl představen návrh nového API. Tato verze má tři systémová volání, z nichž první je timerfd_create():
int timerfd_create(int clockid, int flags);
Parametr clockid systému říká, které hodiny se mají použít: CLOCK_MONOTONIC nebo CLOCK_REALTIME. Parametr flags byl přidán nedávno; v současné době se však nepoužívá a musí být nula. Je tam kvůli předpokladu, že někdo někdy bude chtít chování nějak upravit, takže je lepší se vyhnout potřebě nepřímé verze, dokud to jde. Návratová hodnota z timerfd_create() je popisovač souboru, který je možné předat funkci read() nebo kterékoliv variantě poll(). Nejprve by však měl být časovač asi naprogramován pomocí:
int timerfd_settime(int fd,
int flags,
const struct itimerspec *timer,
struct itimerspec *old_timer);
fd je popisovač souboru získaný z timerfd_create(). Je-li časovač nastaven na absolutní čas, pak flags obsahuje TFD_TIMER_ABSTIME. A timer je doba vypršení časovače. Pokud old_timer není NULL, tak bude umístění, na které je ukazováno, nastaveno na předchozí hodnotu časovače.
Hodnotu časovače je také možné získat pomocí:
int timerfd_gettime(int fd, struct itimerspec *timer);
Hodnota vrácená v *timer bude aktuální nastavení časovače přiřazeného k fd.
Tato nová verze API nebyla moc komentována, takže bude asi začleněno něco podobného. Normálně už by bylo příliš pozdě na přidání změny do 2.6.24, ale log patchů v 2.6.24-rc3-mm2 říká "Asi 2.6.24?". Takže jeden nikdy neví. Pokud to nebude začleněno brzy, skoro určitě se to dostane do 2.6.25.
Systémové volání hijack() je i nadále vyvíjeno v rámci relativně tichých konferencí jaderných subsystémů. Toto volání se chová podobně jako clone() v tom smyslu, že vytvoří nový proces. Na rozdíl od clone() však hijack() způsobí, že nový proces sdílí zdroje s určeným třetím procesem, místo s předkem. Existuje hlavně proto, aby bylo snadné vstupovat do různých jmenných prostorů.
Rozhraní hijack() je skoro beze změny:
int hijack(unsigned long clone_flags, int which, int id);
Zadaná hodnota id je interpretována podle which, který má tři možné hodnoty:
Toto nové systémové volání vůbec nebylo představeno na linux-kernel; je dost možné, že v současné podobě tam svůj první výstup nepřežije. Přinejmenším bude asi požadována změna názvu (na něco trochu více popisného, co by, pokud možno, nezpůsobilo, že se uživatelé objeví na seznamu podezřelých osob výzvědných služeb). Je však zřejmé, že plná implementace kontejnerů v Linuxu bude jednou potřebovat nějaké systémové volání enter_container().
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.