Jaderné noviny - 27. 8. 2008

15. 10. 2008 | Jirka Bourek | Jaderné noviny | 2596×

Aktuální verze jádra: 2.6.27-rc4. Citáty týdne: Al Viro, David Miller, Linus Torvalds, David Airlie. AXFS: komprimovaný souborový systém s vykonáváním na místě. Sysfs a jmenné prostory. TALPA kráčí dál.

Obsah

• Aktuální verze jádra: 2.6.27-rc4
• Citáty týdne: Al Viro, David Miller, Linus Torvalds, David Airlie
• AXFS: komprimovaný souborový systém s vykonáváním na místě
• Sysfs a jmenné prostory
• TALPA kráčí dál

Aktuální verze jádra: 2.6.27-rc4

Současným vývojovým jádrem zůstává 2.6.27-rc4 vydané 20. srpna. Společně se všemi opravami přidává podporu pro multitouch trackpad na nových laptopech od Apple, více stěhování include souborů specifických pro architektury, mnoho vylepšení XFS, stacky pro přerušení na architektuře SPARC64, odstranění zastaralého USB zvukového ovladače Auerswald a nové ovladače pro USB řadiče TI TUSB 6010, USB řadiče Inventra HDRC a AD převodníky National Semiconductor adcxx8sxxx. Zkrácený changelog je v oznámení, všechny detaily vizte v kompletním changelogu.

V repozitáři hlavní řady se dále shromažďují patche a 2.6.27-rc5 může být vydáno už v době, kdy budete číst tento text. Společně s opravami bude -rc5 obsahovat japonské překlady dalších jaderných dokumentů a obecnou obsluhu přerušení pro některá UIO zařízení.

Citáty týdne: Al Viro, David Miller, Linus Torvalds, David Airlie

POZNÁMKA: když jste v pokušení použít vícebytová bitová pole v datech s pevným rozvržením [fixed-layout], podívejte se do zrcadla a zeptejte se sami sebe: "Co mi za tohle udělají během revizí kódu?" Pak se otřeste a rozhodněte, že některá pokušení za tu bolest prostě nestojí.

-- Al Viro

Čím déle ukládáte věci do fronty, tím bolestivější je nutnost změnit věci na začátku té fronty. Všechno ostatní, na čem jste pracovali, totiž pak může být k ničemu.

Jediná smysluplná cesta, jak pracovat, je zasílat svou práci brzy a často, jinak budete žít ve světě plném bolesti a nebude to vina nikoho jiného, jen vaše.

-- David Miller

linux-next není strom, který lze sledovat. Je to strom, který jednou stáhnete a pak ho zahodíte.

To, co můžete dělat, je "stáhnout" linux-next a otestovat ho. Ale VŮBEC NIKDY HO NESMÍTE použít pro nic jiného. Nemůžete na něm vyvíjet, nemůžete podle něj změnit základní bod [rebase], nemůžete s ním dělat nic.

-- Linus Torvalds

Lepší testy na regrese máme z toho, že věci začleňujeme do upstreamu. Nicméně to není způsob, jak regrese hledat - pomáhá to, ale je to suboptimální v tom, že když těch regresí bude příliš mnoho, Linus nás nakonec bude ignorovat.

-- David Airlie

AXFS: komprimovaný souborový systém s vykonáváním na místě

Souborové systémy jsou momentálně zjevně oblast velkého zájmu vývojářů; stěží uplyne týden, ve kterém by se v nějaké konferenci neobjevil nový souborový systém pro Linux. Všechen tento vývoj je motivován mnoha faktory, včetně zvětšujících se kapacit úložných zařízení a schopností úložných zařízení bez rotujících částí. Krom toho je zde jednoduchý fakt, že neexistuje souborový systém, který by byl optimální pro všechny aplikace. Nedávno oznámený souborový systém AXFS je příklad toho, co lze udělat, když se někdo zaměří pouze na specifický případ a optimalizuje pouze pro něj.

Na první pohled AXFS vypadá jako jednoduchý a omezený souborový systém. Například je pouze pro čtení; vývojáři AXFS nijak nezajistili možnost změnit souborový systém poté, co je vytvořen. Některé souborové systémy obsahují mnoho kódu určeného k optimálnímu rozvržení bloků souborů na disku; AXFS nic takového nemá. Místo toho má jednoduchý formát, který dělí médium na "oblasti" a téměř určitě rozprostírá přístupy na celé zařízení. Není žádné žurnálování, žádné logování, žádné snapshoty a žádná správa svazků pro více zařízení.

Co AXFS poskytuje, je komprimované ukládání pomocí zlib. To je zjevně zaměřeno na embedded systémy, které používají na flash založené ukládání dat. Pro taková zařízení lze pomocí poskytnutých nástrojů vytvořit komprimovaný souborový systém a potom ho nahrát do minimální flash paměti v každém zařízení. AXFS se tedy přidává k mnoha dalším komprimovaným souborovým systémům - například cramfs a squashfs - poskytovaným pro tento druh použití. Jedním ze zajímavých aspektů komprimovaných souborových systémů orientovaných na flash je jejich zjevná schopnost zůstat mimo hlavní řadu. Zasláním AXFS do linux-kernel kvůli revidování se jeho vývojář Jared Hulbert možná snaží vyhnout podobnému osudu.

Vlastnost, která AXFS odlišuje od squashfs a cramfs, je podpora pro soubory s vykonáním na místě [execute-in-place, XIP]. Některé typy flash mohou být mapovány přímo do adresového prostoru procesoru. Když se spouští programy uložené na této flash, kopírování stránek vykonatelného kódu z flash do hlavní paměti se zdá být plýtvání: když je kód procesorem již adresovatelný, proč ho nespustit přímo z flash? Vykonání přímo z flash šetří RAM; eliminace potřeby kopírovat tyto stránky do RAM při výpadku stránky věci také zrychluje. Výsledkem je, že systémy používající XIP většinou bootují rychleji, což je vlastnost, kterou designéři (a uživatelé) embedded systémů oceňují.

Linux má mechanismus pro vykonání na místě již několik let, ale relativně málo souborových systémů ho používá. AXFS byl od začátku navržen, aby využíval XIP - to je důvod pro jeho existenci (a původ "X" v jeho jméně").

Je zde ale ještě jeden otazník. Obvykle bychom komprimované ukládání a XIP považovali za vzájemně se vylučující vlastnosti - nemá cenu mapovat komprimovaný vykonatelný kód do adresového prostoru procesu. Aby bylo možné vykonat ji na místě, stránka musí být uložena nekomprimovaná. Čím je AXFS unikátní, je schopnost míchat komprimované a nekomprimované stránky v jednom spustitelném souboru. Stránky, ke kterým se přistupuje často, tedy mohou být uloženy nekomprimované a vykonávány z místa. Stránky s obvykle nepotřebným kódem nebo ty, které obsahují inicializační data, mohou být uloženy komprimované, aby se ušetřilo místo, a rozbaleny při výpadku stránky.

To je hezká funkce, ale není moc užitečná, pokud nevíme, které stránky spustitelného souboru se využívají tak často, aby to ospravedlnilo jejich ukládání bez komprese. Snažit se zjistit tuto informaci a ručně vybrat reprezentaci každé stránky se zdá být cvičením náchylným k chybám - nehledě na to, že by to pravděpodobně vedlo k velkým přesčasům zaměstnanců. Je potřeba jiná metoda.

Za tímto účelem AXFS poskytuje zabudovaný profilující mechanismus. Každý souborový systém AXFS je reprezentován virtuálním souborem v /proc/axfs; zapsání "on" do tohoto souboru způsobí, že AXFS zaznamená každý výpadek stránky v souborovém systému. Přečtení tohoto souboru potom poskytne tabulkový výstup, který pro každý soubor ukazuje, kolikrát u něj došlo v cache stránek k výpadku stránky. S použitím těchto dat je možné generovat souborový systém AXFS s optimálním počtem nekomprimovaných stránek pro cílový systém.

Souborové systémy obvykle potřebují několik kol revizí předtím, než se do hlavní řady dostanou; některé potřebují o dost víc. AXFS je dostatečně jednoduchý, takže do jádra možná najde kratší cestu. Komentáře byly zatím pozitivní, pravděpodobně největší stížnost se vztahovala na to, že jméno je příliš blízké k existujícímu XFS. Začlenění AXFS do 2.6.28 tedy není garantováno, ale rozhodně připadá v úvahu.

Sysfs a jmenné prostory

Podpora pro síťové jmenné prostory - které různým skupinám procesů umožňují mít různé pohledy na síťová rozhraní v systému, routování, pravidla firewallu atd. - se v aktuálních jádrech blíží k dokončení. Pohled na net/Kconfig ale ukáže něco zajímavého: síťové jmenné prostory lze povolit pouze v jádrech, která nepodporují sysfs - tyto dvě vlastnosti se vzájemně vylučují. Vzhledem k tomu, že většina konfigurací systému ke své správné funkci vyžaduje sysfs, toto omezení ztěžuje používání či dokonce testování síťových jmenných prostorů.

Problém je prostý: síťový subsystém vytváří pro každé síťové rozhraní v systému v sysfs adresář. Například eth0 je reprezentováno v /sys/class/net/eth0, tam lze nalézt v podstatě všechny informace o tom, jak je eth0 konfigurováno, statistiky paketů a další. Když se ale používají síťové jmenné prostory, jedna skupina procesů může mít jiný pohled na eth0 než jiná, takže nemohou sdílet globálně přístupný strom sysfs. Jedním řešením by mohlo být přidat síťový jmenný prostor jako explicitní úroveň v sysfs stromě, ale to by znefunkčnilo nástroje v uživatelském prostoru a navíc by tím jmenné prostory nebyly správně odděleny jeden od druhého. Skutečným řešením je zabudovat povědomí o jmenných prostorech hlouběji do sysfs.

Eric Biederman pracoval na sadě patchů pro jmenné prostory v sysfs přibližně rok; tyto patche se nyní zdají být připravené k začlenění do hlavní řady. Síťové jmenné prostory budou prvním uživatelem této vlastnosti, ale je napsaná tak, aby poskytovala různé pohledy na hierarchii sysfs pro jakýkoliv jmenný prostor v systému.

Základním konceptem je "značkovaný" [tagged] adresář v sysfs. Každý adresář v sysfs lze spojit s (nanejvýš) jedním typem značky, kde typ identifikuje, který typ jmenného prostoru udává, jak je na adresář nahlíženo. Například tedy /sys/class/net bude mít typ značky, který identifikuje, že tento adresář je ovládán subsystémem síťových jmenných prostorů. Adresář /sys/kernel/uids bude spravován subsystémem jmenných prostorů uživatelů. Jakmile je adresáři přiřazen typ značky, všechny podadresáře a soubory s atributy zdědí stejný typ.

Kód jmenných prostorů využije značkované adresáře v sysfs přidáním záznamu do enum sysfs_tag_type definovaném v <linux/sysfs.h>, kde identifikuje pro sebe specifický typ značky. Jmenný prostor také musí vytvořit strukturu operací:

struct sysfs_tag_type_operations {
    const void *(*mount_tag)(void);
};

Účelem metody mount_tag() je vrátit specifickou značku (reprezentovanou void * ukazatelem) pro current (současný) proces. Tato značka bude obvykle prostý ukazatel na strukturu popisující relevantní jmenný prostor; pro příklad, síťové jmenné prostory implementují tuto metodu takto:

static const void *net_sysfs_mount_tag(void)
{
    return current->nsproxy->net_ns;
}

Operace se značkami musí být v sysfs registrovány použitím:

int sysfs_register_tag_type(enum sysfs_tag_type type, 
                            struct sysfs_tag_type_operations *ops);

Poté jsou dva způsoby spojení značek s hierarchií sysfs. Jedním z nich je vytvořit značkovaný adresář přímo:

int sysfs_make_tagged_dir(struct kobject *kobj, 
                          enum sysfs_tag_type type);

Adresář spojený s kobj bude mít různý obsah v závislosti na hodnotě značky daného type. Skutečná značka spojená s obsahem tohoto adresáře bude určena (v době vytváření) zavoláním nové funkce přidané do struktury kobj_type:

const void *(*sysfs_tag)(struct kobject *kobj);

Funkce sysfs_tag() je obvykle krátká série volání container_of(), která nakonec naleznou odpovídající jmenný prostor pro daný kobj.

Alternativním způsobem, jak přidat stromu adresářů značku, je spojit ji přímo se strukturou class. Za tímto účelem má struct class dva nové členy:

enum sysfs_tag_type tag_type;
const void *(*sysfs_tag)(struct device *dev);

Když je vytvořena instance třídy, bude mít značky daného tag_type; specifickou značku pro danou třídu lze nalézt zavoláním funkce sysfs_tag().

A nakonec, když specifická značka přestane platit (obvykle proto, že je uvolněn s ní spojený jmenný prostor), měla by být zavolána funkce:

void sysfs_exit_tag(enum sysfs_tag_type type, const void *tag);

Toto volání způsobí, že všechny sysfs adresáře s danou značkou (tag) nebudou dále viditelné a smažou se, když to bude bezpečné.

Přidání podpory pro značkované adresáře vyžaduje významné změny kódu sysfs. Rozhraní je ale navrženo tak, aby bylo používání značkovaných adresářů pro ostatní subsystémy velmi jednoduché; jde o prostou záležitost poskytnutí funkcí, které vrací specifické hodnoty značek, jež mají být použity. V tomto bodě může být největší výzvou pochopit sysfs, když může být jeho obsah různý pro různé pozorovatele. To je ale výzva spojená se jmennými prostory obecně.

TALPA kráčí dál

Když jsme naposledy TALPA opustili, stále se zmítalo kolem solidního modelu ohrožení. Během několika posledních týdnů se to ale změnilo. Eric Paris navrhl poměrně přímočarý - i když poněkud kontroverzní - model ohrožení, která má TALPA řešit. S tímto modelem mají jaderní hackeři alespoň framework k tomu, aby vyhodnotili různé způsoby, jak problém vyřešit a zároveň mít na mysli další potenciální využití.

V podstatě jde o tautologii, ale od antivirového prohledávání se očekává, že bude, ehm, prohledávat soubory. Konkrétně se hledá známý malware a blokuje se přístup k souborům, pokud se zjistí, že jsou napadané. Prohledávání souborů je mnohými za všech okolností považováno za důležitý bezpečnostní mechanismus, takže se TALPA snaží k tomuto účelu poskytnout prostředky. Eric to popisuje takto:

Tohle jsou prohledávače souborů. Možná existuje spousta marketingového materiálů či obecné víry, že mohou poskytnout bezpečí proti všem možným druhům nebezpečí (a je ho spousta), ale ve skutečnosti jediná nebezpečí, proti kterým mohou poskytnout nějakou pomoc, jsou ta, která lze nalézt prohledáváním souborů. Tak je to jednoduché. Někdo může namítat, že to není "dobrá" bezpečnost a nebudu se příliš hádat o opaku. Můžu tu stát dny a ukazovat případy, kde se to velmi hodí, ale nikdo nemůže poskytnout v modelu ohrožení víc, než říct "snažíme se nalézt soubory, které mohou být někde v digitálním ekosystému škodlivé, a zabránit k těmto datům přístup."

Všechny různé scénáře, ve kterých mohou aktivní procesy napadnout soubory malwarem či se aktivně snažit vyhnout se prohledávání, lze v tomto modelu ignorovat. I když to pro někoho vypadá jako "bezpečnostní divadlo", umožní to vyhnout se nekonečným co-kdyby, ve kterých zapadly dřívější diskuze. Takový model ohrožení se mnoha jaderným vývojářům nemusí líbit, ale aspoň s ním mohou pracovat.

Mnoha vývojářům - kteří jsou zvyklí na efektivitu za každou cenu - se na čas náročné prohledávání souborového systému zdá absurdní, obzvláště když "řeší" jenom podmnožinu problémů s malwarem. Faktem ale zůstává, že uživatelé Linuxu obzvlášť v "podnikovém" prostředí věří, že tento druh prohledávání potřebují a jsou ochotni platit za produkty, které jej poskytují. Současné metody prohledávání používané výrobci antivirů jsou přinejlepším problematické a nutí uživatele používat jádra s binárními moduly. S tímto modelem ohrožení - jakkoliv je omezený - mohou pokračovat snahy o nalezení správného způsobu, jak tuto funkci do jádra dodat.

Eric se propracovává k návrhu, který v závislosti na dané operaci volá uživatelský prostor jak synchronně, tak asynchronně. Přístupy k souborům mohou fungovat nějak takto:

• open() - způsobí, že jsou zainteresované programy v uživatelském prostoru asynchronně upozorněny; antivirové programy mohou začít prohledávat, pokud je to potřeba
• read()/mmap() - vyvolá synchronní upozornění pro uživatelský prostor, které umožní antivirovému programu blokovat přístup do doby, dokud není prohledávání dokončeno; jestliže je nalezen malware, antivir zajistí, že read/mmap vrátí chybu
• write() - kdykoliv je aktualizován čas modifikace (mtime), asynchronně upozorní uživatelský prostor; to umožní antivirovým programům znovu prohledat data, pokud je to žádoucí
• close() - asynchronní upozornění pro uživatelský prostor; další místo, kde mohou antivirové programy prohledat soubor, pokud byl změněn

Kde a jak uložit současný stav prohledávání souboru, je stále otevřená otázka. Byly diskutovány různé návrhy počínající nepřetrvávajícím příznakem v inodu souboru v paměti. I když je to jednoduché, způsobilo by to spoustu nadbytečného prohledávání poté, co by inody vypadly z cache. Přetrvávající ukládání statutu prohledávání souboru by tento problém vyřešilo, ale narazilo na jiný: jak řešit stav, kdy běží více antivirových produktů (nebo obecně prohledávačů); čí status se v inodu uloží?

Z tohoto důvodu budou prohledávače v uživatelském prostoru muset udržovat vlastní databázi informací o tom, které inody byly prohledány. U antivirových programů bude také potřeba udržovat informaci o tom, která verze virové databáze přitom byla použita. Podle aplikace lze tuto informaci uložit do rozšířených atributů (xattrs) souboru nebo v jiné databázi specifické pro aplikaci. V žádném případě, jak zdůrazňuje Ted T'so, to není problém jádra:

Jenom říkám, že v jádře by neměla být absolutně žádná podpora pro řešení tohoto konkrétního problému, protože otázka, jestli byl soubor prohledán konkrétní verzí virové DB, patří čistě do uživatelského prostoru.

Je důležité uchovávat status prohledávání mimo kompetence jádra, aby se zajistilo, že rozhodnutí o politice nebudou řešena jádrem samotným. Je to pokračování dlouhotrvajícího principu vývoje jádra, že všechna rozhodnutí o politikách dělá uživatelský prostor. To umožňuje vytváření nových aplikací, takových, které si nikdo možná ani nepředstavoval, když byla vlastnost navrhována. Alan Cox například popisuje další důvod pro to, aby byl stav souboru s ohledem na prohledávání uchováván v uživatelském prostoru:

Tohle je další záležitost aplikační vrstvy. Proč by se jádro mělo starat o to, kde se data uchovávají. Nevíme nic o tom, jestli je může někdo chtít centralizovat nebo dokonce distribuovat mezi uzly v clusterovaném souborovém systému.

Nejnovější návrh TALPA zahrnuje příznak čistý/špinavý v paměti, který může vyzkratovat upozornění blokující read (když je nastaven na čistý). Příznak se nastaví na špinavý pokaždé, když se změní mtime. To optimalizuje obvyklý případ, kdy se čte soubor, který se nezměnil. Jsou možné další optimalizace, které Eric zmínil:

Jestliže se někdy shodneme na nějakém obecném jmenném prostoru xattr, je akceptovatelný patch, který tento jmenný prostor vyčistí při aktualizaci mtime. V současnosti to ale neplánuji dělat, protože porovnání časové značky v xattr s mtime by mělo být dost dobré.

V diskuzi se objevila další možná využití háčků navržených pro TALPA. Správa hierarchického ukládání, kde jsou data transparentně přesouvána mezi různými druhy médií, by mohla používat mechanismus blokujícího čtení. Aplikace indexující soubory a systému detekce průniků by také mohly využít upozornění o změně mtime. Tohle je perfektní příklad vývoje jádra v akci; po drsném začátku lidé od TALPA mnohem lépe spolupracují společně s komunitou.

Dalo by se namítat, že proces vývoje jádra není zcela optimální, ale je to jediný způsob, jak dostat věci do Linuxu. Jak naznačují dřívější příhody s TALPA, přehlížení tradic jádra většinou nikam nevede. TALPA je stále daleko od začlenění - jsou potřeba takové zbytečnosti jako fungující kód - ale je zjevně na cestě do jádra se v nějaké formě dostat.

       

Komentáře

[Mordae]

Daleko radeji nez tyhle srandy kolem open/read/write/close bych videl unifikovany system sync/async notifikaci userspacu o syscallech (nebo rodinach syscallu), tak ze by se dal kazdy proces snadno a ciste hlidat podle dynamicke politiky. Nejen ze by se tim dal hlidat malware (misto init[1] spustim nejprve AV, fork()nu, nastavim childem watch na parentovi forky a IO syscally, parent execne init, sleduji vse...), nebo sandbox pro `make DESTDIR=... install` ktery ciste ohlida jestli proces a jeho childi pisi jen tam, kam smi...). Zkratka spousta moznosti.

[Karel Zak]

selinux & audit