Jaderné noviny – 13. 1. 2011: Co jde do 2.6.38, příznaky RO a NX

24. 1. 2011 | Jirka Bourek

Články - Jaderné noviny – 13. 1. 2011: Co jde do 2.6.38, příznaky RO a NX  

Aktuální verze jádra: 2.6.37. Vánoční citáty: Ted Ts'o, Ingo Molnár, Linus Torvalds, Andrew Morton, Mike Waychison. Citáty tohoto týdne: Andrew Morton, Mike Waychison. Jak nezačlenit protokol. Začleňovací okno 2.6.38, část první. Rozšíření používání RO a NX.

Obsah

• Aktuální verze jádra: 2.6.37
• Vánoční citáty: Ted Ts'o, Ingo Molnár, Linus Torvalds, Andrew Morton, Mike Waychison
• Citáty tohoto týdne: Andrew Morton, Mike Waychison
• Konec dcache_lock
• Jak nezačlenit protokol
• Začleňovací okno 2.6.38, část první
• Rozšíření používání RO a NX

Aktuální verze jádra: 2.6.37

Jádro 2.6.37 je venku, vydáno bylo 4. ledna. Mezi nové vlastnosti patří vylepšení škálovatelnosti ext4, návěstí skoků, „tiny preempt RCU“, další práce na odstranění BKL, odstranění bariér v blokovém subsystému, podpora větší části Dom0, fanotify bylo znovu zapnuto atd. O mnoho více informací najdete na stránce o 2.6.37 na KernelNewbies. Když se to vezme z nadhledu, myslím si, že 2.6.37 bylo poměrně klidné. To se pravděpodobně s otevřením začleňovacího okna změní, protože se těším na to, až přetáhnu na RCU založené vyhledávání cest [pathname lookup] a podobné zajímavé vlastnosti. Takže si užijte klid, dokud trvá. I když je začleňovací okno teoreticky otevřené, Linus řekl, že chvilku počká, aby 2.6.37 stihlo vychladnout a lidi měli motivaci se na něj podívat dřív, než začnou bláznit s novými vlastnostmi v novém stromě.

Začleňovací 2.6.38 je otevřené, takže není žádná vývojová verze jádra. V článku níže najdete shrnutí toho, co bylo zatím začleněno.

Stabilní aktualizace: Jádra 2.6.36.3 a 2.6.32.28 byla vydána 7. ledna; obě obsahují velký počet důležitých oprav.

Aktualizace 2.6.34.8 vyšla 6. ledna; také obsahuje mnoho oprav.

Vánoční citáty: Ted Ts'o, Ingo Molnár, Linus Torvalds, Andrew Morton, Mike Waychison

Zjednodušeně – souborové systémy nejsou databáze a databáze nejsou souborové systémy. Programátoři aplikací mají bohužel nešťastné tendence používat souborové systémy jako databáze, a pak se musí vyrovnat s následky.

-- Ted Ts'o

Jednoduše nepřidáváme do jádra věci, které mohou způsobit přetečení zásobníku, poškození paměti a trojitý výpadek, pokud se náhodou spustí neobvyklý ladící výpis v kontextu IRQ.

-- Ingo Molnár

Není absolutně žádná omluva pro nekonečnou smyčku v jaderném režimu. A rozhodně to není „druhý konec je nekompetentní“.

KAŽDÝ je občas nekompetentní. To prostě znamená, že druhému konci nesmíte moc věřit. Nemůžete říct „potřebujeme, aby server byl příčetný, jinak se to zasekne.“

-- Linus Torvalds

Citáty tohoto týdne: Andrew Morton, Mike Waychison

Zlaté pravidlo je, že když programátor čte kus kódu, měl by pochopit, proč tam je. Ani omylem se nenajde programátor, který by se podíval na tenhle kód a řekl „aha, tohle musí být workaround kvůli -finline-functions gcc-4.5“

-- Andrew Morton

S téměř každým povýšením jádra, které jsme dělali, jsme narazili na spoustu míst, kde se řetězce v logu malinko změnily a naše infrastruktura přestala fungovat :( Najít je všechny je problematické a často se na to přijde až později během nasazování. Pro časový plán nasazování to má katastrofální následky, protože rebootovat tolik strojů, kolik máme, no, to chvíli trvá.

Omlouvám se, jestli se to nehodí k tvému komentáři výše, ale měl jsem pocit, že by si lidi měli uvědomit, že printk() není dobrým základem pro automatizaci.

-- Mike Waychison

Konec dcache_lock

napsal Jonathan Corbet, 12 ledna 2011

Jedna z nejvýznamnějších vlastností v 2.6.38 nebude pro uživatele přímo viditelná; je to sada patchů škálovatelnosti dcache Nicka Piggina. Tyto patche záludnými způsoby přepracovávají vrstvu virtuálního souborového systému a odstraňují dlouhodobé problémy se škálovatelností. Změny byly dost významné na to, aby Linus po jejich začlenění na několik dní pozastavil začleňovací okno a řekl:

Je to děsivé, protože tohle je základní kód a nový model vyhledávání s RCU je mnohem chytřejší a mnohem záludnější než starý spinlock dentry_lock.

Je to nicméně poměrně ohromující a opravdu jsem to chtěl začlenit, protože některá čísla týkající se výkonnosti jsou docela omračující. Například "find . -size" s horkou cache v mém adresáři home (což v podstatě jenom vyhledává jména a pak pro každý soubor rekurzivně načítá informace pomocí stat) je o 35 % rychlejší. A to je případ bez vláken. Ne nějaká podivná high-endová škálující věc a ne nějaká překompilovaná binárka, která využívá nové možnosti. Vyhledávání cest je prostě rychlejší.

Kód z větší části funguje, ale testeři nahlásili jeden nebo dva problémy a pravděpodobně jsou v něm další. Lidé, kteří testují vývojová jádra, by tentokrát měli mít opravdu dobré zálohy. Nick také poznamenal, že souborové systémy mimo strom budou muset trochu pozměnit způsob, jakým pracují s VFS.

Jak nezačlenit protokol

napsal Jonathan Corbet, 12 ledna 2011

„Open Base Station Architecture Initiative“ je konzorcium firem, které se pokouší vytvořit otevřený trh s hardwarem pro základnové stanice mobilních sítí. Jedna z věcí, kterou toto konzorcium definovalo, je protokol UDPCP – protokol založený na UDP, který slouží pro komunikaci mezi základnovými stanicemi. UDPCP poskytuje spolehlivý přenos, multicast a další. Linuxové jádro tento protokol v současnosti nepodporuje, ale Stefani Seiboldová zaslala patch, který by podporu do jaderného síťového stacku přidal.

Kód přitáhl mnoho komentářů, ale jedna poznámka Erica Dumazeta stojí za povšimnutí: zaslaná implementace funguje pouze s IPv4. Vývojáři síťování dali jasně najevo, že nemají zájem přijmout v roce 2011 implementaci pouze pro IPv4; v jakémkoliv novém kódu je vyžadována podpora pro IPv6.

Stefani odpověděla, že žádné základnové stanice IPv6 nepodporují a žádný zákazník o tuto podporu nestál, takže aktuálně nedává smysl to poskytovat. Odpověď se ale nezměnila; vývojáři nemají zájem o začlenění kódu, u kterého je garantováno, že ho bude nutné v blízké budoucnosti opravit. Stefani tento požadavek popsala slovem dogmatický, ale také si, zdá se, uvědomila, že se ho nezbaví. UDPCP tedy zatím zůstává mimo hlavní řadu, ale snad nakonec uvidíme přepracovanou verzi s podporou IPv6.

Začleňovací okno 2.6.38, část první

napsal Jonathan Corbet, 12 ledna 2011

V době psaní tohoto článku bylo začleněno téměř 5400 neslučovacích sad změn, tento cyklus tedy vypadá jako další rušný s poměrně slušným důrazem na přepracování nízkoúrovňové infrastruktury. Mezi zatím začleněné vlastnosti viditelné pro uživatele patří:

• Patch skupinového plánování podle sezení byl začleněn. Díky této změně by při mnoha druzích zátěže měl systém reagovat rychleji.

• Byla začleněna sada patchů škálovatelnosti dcache. Tento záludný kód může poskytnout významné zlepšení výkonnosti pro některé typy zátěží intenzivně využívajících souborové systémy.

• Na architektuře x86 jsou jaderné moduly konečně nahrávány pouze pro čtení; v celém jádře jsou data označena jako nespustitelná. Více informací najdete v článku níže.

• Síťová vrstva nyní podporuje směrování odesílaných paketů. Tato vlastnost vylepšuje výkonnost při odesílání tím, že vkládá data do správné fronty (lokální pro CPU)

• Podpora pro síťový protokol batman-adv se ve stromě staging vyvinula tak, že byla nyní přesunuta do hlavního stromu jádra.

• Sada patchů pro důvěryhodné a zašifrované klíče byla začleněna

• Souborový systém ext3 získal podporu pro operace zahazování v dávkách a ioctl() FITRIM.

• Emulace pro API Video4Linux1 byla odstraněna z jádra; všechny zbývající V4L1 aplikace budou potřebovat knihovnu v uživatelském prostoru nebo musí být konvertovány na V4L2. Některé nepodporované ovladače V4L1 (cpia, stradis) byly odstraněny. Odstraněny byly i zastaralé ovladače ibmcam, konicawc a ultracam; tato zařízení jsou nyní podporována ovladači GSPCA.

Mezi změny viditelné pro jaderné vývojáře patří:

• Pro sledovací body mohou být makrem TRACE_EVENT_FLAGS() specifikovány příznaky. První zajímavý příznak je TRACE_EVENT_FL_CAP_ANY, který umožňuje používání sledovacího bodu neprivilegovaným uživatelem; tento příznak byl aplikován na sledovací body v systémových voláních.

• Příkaz perf trace byl přejmenován na perf script.

• V jádře jsou nyní podporovány podmíněné sledovací body.

• Změnilo se mnoho sledovacích bodů spojených se správou napájení; více informací vizte v Documentation/trace/events-power.txt. Do subsystému RCU a ovladače Radeon byly přidány nové sledovací body.

• Funkce cancel_rearming_delayed_work() a cancel_rearming_delayed_workqueue() jsou zastaralé a v 2.6.39 budou odstraněny.

• Překladový systém jádra je nyní schopen připojit bloby stromu zařízení přímo do obrazu.

• Objevuje se nový bit kvalifikace (CAP_SYSLOG), který řídí přístup k systémovému logu.

• Nová funkce kref_sub() umožňuje kódu vrátit několik odkazů v jediném volání.

• API reprezentace externích dat (external data representation, XDR) bylo změněno tak, aby zahrnovalo koncept „xdr_stream“ (XDR proudy); všichni uživatelé v jádře byli aktualizováni. XDR proudy nabízejí lepší odolnost proti přetečení bufferů, což zvyšuje bezpečnost protokolů implementovaných pomocí XDR.

• Do jaderných subsystémů, které musí udržovat seznam časovačů, byla přidána infrastruktura „timerlist“. Přehled API vizte v <linux/timerlist.h>.

• Jádro přímého vykreslování získalo možnost pracovat s časovými značkami pro přesné vertikální zatmívání [vertical blanking]; tuto vlastnost některé ovladače používají pro zlepšení souladu s rozšířením OpenML.

Lze očekávat, že začleňovací okno bude otevřené přibližně do 19. ledna. Zůstává tedy spousta času na to, aby si do hlavní řady našla cestu další spousta zajímavých vlastností; příští týden shrneme změny druhé poloviny začleňovacího okna.

Rozšíření používání RO a NX

napsal Jake Edge, 12 ledna 2011

Stránky v paměti, které spravuje jádro, jsou řízeny příznaky řízení přístupu, které jsou trochu analogické k oprávněním, která se aplikují na soubory. Tyto příznaky určují, jestli je do stránky možné zapsat a jestli je její obsah možné spustit. Oba atributy jsou užitečné v tom, že mohou omezit, co se ve stránce stane, když dojde na nějakou chybu v programování nebo bezpečnostní útok. Pár patchů, který byl začleněn v tomto začleňovacím okně, rozšiřuje na architektuře x86 používání těchto příznaků.

Příznaky pro přístup ke stránce jsou na rozdíl od práv k souborům vynucovány hardwarem pro správu paměti. Příznaky, které nás zajímají v souvislosti se zmíněnými patchi, jsou „zápis“ (write) a „spuštění“ (execute); z obou vyplývá právo ke čtení, takže se často specifikují jako RO+X (spustitelné, pouze pro čtení) či RW+NX (zápis povolen, nespustitelné). Omezením toho, co se smí se stránkou dělat, se trochu omezují bezpečnostní problémy, protože například přetečení bufferu v NX stránce nebude přímo užitečné pro vykonání kódu.

Paměť, kterou jádro používá k uložení dat pouze pro čtení (tj. segment .rodata), bylo možné označit pouze ke čtení od 2.6.16, které vyšlo začátkem roku 2006, v závislosti na nastavení CONFIG_DEBUG_RODATA. V 2.6.25 byl jaderný segment .rodata označen jako NX, ale pouze pro architekturu x86_64. Patch, který původně mířil do 2.6.30 (pro 32 i 64 bitové architektury) rozšířil používání NX na všechny datové stránky jádra včetně zapisovatelných sekcí pro inicializovaná data a BBS.

Patch vytvořili Siarhei Liakh a Xuxian Jiang, ale odpadl do příkopu, protože na jednom z testovacích systémů Inga Molnára způsobil pády při bootu. Když Kees Cook přišel s nápadem lépe chránit paměť jádra, Ingo si vzpomněl, že Matthieu Castet tyto patche oprášil a zaslal dva z nich již v srpnu. Po několika iteracích Ingo dva z nich přetáhl do stromu -tip a Linus je přetáhl do hlavní řady v začleňovacím okně 2.6.38.

Revidovaný patch je poměrně přímočarý. Pokud je nastaveno CONFIG_DEBUG_RODATA, různé sekce jádra (.text a .rodata) jsou zarovnány na hranice stránek, jak co se týče počátečních, tak koncových adres. NX bit je nastaven pro všechny stránky od konce sekce .text (tj. kód) po adresu _end, která značí konec sekce jaderných dat.

Tento patch řešil další dva kousky skládačky, první z nich byl pravděpodobně příčinou pádů, které Ingo pozoroval u starší verze patchů. Některé starší systémy, které používají PCI BIOS, potřebují, aby některé stránky v oblasti 640k-1M byly spustitelné. Dále jsou tu nějaká mapování ISA, která potřebují do dané oblasti povolený přístup pro zápis. Než tohle všechno řešit a potenciálně narazit na zabugovaný hardware, patch jednoduše nastavuje všechny stránky v této oblasti na RW+X na systémech, kde se používá PCI BIOS. Druhá změna jednoduše modifikuje free_init_pages() a zapíná NX u všech stránek, které jsou takto uvolňovány, takže když se stránka má znovu použít, musí se explicitně povolit vykonávání kódu, pokud tam má být nějaký uložen.

S tím spojený patch přidává příznaky pouze pro čtení a nespustitelné stránkám, které jsou používány jadernými moduly. Přišel od stejných vývojářů a zdá se, že byl zahozen z -tip společně s patchem NX. A jako ten druhý patch ho Matthieu posunul o poslední kousek a nechal ho začlenit do hlavní řady.

Patch dělí oblasti module_core a module_init do tří částí: kód, data pouze pro čtení a zapisovatelná data. Každá z těchto částí je zarovnána na hranici stránek a příznaky stránek jsou nastaveny těsně před návratem z load_module(). Pro kód je nastaveno RO+X, zatímco data dostanou NX a RO nebo RW podle typu. Tyto změny jsou všechny řízeny nastavením CONFIG_DEBUG_SET_MODULE_RONX.

Kromě nastavení příznaků stránek při nahrávání modulu musí jádro příznaky také vyresetovat, když se modul uvolňuje. Krom toho se po inicializaci modulu uvolňuje oblast module_init a její stránky se taktéž musí nastavit zpět na RW+NX. A je tu ještě další vráska: Ftrace potřebuje mít možnost modifikovat kód v modulech, když chce zapnout sledovací body, takže patch poskytuje prostředky, s nimiž je možné všechny stránky s kódem přenastavit na zapisovatelné, aby Ftrace mohl kód změnit, a následně je přepnout zpět na RO.

Hlavními náklady za tyto patche jsou malé kousky vyplýtvané paměti způsobené zarovnáváním různých sekcí v paměti. Vzhledem k tomu, že tyto náklady nejsou kromě embedded systémů s opravdu významně omezenými zdroji nijak významné, budou pravděpodobně CONFIG_DEBUG_RODATA a CONFIG_DEBUG_SET_MODULE_RONX ve většině distribucí zapnuty – nebo možná budou zapnuty ve výchozím nastavení, i když na to Linus a další obvykle nadávají.

Fakt, že tyto patche byly nějaký čas kolem, ale nikdy se jim nezdařil skok do hlavní řady, je nešťastný. Neexistuje žádná osoba nebo skupina, která by se snažila nahnat jaderné bezpečnostní patche do hlavní řady, i když Kees a Dan Rosenberg se odnedávna snaží tyto změny protlačit. Keesův dotaz pomohl oba tyto patche vzkřísit; bez jeho zájmu by se pravděpodobně tiše povalovaly mimo jádro mnohem déle.

Také stojí za to poznamenat, že mnoho z těchto ochran je již dlouho k dispozici v jádrech grsecurity/PaX. I když nikdy nedojde k celkovému importu vlastností z těchto jader, patche, které implementují příčetné kousky (přinejmenším podle Linuse) lze přetáhnout. To by mělo přinést bezpečnější jádro, což je něco, za čím rozhodně stojí se hnát.

Diskuse k tomuto článku

[Filip Jirsák]

Přebývá "e":

Ve článku níže

[Heron]

The problem is an incompetent userspace programmer that tried to use small files and file system calls when they should have used a database.

Díky Tede. Celý thread stojí za přečtení.

[pavlix]

Mě se na spoustu věcí souborové databáze líbí.

[imploder]

Pokud jde o textové databáze, tak ty jsou pěkné (dají se zobrazovat a upravovat jednoduše jako text), ale naprosto to zabíjí neefektivita zápisu a vyhledávání. Text je strašně primitivní datová struktura.

[pavlix]

ale naprosto to zabíjí neefektivita zápisu a vyhledávání.

To nelze obecně tvrdit.

Text je strašně primitivní datová struktura.

Což zní jako velmi dobrý důvod, proč ji v mnoha případech používat.

[imploder]

Doprostřed velké tabulky tvořené textovým souborem se nedá v rozumném čase vložit řádek; pro vyhledávání se dá vygenerovat index, ale někde mimo tabulku. Je to takové barbarské řešení (co se týká výkonu) - u malého množství dat to nevadí (počítače jsou rychlé, tak co...), když dat přibude, tak se z toho stane neřešitelný problém.

Což zní jako velmi dobrý důvod, proč ji v mnoha případech používat.

Tím "primitivní" jsem tady nemyslel, že je jednoduchá (to je vždycky jenom dobře), myslel jsem tím, že je málo pokročilá. Já jsem taky rád, když se dá jeden nástroj (textový editor) používat na hodně věcí, ale to kvůli tomu máme zapomenout na efektivní datové struktury? Už i MS se snaží vytvořit filesystém postavený na něčem pokročilejším, než jsou souvislé kusy dat (soubory v dnešním slova smyslu): WinFS (zatím ale všechny tyhle jeho projekty "strukturovaných úložišť" byly nakonec zrušeny, včetně WinFS). Myslím, že dřív nebo později se nějaké standardní strukturované úložiště jako součást systému prosadí. No, asi spíš později.

[zulu]

BBS -> BSS

[geebranz]

Interesting contents on this one

Reap