Jaderné noviny - 13. 9. 2006

29. 9. 2006 | Robert Krátký | Jaderné noviny | 4048×

Aktuální verze jádra: 2.6.17.13. Citáty týdne: Andrew Morton a tým -stable. MMIO bariéry. Pokus o vzkříšení kvalifikací v Linuxu.

Aktuální verze jádra: 2.6.17.13

Aktuální verze jádra je 2.6.17.13, vydaná 8. září, několik minut po nepovedené 2.6.17.12. Do těchto vydání bylo zařazeno docela dost důležitých oprav, i když žádná z nich není vedena jako CVE.

Adrian Bunk vydal 2.6.16.29-rc1 a 2.6.16.29-rc2 s další sadou oprav.

Aktuální předverze je 2.6.18-rc7, vydaná 13. září Ok, ok, já vím. Myslel jsem, že -rc6 bude poslední, ale mám prostě lepší pocit, když vydáme ještě -rc7, i když změny jsou jen malé. Finální verze by už měla vyjít velmi brzy.

Aktuální verze -mm stromu je 2.6.18-rc6-mm2. Mezi změny patří úpravy USB API, velký patch pro x86-64 (včetně podpory ochrany stacku), ACL pro tmpfs a patch, který na některých systémech možná změní pořadí číslování PCI zařízení. V -mm je teď 1915 patchů - nejvíce, kolik kdy bylo.

Citáty týdne: Andrew Morton a tým -stable

Cesta k 2.6.19-rc1 bude drsná - čeká tu nezvykle hodně práce a mezi subsystémovými stromy jsou nezvyklé (i když stále malé) přesahy, které bude nutné vyřešit. Proto předpokládám, že nám -rc1 zabere delší dobu než obvyklé dva týdny.

-- Andrew Morton

Velmi se omlouváme za chyby, které se připletly do verze .12 - viníky už jsme vykopli.

-- The -stable team

MMIO bariéry

Paul Mackerras nedávno nahlásil záludnou chybku. Ethernetový ovladač tg3 pracuje, podobně jako mnoho dalších síťových ovladačů, se sadou popisovačů bufferů uložených v paměti hostitelského systému. Tyto popisovače popisují buffery, které jsou k dispozici pro příchozí síťové pakety. Když přijde paket, rozhraní vezme další popisovač, nacpe tam data a řekne procesoru, že je paket k dispozici. Hlášená chyba se projevuje takto: procesor pozmění datovou strukturu popisovače, pak provede zápis do MMIO (memory-mapped I/O) registru, aby zařízení řekl, že má začít s I/O. Zařízení však tento MMIO zápis dostane dříve, než data zapsaná do hlavní paměti dorazí ke svému cíli, takže pracuje se starými daty. V takovém případě je správný průběh přinejmenším nepravděpodobný.

Chyby vyplývající z přehození pořadí paměťových operací mohou být zrádné a těžko odhalitelné. Vývojář by na kód mohl zírat hodiny, aniž by si uvědomil, že to, co se ve skutečnosti děje hluboko v hardwaru systému, neodpovídá tomu, jak je napsaný kód. Nesprávné chování může být nepravidelné a nemusí být možné ho reprodukovat.

Řešením tohoto druhu problémů bývá obyčejně umístění nějaké paměťové bariéry v situacích, kde na pořadí operací záleží. Pro autory ovladačů je možná nejznámějším druhem bariéry následující klasické pravidlo: MMIO zápisy do I/O paměti na PCI sběrnici nelze považovat za dokončené, dokud nebude z daného adresního rozsahu provedeno čtení. Takže ovladače vypadají často tak, že i když je u mnoha registrů nastavena hodnota popisující I/O operaci, před konečným zápisem musí být provedeno čtení, které nastaví "OK" bit. Bez toho čtení, které funguje jako MMIO bariéra, by mohlo zařízení začít pracovat se starými hodnotami a nadělat škody.

Chyba v tg3 však znázorňuje trochu odlišný problém: neexistuje žádné zaručené řazení zápisů do běžné paměti a MMIO rozsahu. A proto se Paul ptal: neměl by být MMIO zápis předefinován tak, aby byl přísně zařazen s ohledem na předchozí zápisy do běžné paměti? Na mnoha architekturách (včetně i386) se o řazení hezky postará hardware, ale u jiných (Paul pracuje na PowerPC64) žádné záruky nejsou. Přidání bariér do MMIO zápisových operací (iowrite32(), writel() atd.) na příslušných platformách by mohlo odstranit množství potenciálních chyb.

Linusovi se to nezamlouvalo, protože to považuje za příliš náročné. Paměťové bariéry mohou procesor na dlouhou dobu zdržet, takže je lepší se jim vyhnout, nejsou-li opravdu nutné. Proto je podle Linuse vhodnější chtít po programátorech, aby bariérové operace používali v konkrétních případech.

Tento přístup však také není bezproblémový. Například proto, že jádro v současné době neimplementuje bariéru určenou k udržení řazení běžných a MMIO paměťových operací. Máme sice mmiowb(), ale ta má za učel zajistit řazení pouze MMIO operací. Proto Linus zmínil možnost vytvoření nových bariér s názvy jako mem_to_io_barrier(), které by se postaraly o požadovaný pořádek.

Jinou možností by bylo předefinování MMIO operací tak, aby obsahovaly bariéru předtím, než dojde na MMIO přístup. To by sice opravilo chybu v tg3 bez zbytečné režie, ale jen za cenu odstranění bariéry, která je teď umístěna až za operací. Takové řešení by preferoval Paul:

Řekl bych, že nejlepší by v tuto chvíli bylo přesunout sync ve writeX() před ukládání, jak navrhuješ, a přidat "eieio" před natáhnutí v readX(). To by sice znamenalo, že spoléháme na autory ovladačů, aby dali mmiowb() mezi writeX() a spin_unlock, ale aspoň je to zdokumentované.

Takový přístup se však nelíbil Davidu Millerovi (a dalším):

Autoři ovladačů ty paměťové bariéry nebudou používat správně. Možná myslíš, že ano, protože to bude "dokumentované", ale to nic nemění na skutečnosti, že přestože autoři ovladačů dobře zvládnou jednoduchá rozhraní, tak tyhle paměťové bariéry jsou složité koncepty, které bude polovina z nich mít špatně.

David by byl raději, kdyby věci fungovaly správně i při té jednoduché variantě - i za cenu větší režie. A jak zmiňovali ostatní, vždycky se dají implementovat nebariérové verze základních MMIO funkcí pro vývojáře, kterým záleží na výkonu, a kteří (si myslí, že) vědí, co dělají.

Největší starosti by možná byly s návrhem, který představil Paul: zavolání mmiowb() mezi poslední zapisovací MMIO operací a voláním spin_unlock(). Spinlocky procesorům (nebo procesům v preemptivním prostředí) zabraňují v pomíchání operací na jediném zařízením. Ale spinlock žije v paměti, takže je možné, že by odemykací operace uspěla (a umožnila tak dalšímu procesu přistupovat k MMIO oblasti) před dokončením zápisů předchozího procesu. Proto se volá mmiowb() - ale vypadá to jako věc, na kterou by autoři ovladačů často zapomněli.

Alternativu navrhl Alan Cox. Jde o vytvoření nové dvojice spinlock operací: spin_lock_io() a spin_unlock_io(). Byly by výslovně definovány k ochraně operací s MMIO oblastmi a obsahovaly by potřebné bariéry. Kdyby se podařilo naučit ovladače zařízení, aby tyto zamykací operace používaly (a autory ovladačů je mnohdy snadné něco naučit - stačí jim dát pivo, když se něco povede), nemusely by pamatovat na vkládání bariér.

Pár problémů je však i s tímto řešením. Už existuje množství variací operace spin_lock(); přidání další možnosti by počet zamykacích volání výrazně navýšilo. Kód, který volá funkce, zatímco drží zámky, si musí být už teď vědom zamykacích potřeb volaných funkcí - a to by bylo také daleko komplikovanější. Linus by se proto takovému přístupu raději vyhnul a vyžadoval používání explicitních bariér.

A ještě další přístup - který bude nakonec možná zaveden - je předefinování a rozšíření sady pomocných MMIO funkcí. Podle popisu Benjamina Herrenschmidta by stávající funkce (writel() atd.) byly plně řazené - i kdyby je to mělo zpomalit. Všechny ovladače, které je používají, by i nadále fungovaly - a některé by se díky tomu dočkaly opravení neobvyklých skrytých chyb.

Pro většinu ovladačů by takové funkce byly postačující - paměťové bariéry kolem MMIO operací by zpravidla výkon neovlivnily. Pro situace, kde by bariéry nebyly nutné nebo by byly ke škodě, by byly definovány nové pomůcky s názvy jako __writel() nebo __iowrite32(). Tyto funkce by zajistily, že budou MMIO operace periferním zařízením vnímány v pořadí určeném procesorem, ale bez dalších záruk. Při použití těchto primitiv by byl programátor zodpovědný za umístění bariér (v případech, ve kterých je řazení MMIO a běžných paměťových operací podstatné).

A nakonec byla navržena sada funkcí s názvy jako __raw_writel() - pro programátory, kteří by chtěli balancovat na ostří nože. Tyto funkce by neposkytovaly žádné záruky řazení a nezajímaly by je otázky typu byte swapping. Jsou jen o krůček výše než přímé zadávání I/O operací v assembleru. Benjaminův návrh také znovu oživuje nápad na vytvoření nové sady paměťových bariér pro specifické situace. Takže io_to_io_barrier() by zajistila řazení MMIO operací; byla by užitečná ve spojení s "raw" operacemi popisovanými výše. Další bariéry by se různými způsoby zabývaly řazením MMIO a běžných paměťových operací. Viz Benjaminův email, kde je celý seznam.

Objevilo se dost návrhů na změny, ale žádný vážný odpor. Takže to nakonec možná bude fungovat právě tak - i když v budoucnu lze očekávat další diskuze. Protože se jedná o jednu z nejošemetnějších oblastí programování jádra na současném hardwaru, nebudou snadná a konečná řešení rychle k mání.

Pokus o vzkříšení kvalifikací v Linuxu

V roce 1998, než bylo jádro 2.1 uzavřeno novým funkcím, došlo k začlenění funkce kvalifikací [capabilities]. Kvalifikace rozdělují moc účtu roota na sadu práv, z nichž každé může být uděleno nebo odebráno nezávisle na ostatních. Například proces, který potřebuje mít možnost vázat se na privilegované číslo portu, by mohl tuto schopnost získat, aniž by mu zároveň bylo umožněno přebít práva souborů, zabíjet další procesy nebo překračovat limity zdrojů. Zastánci kvalifikací si již dlouho představují svět, kde není účet roota a všechny úlohy mají právě takovou minimální úroveň oprávnění, kterou potřebují k vykonání své práce. Takový systém by měl být údajně bezpečnější.

Svět je plný linuxových distribucí, z nichž mnohé jsou orientovány na vyšší úroveň bezpečnosti. Ale pokud vím, tak nikdo zatím nesestavil úspěšnou distribuci založenou na kvalifikacích. Pro tento nedostatek implementací je více důvodů, včetně toho, že se nikomu nepodařilo vymyslet, jak spravovat systém s několika desítkami dalších bezpečnostních bitů připojených ke každému spustitelnému souboru. A neměla by se přehlížet ani skutečnost, že od dob jádra 2.1.x až do dneška nebyla jediná verze, kde by kvalifikace opravdu správně fungovaly.

Částečně za to může nekompletní implementace: nebyl začleněn žádný patch, který by k souborům kvalifikační masky připojoval. A jádro také nikdy správně neimplementovalo dědičnost kvalifikací: co se s kvalifikací stane, když proces spustí nový program. Vlastně je to tak, že je dědičnost kvalifikací už nějakou dobu úplně vypnuta, a bez dědičnosti nemůže model kvalifikací fungovat. Takže se využívání kvalifikací omezovalo na velmi malý počet programů, které byly naprogramovány tak, aby se zbavily kvalifikací, které nepotřebují.

David Madore se tento stav rozhodl změnit sadou patchů, které mají podporu kvalifikací opravit. Patch dělá několik věcí, z nichž první je rozšíření sady kvalifikací z 32 na 64 bitů. Stávající jádra mají definovaných 31 kvalifikací, takže není tak těžké si představit, že by v budoucnu bylo potřeba více. Citelně by to bylo znát, kdyby se někdo odhodlal rozdělit na menší práva kvalifikaci CAP_SYS_ADMIN, pod kterou teď může spadat vše.

Patch některé z nových bitů používá v rámci sady "běžných kvalifikací", které by normálně měly mít všechny procesy. Patří k nim možnost používat fork() nebo exec(), schopnost otevírat soubory a zapisovat do nich, používání ptrace() a možnost navýšení práv spuštěním setuid programu. Je to myšleno tak, že vyžaduje-li to bezpečnost, mohou tyto procesy zmíněné kvalifikace zahodit, a tím ztížit zneužití svých zranitelností.

Jádrem patche je však implementace dědičnosti priorit. Pochopení této části vyžaduje malý úvod. Ačkoliv lze mluvit o kvalifikacích procesu, každý linuxový proces má tři samostatné masky kvalifikací. Sada povolených obsahuje všechny kvalifikace, které proces smí mít. Nelze je však používat, pokud nejsou v účinné sadě - podmnožině povolené sady. A konečně má každý proces také sadu dědičnou, která drží seznam kvalifikací (opět podmnožinu povolené sady), jež lze předat programům spuštěným pomocí exec(). Procesy mohou účinné a dědičné sady kdykoliv měnit (v rámci povolené sady), ale povolenou sadu rozšířit nelze.

V systému založeném na kvalifikacích mají spustitelné soubory také sadu tří masek kvalifikací. Tyto masky mají stejné názvy jako masky procesů a funkce je téměř stejná. Zděděná maska souboru však omezí kvalifikace, které lze zdědit z jakéhokoliv jiného procesu. Davidův patch také obsahuje kód od Sergeje Hallyna, který přidává podporu masek kvalifikací do vrstvy souborových systémů.

Když proces spustí nový spustitelný soubor, jsou masky nakombinovány následovně:

• P′_p ← (P_i ∩ F_i) ∪ (F_p ∩ bnd)


• P′_e ← (P_i ∩ P_e ∩ F_i) ∪ (F_p ∩ F_e ∩ bnd)


• P′_i ← P′_p

Tyto rovnice jsou převzaty přímo z Davidovy stránky o "nových kvalifikacích", kde je mnohem více podrobností o celé této práci. Převedeno do běžného jazyka to vypadá asi takto:

• Povolené [permitted] kvalifikace pro nový spustitelný soubor (P′_p) jsou průnikem dědičné sady procesu před voláním exec() (P_i) a dědičné sady souboru (F_i). Pak je přidána povolená sada ze souboru (F_p), ale ne předtím, než bude omezena celosystémovou sadou vymezující kvalifikace.


• Účinné [effective] kvalifikace (P′_e) budou stejné jako dědičné - kromě toho, že kvalifikace, které nejsou u stávajícího procesu aktivní nebo nejsou v účinné sadě souboru, budou odmaskovány.


• Dědičné [inheritable] kvalifikace (P′_i) budou stejné jako povolené kvalifikace.

Tato pravidla se z větší části shodují s tím, jaké chování se očekává od systému založeného na kvalifikacích. Kvalifikace jsou na takových systémech přiznávány programům, nikoliv uživatelům. Běžné bity práv pak mohou hrát roli v tom, které programy smí určití uživatelé spouštět.

Davidův patch se však od představ o systému založeném na kvalifikacích liší v jednom důležitém ohledu: jak zachází s programy, které nemají žádné sady kvalifikací definovány. Na většině systémů se to bude týkat téměř všech spustitelných souborů. Podle pravidel by s takovými programy mělo být nakládáno jako by měly prázdnou dědičnou sadu, což by - podle výše uvedených pravidel - způsobilo, že by byly spouštěny bez jakýchkoliv kvalifikací. Davidův patch však nechává tyto programy spouštět se stejnými kvalifikacemi, které měl proces předtím - i když v případě setuid bitů by samozřejmě mohlo dojít ke změně. Tato interpretace porušuje klasický kvalikační model. Výhodou je, že díky tomu na současných systémech funguje.

Ted T'so namítal, že takový kompromis zásadně oslabuje bezpečnost kvalifikačního modelu. Navrhl, aby šlo o konfigurovatelné chování; každý souborový systém by měl parametr popisující, jak by mělo být s kvalifikacemi nakládáno v případě, že by soubory neměly nastavené masky. Součástí této změny by mohla být i sada výchozích kvalifikací pro nové soubory.

Další připomínky byly poměrně předvídatelné: proč se trápit s kvalifikacemi, když máme SELinux, který umí to samé a ještě více. Ve skutečnosti dělá SELinux něco vzdáleně podobného, ale dost nepřímo; připojuje k souborům nálepky, pak k nálepkám přiřazuje kvalifikace pomocí mechanismu pravidel. Každý, kdo měl to štěstí spatřit tu veselou hlášku při bootu Fedory ("váš souborový systém musí být přenálepkován, čekejte prosím, bude to trvat velmi dlouho"), ví, že udržování správně synchronizovaných souborů a nálepek je složitá záležitost. Není žádný důvod se domnívat, že by udržování masek kvalifikací ve správném stavu mělo být snazší. To samo o sobě by mohlo do budoucna omezovat možnosti využití kvalifikací.

       

Komentáře

[Leoš Literák]

Spise bych to prekladal jako vlastnosti ci schopnosti nez kvalifikace.

[Robert Krátký]

Docela dlouho jsem nad tím přemýšlel. Mimo jiné proto, že se mi nechtělo cizí slovo překládat jiným cizím slovem. Ale nakonec mi to takhle přišlo výstižnější než vlastnosti/možnosti/schopnosti (nejedná se o to, co program/proces umí, ale co smí, čím je pověřen).

[p]

a nebylo by lepsi to tedy prekladat jako povoleni?

[ankh47]

no, a neni tohle uz tak nejak zabrany ?

[Mak]

Opravneni nebo zpusobilost. O schopnosti nejde vubec.

[Boris]

Adrian Bunk vydal 2.6.16.29-rc1 a 2.6.18.29-rc2 s další sadou oprav.

chybka: Má být 2.6.16.29-rc2, ne 2.6.18.29-rc2

[Robert Krátký]

Dík.