Jaderné noviny – 16. 2. 2012: Když hardware není vaším kamarádem

27. 2. 2012 | Luboš Doležel | Jaderné noviny | 4213×

Aktuální verze jádra: 3.3-rc3. Citáty týdne: Andrew Morton, Hugh Dickins. O schopnostech Btrfs (;login:). Uvolněn zdrojový kód ovladače Lima pro GPU Mali. Když se hardwaru důvěřuje až příliš.

Obsah

• Aktuální verze jádra: 3.3-rc3
• Citáty týdne: Andrew Morton, Hugh Dickins
• O schopnostech Btrfs (;login:)
• Uvolněn zdrojový kód ovladače Lima pro GPU Mali
• Když se hardwaru důvěřuje až příliš

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

Aktuální vývojová verze jádra je 3.3-rc3 vydaná 8. února. Nekonají se žádná velká překvapení, přesně tak to mám rád. Polovina patchů je v ARMu, ale většina z toho je kvůli odstranění nepoužívaného kódu pro mapování DMA z podpory pro bcmring. Takže si nestěžuji.

Stabilní aktualizace: verze 3.0.21, 3.2.6 a 2.6.32.57 byly vydány 13. února s dlouhým seznamem důležitých oprav.

Pro ty z vás, co ještě používáte jádro 2.6.27, je tu verze 2.6.27.60 vydaná 12. února, kterou rychle následovala verze 2.6.27.61 opravující chybu při sestavování. Od verze 2.6.27.59 vydané loni v dubnu se tam dostala spousta oprav.

Citáty týdne: Andrew Morton, Hugh Dickins

-static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
+static inline void *wtf_do_i_call_this(size_t n, size_t size, gfp_t flags)
 {
 	if (size != 0 && n > ULONG_MAX / size)
 		return NULL;
-	return __kmalloc(n * size, flags | __GFP_ZERO);
+	return __kmalloc(n * size, flags);
+}
+
+static inline void *kcalloc(size_t n, size_t size, gfp_t flags)
+{
+	return wtf_do_i_call_this(n, size, flags | __GFP_ZERO);
 }

-- Andrew Morton

Když jsem před rokem konečně zjistil, kdo je to ta Virginia opěvovaná v mm/memory.c a mm/page-writeback.c, tak jsem byl opravdu nadšen.

-- Hugh Dickins

Koukám na to a pořád váhám, co jsi vlastně myslel, když jsi napsal „váček ftrace“. Opravdu jsi mě dostal! Ale nesmíš nám to prozradit – tím bys zkazil celou srandu.

-- Andrew Morton

O schopnostech Btrfs (;login:)

V únorovém vydání ;loginu: je detailní přehled zaměřený na Btrfs od vývojáře Josefa Bacika. Snapshotování v Btrfs je snadné používat i pochopit. Snapshot se objeví pod snapshotovaným adresářem jako obyčejné adresáře a můžete je tak i procházet. Ve výchozím nastavení jsou všechny snapshoty v Btrfs zapisovatelné, ale pokud si tak zvolíte, mohou být i pouze ke čtení. Snapshoty pouze ke čtení jsou skvělé, pokud děláte snapshot pro zálohování a po dokončení zálohování jej zase odstraníte. Zapisovatelné snapshoty se také hodí, protože můžete dělat věci jako vytvořit snapshot před aktualizací systému; pokud vám pak update něco v systému rozbije, můžete restartovat do snapshotu a používat jej jako běžný souborový systém.

Uvolněn zdrojový kód ovladače Lima pro GPU Mali

Projekt ovladače Lima zveřejnil kód svého open source grafického ovladače, který podporuje GPU Mali-200 a Mali-400. Cílem tohoto ovladače je dodat do grafických ovladačů pro ARM SoC všechny výhody open source. To, že jsou teď dostupné jen binární ovladače, dělá vývoj a údržbu náročnějšími a současně to zhoršuje přenositelnost a kompatibilitu a omezuje to možnost volby. Každý, kdo řešil podporu GPU na ARM, ať už je to pro Linux s GNU nebo pro Android, ví, jaká otrava je řešit tyto binárky. Lima to vyřeší, ale ještě to bude chtít trochu času.

Když se hardwaru důvěřuje až příliš

Všichni, co se už nějakou dobu věnují nízkoúrovňovému vývoji v jádře, vědí, že hardware není jejich přítelem. Očekávat od hardwaru, že bude poslušný, je zárukou problémů; namísto toho je třeba s hardwarem zacházet, jako by to byl chytrý a svéhlavý pes. S trochou snahy ho můžete naučit úctyhodným kouskům, ale stačí trocha nepozornosti a ukradne vám z grilu večeři a schová ji pod pohovkou. Dobrou zprávou je, že vývojáři Linuxu svému vztahu s hardwarem rozumí a dávají si pozor, aby mu příliš nedůvěřovali. Nebo to si alespoň myslíme.

Podívejme se na tento úryvek kódu z drivers/char/hpet.c:

do {
	m = read_counter(&hpet->hpet_mc);
	write_counter(t + m + hpetp->hp_delta, &timer->hpet_compare);
} while (i++, (m - start) < count);

V tomto příkladu je read_counter() jednoduchým makrem nad readl(). Ovladač zapisuje do porovnávacího registru časovače ve smyčce a počítá s tím, že hodnota „hlavního čítače“ z HPET nakonec jednou překročí hraniční hodnotu. Téměř vždy se přesně tak stane. Jenže pokud se HPET trochu poblázní a přestane vracet smysluplné hodnoty při čtení hlavního čítače, tak se z výše uvedeného cyklu stane cyklus nekonečný. Jádro věří hardwaru, že se bude chovat rozumně, ale hardware se může rozhodnout trochu jinak.

"Usbmuxd" je daemon, jenž usnadňuje komunikaci s různými iZařízeními od Apple. Přednedávnem byl tento patch pro usbmuxd označen za opravu bezpečností chyby, která nakonec získala označení CVE-2012-0065. Šlo o to, že daemon četl sériové číslo ze zařízení a kopíroval jej do vnitřního pole, aniž by zkontroloval jeho délku. Zneužít této zranitelnosti není snadné – je třeba mít možnost připojit USB zařízení, které bylo navrženo tak, aby dokázalo vyvolat přetečení tohoto konkrétního bufferu. Ale i tak to je zranitelnost a stojí za pozornost, že čím dál více USB zařízení jsou ve skutečnosti linuxové systémy používající kód pro „USB gadgety“; vytvoření zákeřného zařízení pak není tak těžké. Takže tato zranitelnost by mohla být zajímavá pro ten typ útočníků, co nechávají zákeřné USB flashky pohozené na parkovištích.

Tato chyba je rovněž důsledkem důvěry v hardware. Jak můžeme vidět, hardware může být naprosto nepokrytě zlý. V ostatních případech může jít o důsledek opotřebení, výkyvů v dodávané energii, kosmického záření a rozličných dovedností těch, co píší firmware – v podobě uzavřeného kódu, který nikdo nekontroluje. I ve světě, kde by tlak na ceny neměl za následek co největší úspory na komponentách, mohou chyby hardwaru představovat problém.

Poučení by už teď mělo být jasné: vývojáři ovladačů by měli s hardwarem jednat vždy podezřívavě a nic nebrat za jisté. Problémem je, že i těm nejsvědomitějším vývojářům (a kontrolorům) může tento typ chyb snadno proklouznout. V téměř všech případech to vypadá, že ovladač funguje dobře i bez speciálních kontrol v kódu; hardware koneckonců povětšinou funguje správně, dokud se nepřihodí něco zlého. Někdy spatří výsledné selhání vývojář, což má za následek „no jasně, musím se ujistit, že se tam a tam hardware nezblázní“ – neboli moment, který je při vývoji ovladačů až příliš častý. Jindy se to přihodí kdesi daleko u nějakého uživatele a nikdo netuší proč.

Bylo by hezké, kdyby počítač mohl vývojářům říci, v jakých místech hardwaru až příliš důvěřují; pak by se mohl přeskočit celý krok nazvaný „vystopovat původ problému“. A takový nástroj pro statickou analýzu dokonce existuje a nazývá se Carburizer, autory jsou Asim Kadav, Matthew J. Renzelmann a Michael M. Swift. Více o tomto nástroji se dozvíte na jednostránkovém posteru, tomto PDF dokumentu nebo na tomto trochu zběsilém webu.

Ve zkratce dělá Carburizer to, že analyzuje jaderný kód a hledá nedostatečně odolné zacházení s hardwarem. Jeho klíčovou schopností je odhalování potenciálně nekonečných cyklů – cyklů, jejichž ukončení plně závisí na hodnotě získané z hardwaru. V jádře 3.2.1 je, jak už to tak vypadá, více než 1000 takových cyklů. Tento nástroj hledá i případy, kde jsou hodnoty z hardwaru bez ověřování použity k indexaci polí nebo jsou bezprostředně používány jako ukazatele, i když v těchto případech se objevuje mnohem více planých poplachů. Výsledkem je soubor odkazovaný výše, se kterým pak mohou vývojáři pracovat.

Tento nástroj však neskrývá svůj akademický původ. Je napsaný v Ocamlu a před spuštěním jsou ve stromu nutné určité úpravy. Carburizer dále vyžaduje to, aby velké ovladače rozdělené do několika souborů byly sloučeny do jednoho, což má ten důsledek, že čísla řádek z diagnostiky neodpovídají číslům řádek v kódu, který mají všichni ostatní. To může být jedním z důvodů, proč je navzdory kladné odezvě, když byl tento nástroj v lednu 2011 představen na kernel-janitors, množství oprav docela malé. Nebo to může být prostě jen tím, že se na výsledky podívalo jen pár vývojářů.

Zajímavé je to, že Carburizer dokáže navrhovat opravy. Mezi ně patří přidání časového limitu do potenciálně nekonečných cyklů a přidávání kontrol při indexování polí. Mezitím se Carburizer věnuje i tomu, že opravuje zdánlivě zbytečná volání panic() a přidává logování informací tam, kde si myslí, že ovladač zanedbává hlášení selhání hardwaru. S odděleným modulem pak dokáže pracovat i se zaseknutými přerušeními [stuck interrupts] (ovladač je nucen používat polling) a ještě více věcmi. Výsledný kód ještě nebyl zaslán ke zvážení, což není nutně překvapivé; opravy by měly být velmi konzervativní povahy ve smyslu „nerozbít ovladač“. Tyto opravy zcela jistě nejsou tím, co by člověk při pohledu na kód napsal. Ale nástroj je open source, takže ti, kdo mají zájem, si to mohou sami spustit, aby zjistili, co dokáže.

Ale i bez automatických oprav stojí výstupy programu za pozornost. Počítače mohou být při odhalování řady chyb mnohem schopnější než lidé; jakmile k tomuto byly počítače použity, některé typy chyb z jádra téměř vymizely. Jednoho dne možná budeme mít Carburizer v podobě, kdy bude moci být ohnut do podoby nástroje jako checkpatch; prozatím ale bude nutné se dívat na stížnosti v kódu odděleně a rozhodovat se, co se s tím má udělat.

       

Komentáře

[Honz]

Úsloví "vedle jak ta jedle" se používá v úplně jiném významu, než odpovídá logice citovaného textu...

[pavlix]

Pravda.

[Luboš Doležel (Doli)]

Hmm, vida, když jsem to překládal, tak jsem si vzpomněl na Simpsonovi ve filmu, jak tam zkouší na blbcovi, jestli je zátaras kolem místního jezera odolný. Tam právě tohle říkal a to mě zmátlo.

[kolemjdouci]

Jestli dobře počítám, tak v úryvku o Btrfs od pana Bacika je v pěti větách devětkrát použito slovo snapshot. To už je výkon. Škoda, že se momentálně nedostanu na celý příspěvek, může to být zajímavé počtení.

[Petr Ježek]

Originnál na LWN má navíc pouze diskusi...

[Michal Vyskočil]

Originál je přeci to pdf na usenix.org, ne?

[Ivan]

Na takovou nekonecnou smycku v kernelu jsem taky narazil. Pripojil jsem USB ramecek s diskem. Ten ramecek nahlasil, ze disk ma velikost XY bambilionu bloku. Velikost bloku u USB zarizeni neni nikde definovana a neni mozne ji zjistit. udev script zjistil, ze mam pripojeny novy SCSI disk a nenapadhlo ho nic chytrejsiho, nez zkontrolovat, jestli to nahodou neni nejaky obsurdni HPT pseudo-SCSI raid. A tak se zkusil podivat na "posledni" blok na disku. A tak to spadlo zase nazpatek to kernelu a ten se pokusil o precteni bloku z disku, ktery ale lezel daleko v outu za koncem skutecneho disku. SCSI layer zjistil, ze se z USB celkove precetlo 0 bajtu a vratil "temporary error". No protoze ta chyba byla pouze docasna, tak se z toho disku cetlo znova a znova.

[JS]

Kdo je to ta Virginia?

[Sten]

Virginia O’Hanlon

[lertimir]

to je skutečně nádherné.

[Dusan]

Pekné. Dik za preklad.

[Petr]

Proc tam Andrew pridal tu funkci wtf_do_i_call_this??? Nebo to komitnul omylem neco, co tam mel docasne?

[pavlix]

Trocha programátorského humoru neuškodí :)... doporučuju si to přečíst v klidu, kdy nejsi zatížen každodenní suchou realitou.

[Luboš Doležel (Doli)]

Je třeba si přečíst kontext e-mailu, ze kterého to pochází.