Jaderné noviny - 5. 3. 2008

8. 5. 2008 | Jirka Bourek | Jaderné noviny | 2937×

Aktuální verze jádra: 2.6.25-rc4. Citáty týdne: Rusty Russel, Daniel Phillips. Adaptivní zámky v reálném čase. Infrastruktura pro ladění objektů. Zbytek příběhu o vmsplice() exploitu.

Obsah

• Aktuální verze jádra: 2.6.25-rc4
• Citáty týdne: Rusty Russel, Daniel Phillips
• Adaptivní zámky v reálném čase
• Infrastruktura pro ladění objektů
• Zbytek příběhu o vmsplice() exploitu

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

Aktuální vývojové jádro je 2.6.25-rc4 vydané 4. března. Do repozitáře hlavní řady stále proudí značné množství patchů; většina jsou opravy chyb, ale také se objevila podpora kdump pro ovladač ehea, zvládání dynamického kódu v kódu RCU, dočasné znovuexportování init_mm do doby, než budou opraveny externí moduly, podpora pro HT1100 SATA, podpora pro DMA řadič Freescale MPC85xx, podpora pro RTC Seiko Instruments S-35390A a obnovení přístupu ke GPL-only symbolům pro ndiswrapper. Detaily najdete ve zkráceném changelogu, více potom v kompletním changelogu.

V době psaní tohoto článku nebyly do hlavní řady po -rc4 začleněny žádné patche.

Současná verze -mm stromu je 2.6.25-rc3-mm1. Nedávné změny v -mm zahrnují velkou sadu změn v IDE a odstranění některých starých bezdrátových ovladačů. Souborový systém ext4 je zakázán do doby, než -mm dožene některé změny v API.

Citáty týdne: Rusty Russel, Daniel Phillips

/* Protože Linux má tendence se rozpadnout při namáhání cestováním v čase, musíme být opatrní */

-- Rusty Russell

Po tolika letech snahy by mělo být krájení svazků na plátky a na kostičky naší druhou přirozeností, měli bychom měnit konfiguraci za běhu, transparentně zvětšovat, zmenšovat a migrovat souborové systémy a také spoustu dalších věcí, které ZFS a GEOM už umí a my ne. A není to tolik ani tím, že device mapper neumí dělat takové pěkné triky, ale spíš tím, že jsme vzali velmi mocný jaderný subsystém a ochromili jsme ho téměř nepoužitelným aplikačním rozhraním. Teď je jako závodní auto s proudovým motorem, které má dvoupalcové sání na vzduch.

-- Daniel Phillips

Adaptivní zámky v reálném čase

Realtime patchset má jeden cíl, který je nadřazen všem ostatním: poskytnout za každé situace deterministické doby odezvy. Z toho důvodu bylo uděláno hodně práce na odstranění míst v jádře, která mohou být zdrojem nadměrného zpoždění; velká část této práce byla během posledních přibližně dvou let začleněna do hlavní řady jádra. Jednou z největších komponent, která zůstává mimo strom, je kód pro spící spinlocky [sleeping spinlock code]. Spící spinlocky mají výhody a nevýhody, ale nedávno zaslaná sada patchů má potenciál významně zredukovat jednu z největších nevýhod tohoto kódu.

Spinlocky fungují především tak, že se opakovaně dotazují na proměnnou reprezentující zámek do doby, než je dostupná. Díky tomu se kód aktivního čekání během čekání na zámek "točí" [spins]. Spinlocky jsou poměrně rychlé, ale také mohou být zdrojem významných latencí: procesor, který drží zámek, může ostatní zpozdit o nedefinované množství času. V hlavní řadě jádra navíc není možné preemptivně odstranit vlákno, které spinlock drží - další zdroj latencí. (Detailnější popis implementace spinlocků v hlavní řadě najdete v článku Spinlocky s pořadovými lístky.)

Realtime patch tento problém řeší několika způsoby. Jedním z nich je uspání procesu, který soupeří o zámek, místo toho, aby se točil ve smyčce. Výsledkem je, že soupeření o zámek nemůže způsobit zpoždění na procesorech, které zámek nedrží. Když je odstraněno točení [spinning], je také možná preempce kódu, i když drží zámek, aniž by došlo k problémům s deadlocky. To umožní procesům o vysoké prioritě běžet bez ohledu na jakýkoliv proces o nižší prioritě, který na současném CPU drží zámek. Nakonec realtime patch přidává do kódu zámků povědomí o prioritě a dědění priority, takže proces o největší prioritě vždycky může běžet.

To je všechno dobré, ale má to jednu malou nevýhodu: režie [overhead] způsobená komplikovanějšími zámky může významně omezit propustnost systému. To je cena, kterou vývojáři RT jádra byli ochotni zaplatit; je často nutné vyměnit propustnost za kratší odezvu. Nicméně v nedávné době vývojáři v Novellu došli k závěru, že úbytek propustnosti realtime patche nemusí být tak vážný, jak v současné době je, čímž vznikl patch pro adaptivní zámky v reálném čase, který vrací propustnost realtime jádra na úroveň blízkou k hlavní řadě - alespoň pro některé typy zátěže.

Jádrem této sady patchů je pozorování, že doba držení zámku je pro spinlocky většinou poměrně krátká, zvlášť v realtime jádře, takže cena za uspání čekajícího vlákna může snadno překročit cenu jednoduchého aktivního čekání do doby, než se spinlock uvolní. Adaptivní zámky proto fungují více jako jejich protějšky v hlavní řadě a pokud se spinlock neuvolní, čekají aktivně. Objevují se tam ale také nějaké odchylky, které jsou nutné pro realtimový systém:

• Točení nemůže běžet donekonečna, protože by mohlo způsobit neakceptovatelné zpoždění ve zbytku systému. Adaptivní zámek se proto točí jenom omezenou dobu (ve výchozím nastavení desettisíckrát), potom to vzdá a uspí se.
• Vzhledem k tomu, že držitelé zámků jsou v realtime jádře preemptivní, je možné, že vlákno, které momentálně drží zámek, předtím běželo na stejném CPU jako proces, který se snaží zámek získat. V takové situaci by byl běh v nekonečné smyčce zjevně špatný nápad. Při absenci čítače by došlo k tvrdému deadlocku; s čítačem dojde akorát ke zbytečnému zpoždění. V každém případě je výsledek nežádoucí, takže pokud majitel zámku běží na stejném procesoru, vlákno čekající na zámek se prostě uspí.
• Pokud vlastník zámku spí sám, protože na něco čeká, není důvod, aby jiné vlákno běželo a doufalo, že vlastník zámek brzo uvolní. V tomto případě se tedy vlákno soupeřící o zámek také uspí.

Další vylepšení propustnosti je získáno změnou kódu ukradení zámku (lock stealing). V realtimovém systému jsou zámky obyčejně spravedlivé v tom ohledu, že na vlákna čekající na zámek se dostane v pořadí kdo dřív přijde, ten dřív mele. Nicméně proces o vyšší prioritě předběhne ve frontě a "ukradne" zámek procesům o nižší prioritě, které čekaly déle. Patch adaptivních zámků ladí tento algoritmus tak, že umožňuje běžícímu procesu ukrást zámek jinému procesu, který má stejnou prioritu, ale spí. Tato změna přidává do kódu zamykání určitou nespravedlnost, ale umožňuje systému vyhnout se přepnutí kontextu a nechat běžící proces s "ohřátou cache" dál běžet.

Byly zaslány výsledky benchmarků (PDF). Na testovacím sytému benchmark dbench běží s propustností okolo 1500 MB/s s běžným jádrem 2.6.24, ale jenom pod 170 MB/s s jádrem, na které byly aplikovány RT patche. Patch adaptivních zámků toto číslo zvedá zpět přes 700 MB/s - stále daleko od výsledků hlavní řady, ale mnohem lepší než předtím. Zlepšení v hackbench je ještě lepší, zatímco změna v nejdůležitějším benchmarku "překlad jádra" je malá (ale stále kladná). Tak zásadní patch jako tento bude vyžadovat značné testování a revize, než ho bude možné akceptovat, ale první výsledky naznačují, že adaptivní zámky mohou být pro RT sadu patchů značným přínosem.

Infrastruktura pro ladění objektů

Thomas Gleixner zjistil, že práce správce infrastruktury jádra jádra [core kernel] může přinést i zajímavé výzvy. Kdykoliv něčí jádro oopsne například v kódu časovače, Thomas se o tom většinou dozví. Jediný problém je v tom, že kód časovače téměř nikdy není ten kód, který obsahuje chybu. Místo toho je mnohem pravděpodobnější, že jiný jaderný subsystém poškodil aktivní časovač a zanechal tak po sobě bombu, která později vybuchne v kódu časovače, když ten vyprší. V tu chvíli může být těžké přijít na to, kde se problém skutečně skrývá, protože pachatel je dávno pryč.

Z toho důvodu Thomas vyvinul speciální kód určený k nalezení skutečné příčiny problémů spojených s časovači pokud možno dřív, než shodí jádro. Nyní svůj kód zobecnil a zaslal jako patch infrastruktury ladění objektů, který byl později významně zrevidován. Jak se tento kód rozvíjí, má potenciál pomoci najít celé třídy obzvláště nepříjemných chyb předtím, než shodí systém.

Přidávání podpory pro ladění objektů do nového subsystému zahrnuje několik kroků. První je založení a vyplnění struktury debug_obj_descr (definované v <linux/debugobjects.h>):

struct debug_obj_descr {
    const char              *name;

    int (*fixup_init)       (void *addr, enum debug_obj_state state);
    int (*fixup_activate)   (void *addr, enum debug_obj_state state);
    int (*fixup_destroy)    (void *addr, enum debug_obj_state state);
    int (*fixup_free)       (void *addr, enum debug_obj_state state);
};

Pole name je jméno subsystému; používá se v ladícím výstupu. K ostatním polím se vrátíme níže.

Dalším krokem je volání kódu ladění objektů, kdykoliv nějaká akce, která nás zajímá, zahrnuje některý ze sledovaných objektů. Pro tento účel existuje sada funkcí:

    void debug_object_init      (void *addr, struct debug_obj_descr *descr);
    void debug_object_activate  (void *addr, struct debug_obj_descr *descr);
    void debug_object_deactivate(void *addr, struct debug_obj_descr *descr);
    void debug_object_destroy   (void *addr, struct debug_obj_descr *descr);
    void debug_object_free      (void *addr, struct debug_obj_descr *descr);

Ve všech případech je addr ukazatel na objekt, se kterým se pracuje, a descr ukazatel na strukturu debug_obj_descr, která byla zmíněna výše. Význam těchto volání je:

• debug_object_init(): objekt je inicializován.
• debug_object_activate(): je přidáván do seznamu subsystémů. Pro ladění časovače tato akce nastane, když je zavolán add_timer().
• debug_object_deactivate(): objekt je odstraňován ze seznamu subsystémů.
• debug_object_destroy(): objekt je zničen [destroyed] a v rámci subsystému již není odkazován. Ve verzi 2 sady patchů se toto volání nepoužívá.
• debug_object_free(): objekt je uvolněn.

Ladící kód udržuje hashovanou sadu seznamů pro sledované objekty; každý objekt je přidán do odpovídajícího seznamu, když je vykonáno jedno z výše zmíněných volání. Když akce objekty mění, jejich stav je sledován. Tímto způsobem může ladící kód hledat mnoho běžných chyb, včetně deaktivace objektu, který není aktivní, reinicializace aktivních objektů nebo jejich opakované přidávání.

Když se něco pokazí, do systémového logu je zaslán backtrace. Díky tomu, že backtrace identifikuje místo, kde došlo k původní chybě, pravděpodobně bude mnohem užitečnější než backtrace spojený s pádem systému, ke kterému pravděpodobně dojde později. Tato infrastruktura ale také může pomoci snížit pravděpodobnost pádu díky tomu, že každý subsystém může zaregistrovat sadu "opravných funkcí" - ty jsou samozřejmě metodami struktury debug_obj_descr, o které se mluvilo dříve.

Například pokud je volána funkce debug_object_init() s objektem, který již byl aktivován, ladící infrastruktura zareaguje voláním callbacku fixup_init(), kterému předá dotyčný objekt a jeho současný stav (v tomto případě ODEBUG_STATE_ACTIVE). Callback by měl vrátit nulu, pokud je nějakým způsobem schopen chybu napravit. A i když věci nemohou být skutečně opraveny, i tak má funkce svůj účel; například kód časovače zakáže aktivní časovač, pokud s ním volající špatně zacházel. Jádro určitě nebude fungovat tak, jak se od něj očekává, ale alespoň se menší hrozba pádu v nějakém náhodném čase v budoucnu.

Většina ladících kontrol se provádí jako reakce na volání přímo ze subsystému samotného. Existuje jedna užitečná kontrola, kterou tímto způsobem provést nelze: detekce uvolnění objektů, které jsou stále nějakým způsobem subsystémem spravovány. K odchycení této chyby Thomasův patch vkládá háček [hook] do funkcí jako kfree() a free_hot_cold_page(). Pokaždé, když je objekt uvolněn, kód zkontroluje příslušný seznam, aby zjistil, jestli dotyčný objekt není v nějakém subsystému veden jako aktivní. Uvolnění objektu, který je nějakému subsystému známý, je téměř vždy chyba - taková, kterou je později obtížné najít.

Kontrola uvolňování objektů z paměti je zjevně užitečný ladící nástroj. Nicméně také může mít nezanedbatelnou režii, protože potřebuje prohledávat seznam pokaždé, když se nějaký objekt uvolňuje. Proto má vlastní konfigurační volbu a může být z jádra odstraněna, i když zbytek ladícího kódu přeložen bude.

V současné době je touto infrastrukturou pokryt pouze subsystém časovačů, ale je spousta dalších zjevných kandidátů. Na prvním místě seznamu by pravděpodobně byly kobjekty [kobjects], které jsou slavné svou náchylností ke všem možným druhům chyb při programování. Proto v blízké budoucnosti očekávejme růst pokrytí tímto kódem.

Zbytek příběhu o vmsplice() exploitu

V únoru LWN publikoval diskuzi o exploitu vmsplice(), která ukazovala, jak opomenuté ověření práv pro operaci čtení vedlo k přetečení zásobníku [buffer overflow] v jádře. Následně čtenář konference linux-kernel upozornil na to, že článek končil, aniž by poskytl celé vysvětlení: toto není běžný exploit typu buffer overflow. Cestovní plány a podobné zabránily sepsat reakci okamžitě, ale Jonathan Corbet by rád vydal příběh celý, takže tento článek navazuje tam, kde minulý skončil, a popisuje, jak exploit ve vmsplice() využívá přetečení zásobníku k převzetí kontroly nad systémem.

Když je vmsplice() použit k tomu, aby poslal data z paměti do roury [pipe], funkce pověřená vykonáním této operace je vmsplice_to_pipe() implementovaná v fs/splice.c. Ta deklaruje několik polí, která nás budou zajímat:

struct page *pages[PIPE_BUFFERS];
struct partial_page partial[PIPE_BUFFERS];

Vzpomeňme, že PIPE_BUFFERS je na zranitelných konfiguracích 16. Obě tato pole jsou předána do get_iovec_page_array(), která, jak bylo popsáno v předchozím článku, volá get_user_pages(), která vyplní pole pages. Důsledkem opomenutí ověření práva na čtení požadované oblasti paměti je to, že get_user_pages() přeplní [overflows] pole pages tak, že do něj zapíše více než PIPE_BUFFERS ukazatelů. Tyto ukazatele nicméně ukazují na legitimní datové struktury jádra; zbývá jen ukázat, jak toto přetečení umožní útočníkovi převzít kontrolu nad systémem.

Pole partial je také předáváno funkci get_iovec_page_array(); popisuje část každé stránky, která by měla být zapsána do roury. Za tímto účelem je po návratu z get_user_pages() vykonána takováto smyčka:

for (i = 0; i < error; i++) {
    const int plen = min_t(size_t, len, PAGE_SIZE - off);
    partial[buffers].offset = off;
    partial[buffers].len = plen;
    /* ... */
}

Kvůli tomu, že v tomto případě jsou zapisovány celé stránky, vypočítaný offset bude nula a délka bude PAGE_SIZE (4096). Hodnota error je návratová hodnota get_user_pages(); to je počet stránek, které byly skutečně namapovány: v případě exploitu 46. Vzpomeňme, že pole partial je také dimenzováno na uložení 16 záznamů, takže smyčka přeplní i toto pole.

Obě tato pole jsou deklarována těsně vedle sebe v vmsplice_to_page(). Rychlý test naznačuje, že pole partial je v paměti umístěno pod pages, takže jakmile partial přeteče, smyčka začne přepisovat pages. Pole pages tedy nakonec obsahuje střídající se hodnoty 0 a 4096 místo skutečných ukazatelů na struct page, které obsahovalo předtím. (Stojí za to podotknout, že exploit funguje i v případě, že jsou pole umístěna v opačném pořadí, protože přetečení způsobí, že kód si myslí, že pole pages je větší, než ve skutečnosti je.)

Poté, co se všechno toto dokončí, kontrola se vrací funkci vmsplice_to_pipe() - přetečení není tak velké, aby přepsalo návratovou adresu. Volání splice_to_pipe() má práci dokončit, ale tam se stane něco zajímavého. Na začátku této funkce je proveden následující test:

if(!pipe->readers) {
    send_sig(SIGPIPE, current, 0);
    if (!ret)
        ret = -EPIPE;
    break;
}

Při pohledu zpět na kód exploitu vidíme, že zavírá čtoucí stranu roury před voláním vmsplice(). Kvůli tomu se splice_to_pipe() téměř okamžitě ukončí, ale ještě před návratem do volající funkce udělá toto:

while (page_nr < spd_pages)
    page_cache_release(spd->pages[page_nr++]);

Volání get_user_pages() by zamklo každou relevantní stránku v paměti, aby se jádru umožnilo s nimi pracovat; toto je uklízecí kód, který to vezme zpět a odemkne stránky, které nebudou použity. Vzpomeňme ale, že ukazatele v poli pages byly již přepsány a nyní mají hodnotu buď 0 nebo 4096. Zde by normálně nastal oops jádra, protože ani jedna z těchto hodnot není platná adresa. Kód exploitu ale udělal něco dost mazaného: použitím zvláštního volání mmap() vytvořil anonymní paměť ve spodní části svého adresovacího prostoru.

Na přímé dereferencování adres z uživatelského prostoru v době běhu v jaderném režimu se z několika důvodů nehledí příliš nadšeně - může to několika způsoby vybuchnout. Nicméně pokud je adresa platná a relevantní stránka nahraná v paměti, přímý přístup do paměti uživatelského prostoru bude fungovat. Takže ve chvíli, kdy jádro začne pracovat s adresami, o kterých si myslí, že jsou ukazatele na struct page, nedojde k žádnému selhání; místo toho dostane data, která do paměti uložil exploit. Je zbytečné říkat, že tato data jsou opatrně předpřipravená.

Jádro Linuxu obvykle spravuje každou stránku jako nezávislý objekt. V některých situacích jsou ale stránky seskupeny do větších jednotek nazývaných "složené stránky" [compound pages]. Obecně se tak stane v situaci, kdy jádro potřebuje fyzicky souvislou alokaci větší, než je jedna stránka; když se tak stane, volajícímu je vrácena oblast stránek. Tyto stránky jsou zvláštní v tom, že když jsou vraceny systému, musejí být opět rozděleny a může být potřeba provést i další úklidové práce. Proto mají složené stránky vlastnost, kterou u normálních stránek nenajdeme: destruktor, který je zavolán, když je stránka uvolňována.

Když se podíváme, jak exploit nastaví strukturu page ve své nízké paměti, vidíme:

pages[0]->flags    = 1 << PG_compound;
pages[0]->private  = (unsigned long) pages[0];
pages[0]->count    = 1;
pages[1]->lru.next = (long) kernel_code;

Podívá-li se jádro na strukturu page na adrese 0 v uživatelském prostoru, najde něco, co vypadá jako složená stránka [compound page]. Destruktor (uložený v poli lru.next druhé struktury page) je nastaven na kernel_code(), což je funkce definovaná v samotném exploitu. Protože count je nastaveno na jedničku, volání page_cache_release() (které count snižuje) usoudí, že na stránku nejsou další reference, a protože stránka vypadá jako složená stránka, je zavolán destruktor. V tuto chvíli má exploit k dispozici možnost spustit jakýkoliv kód v jaderném režimu a tím show skutečně končí. Kód prostě nastaví své uid na nulu (čímž si přidělí práva roota), potom udělá nějaké v assembleru napsané finty, aby se vrátil do uživatelského prostoru a přeskočil tak zbytek úklidového procesu.

Z toho všeho plyne několik zajímavých věcí. První je ta, že tento exploit nebyl napsán přes noc nějakým script-kiddie. Byl napsán někým, kdo se docela dobře vyzná v nízkoúrovňovém jaderném kódu a je schopen použít tyto znalosti, aby ze zjevné zranitelnosti, která spočívá v odhalení informací, udělal problém umožňující vykonat kódu. Je zjevně chyba podceňovat ty, kteří exploity píší, ne všichni z nich okamžitě na svou práci upozorní komunitu vývojářů. Nikdo by také neměl předpokládat, že již nenapsali exploity na jiné, zatím neopravené chyby.

Za zmínku také stojí fakt, že obvyklá ochrana proti přetečení zásobníku proti této zranitelnosti nemusí být efektivní. Návratová adresa na zásobníku nebyla přepsána a do datových oblastí nebyl vložen žádný kód. Popisovaná epizoda způsobila obnovení zájmu o technická bezpečnostní opatření v jádře. Tato opatření jsou dobrá, ale bylo by chybou myslet si, že problém vyřeší. Co je skutečně potřeba, je silnější revize patchů z bezpečnostního hlediska; Jonathanovi se nezdá, že by k těmto revizím docházelo.

       

Komentáře

[Jary]

Děkuju za JN.

Povídání o vmsplice bylo zajímavé.