Jaderné noviny - 15. 9. 2016: Exkluzivní vlastnictví rámců stránek

25. 9. 2016 | Redakce | Jaderné noviny | 2485×

Stav vydání jádra. Citáty týdne: Greg Kroah-Hartman, Thomas Gleixner. Lindholm: Vývoj ovladačů UEFI – 1. část. Exkluzivní vlastnictví rámců stránek.

Stav vydání jádra

Současný vývojový kernel je 4.8-rc6, vydaný 11. září. „Stále jsem se ještě nerozhodl, zda uděláme rc8, ale myslím, že zatím nemusím spěchat. Nic nevypadá úplně zle a bude záležet na tom, jak dopadne rc7.“

Seznam známých regresí v řadě 4.8 měl k 11. září 10 položek.

Stabilní aktualizace: 3.14.79, poslední z řady 3.14.x, byla vydána 11. září.

Stabilní aktualizace 4.7.4 (oznámení chybí) a 4.4.21 byly v době vydání tohoto článku v procesu revidování, nyní by již měly být dostupné.

Citáty týdne

Jenže se ukázalo, že příslušnou řadu jádra používali pouze po nějakou dobu během vývoje, načež s tím přestali, jakmile se zařízení dostalo na trh. Podívejte se na všechny ty telefony s Androidem, které využívají zastaralé verze stabilních jader 3.4 a 3.10. Už je ani neaktualizují na novější, a tak to vlastně skoro nijak nepomohlo. Přestože v těchto jádrech pořád opravuji bezpečnostní chyby, nikdo to neposílá dál uživatelům. Mám příklad bezpečnostní chyby, kterou jeden vývojář z Google našel v jádře 3.10 (ale ne v upstreamu). Opravil jsem ji a vydal aktualizaci, tu ale nikdo celých šest měsíců nedostal do telefonů Nexus – až jsem po těch šesti měsících našel toho správného člověka/skupinu, kterou bylo třeba v Google postrčit.

Takže kdokoli měl k dispozici šestiměsíční okno, během kterého mohl snadno získat roota na vašem telefonu.

Lidé říkají: „Podívejte, ve svém produktu používáme LTS jádro, takže všechno musí být v pořádku!“ Ale pokud jej neaktualizují, je rozbité a nezabezpečené a vůbec o nic lepší, než kdyby rovnou použili 3.10.0.

-Greog Kroah-Hartman

Nezbývá mi než dodat:

yell_WTF(nr_wtf_moments);

Hodnotu argumentu funkce ponechám na vaší představivosti.

-Thomas Gleixner

Lindholm: Vývoj ovladačů UEFI – 1. část

Leif Lindholm začal pracovat na seriálu o psaní ovladačů UEFI. „Vzhledem k tomu, že jsem vlastně nikdy ovladač UEFI nenapsal na zelené louce a většina ovladačů, se kterými jsem se dostal do styku, byly hlavně ovladače platformy, řekl jsem si, že by nebylo špatné napsat samostatný ovladač celý od počátku. Výsledkem je tento lehce praktický seriál.“

Exkluzivní vlastnictví rámců stránek

Cílem většiny útoků na jádro je spustit kód dle útočníkova výběru, s právy jádra. Není tedy překvapením, že existuje mnoho technik tvrzení, které jsou zaměřeny na prevenci vložení libovolného kódu do míst, kde by napadené jádro mohlo být přesvědčeno k jeho spuštění. Bohužel návrh jaderného subsystému správy paměti je takový, že řadu technik bránících v přístupu lze obejít. Aktuálně koluje sada patchů, jež má za cíl tuto „díru“ zavřít, přináší však s sebou také zajímavou otázku: je jaderná komunita ochotna obětovat výkon, aby se dosáhlo lepšího zabezpečení?

Útočník, který chce, aby jádro spustilo libovolný kód, čelí problému: kam takový kód vložit, aby ho jádro mohlo spustit? V případě, že je možné jádro přesvědčit, aby spustilo kód, který se nachází v uživatelském prostoru, je mnohem jednodušší tento problém vyřešit, protože vložit kód do paměti uživatelského prostoru zvládne každý. Vzhledem k tomu, že paměť uživatelského prostoru zůstává namapovaná, i když procesor běží v jaderném režimu, vše co je třeba udělat, je přesvědčit jádro, aby skočilo na adresu v uživatelském prostoru. Před lety bylo možné jednoduše namapovat stránku na adrese 0 a najít chybu, která by způsobila, že jádro přeskočí na ukazatel na null. Takové jednoduché útoky se podařilo eliminovat, ale složitější exploity jsou stále běžné.

Je jasné, že nejlepším řeším je ujistit se, že se jádro nikdy nepokusí skočit na adresu v uživatelském prostoru. Pokud se však smíříme s tím, že chyby budou vždycky existovat, má smysl přidat další ochranu, a sice jednoduše zabránit jádru ve vykonávání kódu z paměti uživatelského prostoru. Mechanismy PaX KERNEXEC a UDEREF jsou navrženy tak, aby těmto typům přístupu do uživatelského prostoru zabránily. Nedávno se do hry přidali také výrobci procesorů: Intel nyní má SMAP (Supervisor Mode Access Prevention) a SMEP (Supervisor Mode Execute Protection), zatímco ARM přidal PXN (Privileged Execute-Never). Na systémech, kde jsou tyto mechanismy plně implementovány, by už mělo být pro jádro nemožné spustit kód, který se nachází v paměti uživatelského prostoru.

Až na to, jak stojí v příspěvku Vasileiose P. Kermelise a kol. (PDF), že existuje skulina. Paměť uživatelského prostoru je dostupná skrze stránkovací tabulky procesu a různé mechanismy prevence přístupu pracují tak, že blokují přístup do jádra právě skrze tyto tabulky. Ale jádro zároveň udržuje lineární mapování celého rozsahu fyzické paměti (na 64bitových systémech, u 32bitových systémů je to složitější). Toto mapování má v jádře četná využití, na předních místech seznamu bychom pak našli správu paměti na úrovni stránek. Každé fyzické stránce v systému poskytuje samostatnou adresu. Co je zásadní, jedná se o adresu v jaderném prostoru a na některých systémech (x86 před verzí 3.9, ARM všeobecně) je obsah paměti v tomto rozsahu vykonatelný jádrem.

Jestliže útočník přinutí jádro skočit na přímo mapovanou adresu, nedostane se žádný z mechanismů zabraňujících přístupu k uživatelskému prostoru do hry, a to ani v případě, že cílová adresa odpovídá stránce v uživatelském prostoru. Přímé mapování tedy nabízí pohodlný způsob, jak tyto ochrany obejít. Má to jen jeden háček: útočník musí být schopen určit fyzické stránky obsahující škodlivý kód. Jak vyplývá z příspěvku, soubory pagemap v /proc tyto informace poskytnou – přestože je možné tyto soubory zakázat, distribuce to obvykle nedělají. Takže na většině systémů je všechno připraveno k tomu, aby útočník mohl zneužít chybu, která by způsobila skok na libovolnou adresu, zatímco existující ochranné mechanismy by byly naprosto bezmocné.

(Trošku složitější je to na současných jádrech pro x86, kde již není možné přímo spouštět kód skrze přímé mapování. V takovém případě se útočník musí uchýlit k programování zaměřenému na návratové hodnoty (return-oriented programming) – což pro spoustu útočníků nepředstavuje velkou překážku.)

Řešením, jak bylo popsání v příspěvku a implementováno v sadě patchů exkluzivního vlastnictví stránek (XPFO), kterou zaslal Jürg Haefliger, je odebrat přístup zadními vrátky ke stránkám uživatelského prostoru skrze přímé mapování. Mechanismus je to v principu velmi jednoduchý. Kdykoli dojde k alokaci stránky pro použití v uživatelském prostoru (což jádro už teď označuje pomocí příznaků GFP v požadavku na alokaci), dojde k odstranění přímého mapování této stránky. Takže i když by se útočníkovi podařilo získat přímo mapovanou adresu stránky a přinutit jádro, aby tam skočilo, to vzhledem k nedostatku přístupových oprávnění selže. Když uživatelský prostor stránku uvolní, bude vynulována (aby se zabránilo útokům pomocí nebezpečného kódu, který ve stránce zůstal) a navrácena k přímému mapování.

Jsou samozřejmě situace, kdy jádro musí mít k paměti uživatelského prostoru přístup: funkce copy_to_user() a copy_from_user() jsou jasné příklady. V těchto případech je po dobu průběhu operace přímé mapování obnoveno.

Cenou je přirozeně výkon. Mapování a odmapování stránek v adresním prostoru jádra bude trochu zpomalovat, stejně tak nulování stránek vrácených z uživatelského prostoru. Možná, že ještě důležitější je změna implementace přímého mapování. Obyčejně jádro vytvoří takové mapování s velkými stránkami, což mj. výrazně snižuje tlak na TLB (translation lookaside buffer) procesoru při přístupu k přímému mapování. Ovšem velké stránky nejsou kompatibilní s přidáváním a odstraňováním mapování pro jednotlivé (malé) stránky v daném rozsahu, takže s přechodem na XPFO, musí jít mapování velkých stránek pryč. Dojde také ke zvýšení režie paměti vyplývající z potřeby ukládat více informací na stránce. Jinak řečeno, nastavením XPFO dojde v nejhorších případech ke snížení výkonu až o 3 %, ačkoli většina výsledků benchmarků v příspěvku výše jmenovaných autorů byla mnohem nižší.

Sada patchů vyžaduje nějaké dokončovací práce, než bude možné vážně uvažovat o jejím začlenění do upstreamu. Dá se předpokládat, že až na to dojde, stočí se konverzace k tomu, jak je sada patchů vlastně efektivní při předcházení útokům a zda za snížení výkonu opravdu stojí. Skutečnost, že zpomalení pro sestavená jádra je asi 2,5 %, by mohla představovat překážku v této diskuzi. S tak velkým úbytkem výkonu je těžké se smířit, ale totéž platí i o úspěšných útocích. Která pilulka se ukáže jako jako ta nejhořčejší, se asi ukáže, až práce na sadě patchů postoupí.

       

Komentáře

[nyan]

Hezky to napsal GKH. Svet ARMu je jako wokna v 90tych letech... obrovska zumpa. A pak si jeste vyvojari ARM driveru stezuji, ze "linux by mohl konecne vystoupit z 60tych let a udelat kernel driver API" ... haha.

[BFU]

> Hezky to napsal GKH. Svet ARMu je jako wokna v 90tych letech

Svet mimo mainline je obecne plny sracek, ale to neni nic noveho.

> A pak si jeste vyvojari ARM driveru stezuji

Nejsou zadne "ARM drivery", jenom drivery mimo mainline a drivery napsane proti nejake konkretni verzi kernelu (typicky s 1000+ patchema).

> udelat kernel driver API

Kernel driver API tam samozrejme je, jenom je interni a meni se, coz je OK pokud je driver v mainline.

[Matlák]

Kernel driver API tam samozrejme je, jenom je interni a meni se, coz je OK pokud je driver v mainline.

Oni ti vývojáři podle všeho volají po jaderném ABI, nikoliv API. A vývojáře co chce používat GPL jádro ve svém zařízení a volá po ovladačovém ABI (aby svůj ovladač mohl následně uzavřít a zamknout na určitou verzi svého zběsile opatchovaného jádra) by někdo měl rituálně nechat přečíst celý ten ovladač v Jambickém pentametru.

[Michal Kubeček]

Pevné ABI není zajímavé pro vývojáře, ale spíš pro uživatele. Vývojářům out of tree driverů komplikují život změny API, kvůli kterým je musejí zaplevelit hromadami ifdefů, nejčastěji podle verzí (což je zase problém u distribučních jader). Vývojáře netrápí změny ABI, to jen znamená, že je potřeba modul přeložit proti danému jádru.

Koho zajímá ABI, to jsou uživatelé third party driverů, a to zejména těch closed source. Proto se snaží při běžných updatech zachovávat kABI enterprise distribuce. Ale taky to není žádný med, někdy se kvůli tomu musejí vymýšlet hodně divoké obezličky a občas to nejde vůbec.

[pc2005]

Ty drivery v EUFI jsou interpretovanej bytekód? To musí být strašně pomalý :-/ (viz různé polling hacky pro 1/10Gbps síťovky).

[Sten]

Typicky jsou naivní kód, ale mohou být i bajtkód, třeba pro hardware, který jde zastrčit do PC i Itania.

[pc2005]

naivní kód

Vím, že to bude nativní kód, ale překlep pobavil .

Jinak dost nebezpečný teda, nepředpokládám, že ke všemu budou zdrojáky :-/.