Jaderné noviny - 8. 8. 2007

16. 8. 2007 | Robert Krátký

Články - Jaderné noviny - 8. 8. 2007  

Aktuální verze jádra: 2.6.23-rc2. Citáty týdne: Linus Torvalds, Jeff Garzik. Spoušť po spouštěcích bodech. Smack: zjednodušená kontrola přístupu. Novější, novější NAPI.

Obsah

• Aktuální verze jádra: 2.6.23-rc2
• Citáty týdne: Linus Torvalds, Jeff Garzik
• Spoušť po spouštěcích bodech
• Smack: zjednodušená kontrola přístupu
• Novější, novější NAPI

Aktuální verze jádra: 2.6.23-rc2

Aktuální předverze je (k 8. 8. 2007) 2.6.23-rc2, vydaná 3. srpna. Linus: Snažil jsem se tedy omezit začleňování na vyhrazené období a několik žádostí jsem odmítl. Ale přesto se rozmáhá představa, že '-rc2 je nová -rc1' - a nejenže má -rc2 zpoždění, ale je i větší, než by měla být. Kromě spousty oprav přibyla i rozsáhlá dokumentace ke kódu Lguest, mechanismus, pomocí kterého může jaderný kód požádat o upozornění, má-li na něj být uplatněna preempce, nové konfigurační možnosti pro softwarové uspání a hibernaci a podpora framebufferu u AMD Geode LX. Kromě toho byla odstraněna podpora procesorů SuperH sh73180 a 7300 a zmizel i celý port pro arm26. A změna API pro kontrolu zahlcení TCP. Podrobnosti najdete v krátkém a dlouhém changelogu.

Od vydání -rc2 bylo do hlavního repozitáře zařazeno dalších asi 50 sad patchů.

Aktuální stabilní jádro řady 2.6 je i nadále 2.6.22.1. V tuto chvíli probíhá kontrola aktualizace 2.6.22.2, která by mohla vyjít už 9. srpna. Obsahuje 84 oprav problémů ze všech částí stromu.

Starší jádra: 2.6.21.7 bylo vydáno 4. srpna se slušnou řádkou důležitých oprav.

Citáty týdne: Linus Torvalds, Jeff Garzik

Vůbec nepochybuji o tom, že je virtualizace v některých oblastech užitečná. Mám však silné pochybnosti o tom, že by někdy měla takový dopad, jak doufají lidé, kteří se virtualizací zabývají. Připadá mi, že virtualizace je "mikrojádro" tohoto desetiletí, a že lidé jen těžko akceptují důvod, proč operační systémy vypadají už skoro 40 let téměř úplně stejně: je to prostě velmi praktické!

-- Linus Torvalds

V Linuxu nikdy nečekáme, že bude ovladač fungovat jen proto, že ho výrobce otestoval. Desetiletí zkušeností DOKAZUJE pravý opak - časné a časté vydávání kódu opakovaně odhaluje problémy, které se při testech u výrobce neprojevily.

-- Jeff Garzik

Spoušť po spouštěcích bodech

Současné procesory mají zajímavý problém: pokud jsou delší dobu provozovány na plný výkon, hrozí jim vážné nebezpečí zahřátí na takovou úroveň, že by se z nich mohlo začít kouřit a neběžely by už nikdy. Aby se tomu předešlo, jsou procesory (a další komponenty) vybaveny teplotními čidly. BIOS pro čidla programuje určité "spouštěcí stupně" [trip points] - teploty, při kterých se stane něco, co zabrání přehřátí systému. Při dosažení daného spouštěcího stupně může systém zapnout větrák, přiškrtit procesor nebo, je-li katastrofa na spadnutí, se úplně vypnout.

Linuxový ACPI subsystém umožňuje prohlížení těchto spouštěcích bodů; příslušné virtuální soubory najdete v /proc/acpi/thermal_zone. Na mém notebooku je například nastaveno přiškrcení procesoru při 86°C a vypnutí při 91°. ACPI kód tradičně nabízel uživatelům s dostatečnými právy možnost měnit spouštěcí body zápisem nových hodnot do odpovídajících /proc souborů. Tato funkce však byla v jádře 2.6.22 odstraněna.

Uživatelé si teď na změnu začínají stěžovat. Mají pocit, že na některých systémech nastavuje BIOS spouštěcí body špatně, takže pak systém běží pomaleji, než by měl, větráky se spouštějí, když to není potřeba atd. Připadá jim tedy, že kvůli odstranění možnosti přenastavit spouštěcí body fungují jejich stroje hůře.

Správce ACPI Len Brown reaguje tak, že možnost přenastavení má několik nevýhod. Hlavní z nich je fakt, že systém ve skutečnosti nemůže změnit hardwarové spouštěcí body. Může je pouze vypnout. Pak musí práci převzít procesor a dotazovat se na teplotu sám; a případně reagovat, pokud je dosaženo některého ze softwarových spouštěcích bodů. Pokud by z nějakého důvodu dotazování a/nebo reakce neproběhly, existuje reálná možnost, že bude hardware poškozen. Potíže mohou také nastat při špatném nastavení spouštěcích bodů, což pak vede k nářkům typu "Linux mi zničil notebook" na internetových fórech.

Navíc může spouštěcí body kdykoliv změnit BIOS, který může mít své vlastní důvody. Mnohé z případů, kdy se hodí přenastavení spouštěcích bodů (např. ovládání větráků), je lepší řešit démonem v uživatelském prostoru. A navíc to většinou (Len by řekl vždy) bývá tak, že je přenastavování spouštěcích bodů nevhodnou reakcí na problémy, které by bylo lepší napravovat jinde. Když se o věci diskutovalo v květnu, shrnul situaci takto:

Skutečnost, že lze spouštěcí body zapisovat, spíše zamlžila než osvětlila opravdové příčiny problémů. 4 lidé v tom hlášení o chybě nakonec uvedli, že odstranění prachu z větráků jejich problém vyřešilo. Několik dalších řeklo, že problémy zmizely, když přestali používat šetřícího démona z Ubuntu.

Pár dalších má potíže s ovládáním aktivního větráku - což se však přenastavením spouštěcích bodů také spíše zamaskuje než objasní.

Zbývající problémy se, podle Lena, pravděpodobně neprojevují, když na dotyčném hardwaru běží Windows. A Windows téměř určitě se spouštěcími body nehýbe. Vyplývá z toho, že Linux na těchto systémech dělá něco se správou teploty špatně. Daleko raději by našel a opravil původní problém, místo aby se schovával přenastavovávím spouštěcích bodů.

Len tvrdí, že se ještě neobjevilo žádné hlášení o chybě, které by naznačovalo, že se má Linux takhle ve spouštěcích bodech vrtat. To je jasná výzva pro každého, komu možnost přenastavování chybí: pošlete odpovídajícím způsobem podloženou zprávu o problému, který tato funkce řeší. Pokud se doopravdy ukáže, že je přenastavování potřebné, možná se vrátí - ale také by mohla být místo toho prostě začleněna oprava samotného problému.

Smack: zjednodušená kontrola přístupu

SELinux poskytuje komplexní bezpečnostní řešení, ale je velký a komplikovaný. Mnohem jednodušší přístup volí Simplified Mandatory Access Control Kernel (Smack) [jádro se zjednodušenou povinnou kontrolou přístupu], patch, který do LKML poslal Casey Schaufler. Podobně jako SELinux, i Smack implementuje Mandatory Access Control (MAC), ale záměrně vynechává kontrolu přístupu založenou na rolích a vynucování typů, které jsou zásadními součástmi SELinuxu. Smack je určen pro řešení menších bezpečnostních problémů než SELinux a vyžaduje také mnohem méně konfigurace a podpory ze strany aplikací.

Smack administrátorovi umožňuje definovat značky [labels] pro objekty jádra dlouhé 1 - 7 znaků. Značky na objektech jsou porovnávány se značkami úlohy, která se k nim snaží přistupovat. Ve výchozím nastavení je přístup povolen pouze za předpokladu, že se značky shodují. Sada značek vyhrazených pro Smack se řídí jinými pravidly, takže většina systémových objektů a procesů není omezeními Smacku nijak ovlivněna. Smack se neplete operačnímu systému do cesty, a administrátor se tak může soustředit jen na uživatele a procesy, které chce zabezpečit.

Smack používá k ukládání značek u souborů rozšířené atributy souborového systému; administrátoři značky nastavují pomocí příkazu attr. Atribut security.SMACK64 se používá k uložení Smack značky na každém souboru, takže nastavení /dev/null tak, aby mělo Smack "hvězdičku", by vypadalo takto:

    attr -S -s SMACK64 -V '*' /dev/null

U sítí se pro nastavení CIPSO značek a domén interpretace pro sokety používá NetLabel, což systémům se Smack umožňuje fungovat v těchto striktně kontrolovaných prostředích.

Administrátor sice může přidávat pravidla, ale neexistuje podpora hvězdičkové konvence [wildcards] nebo regulárních výrazů; každé pravidlo musí doslova specifikovat značku subjektu i objektu a jestli je přístup povolen. Přístupové typy jsou velmi podobné tradičním unixovým rwx bitům, ke kterým přibyl bit a pro append [připojit]. Pro konfiguraci používá Smack techniku SELinuxu - připojitelný souborový systém: smackfs. Obyčejně je připojen do /smack, kde pak jsou k dispozici různé soubory, do kterých můžete zapisovat a ovládat tak provoz Smacku. Například přístupová pravidla jsou v /smack/load; pro změnu pravidel stačí prostě zapsat novou sadu přístupových práv pro daný pár subjekt-objekt.

Jeden z mnoha příkladů nabízených s patchem používá standardní bezpečnostní úrovně známé z vládních dokumentů. Pro každou úroveň jsou definovány Smack značky: Unclass pro nedůvěrné, C pro důvěrné, S pro tajné a TS pro přísně tajné. Pak je s pomocí několika pravidel definována tradiční přístupová hierarchie:

        C        Unclass       rx
        S        C             rx
        S        Unclass       rx
        TS       S             rx
        TS       C             rx
        TS       Unclass       rx

Vzhledem k výchozímu nastavení Smacku bude moci Unclass přistupovat pouze k datům se stejnou značkou, zatímco TS bude smět na základě výše uvedených pravidel přistupovat k S, C a Unclass.

Pravidla nejsou nijak přenosná. Že S může přistupovat k C a TS může přistupovat k S, to neznamená, že TS by mohlo přistupovat k C. Takové pravidlo musí být výslovně uvedeno. A protože nebyla udělena žádná práva k zápisu, mohou úlohy ze všech úrovní zapisovat jen data se svojí vlastní značkou. Tajné úlohy tedy zapisují tajná data atd. Soubory zdědí značku úlohy, která je vytvořila, přičemž Smack se postará o to, aby byl nastaven atribut. Značku si ponechají, dokud nebude přímo přenastavena administrátorem pomocí příkazu attr.

Patchovaná verze sshd je k dispozici na Schauflerově domácí stránce - administrátorům umožňuje přiřadit značky uživatelům. Takové značky jsou nastaveny i pro uživatelův shell a terminálové zařízení, když se přihlásí do systému - to uživatele přinutí se řídit pravidly přiřazenými k jejich značce. Nabízena je i opatchovaná verze ls, která umí zobrazovat značky připojené k souborům.

Smack se hodí pro omezování přístupu uživatelů a specifických procesů k různým zdrojům - není zamýšlen pro tak obecné použití jako SELinux. Sestavení sady značek a pravidel pro systémové procesy, síťové služby apod., aby se omezil přístup podobně jako u SELinuxu, by nebylo možné. Pro administrátory, kteří potřebují tyto služby zabezpečit, je SELinux pravděpodobně lepším nástrojem. Ale pro jednoduché rozškatulkování může Smack dobře vystačit.

Novější, novější NAPI

Minulý prosinec jsme se dívali na návrh k přepracování NAPI, které se používá pro příjem paketů v síťových ovladačích pro velkou šířku pásma. Od té doby prošlo rozhraní nějakými změnami, ale teď to vypadá, že se blíží své konečné podobě. Všichni správci NAPI síťových ovladačů budou muset přejít na nové API; v mnoha případech půjde o jednoduché změny, ale nové-NAPI nabízí i nové funkce, které by se mohly hodit u ovladačů komplikovaného hardwaru.

Základní myšlenkou NAPI je to, že na rušné síti nemusí být jádro upozorňováno pokaždé, když přijde síťový paket. Místo toho se může jádro čas od čas dotázat, protože ví jistě, že tam nějaké pakety budou čekat. Jonathan Corbet přerušení o přijetí paketu rád přirovnává k pípnutí, které jsme měli dříve všichni nastavené, aby nás upozornilo na nově příchozí email. Jen málokdo to ještě používá; můžeme si být jistí, že kdykoliv se podíváme, nějaký email tam najdeme. Podobně jako my, i jádro se obejde bez nepotřebného vyrušování; a to platí zvláště v situacích, kdy by se takové vyrušování mohlo projevovat tisícovkami přerušení za vteřinu.

NAPI přístup má i další výhody. Pokud je síťovací subsystém přehlcen a je nutné pakety zahazovat, umožní NAPI, aby byly zahozeny dříve, než jsou poslány do stacku. Přeskupování paketů také z různých důvodů funguje s NAPI lépe.

Nová sada patchů napi_struct (aktuálně ve verzi 5) zavádí, podobně jako předchůdce, novou strukturu pro ovládání příjmu paketů:

    struct napi_struct {
	struct list_head	poll_list;
	unsigned long		state;
	int			weight;
	int			quota;
	int			(*poll)(struct napi_struct *, int);
	/* pole související s netpoll vynechána */
    }

Tato struktura už však není součástí struktury net_device; od ovladačů se místo toho očekává, že ji alokují samostatně. Většinou bude součástí libovolné větší struktury, kterou ovladač používá pro interní reprezentaci zařízení. Jednou z výhod tohoto přístupu je to, že ovladače zařízení mohou, je-li to třeba, vytvořit pro dané zařízení více než jednu strukturu napi_struct. Novodobý hardware dokáže podporovat více přijímacích front s hezkými funkcemi jako přiřazení k procesoru a rozddělení proudu; více NAPI struktur usnadňuje efektivní využívání těchto front.

Ovladače nemusejí vyplňovat jednotlivá pole v napi_struct, ale naplnění celé struktury nulami ve chvíli alokace nemůže uškodit. Každá instance NAPI však musí být v systému zaregistrována pomocí:

    void netif_napi_add(struct net_device *dev,
                        struct napi_struct *napi,
			int (*poll)(struct napi_struct *, int),
			int weight);

dev je struktura net_device přiřazená k rozhraní, napi je struktura NAPI, poll() je dotazovací metoda, která bude v této instanci používána, a weight je relativní váha, která má být rozhraní přidělena. Všimněte si, že poll() a weight už nejsou součástí struktury net_device. Jako vždy je nastavování weight v podstatě libovolné, jelikož se většina hodnot pohybuje mezi 16 (pro základní Ethernet) a 64 - i když InfiniBand používá 100. Mluví se o přepracování weight v budoucí verzi, ale to je samostatná záležitost.

Neexistuje netif_napi_remove(), protože v tuto chvíli není potřeba.

Prototyp metody poll() se trochu změnil:

    int (*poll)(struct napi_struct *napi, int budget);

Struktura NAPI je samozřejmě napi. Parametr budget určuje, kolik paketů smí ovladač při tomto volání do síťového stacku přidat. Není už nutné spravovat nezávislá pole s kvótami; ovladače by měly prostě respektovat budget a vracet počet paketů, které byly zpracovány.

Většina prototypů ostatních funkcí souvisejících s NAPI se dočkala předvídatených změn. Jsou dva způsoby, jak zapnout dotazování:

    void netif_rx_schedule(struct net_device *dev, 
                           struct napi_struct *napi);
    /* ...nebo... */
    int netif_rx_schedule_prep(struct net_device *dev,
			       struct napi_struct *napi);
    void __netif_rx_schedule(struct net_device *dev,
		       	     struct napi_struct *napi);

Vypíná se pomocí:

    void netif_rx_complete(struct net_device *dev,
			   struct napi_struct *napi);

Protože může být více struktur napi_struct, může každá zapínat dotazování samostatně. Je-li rozhraní vypnuto (nebo je zavolána jeho metoda stop()), zodpovídají ovladače za zrušení dotazování u všech zbývajících NAPI struktur.

Funkce netif_poll_enable() a netif_poll_disable() už neexistují, protože dotazování už není vázáno na strukturu net_device. Místo toho by měly být používány následující funkce:

    void napi_enable(struct napi *napi);
    void napi_disable(struct napi *napi);

Správce síťování David Miller, který převzal vývoj tohoto patche, říká:

Neočekávám další změny, jen opravování chyb. Tak mi s tím prosím pomozte, ať ten patch dokončíme. Koncem týdne se chystám odříznout strom net-2.6.24 a tento patch do něj nacpat.

Každý, kdo se stará o síťové ovladače nezařazené do jádra, by se měl připravit na výraznou změnu API v 2.6.24.

Diskuse k tomuto článku

[Kyosuke]

Access Control bude spíš řízení přístupu. (Stejně jako control theory je teorie řízení, nikoli teorie kontrol. )

[Robert Krátký]

Myslel jsem "kontrola" ve smyslu "ovládání" (kontrola nad něčím), ale je pravda, že "řízení" je výstižnější.

[stativ]

Podrobnosti najdete v krátkém changelogu a dlouhém changelogu.

[filbar]

Každý, kdo se stará o síťové ovladače nezařazené do jádra, by se měl připravit na výraznou změnu API v 2.6.24.
Ach, jo. To bude zase nutné hledání patchů pro VMWare a Cisco VPNClienta To by už se s těmi změnami v síťování nemolo přestat

[Michal Ludvig]

Myslim ze Cisco VPN Client z http://www.unix-ag.uni-kl.de/~massar/vpnc/ to prezije bez uhony

(no dobre, nefunguje vzdy a vsude jako originalni cisco client, ale zas na druhou stranu kdyz funguje tak neopruzuje zablokovanim ostatniho sitoveho provozu atd)