Jaderné noviny - 28. 1. 2009

5. 3. 2009 | Jirka Bourek | Jaderné noviny | 2515×

Aktuální verze jádra: 2.6.29-rc3. Citáty týdne: Dave Jones, Ingo Molnár, Rusty Russell. LCA: nový přístup k asynchronnímu I/O. Bezpečnostní modul Snet a API LSM.

Obsah

• Aktuální verze jádra: 2.6.29-rc3
• Citáty týdne: Dave Jones, Ingo Molnár, Rusty Russell
• LCA: nový přístup k asynchronnímu I/O
• Bezpečnostní modul Snet a API LSM

Aktuální verze jádra: 2.6.29-rc3

Současné vývojové jádro 2.6 je 2.6.29-rc3 vydané 28. ledna. Od 2.6.29-rc2 bylo začleněno nějakých 430 sad změn; většina z nich jsou opravy, ale také mezi ně patří reorganizace Kconfig souborů souborových systémů, několik ovladačů pro procesor i.MX31, ovladač pro rozhraní vysokorychlostních multimediálních karet TI OMAP a ovladač pro hostitelské řadiče USB Freescale QUICC Engine. Zkrácený changelog je v Linusově oznámení; spoustu detailů vizte v kompletním changelogu.

Současné stabilní jádro 2.6 je 2.6.28.2 vydané 24. ledna; ve stejný den byla vydána aktualizace 2.6.27.13. Obě obsahují poměrně dlouhý seznam oprav několika závažných problémů.

Citáty týdne: Dave Jones, Ingo Molnár, Rusty Russell

Znovu a znovu jsme předvedli "podívejte se, kolik věcí dokážeme začlenit", ale zdá se, že nikdo nikdy nemá návrh, jak zvýšit počet revizí, kterých se kódu dostane, než je začleněn.

Jedna věc je snížení laťky pro vstup a druhá věc je nemít žádnou laťku. A obávám se, že staging/ se stal tím druhým.

-- Dave Jones

Ve skutečnosti tvrdím, že "skutečné revidování" kódu ošklivého jako zadek je ztráta času a zdrojů a také škodí. Skutečným revidováním něčeho, co není ani stylisticky správně, do toho vkládáš hodnotu. Tím ovšem podporuješ autora toho ošklivého kusu kódu, aby přispíval dalším kódem stejné kvality. Nepřímo tímto způsobem poškozuješ Linux, protože podporuješ špatný vkus.

Silně podporuji názor, že revidování na vysoké úrovni je ospravedlnitelné pouze u kódu, který je revidovatelný a vypadá slušně, a že kód, který nesplňuje ani základní styl, by neměl být začleněn vůbec.

-- Ingo Molnár

Tohle vypadá jako ten druh naivní otázky, kterou by položil nováček. Špatný programátor by to zvýšení prostě přidal patchem. Rozumný programátor by také učinil poznámku o potenciálním bobtnání [bloat]. Dobrý programátor by se zeptal, proč potřebuješ víc než padesát_pět_znaků_v_jediném_exportovaném_identifikátoru.

Ty ale pracuješ na úplně jiné úrovni!

Ty sis zvolil tento příklad, abys pomocí (když dovolíte) expandio ad absurdum demonstroval, že náš současný přístup je chybný. Zjevně jsi věděl, že by to bylo možné konvertovat na ukazatel a stejně tak zjevně, že by to od nás vyžadovalo zpracovat přemístění [relocations] před procházením symbolů verze. Jasně jsi pochopil, že to by znamenalo, že bychom museli najít jiné řešení pro verzování struct module, ale věděl jsi, že to stejně vždycky byla první verze symbolu.

Bezpochyby jsi věděl, že bychom použitím tohoto přístupu potenciálně mohli ušetřit 7 % velikost modulu. Zjevně jsi ale nechtěl kritizovat můj kód, místo toho jsi použil tento ó-jak-jemný náznak, abych mohl věřit, že úspěch je jenom můj!

Skláním se před tvým géniem a jenom doufám, že moje sada patchů se přibližuje nirvanické dokonalosti, kterou jsi předpověděl.

-- Rusty Russell

LCA: nový přístup k asynchronnímu I/O

Asynchronní I/O bylo po mnoho let pro linuxové jádro problematickou záležitostí. Současnou implementaci je složité používat, nepokrývá všechno a je obtížné ji uvnitř jádra podporovat. Nedávno se objevil pokus vyřešit problém konceptem sysletů, ve kterém by se použitím jaderných vláken potenciálně dalo změnit každé systémové volání na asynchronní. Syslety mají ale své vlastní problémy, ne nejmenším z nich je to, že jejich použití může časem způsobit změnu ID procesu v uživatelském prostoru. Práce v této oblasti se zpomalila, od poloviny roku 2007 bylo k vidění jenom několik aktualizací.

Zach Brown nicméně stále pracuje na problému asynchronního I/O; svoji přednášku na linux.conf.au využil k diskuzi svého současného přístupu. Jeho nové rozhraní "acall" má potenciál vyřešit mnoho problémů, které jsou v této oblasti k vidění, ale jde o práci ve velmi raném stádiu vývoje, u které je pravděpodobné, že se nějak vyvine předtím, než bude vážně zvažováno její začlenění do hlavní řady.

Jedním z velkých výzev pro asynchronní jaderné operace je to, že jaderný způsob, jak přistoupit ke stavu procesu, je omezený. Systémová volání z větší části očekávají, že proměnná current ukazuje na relevantní strukturu úlohy. To se ukazuje jako problematické, když mají věci běžet asynchronně a potenciálně nemít přímý přístup ke stavu procesu, odkud požadavek vzešel. Současné rozhraní pro AIO tento problém řeší rozdělením věcí na dvě fáze: předložení a vykonání. Fáze předložení má přístup k current a může blokovat, ale fáze vykonání je od tohoto všeho oddělena. Konečným výsledkem je, že podpora AIO vyžaduje duplicitní sadu obsluhy systémových volání a oddělenou I/O cestu. To je důvod, říká Zach, proč je naše podpora AIO po deseti letech stále na prd.

Nápad sysletů nebo fibril tento přístup nahrazuje takovým, který je koncepčně zcela odlišný: obsluhy systémových volání zůstávají synchronní a jaderná vlákna se použijí, aby se nad ně přidala asynchronní operace. Tato práce má formu záludných triků v plánovači; jestliže operace, která má být asynchronní, blokuje, plánovač se rychle přesune k dalšímu vláknu a v tomto vláknu se vrátí do uživatelského prostoru. To umožňuje zachování stavu vystavěného do bodu zablokování a vyhýbá se režii v podobě přivádění nového vlákna, pokud operace blokovat nemusí. Tento zisk ale přichází za cenu změny ID volajícího procesu - změny, která s jistotou způsobí zmatek.

Když Zach tuto práci zdědil, rozhodl se na ni podívat od začátku s jasným krátkodobým cílem zjednodušit implementaci POSIXových specifikací AIO. Další vlastnosti jako syslety (které umožní procesu nahrát do jádra jednoduchý program pro asynchronní vykonání) mohou přijít později, pokud se to bude zdát jako dobrý nápad. Konečným výsledkem je API "acall"; tento kód ještě nebyl zaslán do konferencí kvůli revizím, ale je je k dispozici na Zachově webové stránce.

S tímto rozhraním proces v uživatelském prostoru specifikuje asynchronní operaci takto:

struct acall_submission {
    u32 nr;
    u32 flags;
    u64 cookie;
    u64 completion_ring_pointer;
    u64 completion_pointer;
    u64 id_pointer;
    u64 args[6];
    };

V tétu struktuře nr identifikuje, které systémové volání má být vyvoláno asynchronně, args jsou argumenty, které mají být tomuto systémovému volání předány. Pole cookie je hodnota, kterou volající program používá k identifikaci operace; pokud se má použít, měla by být nenulová. Pole flags a různá pole _pointer budou popsány za chvíli.

Jedno či více asynchronních volání aplikace vyšle voláním:

long acall_submit(struct acall_submission **submissions,
                  unsigned long nr);

submissions je seznam ukazatelů na požadavky a nr je délka tohoto seznamu. Návratová hodnota je počet operací, které byly opravdu předány. Pokud v procesu předávání dojde k nějaké chybě, současná implementace vrátí hodnotu menší než nr, ale chybový kód, který přesně sděluje, co se stalo, se ztratí, pokud byly nějaké operace úspěšně předány.

Ve výchozím nastavení vytvoří acall_submit() pro každou předanou operaci jaderné vlákno. Jestliže však bude pole flags u některého požadavku obsahovat ACALL_SUBMIT_THREAD_POOL, tento požadavek bude místo toho předán fondu čekajících vláken [pool of threads]. Tato vlákna jsou specifická pro volající proces a nečinně sedět mohou jenom 200 ms, pak se ukončí. Předání do fondu vláken tedy má smysl, pokud aplikace předává plynulý proud asynchronních operací; jinak bude jádro stejně pro každou operaci vytvářet samostatná vlákna. Vlákna ve fondu neaktualizují svůj stav úlohy [task state] před každým požadavkem, takže mohou být pozadu za současným stavem volajícího procesu.

Jestliže pole id_pointer není NULL, acall_submit() ho bude považovat za ukazatel na strukturu acall_id:

struct acall_id {
    unsigned char opaque[16];
};

To je zvláštní hodnota, kterou aplikace používá k identifikaci své operace jádru. Interně vypadá takto:

 struct acall_kernel_id {
    u64 cpu;
    u64 counter;
};

V podstatě je to klíč, který se používá k vyhledání operace v červeno/černém stromě [red-black tree].

Ukazatel completion_pointer (není-li NULL) ukazuje na strukturu, jako je tato:

struct acall_completion {
    u64 return_code;
    u64 cookie;
};

Konečný status operace lze nalézt v return_code, cookie je hodnota, kterou předal volající. Jakmile hodnota cookie není nulová, návratový kód je platný.

Aplikace může čekat na dokončení specifických operací voláním:

long acall_comp_pwait(struct acall_id **uids,
                      unsigned long nr,
                      struct timespec  *utime,
                      const sigset_t *sigmask,
                      size_t sigsetsize);

Pole uids obsahuje ukazatel na struktury acall_id identifikující operace, o které se aplikace zajímá; nr je délka pole. Jestliže utime není NULL, ukazuje na strukturu timespec, která specifikuje, jak dlouho má acall_comp_pwait() čekat předtím, než se vzdá. Během operace lze maskovat sadu signálů udanou v sigmask a sigsetsize. Návratová hodnota jedna ukazuje, že alespoň jedna operace byla opravdu dokončena.

Aplikace, která předává velké množství asynchronních volání, se může chtít vyhnout tomu provádět další systémové volání kvůli získání stavu dokončených operací; takové aplikace mohou nastavit jeden nebo více kruhových bufferů dokončení [completion ring], do kterých se zapíše stav dokončených operací. Kruhový buffer vypadá takto:

struct acall_completion_ring {
    uint32_t head;
    uint32_t nr;
    struct acall_completion comps[0];
};

Zpočátku by head měla být nula a nr skutečná délka pole comps. Když je jádro připraveno uložit výsledky operace, nejprve inkrementuje head a poté výsledky vloží do comps[head % nr]. Konkrétní záznam v kruhu je tedy platný, pouze když se hodnota v poli cookie změní na nenulovou. Jádro se snaží vyhnout se přepisování záznamů o dokončení, které si aplikace ještě nevybrala; předpokládá se, že aplikace nezašle více požadavků, než se vejde do bufferu.

Který kruhový buffer se má používat, je nastaveno hodnotou completion_ring_pointer v prvním předání. Mezi jinými věcmi to znamená, že různé operace mohou být vraceny do různých kruhů nebo že aplikace může kdykoliv přejít na kruh o jiné velikosti. Teoreticky to také znamená, že by více procesů mohlo používat stejný kruh, nicméně čekání na dokončení v takovém případě nebude fungovat správně.

Jestliže aplikace potřebuje čekat, než bude kruh obsahovat alespoň jeden platný záznam, může zavolat:

long acall_ring_pwait(struct acall_completion_ring *ring,
                      u32 tail, u32 min,
                      struct timespec  *utime,
                      const sigset_t *sigmask,
                      size_t sigsetsize);

Toto volání bude čekat, dokud nebude daný ring obsahovat alespoň min událostí od té, která je uvedena na indexu tail. Argumenty utime, sigmask, sigsetsize mají stejný význam jako acall_comp_pwait().

A nakonec - jakoukoliv probíhající operaci lze zrušit voláním:

long acall_cancel(struct acall_id *uid);

Zrušení funguje tak, že se vláknu, které operaci vykonává, pošle signál KILL. V závislosti na tom, co se právě dělalo, to může vést k částečnému vykonání požadavku.

API se pravděpodobně v mnoha směrech změní. Například kromě obecného omezení počtu procesů není žádný limit velikosti fondu vláken. Každý požadavek je okamžitě předán vláknu s tím, že vlákna jsou vytvářena podle potřeby; neexistuje způsob, jak požadavek vložit do fronty do doby, než bude k dispozici nějaké vlákno. Možnost nahrávat programy do jádra k asynchronnímu vykonání ("syslety") bude možná přidána také, ale Zach, zdá se, považuje syslety za vlastnost o relativně nízké prioritě.

Kromě nového API se tato implementace asynchronních operací liší od svých předchůdců několika způsoby. Požadavky jsou k vykonání vždy předány vláknům; neexistuje žádný koncept synchronního zpracování, dokud něco nezačne blokovat. To může zvýšit režii v případech, kdy by bylo možné požadavek provést bez blokování, i když využití fondu vláken by mohlo tuto cenu minimalizovat. Velkým přínosem je ale to, že volající proces nemění své ID, když věci blokují. To vyúsťuje v přímější API do uživatelského prostoru s minimem překvapení - což je rozhodně dobrá věc.

Linus na přednášce byl a zdálo se, že podle něj navrhované API není úplně nerozumné. Takže nakonec může vést k tomu, že zanedlouho uvidíme verzi API acall navrženou do hlavní řady. A to by konečně mohlo znamenat správné řešení problémů asynchronních I/O.

Bezpečnostní modul Snet a API LSM

Do mailové konference linux-security-module byl nedávno jako RFC zaslán nový bezpečnostní modul snet (což je zkratka pro "bezpečnost pro síťová systémová volání" [security for network syscalls].) Jeho účel je vcelku jednoduchý - mnohem jednodušší než účel dvou současných uživatelů rozhraní LSM z hlavní řady - zachytit systémová volání pro síťování a zavolat uživatelský prostor, aby zjistil, jestli mají být povolena. Účelem je mít možnost vytvořit linuxovou verzi "osobního firewallu", který je oblíbený na strojích s Windows. Reakce na snet byly smíšené, částečně kvůli despektu k danému typu bezpečnostního nástroje, ale částečně proto, že je implementován s použitím LSM [Linux Security Module, linuxový bezpečnostní modul].

Snet, který vyvinul Samir Bellabes, se skládá z jaderné části, která používá LSM, aby zachytila "zajímavá" systémová volání spojená se sockety (socket(), bind(), connect(), listen() a accept()), a knihovny v uživatelském prostoru, kterou lze použít k přijetí nebo odmítnutí těchto volání. Komunikace mezi jádrem a uživatelským prostorem je řešena přes netlink socket použitím libnl. Rozhodnutí jsou v jádře cachována, aby se omezil počet volání uživatelského prostoru. Tato poslední část je důležitá, protože osobní firewally většinou zobrazí uživateli okno, ve kterém se táží, jestli dané systémové volání povolit. Pro volání uživatelského prostoru lze stanovit časové limity stejně jako výchozí reakci, když limit vyprší.

Vlastnost "dotazování se uživatele" osobních firewallů je jedna věc, ke které mohou být námitky. Jak to říká Paul Moore: Můj názor je, že pro bezpečnost je to špatná volba a typicky vyustí v to, že se uživatel naučí kliknout na 'povolit', kdykoliv na obrazovce vyskočí dialogové okno. I tak je to "vlastnost" jiných operačních systémů a není nerozumné, aby ji Linux podporoval. Z této perspektivy snet vypadá jako dobrý počáteční bod.

Je zde nicméně pár dalších problémů, které pochází z rozhodnutí použít API LSM. Zdá se, že Peter Dolding si myslí, že tato vlastnost by měla být přidána do netfilteru a ne vybudována jako samostatné řešení. Další upozornili na to, že netfilter je příliš nízkoúrovňový, takže není k dispozici žádný kontext uživatelů nebo procesů, kteří by se rozhodovali. To by se mohlo změnit, ale vyžadovalo by to koordinovanou snahu změnit kód netfilteru, což krátkodobě nevypadá pravděpodobně, pokud k tomu vůbec někdy dojde.

Větší problém pochází z nemožnosti skládat LSM moduly [module stacking]. Pokud by uživatel měl zájem o ochranu toho druhu, kterou poskytuje snet, musel by oželet všechna ostatní bezpečnostní opatření implementovaná pomocí LSM (tj. SELinux, Smack, AppArmor, TOMOYO atd.). V linux-security-module probíhá paralelní dikuze o skládání LSM, která je částečně motivovaná potřebami snet a dalších "menších" bezpečnostních řešení; tyto nástroje neimplementují bezpečnostní řešení v plném rozsahu jako SELinux nebo Smack, ale místo toho se snaží řešit menší část problému.

Skládání LSM se řešilo i na LCA v diskuzi o bezpečnosti, takže vývojáři bezpečnostních záležitostí v Linuxu se tím zjevně zabývají. Casey Schaufler shrnul současný stav věcí a přidal náhled na možnou budoucnost.

Skládání LSM se zvláštním účelem je skvělý nápad. Jedním důvodem, proč nemáme LSM pro zvláštní účely, je to, že je nelze skládat. Je potřeba poskytnout kompletní "řešení" v jednom LSM. Kompletní řešení se samozřejmě neskládají.

Velice rád bych viděl LSM, který by nedělal nic jiného, než multiplexoval další LSM. Tím by bylo proveditelné spojení několika spolu nesouvisejících LSM bez nutnosti vytvořit něco, co by bylo schopné pracovat s odlišnými pohledy na model řízení přístupu k síti SELinuxu a Smacku. Když už v tom budete, můžete vzkřísit pohled na nahrávatelné moduly. LSM multiplexující LSM by mohl stanovit jakákoliv omezení na to, které LSM bude podporovat.

Zdá se pravděpodobné, že se někdo brzy pokusí LSM multiplexer vytvořit. Kromě snetu se zdá, že se po období ticha znovuprobouzí projekt TuxGuardian. Je podobný snet a také používá LSM, aby zachytil přístupy k síti. V diskuzi na linux-security-module jsou zmíněny také další projekty. V konečném důsledku je to, že všechny bezpečnostní moduly musí implementovat kompletní bezpečnostní řešení, prostě příliš omezující. Vzhledem k tomu, že LSM je jediný akceptovaný způsob, jak některé z těchto háčků implementovat, bude pravděpodobně nalezena nějaká střední cesta.

V jiném vlákně Casey poznamenává, že mnoho z toho, co je popisováno pro osobní firewally, by bylo možné implementovat pomocí SELinuxu - minimálně zpočátku. Problematickým bodem tohoto řešení je potřebná interakce s uživatelem. Není zjevné, jak by na SELinuxu založené řešení mohlo komunikovat s uživatelem kvůli některým rozhodnutím, ale ne kvůli jiným. Je to také zjevně mimo rozsah toho, k čemu je SELinux zamýšlen.

I když podle některých může snet implementovat "špatnou bezpečnost", diskuze o něm, obzvláště s ohledem na skládání LSM byla velmi cenná. Může se ukázat, že není žádná rozumná cesta, jak skládat jakékoliv bezpečnostní moduly způsobem, který a) dává smysl a b) nepřivede všechny bezpečnostní vývojáře k šílenství. Rýsují se nicméně rozumné případy použití této možnosti, takže se zdá, že průzkum těchto možností je oprávněný. S trochou štěstí brzy uvidíme, k čemu dospěje.

       

Komentáře

[azurIt]

Ten osobny firewall je mozne vytvorit pomocou iptables a ich NFQUEUE (problem je len v tom, ze nejaka jeho cast musi bezat pod rootom).

[Filip Jirsák]

On hlavně firewall nemá smysl v rukou někoho, kdo nerozumí síťování. Problém je, že jako objekt zabezpečení se bere "firewall" a ne "nastavení firewallu". Takže většina lidí si myslí, že jim nějak pomůže, když "mají (zapnutý) firewall" (jako jim pomáhá, když mají (zamknutý) zámek).

[Nicky726]

No by se spíš měli dívat na celý dům, protože k čemu jsou zamčené dveře, když je vedle otevřené okno. To, že se oknem běžně nechodí, bude zloději jedno.