Jaderné noviny – 19. 5. 2011: Skrývání adres před útočníky

30. 5. 2011 | Jirka Bourek | Jaderné noviny | 3991×

Aktuální verze jádra: 2.6.39-rc7. Citáty týdne: Andrew Morton. Omezení skrývání ukazatelů. Integrace paměťových řídících skupin.

Obsah

• Aktuální verze jádra: 2.6.39-rc7
• Citáty týdne: Andrew Morton
• Omezení skrývání ukazatelů
• Integrace paměťových řídících skupin

Aktuální verze jádra: 2.6.39-rc7

Současné vývojové jádro je stále 2.6.39-rc7. Linus oznámil svůj záměr vydat finální verzi 2.6.39 18. května, ale k tomu v době psaní tohoto článku ještě nedošlo. Pravděpodobně jednoduše čeká na to, až vyjdou Jaderné noviny; 2.6.39 téměř určitě bude venku v době, kdy budete tento článek číst.

Stabilní aktualizace: v uplynulém týdnu žádné nevyšly.

Citáty týdne: Andrew Morton

Tahle věcička s %p se mi líbí – je hezká a celkově je to zlepšení. Jestli to umře, zapíchnu do své Ingo panenky další špendlík.

-- Andrew Morton (který poskytl i obrázek zmíněné panenky)

Omezení skrývání ukazatelů

napsal Jonathan Corbet, 17. května 2011

Během minulých vývojových cyklů byla k vidění cílená snaha zlikvidovat prosakování jaderných adres do uživatelského prostoru. Má se za to, že odhodlaný útočník by tyto adresy mohl použít k tomu, aby zjistil, kde jsou v paměti důležité struktury; to je velmi důležitý krok při snaze tyto struktury poškodit. Dává tedy smysl vyhnout se odhalování jaderných adres v souborech v /proc a na dalších místech, kde jádro předává informace uživatelskému prostoru.

V počátku vývojového cyklu 2.6.39 byl začleněn patch, který cenzuruje jaderné adresy v /proc/kallsyms a /proc/modules. Na takovém systému /proc/kallsyms vypadá takto:

...
0000000000000000 V callchain_recursion
0000000000000000 V rotation_list
0000000000000000 V perf_cgroup_events
0000000000000000 V nr_bp_flexible
0000000000000000 V nr_task_bp_pinned
0000000000000000 V nr_cpu_bp_pinned
...

Není potřeba říkat, že vynulování všech informací o adresách způsobí, že tento soubor bude mnohem méně užitečný než dříve. Co ale k této změně přitáhlo pozornost, bylo hlášení, že perf v takovém případě hlásí nesmyslné informace. Zdá se, že perf nedetekoval skrývání jaderných adres, takže s klidem použil nuly.

Jednoznačně je to chyba v perfu; opravena bude v krátkosti. Mnoho vývojářů si ale stěžovalo na skrývání jaderných adres ve výchozím nastavení. Kvůli takovému chování je systém hůře použitelný a určitě dojde i na další nepříjemná překvapení. Lidé, kteří chtějí dodatečné zabezpečení poskytované touto vlastností, si o ně mají explicitně říci. David Miller poukázal na to, že další bezpečnostní technologie – například SELinux – také nejsou ve výchozím nastavení zapnuté.

Tento argument zvítězil, takže finální 2.6.39 nebude jaderné ukazatele skrývat. Každý, kdo je chce skrýt, musí nastavit kernel.kptr_restrict na 1.

Integrace paměťových řídících skupin

napsal Jonathan Corbet, 17. května 2011

Mechanismus řídících skupin umožňuje správci seskupit procesy do skupiny a na tuto skupinu aplikovat politiku pro omezení využívání zdrojů. Tato vlastnost je tu už nějaký čas, ale teprve odnedávna můžeme vidět její významnější používání. Řídící skupiny jsou základem pro plánování CPU podle skupin (včetně automatického skupinového plánování podle sezení, které bylo začleněno do 2.6.38), správu procesů v systemd atd. Tato vlastnost je zjevně užitečná, ale také má mezi mnoha jadernými vývojáři jádra špatnou pověst a často je lze slyšet mumlat, že by se řídící skupiny měly z jádra úplně vytrhnout. Ve skutečném světě by nicméně jejich vytržení bylo čím dál tím problematičtější, takže dává smysl zvážit alternativu: opravit je.

Jednou ze stížností je to, že řídící skupiny byly k existujícím jaderným mechanismům „přibity hřebíkem“ místo toho, aby do nich byly správně integrovány. Vzhledem k tomu, že se objevily teprve nedávno, není to velké překvapení – když se do dlouho existujícího jaderného kódu přidávají významné nové vlastnosti, je přirozené držet se stranou a minimalizovat změny ve stávajícím kódu. Přibít takto kód na stranu ale není dobrá cesta k optimálnímu řešení, které bude možné dlouhodobě udržovat. Nedávná práce na řadiči paměti tento problém zdůrazňuje – a ukazuje na zlepšení této situace.

Mapa systémové paměti se skládá z jedné struct page pro každou fyzickou stránku v systému; lze ji považovat za rozsáhlé pole struktur, které odpovídá poli stránek:

Jádro udržuje globální seznam nejméně používaných stránek [least recently used, LRU] a s jeho pomocí sleduje aktivní stránky. Nově aktivované stránky se ukládají na konec seznamu; když je potřeba stránky odebírat [reclaim], stránky na začátku seznamu se zkoumají nejdříve. Struktura vypadá nějak takto:

Většina záludného kódu v systému pro správu paměti se zabývá tím, jak jsou tyto stránky vkládány na seznam a jak se v něm pohybují. Skutečný stav je samozřejmě o něco komplikovanější. Jádro ve skutečnosti udržuje dva LRU seznamy, ten druhý obsahuje „neaktivní“ stránky, které byly odmapovány, ale stále v systému existují:

Jádro přesune stránky z aktivního do neaktivního seznamu, když si myslí, že v blízké budoucnosti nebudou použity. Stránky v neaktivním LRU lze rychle přesunout do aktivního seznamu, pokud se k nim pokusí přistoupit nějaký proces. Neaktivní seznam lze považovat za určitou testovací oblast pro stránky, u kterých systém zvažuje, že by je mohl brzy zabrat pro použití jinde.

Situace je samozřejmě ještě o něco komplikovanější. Současná jádra ve skutečnosti udržují pět LRU seznamů. Anonymní stránky mají samostatný aktivní a neaktivní seznam – politika pro zabírání stránek je zde odlišná a pokud systém běží bez swapu, nemusí být vůbec možné nějaké stránky zabrat. Také existuje seznam stránek, o kterých se ví, že je nepůjde znovu zabrat – příkladem mohou být stránky, které byly zamčeny v paměti. Jo, a samozřejmě je potřeba říci, že každá tato sada existuje pro každou paměťovou zónu. Takže i když se počet seznamů zvyšuje, jako celek se tato sada nazývá „globální LRU“.

Vytvořit obrázek, ve kterém by byly zachyceny všechny tyto seznamy, by přetížilo poměrně neadekvátní kreslířské schopnosti autora článku, takže představit si takovou strukturu budiž cvičení pro čtenáře.

Řadič paměti přidává další úroveň složitosti, protože potřebuje zabírat stránky patřící specifickým řídícím skupinám. Řadič potřebuje u každé stránky sledovat víc informací včetně jednoduchého ukazatele spojujícího každou stránku s řídící skupinou, které je účtována. Přidat tyto informace do struct page rozhodně nebylo možné; tato struktura je už teď přecpaná a je jenom malý zájem ji zvětšovat. Řadič paměti tedy přidává pro každou stránku novou strukturu page_cgroup; v podstatě tím vytváří novou stínovou mapu paměti:

Když jsou aktivní řídící skupiny pro paměť, pro každou skupinu se udržuje další kompletní sada LRU seznamů. Struktury list_head potřebné pro udržování těchto seznamů se uchovávají ve struktuře page_cgroup. Výsledkem je zmatená struktura, která vypadá nějak takto:

(Situace je opět o něco komplikovanější, než je zde vyobrazeno; mezi jinými věcmi je mezi LRU seznamy a struct mem_cgroup série překrývajících struktur.)

Správa tímto způsobem má mnoho nevýhod. Globální zabírání stránek používá globální LRU jako vždy, takže při své práci kompletně ignoruje řídící skupiny. Zabere tak stránky bez ohledu na to, jestli patří skupině, která přesahuje limit. Zabírání podle řídících skupin naproti tomu pracuje pouze s jednou skupinou naráz; výsledkem je to, že některé skupiny jsou omezovány, zatímco na jiné se nesahá. Násobné LRU seznamy jsou nejenom složité, ale také drahé. Struktura list_head má na 64bitovém systému 16 bytů. Pokud systém má 4GB paměti, má milion stránek a jenom pro infrastrukturu spojenou s LRU seznamy pro jednotlivé skupiny je tak vyhrazeno 16 milionů bytů.

Na tuto situaci naráží vývojáři, když říkají, že řídící skupiny byly ke zbytku jádra „přibity“. Dané uspořádání bylo efektivním způsobem, jak zjistit, co představuje správa paměti tímto způsobem, ale rozhodně je zde prostor pro zlepšení.

Patche pro naturalizaci memcg, jejichž autorem je Johannes Weiner, reprezentují pokus zlepšit tuto situaci tím, že se řadič paměti lépe integruje do zbytku subsystému virtuální paměti. Jádrem této práce je odstranění duplicitních LRU seznamů. S touto sadou patchů konkrétně přestává existovat globální LRU – všechny stránky existují přesně v jednom LRU seznamu specifickém pro skupinu. Stránky, které nepatří žádné specifické skupině, jdou do LRU seznamu pro „kořenovou“ skupinu na vrcholu hierarchie. Zabírání podle skupin zjednodušeně přebírá práci po starším kódu globálního zabírání; i systém, na kterém jsou řídící skupiny zakázány, se považuje za systém, ve kterém je právě jedna řídící skupina obsahující všechny běžící procesy.

Algoritmy pro zabírání paměti se v této situaci rozhodně musí změnit. Základní algoritmus nyní nejprve projde hierarchii řídících skupiny [depth-first traversal] a v každé se pokusí zabírat stránky. Neexistuje žádné globální stárnutí stránek; každá skupina má svoje nejstarší stránky bez ohledu na to, co se děje v ostatních skupinách. Pro každou skupinu se samozřejmě zvažují měkké a tvrdé limity, když se zjišťuje, kolik paměti se má uvolnit. Konečným výsledkem je to, že globální zabírání stránek se rozprostře mezi všechny řídící skupiny, přičemž je implementována politika každé skupiny. Do tohoto mechanismu byly integrovány i měkké limity, takže jejich vynucování je nyní rovnoměrněji rozdělené mezi všechny řídící skupiny v systému.

Johannesův patch zlepšuje situaci a zároveň zmenšuje současný kód o více než 400 řádek; také se zbavuje ceny za duplikaci LRU seznamu. Jeho nevýhodou je, že provádí zásadní změny v algoritmech zabírání paměti jádrem; takové změny mohou na specifických typech zátěže způsobit překvapivé regrese, a tudíž vyžadují hodně testování a zkoumání. Pokud se taková překvapení neobjeví, vypadá tento patch již ve své první fázi jako slibný krok směrem k tomu, aby se z řídících skupin stala pořádná vlastnost jádra.

       

Komentáře

[Karry]

Ingo panenka mě poslala do kolen...

[clayman]

To jo, ale jinak ten pes musel trpět jako pes...

[Mrkva]

Nemá srát dikobrazy :)

[salam]

Když je blbá hlava, trpí celé tělo.

[Petr Tomášek]

se ani nedivím Reiserovi... řekl bych, že programování jádra leze pěkně na mozek

[geebranz]

Smart way for prevention

Reap

[ludvik]

nevíte někdo, kdy bude 2.6.39.1 ?

[Xerces]

Dneska večer, nebo zítra ráno.

[David Heidelberg]

Myslis?

[Petr Tomášek]

P.S. bude tam nějaká ochrana, aby si to útočník nemohl zase vypnout? Anebo to je jen parametr při bootu?

[Luboš Doležel (Doli)]

No, předpokládám, že má jít o ochranu před získáním roota. A pokud se mu už podaří vypnout tohle jako ne-root, tak to je díra sama o sobě.

[Zopper]

Není to náhodou nastavení pro kompilaci? Obvykle se takovéto věci nastavují právě před kompilací.

[Luboš Doležel (Doli)]

Jaké věci? Tohle je volba sysctl.

[Petr Tomášek]

Ale nastavit to snad jde i přes argumenty jádra (při bootu), ne?

[zp]

least recently used znamená nejdéle nepoužitý, ne nejméně používaný

[trekker.dk]

Njn, chybička se vloudila...