Portál AbcLinuxu, 27. dubna 2024 19:36
Aktuální verze jádra: 2.6.22.1. Citáty týdne: Linus Torvalds, Kay Sievers, Rafael Wysocki. Začleněno do 2.6.23. Autentizace a autorizace USB zařízení. Další pokus o software suspend.
Během posledního týdne nevyšly žádné nové verze. Začleňování do 2.6.23 stále probíhá a do hlavního repozitáře se valí další patche; vizte níže.
Já si jen moc a _moc_ přeji, abychom měli dvě stabilní verze za sebou. Mám pocit, že 2.6.22 má dobrý potenciál a nerad bych měl hned potom další 2.6.21.
Sysfs se nikdy nesnažil být ABI/API v běžném slova smyslu - některé části jsou jen trochu hezčí "kernel dump" :)
Musíte se tam řídit _velmi_ specifickými pravidly, abyste získali informace způsobem, který v další verzi jádra, nebo dokonce o vteřinu později, nepřinese neočekávané výsledky.
-- Kay Sievers
Podle mého názoru je každý hibernační systém, který nebere ohled na uvedené požadavky, odsouzen k neúspěchu. Navíc se některými z nich neřídí ani existující systémy, takže je všechny považuji za nedokončené. Z toho důvodu bych daleko více uvítal nápady, které by nám umožnily, více či méně evolučním způsobem, vylepšit stávající systémy, místo pokusů o jejich celkové nahrazení něčím úplně novým.
Od minulého týdne bylo do repozitáře hlavního jádra zařazeno dalších 2600 sad změn. Začíná být jasnější, jak bude 2.6.23 vypadat; jádro bude obsahovat:
Změny viditelné vývojáři jádra:
char *kstrndup(const char *s, size_t max, gfp_t gfp);
Duplikuje řetězec podobně jako strndup() v uživatelském prostoru.
Za zmínku stojí i pár věcí, které v 2.6.23 nebudou. První z nich je patch s kontejnery procesů - ještě není tak docela hotový. Některé další funkce (například skupinové plánování CFS) na kontejnery procesů čekají, takže je pravděpodobné, že bude kód připraven pro začlenění v 2.6.24.
Další velká věc, na kterou se nedostane, jsou clockevents, dynamický tik a časovače s vysokým rozlišením pro x86_64. Autoři už patch považují za připravený, ale po potížích, které způsobilo začlenění verze pro i386 v 2.6.21, mají někteří vývojáři pocit, že by se tentokrát mělo postupovat opatrněji. Výsledkem byla poněkud otrávená diskuze v konferencích a rozhodnutí patche lépe rozdělit, aby mohly být pečlivě prohlédnuty v rámci dalšího vývojového cyklu.
Zařízení universal serial bus (USB) [univerzální sériová sběrnice] obyčejně nepodléhají nějakým bezpečnostním opatřením. Může-li uživatel USB zařízení strčit do počítače, předpokládá se, že je oprávněn to udělat. Existují však situace, ve kterých přidělává zapojování USB zařízení lidem vrásky; obvykle se jedná o strach z kopírování obchodních tajemství na nějaké USB zařízení, které lze z budovy snadno odnést. Většinou se takové hrozby řeší zákazem (nebo pokusem o zákaz) USB zařízení nebo prostě zapatláním USB portů lepidlem.
Bezdrátové USB situaci mění. Tento protokol umožňuje vzdálené připojení USB zařízení, takže není potřeba mít kabel, o který všichni zakopávají. Zatímco běžný uživatel notebooku by si pravděpodobně všiml, kdyby mu útočník zastrčil do USB portu kabel od svojí klávesnice, v případě využití bezdrátového USB by mohl útočník klávesnici připojit, aniž by se přiblížil. Je zřejmé, že je potřeba nějaká bezpečnostní vrstva. Specifikace bezdrátového USB tuto potřebu předvídala, takže nabízí celou řadu technik s množstvím zkratek pro zajištění 1) autentizace jak hostitele, tak zařízení a 2) dostatečného šifrování bezdrátové USB komunikace, aby nemohla být odposlouchávána.
Iñaky Perez-Gonzalez pracuje na podpoře bezdrátového USB pro Linux. Došel k závěru, že nehezké detaily autentizace bezdrátového USB patří do uživatelského prostoru; jádro nemůže (samo o sobě) udržovat přehled o tom, která zařízení se smějí k systému připojit. Je však na jádře, aby implementovalo autorizační stranu rovnice: neautorizované bezdrátové USB zařízení by nemělo mít možnost s hostitelským systémem jakkoliv komunikovat. Iñakyho odpověď na otázku autorizace je tato sada patchů pro subsystém USB.
Patche přidávají do struktury usb_device tři nové příznaky: wusb, authorized [autorizované] a authenticated [autentizované]. První značí, že se jedná o bezdrátové zařízení, a poslední (který ještě není používán) říká, že zařízení prošlo autentizací. Prostřední ukazuje, že se smí se zařízením mluvit. Dokud není zařízení autorizováno, nepřečte si jádro ani jeho konfiguraci (aby zjistilo, jaké styčné body poskytuje); v tu chvíli může dojít pouze k autentizaci. Kvůli tomu jsou různá místa v USB stacku změněna, aby kontrolovala příznak authorized, než povolí přístup.
Uživatelský prostor je do obrazu uveden pomocí obvyklého oznámení o připojení zařízení a vytvoření příslušného sysfs stromu. Sysfs adresáře jednotlivých USB zařízení mají nový atribut authorized, který odpovídá internímu příznaku; uživatelský prostor může povolit přístup k zařízení zapsáním nenulové hodnoty do atributu. Taková infrastruktura postačuje k tomu, aby si mohl nějaký uživatelský démon všimnout nového bezdrátového USB zařízení, projít databázi známých zařízení a případně uživateli předhodit dialogové okno - a rozhodnout se, jestli by mělo být zařízení povoleno se připojit nebo ne.
Iñaky posunul věci ještě o krok dál, když si uvědomil, že tento autorizační mechanismus nemusí být omezen jen na bezdrátová zařízení; ve skutečnosti může být využit k tomu, aby se nějakému správcovskému kódu umožnilo rozhodovat o kterémkoliv USB zařízení. Administrátor může nakonfigurovat sadu příznaků authorized_default; pokud se prostě nastaví výchozí hodnota na nulu, bude zamítnuto připojení všech nových zařízení, ať už bezdrátových nebo jiných.
Komplexnější implementace by mohla povolovat připojení jen některým druhům zařízení. Klávesnice a myši by mohly být přijatelné, ale cokoliv, co by mohlo ze systému brát data - třeba úložná zařízení nebo tiskárny - by bylo zakázáno. Nebo by mohla být úložná zařízení povolena, ale pouze za předpokladu, že by obsahovala nějaký řádně podepsaný certifikát, který by hostitelský systém ověřil. Existuje množství zajímavých možností. Výsledné zabezpečení nebude tak odolné jako ucpané porty nebo úplné odstranění podpory USB, ale mohlo by to být právě to, co je na některých místech potřeba.
Je to poměrně jednoduchá sada patchů, která přidává zajímavé možnosti. Zbývá ještě dodělat hodně té obtížné práce - autentizaci a šifrování - ale to je práce pro uživatelský prostor. Iñaky požádal o začlenění do 2.6.23; pro v podstatě netestovaný kód je však trošku pozdě. 2.6.24 se zdá pravděpodobnější.
V roce 2006 probíhala živá debata o budoucnosti softwarového uspávání (na disk) - a pokračuje až do dnes. Andrew Morton do toho tenkrát skočil s návrhem na jiný přístup:
Pokud chcete můj vesele neinformovaný názor, tak já myslím, že bychom je měli všechny vyhodit a implementovat suspend3, který by byl založen na infrastruktuře kexec/kdump. Máme tu tolik duplicitní práce, až to už ani není vtipné. A když jsou takhle oddělené, tak to oba přístupy zeslabuje tam, kde jsou opravdové problémy: v oblasti ovladačů.
O 18 měsíců později to vypadá, že bychom přeci jen mohli mít "suspend3" - Ying Huang poslal patch kexec jump.
Yingův patch staví na existující funkci kdump. Účelem kdump je poskytnout bezpečné a užitečné crash dumpy [výpisy informací o pádu] v situacích, kdy je stav systému nejistý. Pokud systém zpanikaří, je fajn mít možnost uložit aktuální stav pro posmrtné debugování. Je však důležité, aby chybující jádro, kterému se v tu chvíli nedá věřit, nebylo používáno k provádění nebezpečných věcí - třeba zapisování crash dumpu na disk. Aby se tomu předešlo, vloží se do rezervované oblasti paměti malé "dump jádro", kde většinu času vyčkává, aniž by si ho někdo všímal nebo bylo potřeba. Dojde-li k panice, provede se volání kexec(), které převede kontrolu na dump jádro. Dokud zůstává dump jádro v rezervované oblasti paměti, bude schopno zapsat zbytek systémového stavu na disk (nebo jinam) poměrně bezpečně.
Minulý rok si Andrew všiml, že suspend-to-disk (které se pomalu přejmenovává na hibernaci) dělá v podstatě totéž: je zastavena činnost systému a aktuální stav je zapsán na disk. Pokud by dump jádro mohlo načíst stav zpět do paměti a vrátit kontrolu původnímu jádru, mohlo by hibernovat (a probudit) systém. Implementace v tomto duchu by měla výhodu ve sjednocení většiny kódu kdump a hibernace, což by umožnilo koncentraci vývojářského úsilí a obecné zjednodušení. Navíc by pak bylo možné odstranit současný kód, který není zrovna moc oblíben - navzdory mnohaletému pobytu v jádře.
Aktuální kód zatím tohle všechno neumí; je to jen první krok: umožňuje skok na původní jádro. Kód je poměrně jednoduchý; ačkoliv spoléhá na většinu existující infrastruktury, aby mohl řádně uspat a vypnout všechna zařízení při přípravě ke skoku oběma směry. Takže pokud ovladač zařízení nespolupracuje s hibernací, problém bude přetrvávat i v implementaci pomocí kexec. Ale spousta dalšího hibernačního kódu, včetně pomlouvaného zmrazovače procesů, by už nebyla potřeba a mohla by být odstraněna.
Než se však vezme kudla na stávající hibernační kód, je potřeba dořešit několik detailů. Vypínání zařízení při přechodu mezi těmi dvěma jádry není vlastně nutné ani žádoucí; musí být pouze v tichém "hibernačním" stavu. Kdump jádro musí být umístěno v rezervované oblasti paměti od počátku; snažit se ho natáhnout v okamžiku paniky už by bylo příliš pozdě. Jádro používané pro hibernaci však nemusí být v paměti celou dobu, takže je potřeba nějaký systém, který umožnil vyžádat natažení sekundárního jádra. Vlastní ukládání a obnovování obrazu systému ještě není implementováno - to se však dá snadno udělat v uživatelském prostoru, aniž by bylo potřeba podpory ze strany jádra. Dá však práci dostatečně zrychlit proces obnovy - uživatelům by se asi nelíbilo čekat, až nabootují dvě jádra, než budou moci používat svůj systém. A tak dále.
Jinými slovy, kexec hibernaci nečekejte nijak brzy. Počáteční reakce na tento přístup byly příznivé; zdá se, že se hodně lidem líbí představa nového začátku v této oblasti. Něco z tohoto odhodlání možná vyprchá časem, až se ukáže, že i s novým přístupem je hibernace složitý a poněkud obskurní problém. Jen čas ukáže, jestli z tohoto kódu vzejde lepší implementace.
Vzhledem k tomu, že Jeremy na kerneltrap.org zjevně chytil nějaký druhý dech a rozjel vydávání článků v míře dosud (nebo alespoň za poslední dva roky) nevídané, tak už jich je pro přidávání do Jaderných novin moc. Mnohé z nich jsou sice o věcech, které už byly v LWN (a tedy i v JN) popisovány podrobněji, ale i tak zůstává v průměru skoro jeden článek na den, což už by jednotlivé díly JN neúnosně natáhlo. (Shodou okolností jsem si to uvědomil jen pár dní po té, co jsem v diskuzi prohlásil, že všechny články z kerneltrap.org do JN dávám...)
Proto vkládám do tohoto článku anketu, ve které vás nechám rozhodnout, jak s tím přívalem novinek v Jaderných novinách zacházet.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.