Jaderné noviny – 30. 6. 2010

20. 7. 2010 | Jirka Bourek | Jaderné noviny | 2471×

Aktuální verze jádra: 2.6.35-rc3. Citáty týdne: Lennart Poettering, Linus Torvalds, Dave Chinner, Joel Becker. xstat() a fxstat(). Návrat EVM. Slab alokátor týdne: SLUB+fronta. Jaká timespec je platná?

Obsah

• Aktuální verze jádra: 2.6.35-rc3
• Citáty týdne: Lennart Poettering, Linus Torvalds, Dave Chinner, Joel Becker
• xstat() a fxstat()
• Návrat EVM
• Slab alokátor týdne: SLUB+fronta
• Jaká timespec je platná?

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

Současné vývojové jádro je stále 2.6.35-rc3; Linus se ale vrátil z dovolené a začal opět začleňovat změny.

Stále nevyšly žádné aktualizace stabilních jader od 2.6.32.15 (1. června) a 2.6.33.5 (26. května).

Citáty týdne: Lennart Poettering, Linus Torvalds, Dave Chinner, Joel Becker

Zamykání souborů v Linuxu prostě nefunguje. Nefunkční sémantika POSIXového zamykání ukazuje, že ho návrháři tohoto API zjevně nikdy nezkoušeli skutečně použít. Hodně to vypadá jako rozhraní, o kterém si lidé od jádra mysleli, že dává smysl, ale které ve skutečnosti smysl nedává, když se ho pokoušíte použít z uživatelského prostoru.

-- Lennart Poettering

Jo, jasně, možná čekáš na návrat květinových dětí a volného sexu. Fajn. Ale jestli chceš čekat, nechtěj po linuxovém jádře, aby čekalo s tebou, ok?

-- Linus Torvalds (vizte níže)

Teď, když jsem se podíval na celou sérii, si dovolím jeden komentář: Mám podezření, že zamykání je dostatečně složité na to, abychom na prstech jedné ruky dokázali spočítat lidi schopné ho ladit. Tato sada patchů nejenom že spadla ze zamykacího útesu, ale také do bezedné jámy…

-- Dave Chinner

Tohle je katastrofa. Nemám nejmenší tušení, proč jsme nedostali 100 000 hlášení o chybě.

-- Joel Becker (uživatelé OCFS2 by teď měli s 2.6.35-rc být opatrní)

xstat() a fxstat()

napsal Jonathan Corbet, 30. června 2010

POSIX dlouho definuje varianty systémového volání stat(), které vrací informace o souborech v souborovém systému. Se stat() je spojeno několik omezení, která jsou již dlouho považována za problém: Může vrátit pouze informace stanovené ve standardu a vrací všechny informace bez ohledu na to, jestli je volající potřebuje. David Howells se pokusil oba problémy vyřešit novou sadou systémových volání:

ssize_t xstat(int dfd, const char *filename, unsigned atflag,
              struct xstat *buffer, size_t buflen);

ssize_t fxstat(int fd, struct xstat *buffer, size_t buflen);

Struktura struct xstat připomíná struct stat, ale je zde několik odlišností. Obsahuje pole pro metadata souboru jako čas vytvoření, „číslo generace“ [generation number] inode a „číslo verze dat“ [data version number] u souborových systémů, které tuto informaci poskytují. Také má číslo verze, které do budoucna umožňuje změny API systémového volání.

Také bylo přidáno pole query_flags, ve kterém volající udává, která pole chce získat; jestliže je potřeba zjistit jenom velikost souboru nebo počet odkazů, lze si říci jenom o ně. Jádro může vrátit i další informace, ale nemusí se snažit zajistit, aby byly přesné. Toto chování může mít velké výkonnostní výhody obzvláště u souborových systémů připojených přes síť, kde získání aktualizované informace může vyžadovat konverzaci se serverem. Také jsou zde prostředky pro přidání „výsledků navíc“ pro typy metadat, které aktuálně nejsou předvídány.

Přidání této varianty stat() je diskutováno již léta a něco pravděpodobně začleněno bude. Je nicméně dost možné, že se toto API změní, než bude patch dokončen. Objevily se námitky proti číslu verze ve struktuře xstat; režie způsobená podporou dalšího systémového volání, pokud by nějaké bylo zapotřebí, bude menší, než když se bude muset řešit několik verzí. Také se objevily stížnosti na to, že struktura se používá jako vstupní i výstupní parametr, takže vstupní část (příznaky dotazu) se snadno může stát samostatným parametrem.

Aktuálně: Již je k dispozici nová verze patche s nějakými změnami API systémového volání.

Návrat EVM

napsal Jake Edge, 30. června 2010

Architektura pro kontrolu integrity [integrity measurement architecture, IMA] je součástí Linuxu přibližně rok – začleněna byla do 2.6.30 – lze ji použít k testování integrity běžícího linuxového systému. IMA ale lze obejít „offline“ útoky, kde se data nebo metadata změní a IMA se tím obejde. Mimi Zohar navrhl v sadě patchů modul rozšířeného ověřování (EVM, extended verification module), který má být prostředkem proti těmto offline útokům.

Ve své výchozí konfiguraci IMA počítá hashe spustitelných souborů, souborů, které jsou mmap()ovány pro spuštění, a souborů, které otevírá root. S tímto seznamem hashů se porovnává pokaždé, když se k těmto souborům přistupuje později, takže lze neočekávané změny detekovat. Krom toho lze IMA použít s modulem důvěryhodné platformy [trusted platform module, TPM], který je v mnoha systémech přítomen a kterým lze tuto sbírku hashů podepsat tak, aby vzdálený systém mohl ověřit, že běží pouze „důvěryhodný“ kód (vzdálené ověření).

Útočník by ale mohl změnit obsah disku tak, že k němu přistoupí pod jiným jádrem nebo operačním systémem. To by potenciálně šlo zjistit pomocí vzdáleného ověřování, ale systém sám to zjistit nemůže. EVM chce toto změnit.

Jedním z přídavků, který přichází v sadě patchů EVM, je rozšíření pro zhodnocení integrity [integrity appraisal extension], které ukládá výsledek měření integrity souboru (hodnotu hashe) do rozšířeného atributu (xattr) tohoto souboru. Používá se xattr security.ima, do kterého se hash uloží, a poté se porovnává s vypočítanou hodnotou pokaždé, když je otevřen soubor.

EVM samo o sobě pouze vypočítá hash rozšířených atributů ve jmenném prostoru security (např. security.ima, security.selinux a security.SMACK64), s pomocí TPM ho podepíše a uloží do atributu security.evm souboru. V současnosti se klíč, který má být použit pro podpis TPM, nahrává do kořenového svazku klíčů pomocí readevmkey, které se jednoduše v konzoli zeptá na heslo. Protože útočník klíč nemá, offline útok nemůže správně modifikovat xattr EVM, když se mění data souboru. Důležité je zabezpečení klíče, takže budoucí práce přinese používám klíčů zapečetěných pomocí TPM a zašifrovaných symetrických klíčů, takže EVM klíč v čistém textu nikdy nebude viditelný v uživatelském prostoru.

S tímto opatřením si administrátor systému může být jistý, že je běžící kód stejný jako ten, který byl ověřován. Předpokládá se samozřejmě, že počáteční měření proběhne ze známého dobrého stavu. Poté bude muset jakýkoliv offline útok buď modifikovat obsah souboru, což způsobí selhání při porovnávání IMA, nebo modifikovat jeho bezpečnostní xattrs, což způsobí, že selže porovnání EVM.

Tyto patche zde v různých podobách poskakovaly více než pět let; na EVM jsme se prvně dívali roku 2005. Patch EVM popisuje některé ze změn, které EVM po cestě podstoupilo: EVM prošlo mnoha iteracemi, původně bylo LSM, následně poskytovatel LIM [Linux integrity module] integrity a nyní, když je vázáno na bezpečnostní háček security_, je zabudováno přímo do háčku security_ podobně jako IMA. Tato evoluce odráží jak změny navržené během revizí, tak uvědomění si, že když nelze skládat linuxové bezpečnostní moduly, nebylo by možné mít EVM a SELinux v jednom jádře. To vedlo k přidání IMA a nyní EVM tak, že se volají z odpovídajících háčků v kódu VFS.

EVM ovlivňuje háčky security_inode_setxattr(), security_inode_post_setxattr() a security_inode_removexattr(), každý z nich obsahuje volání odpovídající funkce evm_*. Funkce evm_inode_setxattr() chrání před modifikací security.evm, pokud se o něj nepokouší někdo s kvalifikací CAP_MAC_ADMIN. Další dvě volání aktualizují EVM hash spojený se souborem, když se mění rozšířené atributy.

Nové patche nejsou příliš rušivé mimo subsystém zabezpečení, i když se dotýkají několika dalších oblastí. Ke zjednodušení práce s xattr byla přidána dvě nová obecná volání VFS (vfs_getxattr_alloc() a vfs_xattr_cmp().) Protože při výpočtu EVM hashe se používají další atributy souboru (nejenom bezpečnostní xattrs, ale také číslo inode, uid, režim a tak dál), jejich změny vyžadují přepočítání hashe, což vynucuje změny v fs/attr.c. A tak dál.

Tato iterace EVM patchů přitáhla jenom pár komentářů. Nápad prošel během let několika koly revizí a patche získaly ACK od Serge E. Hallyna. EVM uzavírá díru v podobě offline útoku, kterou má IMA, takže by vypadalo jako dobrý přírůstek do hlavní řady jádra. Pro ty, kteří by patch chtěli vyzkoušet hned, jsou na webové stránce subsystému integrity v Linuxu k dispozici instrukce. Pokud se neobjeví výrazné stížnosti, dalo by se očekávat, že EVM může být kandidátem do 2.6.36.

Slab alokátor týdne: SLUB+fronta

napsal Jonathan Corbet, 29. června 2010

Alokátor SLUB se poprvé objevil v dubnu 2007, do hlavní řady byl začleněn nedlouho poté. Tento alokátor měl poskytnout lepší výkon a přitom být efektivnější při využívání paměti než existující slab alokátor. Jedním z mechanismů pro vylepšení spotřeby paměti bylo zbavit se rozsáhlých front objektů, které slab udržoval; s dostatečným počtem procesorů tyto fronty mohou vyrůst do takových rozměrů, že zaberou významné procento celkové dostupné paměti, i když v nich nic není. SLUB v mnoha pracovních zatíženích pracuje dobře, ale trápí ho regrese v některých benchmarcích. Nikdy tedy nedosáhl svého cíle úplného nahrazení slabu a vývojáři občas mluvili o tom se ho zbavit.

SLUB se ale na jiných benchmarcích chová lépe než slab a kód je široce považován za čitelnější než kód slabu – i když to je také často považováno více za přání než za skutečnost. Během let tedy došlo k pokusům zlepšit výkonnost alokátoru SLUB. Nejnovější pokus je SLUB + fronta, který podle svého vývojáře Christopha Lametera poráží slab na tom nejdůležitějším benchmarku „hackbench“.

V sadě patchů SLUB+Q je pár významných změn, které mají vylepšit výkonnost SLUBu. Na vrcholu seznamu je obnovení front. SLUB+Q ale nepoužívá složité fronty, které jsou k nalezení ve slabu; místo toho je zde jediná fronta pro každé CPU, která obsahuje ukazatele na volné objekty patřící do cache. Operace alokace jsou nyní jednoduché, tedy alespoň pokud fronta není prázdná: Vydáván je poslední objekt ve frontě a délka fronty se sníží o jedna. Uvolnění do neprázdné fronty je podobné. V obou případech by tedy rychlá cesta měla být opravdu rychlá.

Jestliže se fronta daného CPU vyprázdní, musí se alokátor SLUB+Q vrátit k alokaci objektů ze stránek a přitom možná alokovat víc stránek. To je samozřejmě o něco pomalejší. Ve snaze minimalizovat cenu této pomalé cesty SLUB+Q rovnou frontu přednaplní do přednastavené velikosti [batch size, ve výchozím nastavení polovina celkové délky fronty] volnými objekty. V situaci, kdy se alokuje mnohem více objektů, než je uvolňováno, se tedy bude rychlá cesta alokace používat ve většině případů.

Jestliže fronta naopak přeteče, alokátor musí objekty vytlačit zpět do stránek, ze kterých přišly. Zde se opět používá chování, ve kterém se fronta pročistí do stavu polovičního zaplnění; alokátor nevytlačí všechny objekty z fronty, pokud jádro nenaznačilo, že má vážný nedostatek paměti. Výchozí velikost fronty závisí na velikosti objektu, ale je možné ji měnit (stejně jako přednastavenou velikost) pomocí parametru v sysfs.

Další významná změna se týká toho, jak se pracuje s volnými objekty, když nejsou uloženy v jedné z front specifických pro CPU. V současných jádrech hlavní řady si SLUB udržuje seznam stránek, které obsahují nějaké volné objekty. Zde je vhodné si všimnout, že neudržuje stránky, které jsou plně využity (na ty lze jednoduše zapomenout, dokud není uvolněn alespoň jeden objekt); také neudržuje zcela prázdné (ty jsou odevzdány zpět alokátoru stránek). Částečně obsazené stránky obsahují jeden nebo více objektů, které jsou organizovány do spojového seznamu, což je naznačeno v obrázku napravo. Dělat věci takto má určitou estetickou hodnotu; ke sledování volných objektů se používá samotná volná paměť, čímž se minimalizuje režie spojená se správou objektů.

Bohužel je zde také cena za to, že se ukazatele ukládají do volných objektů. Je dost pravděpodobné, že když se jádro dostane k uvolnění objektu, je tento objekt již dlouho nevyužívaný; na uvolňujícím CPU už dávno nemusí být v cache. Objekty na seznamu volných ještě s větší pravděpodobností nebudou v cache. Vložení seznamu ukazatelů do daného objektu ho tedy vrátí do cache CPU, což znamená nutnost číst ze systémové paměti a s určitou pravděpodobností vytěsnění něčeho, co je užitečnější. Výsledkem je měřitelný výkonnostní postih.

Postupem času se tedy ukázalo, že je správa paměti efektivnější, když se nemusí dotýkat objektů, které spravuje. Patche SLUB+Q tohoto cíle dosahují tak, že ke sledování volných objektů v dané stránce používají bitovou mapu. Jestliže je počet objektů, které se vejdou do stránky, dostatečně malý, lze bitovou mapu uložit ve struktuře page v mapě systémové paměti; jinak je uložena na konec samotné stránky. Správa volných objektů tedy nyní vyžaduje jenom úpravu bitů v malé bitové mapě; na objekty samotné alokátor nesahá.

Benchmark hackbench pracuje tak, že vytvoří skupinu procesů a pomocí socketů mezi nimi rychle předává zprávy. SLUB mívá tendenci vést si na tomto benchmarku hůře než slab, někdy i výrazně hůře. S novými patchi Christoph zaslal výsledky benchmarků, které ukazují, že je výkonnost výrazně lepší, než má slab. Pokud se tyto výsledky udrží, SLUB+Q překoná jeden z nejvýznamnějších problémů, které jsou k vidění u SLUBu.

Je nicméně potřeba poznamenat, že výkonnost na jediném benchmarku nijak zvlášť nevypovídá o chování alokátoru paměti obecně; SLUB již nyní poráží slab v mnoha dalších testech. Výkonnost správy paměti je jemná a záludná oblast, bude tedy potřeba mnoho testů, než bude možné říci, že SLUB+Q opravdu vyřešil potíže SLUBu bez zavedení vlastních regresí. Počáteční výsledky ale vypadají dobře.

Jaká timespec je platná?

napsal Jonathan Corbet, 29. června 2010

Tvrzení, že by jeden měl být liberální v tom, co přijímá, ale konzervativní v tom, co vysílá, se často objevuje v oblasti síťování, ale i v mnoha jiných oblastech. Často však dává větší smysl být konzervativní i na přijímací straně; stav mnoha webových stránek by byl mnohem lepší, kdyby první prohlížeče nebyly tak shovívavé ke špatnému HTML. Výhody a nevýhody přijímaní čehokoliv a trvání na korektnosti se nedávno objevily v diskuzi o navrhované změně API systémového volání futex(); „konzervativní“ přístup v tomto případě asi vyhraje.

Systémové volání futex() poskytuje uživatelskému prostoru operace pro rychlé zamykání. Volající bude obvykle blokovat, dokud se zámek neuvolní, ale také může poskytnout hodnotu struct timespec, ve které udává maximální dobu, po kterou chce čekat:

struct timespec {
    long            tv_sec;              /* seconds */
    long            tv_nsec;             /* nanoseconds */
};

Interpretace časového limitu [timeout] je trochu podivná. Pro příkaz FUTEX_WAIT je časový limit relativní k aktuálnímu času; pro jakýkoliv jiný příkaz je buď ignorován, nebo považován za absolutní čas. Konkrétně operace jako FUTEX_WAIT_BITSET a FUTEX_LOCK_PI používají absolutní časové limity.

Oleg Nesterov nedávno přišel do jaderné e-mailové konference se zajímavým problémem s glibc. Když je tv_sec časového limitu záporné, volání futex() v jádře selže a volání vrátí EINVAL. POSIXový kód vláken na toto není připraven a svůj hněv dá najevo tak, že přejde do nekonečné smyčky – takové chování programátoři v uživatelském prostoru obvykle neoceňují. Vývojáři glibc se shodli, že toto chování je chyba v jádře; pro ně záporný absolutní čas znamená čas před epochou. Protože epocha je pro všechny praktické účely počátkem času, reakce na čas před ní by měla být ETIMEDOUT, na což je knihovna připravena.

Tento postoj nebyl přijat dobře. Thomas Gleixner zareagoval tak, že čas před epochou nelze nastavit do systémových hodin a tudíž ho neakceptuje žádné linuxové systémové volání, které pracuje s absolutními časy. Vzhledem k tomu, že některá systémová volání nemohou takové hodnoty přijmout, říká Thomas, že by je neměla přijímat žádná: Jsem zásadně proti tomu mít různé definice korektních hodnot pro různá systémová volání.

Linus je také proti přijímání záporných časů, ale z trochu jiného důvodu:

Kladná hodnota time_t je dobře definována. Oproti tomu je záporná hodnota tv_sec zjevně podezřelá. Tradičně jsi dokonce ani nemohl zjistit, jestli je time_t znaménková hodnota! A na 32bitových strojích je záporný time_t poměrně často důsledkem přetečení (ne, nemusíš čekat do roku 2038, abys něco takového viděl – k přetečení může dojít jednoduše kvůli velkým relativním časovým limitům atd.).

Jinými slovy je záporná hodnota času náznak toho, že se někde něco pokazilo. V podobných situacích může být odmítnutí takové hodnoty dost dobře to nejlepší řešení.

Vývojářům glibc tudíž nezbývá nic jiného, než opravit svůj kód, aby se vyrovnal s touto (dříve) neočekávanou návratovou hodnotou. Dobrá zpráva je, že na tomto kódu budou pracovat tak jako tak. Zdá se, že stejná funkce se do smyčky dostane také, když se jí z futex() vrátí EFAULT, což je zjevně chyba v uživatelském prostoru.

       

Komentáře

[Jardík]

Kdyby v timespec alespoň použili neznaménková čísla, mohli mít pokoj a větší rozsah času.

[Xerces]

Nj. evidentně jim chybíš

[Bedňa]

Ale zas glibc by nezistilo že jadro posiela haluze.

[Martin Mareš]

Jádro je v tom celkem nevinně, spíš autoři glibc zapomněli na to, že syscall může selhat

[Bedňa]

To je ale klasický postup. Ešte som nevidel odstraňovať chybu čo sa dá ťažko vyriešiť, väčšinou sa na to spraví "krásny" hack :) Proste sme ošetrili chybu tak, že vieme kedy nastala :)

[geebranz]

Worth reading

fort collins fence