Jaderné noviny - 10. 5. 2006

23. 5. 2006 | Robert Krátký | Jaderné noviny | 5113×

Aktuální verze jádra: 2.6.16.15. Citát týdne: Chris Wright. Chráněné VMA. O bezpečnosti náhodných čísel v Linuxu. Patche Xen.

Aktuální verze jádra: 2.6.16.15

Aktuální stabilní jádro je 2.6.16.15, vydané 9. května. Přidává čtyři bezpečnostní patche, všechny se týkají SCTP kódu. Předtím bylo 5. května vydáno 2.6.16.14 s patchem opravujícím smbfs problém, který mohl procesu umožnit uniknout z chroot prostředí.

Aktuální předverze zůstává 2.6.17-rc3. Od vydání -rc3 bylo do hlavního git repozitáře začleněno několik stovek patchů; jde především o opravy, ale je mezi nimi i sada vylepšení splice() a možnost přidávat atributové skupiny záznamům class_device v okamžiku registrace.

Minulý týden nevyšly žádné verze -mm.

Citát týdne: Chris Wright

Já si myslím, že systém funguje docela dobře. Máme rychlý způsob, jak dostat opravy chyb a bezpečnostních problémů k uživatelům, a kratší vývojový cyklus umožňující distribucím získávat pravidelnější aktualizace. Tento konkrétní patch [2.6.16.14] lze aplikovat na všechny verze až do dob před gitem (více než rok) a jsem si jistý, že by to šlo i dále. Takže je těžké tvrdit, že by to byl vedlejší produkt cyklu vydávání hlavních verzí.

-- Chris Wright

Chráněné VMA

Struktura "oblast virtuální paměti" (VMA - Virtual Memory Area) (struct vm_area_struct) je jedním ze základních stavebních kamenů linuxového kódu virtuální paměti. Každá VMA popisuje kus adresního prostoru procesu; tento kus (většinou souvislý) je řadou stránek z jediného úložiště (soubor nebo u anonymní paměti swap) s jednotnou sadou přístupových práv. Každá VMA udržuje informace o pokrytém adresním prostoru, ukazatele na úložiště, info o právech, sadu funkčních ukazatelů pro operace prováděné s danou VMA a další informace pro údržbu.

Před vydáním jádra 2.6 mapovaly všechny VMA rozsah adresního prostoru na souvislý rozsah stránek v úložišti. S přidáním systémového volání remap_file_pages(), které aplikacím umožňuje přeorganizovat mapování paměťových stránek na stránky úložiště v rámci VMA, se věci trochu zkomplikovaly. Toto systémové volání obsahuje parametr pro nastavení práv přemapovaných stránek, ale tento parametr je v současné době ignorován. Prozatím i nadále platí, že všechny stránky v rámci VMA mají stejná práva. Pokusí-li se aplikace toto pravidlo porušit - například voláním mprotect() na podmnožinu stránek ve VMA - rozdělí se VMA na více VMA, z nichž každá bude na svém (zmenšeném) kousku adresního prostoru držet jednotná práva.

Tohle chování se však možná změní. Paolo Giarrusso nedávno oprášil jeden starý patch (vyvinutý s Ingo Molnarem), který systémovému volání remap_file_pages() umožňuje měnit také práva. Teoreticky by mělo jít o poměrně jasnou změnu. Tabulky stránek už teď udržují práva pro každou stránku, takže pro sledování práv jednotlivých stránek nejsou potřeba žádné další datové struktury. Ošemetné to začne být ve chvíli, kdy je stránka vyswapována. V tom okamžiku musí jádro uchovat informace o právech v záznamu tabulky stránek. Nový VMA parametr VM_MANYPROTS jádru říká, aby použilo tato uložená práva (místo práv uložených přímo ve VMA), když se stránka vrátí.

Aby mohla aplikace změnit práva, musí systémovému volání remap_file_pages() předat nový parametr MAP_CHGPROT. Nový patch kupodivu nepodporuje vytváření nebo operování s oblastmi VM_MANYPROTS pomocí mprotect(); zjevně nepanuje shoda o tom, jak by měla v takovém případě sémantika vypadat.

Motivací pro tyto změny je vylepšení výkonu User-mode Linuxu. Kód UML vytváří obrovské množství (desítky tisíc) jednostránkových mapování k simulaci svého vlastního prostředí virtuální paměti. Každé z těchto mapování vytváří VMA. Když jádro pracuje s tolika VMA, výrazně to zpomaluje paměťové operace. Režie paměti je také značná - každá VMA vyžaduje přinejmenším 88 bajtů paměti, 200 pak na mém x86-64 stroji. Odstranění všech těchto VMA by mohlo UML velmi zefektivnit; Ingo Molnar hlásí, že se výkon UML s aplikovaným patchem výrazně zlepšil.

Běžné uživatelé Linuxu by však také mohli z patche těžit. Ulrich Drepper vysvětlil, jak používá VMA v současné době knihovna C; linkování na jedinou sdílenou knihovnu může vytvořit až pět samostatných VMA. Aplikace využívající velký počet knihoven - jak to dělají mnohé desktopové programy - může tedy vytvořit stovky VMA. V systému je tak vytvořeno spousta VMA; kolik přesně, to zjistíte pohledem na řádek vm_area_struct. Já mám právě teď 13 000 aktivních VMA, které zabírají kolem 2,5MB paměti.

Z pěti VMA, které může glibc potenciálně vytvořit pro každé mapování sdílené knihovny, jsou čtyři do stejného souboru s jinými právy. Možnost mít více práv v rámci jediné VMA by mohla znamenat zhuštění těch čtyřech VMA do jediné, což by ponechalo u každé knihovny jediné mapování souboru a anonymní paměťový segment. Výsledkem by bylo výrazné snížení využití paměti a lepší výkon jádra. Tyto výhody pravděpodobně dříve nebo později zajistí začlenění patche.

O bezpečnosti náhodných čísel v Linuxu

Generování náhodných čísel je důležitou funkcí operačního systému. Na vytvoření čísel dostatečně náhodných na to, aby nemohla být uhodnuta útočníkem, závisí generování čísel síťovacích sekvencí, kryptografických klíčů sezení a veřejných klíčů. Slabá náhodná čísla mohou vést k nabourání sezení, vyzrazení tajemství a zfalšovaným identitám. Každý systém, který to s bezpečností myslí vážně, musí brát vážně i vytváření kvalitních náhodných čísel.

Pro počítače to však může být problém. Obecně platí, že výrobci počítačů dělají hardware tak, aby opakoval stále stejnou věc. Náhodnost nebývá při provozu počítače vítanou vlastností; u většiny systémů se náhodnost omezuje na reakce Emacsu na chybně stisknuté klávesy. Takže, i když existuje množství algoritmů, které umí vytvořit zdánlivě náhodnou řadu čísel, nejsou to čísla skutečně náhodná. Když algoritmus restartujete se stejnými počátečními podmínkami, vznikne stejná řada čísel.

Linux implementuje čistě algoritmický generátor náhodných čísel; lze k němu přistupovat pomocí /dev/urandom. Pro většinu účelů jsou jeho výsledky postačující, ale existují případy, kdy jsou potřeba opravdu náhodná čísla. Kvůli tomu se jádro snaží získávat náhodnost (nazývanou "entropie") ze svého prostředí. Například čas mezi stiskem kláves při psaní se vyznačuje jistou náhodností. Totéž platí i načasování diskových přerušení. Spodní bity systémového času mohou také poskytnout trochu entropie. Jádro tuto entropii střádá do speciálního zásobníku bitů, který pak využívá, když jsou potřeba skutečně náhodná čísla (z /dev/random). Je sledováno i množství nashromážděné entropie; je-li v zásobníku nedostatek entropie na obsloužení požadavku na náhodná čísla, bude proces vyžadující náhodná čísla zablokován, dokud nebude entropie dost.

Jedním z nejobvyklejších způsobů vkládání entropie do zásobníku je registrace přerušení pomocí parametru SA_SAMPLE_RANDOM. Tento parametr jádru říká, že se dané přerušení bude objevovat v náhodnou dobu, takže může být jeho načasování použito pro vytvoření entropie. Popisované rozhraní funguje již mnoho let, ale Matt Mackall nedávno usoudil, že to není nejlepší způsob. Takže poslal sadu patchů odstraňujících SA_SAMPLE_RANDOM z mnoha request_irq() volání. Většina změn není nijak kontroverzních. Například množství diskových ovladačů nastavuje SA_SAMPLE_RANDOM, ale zároveň používají blokovou funkci add_disk_randomness(). Odstraněním SA_SAMPLE_RANDOM se v těchto případech eliminuje zdroj redundantní "entropie". Ale Matt také rozdmýchal starou diskuzi, když jeden z jeho patchů odstranil SA_SAMPLE_RANDOM ze skupiny síťových ovladačů.

Problém se síťovými ovladači je následující: síťová přerušení jsou vytvářena příchozími a odchozími pakety. Získá-li útočník přístup k segmentu sítě, který využívá cílový systém, může útočník sledovat časování příchozích a odchozích paketů. Útočník může také časování ovlivnit generováním paketů, které bude odesílat na cíl v přesně naplánovaných intervalech. Čas od času mají někteří lidé obavy, že by dobře napojený útočník mohl uhádnout obsah zásobníku entropie a předvídat budoucí náhodná čísla.

Jiní namítají, že nikdo zatím nepředvedl situaci, ve které by možnost sledovat a vytvářet časování paketů mohla nakonec vést ke kompromitaci zásobníku entropie. Vlastní časování paketů přicházejících na daný systém může být spolehlivě sledováno pouze jiným systémem v rámci stejného segmentu sítě. Ale síťové segmenty už téměř nikdy nejsou sdílené; většina systémů bývá připojena ke switchům a switch pakety ukryje a změní jejich načasování. Nehledě na to, že je-li někdo v pozici, ze které má přístup k segmentu sítě cílového systému, je dost pravděpodobné, že bude moci získat k cílovému systému fyzický přístup. A v tu chvíli se zdá jednodušší nainstalovat odchytávač stisků klávesnice nebo patch na jádro než se pokoušet o uhodnutí obsahu zásobníku entropie.

Budeme-li předpokládat zvláště odhodlaného a masochistického útočníka, pak můžeme začít přemýšlet o potížích, se kterými by se taková osoba musela vypořádat. První je uhádnutí obsahu zásobníku entropie v danou chvíli. K tomu by bylo nutné pozorovat náhodná čísla generovaná systémem, což lze provést sledováním sekvence čísel a klíčů, které tento systém produkuje. Pak by útočník musel najít způsob, jak obrátit výpočet algoritmu (SHA-1), který se pro vygenerování náhodného čísla ze zásobníku používá. Takové obrácení by vrátilo velkou skupinu možných hodnot zásobníku, z nichž všechny by šly hashovat do stejných čísel, takže by útočník musel být připraven na práci s mnoha možnostmi současně.

Jakmile je odhalen obsah zásobníku, je na čase předpovědět jeho budoucí hodnotu určenou příchozí entropií. Problém je, že časování paketů na drátě není zcela shodné s časováním přerušení v jádře. Dochází ke zpoždění na síťové kartě, při přesunu paketu pomocí DMA do hlavní paměti (což může být ovlivněno provozem, který v paměti způsobuje zbytek systému), různými časy zpracování přerušení atd. Pak tu máme občasné zamíchání bitů z počítadla času, jehož hodnotu útočník nezná. Uhádnout díky pozorování provozu na síti, jaké číslo generátor poskytne, je prostě dost nepravděpodobné.

Kromě toho má mnoho systémů sloužících jako síťové servery přístup k relativně málo zdrojům entropie. Kdyby nebylo k dispozici časování přerušení ze síťových rozhraní, mohly by entropii vyčerpat úplně. Vzhledem k této potřebě a také vzhledem k tomu, že většinu vývojářů ty potenciální slabiny netrápí, je dost nepravděpodobné, že by se síťové časování přestalo v dohledné budoucnosti používat. Je však možné, že bude přidána konfigurační volba nastavitelná za běhu. Skutečně paranoidní administrátoři by mohli entropii ze síťových rozhraní úplně zakázat. Ti, kteří by měli jen obavy, by mohli tyto časy používat, ale snížil by se objem entropie, která je z časových hodnot síťových rozhraní brána. A většina nás ostatních by asi ponechala věci tak, jak jsou teď.

[Vizte také tuto práci od Z. Guttermana, B. Pinkase a T. Reinmana [PDF] o potenciálních slabinách linuxového generátoru náhodných čísel (díky Neilu Harrisovi).]

Patche Xen

Xen hypervisor (software spravující hostované systémy) byl v poslední době zdrojem nemalého vzrušení. Paravirtualizační schéma Xenu umožňuje provozování hostovaných operačních systémů, ale jádro hosta musí být portováno na "architekturu" podporovanou hypervisorem. Paravirtualizace poskytuje silnou izolaci virtuálních strojů a může být dosti rychlá, ale v rámci virtuálních strojů nelze provozovat neupravené operační systémy. Dost lidí čekalo, že touhle dobou už bude Xen začleněn do hlavního jádra, ale nestalo se tak. Faktem je, že patche Xen byly poskytnuty k prohlédnutí teprve nedávno. 9.  května však byla nabídnuta nová sada Xen patchů, ze které je patrné, jak by Xen jádro ovlivnil.

Patche z 35dílné sady se dělí na dvě velké skupiny. První vytvářejí novou architekturu (podarchitektura i386) a port linuxového jádra pro tuto architekturu. To je kód, který je zabudován do upraveného jádra, jež může být spuštěno jako host Xenu. Mezi ty výraznější změny patří:

• Umožňuje více vektorů přerušení. Xen používá pseudopřerušení pro různé druhy komunikace s hosty, takže je potřeba prostor pro více přerušení.
• Mechanismus událostí postavený na kódu správy přerušení, takže hypervisor může hostovaným systémům předávat informace. Virtuální stroje mohou kanály událostí také používat pro vzájemnou komunikaci.
• Většina inicializačního kódu i386 je oddělena, aby jej podarchitektury mohly nahradit. Jelikož hostované jádro nebude bootovat na studeném hardwaru a nebude využívat mnohé vlastnosti hardwaru, bude se muset inicializovat jinak než hostitelský systém.
• Verze patche pro dynamický tik se používá k tomu, aby nečinné virtuální stroje neztrácely čas obsluhováním přerušení časovače. Existuje také samostatná implementace času, která hostovaným systémům umožňuje starat se o svůj vlastní čas bez zapojení hypervisora.
• Celá řada virtuálních zařízení. Konzole, virtuální síťová rozhraní a virtuální bloková zařízení.

A pak pár změn hostitelského jádra:

• Nová sada operací se synchronními bity s názvy jako synch_set_bit(). Tyto operace se od běžných bitových operací liší tím, že jsou vždy atomické. Běžné bitové operace budou - jsou-li zkompilovány pro jednoprocesorový systém - využívat méně náročné neatomické operace. Ale to nebude fungovat v případě, kdy poběží jednoprocesorový Xen host na SMP hostiteli.
• Funkce apply_to_page_range() zavolá pro každý záznam v tabulce stránek v daném rozsahu danou funkci. Tento patch by mohl být začleněn s předstihem; v současné době totiž kód iterující přes záznamy v tabulce stránek duplikuje komplikovanou sadu funkcí pro procházení strukturou tabulky.

Patche byly poměrně dost komentovány, ale objevilo se jen málo závažných připomínek. Místo toho mají vývojáři Xenu dlouhý seznam drobností, o které se musí postarat. Nejzávažnější otázkou je tedy pravděpodobně síťový ovladač, který obsahuje svou vlastní zabudovanou implementaci ARP. Vývojáři Xenu tento kód obhajují jako nezbytnost pro rychlou migraci Xen hostů. Kdyby byl ARP kód přesunut na vhodnější místo - například do uživatelského prostoru - mohla by se migrace, která teď trvá milisekundu, protáhnout na vteřinu (nebo déle). A takovou cenu vývojáři Xenu platit nechtějí. Přidávání souborů do /proc také není vítané, ale to je kód, který už byl na seznamu věcí ke změně.

Není jasné, kdy bude Xen nakonec začleněn. Stále zbývá dost práce a jde o velký kus kódu, kterým se vývojáři musí prokousat. Ale teď, když je k dispozici kód, o kterém lze diskutovat, se to datum blíží.

       

Komentáře

[next]

Aktuální verze jádra: 2.6.16.13

Aktuální stabilní jádro je 2.6.16.15

[..]

Je treba si uvedomit, ze tahle verze vychazi s jistym casovym zpozdenim. Takze bych na tom verzovani az tak nelpel :)

[Robert Krátký]

Je treba si uvedomit, ze tahle verze vychazi s jistym casovym zpozdenim.

To je fakt, ale v tomto případě jde o moji chybu (opraveno).

[Leoš Literák]

to s tim emacsem je dobry for

[Nikola Ciprich]

no ja bych rekl ze tohle by vice sedelo na vi(m) - vzdycky kdyz v nem delam a zapomenu se ze jsem v tom prikazovem rezimu, a zacnu psat, to se pak obvykle deji veci

[mhepp]

Ale reakce vim jsou predvidatelne -- jde jen o to, ze neni predvidatelne, co zadas jako uzivatel...

TAKZE, kde je ta nahodnost? ;)

[Lukáš Zapletal]

uuu to jisti