Jaderné noviny – 3. 6. 2009

29. 6. 2009 | Jirka Bourek | Jaderné noviny | 3438×

Aktuální verze jádra: 2.6.30-rc8. Citáty týdne: Andrew „akpm“ Morton, Steven Rostedt. V krátkosti: Opakování zápisů core dumpu; Strom zařízení; „Oblast chráněná před hostitelem“; reflink(); Řízení ID procesů. Kolik příznaků stránek opravdu máme? Zase Xen. Čištění stránek, část druhá.

Obsah

• Aktuální verze jádra: 2.6.30-rc8
• Citáty týdne: Andrew „akpm“ Morton, Steven Rostedt
• V krátkosti
  • Opakování zápisů core dumpu
  • Strom zařízení
  • „Oblast chráněná před hostitelem“
  • reflink()
  • Řízení ID procesů
• Kolik příznaků stránek opravdu máme?
• Zase Xen
• Čištění stránek, část druhá

Aktuální verze jádra: 2.6.30-rc8

Současné vývojové jádro je 2.6.30-rc8 vydané 2. června. Pravděpodobně to bude poslední předverze před konečným vydáním 2.6.30. Spousta malých záležitostí, které opravují pár regresí (a přinejmenším jeden záznam v bugzille, který se táhne od 2.6.24). Na malých věcech záleží, prosím testujte. Všechny detaily lze nalézt v kompletním changelogu.

V minulém týdnu nebyla vydána žádná stabilní aktualizace; poslední stabilní verze je 2.6.29.4 z 19. června.

Citáty týdne: Andrew „akpm“ Morton, Steven Rostedt

Pro vaši informaci, diskuze výše přepíná akpm do „zmateného“ stavu. Patch zatím bude pozdržen, dokud se akpm nepřepne zpět.

-- Andrew „akpm“ Morton

Protože když se nad tím zamyslíš, opravdu nemá smysl mít konzistentně špatný kód. Směs dobrého a špatného je lepší, než 100% špatné.

-- Andrew Morton

Tenhle tlak Dom0 Xenu prostě příliš vypadá, jako že Linux je sexuální otrok Xenu, když by tomu mělo být naopak.

-- Steven Rostedt

V krátkosti

Opakování zápisů core dumpu

Paul Smith zaslal patch, který zopakuje krátké nebo přerušené zápisy core dumpu a tím brání vytvoření nekompletního dumpu, když přijde signál. Alan Cox patch neschválil s komentářem: Současné chování je absolutní dar z nebes, když máš něco jako zaseklý core dump na NFS připojení nebo něco, co se snaží zapsat dump na velmi pomalé médium.. Nápad jako takový nicméně vedl k zajímavé diskuzi o tom, které signály by měly způsobit přerušení zápisu core dumpu – a tím za sebou nechat zkrácený soubor – a které by měly být ignorovány.

Je jasný rozdíl mezi interaktivním programem, který vypisuje svůj stav a uživatel ho chce přerušit pomocí SIGINT, a neinteraktivním procesem, jehož uživatel nebo vývojář si přeje, aby byl výpis dokončen. Smith popisuje jeden scénář: Pracovní proces nemusí reagovat, když je vypisován jeho stav, takže se rodič rozhodne ho odstřelit SIGINTem kvůli časovým limitům atd. K žádnému rozhodnutí nedošlo, ale Roland McGrath analyzoval čtyři kategorie signálů a poznamenal, že alespoň dvěma z nich je potřeba se věnovat, protože současný kód je řeší špatně.

Strom zařízení

„Strom zařízení“ Open Firmware je popis hardwaru v systému ve standardizované datové struktuře. Některé platformy používají stromy zařízení, aby oddělily popis hardwaru od jádra, které na tom hardwaru běží; to umožňuje jednomu jádru podporovat širší škálu systémů. Janboe Ye nedávno navrhl přidat podporu pro strom zařízení do architektury ARM, která pravděpodobně podporuje největší množství hardwaru ze všech. To následně vedlo k dlouhé diskuzi o tom, jak moc strom zařízení opravdu pomáhá a jak proveditelné je vytvořit jedno jádro pro všechny systémy dané architektury.

Vývojáři architektur, které strom zařízení používají, se zdají být s výsledky spokojeni; vizte tento článek z OLS 2008 [PDF], kde je popsáno, jak se věci měly u architektury PowerPC. Správci ostatních architektur však tolik přesvědčeni nejsou. Správce ARM Russel King se obává, že by strom zařízení mohl být drahou slepou uličkou; byl by rád, kdyby byla konvertována jenom podmnožina ARM architektur, aby se zjistilo, jestli budou fungovat dobře, nebo ne. Inkrementální přístup je pravděpodobně rozumnější obecně, takže se věci asi budou ubírat dále tímto způsobem.

„Oblast chráněná před hostitelem“

[host protected area, HPA] je koncept IDE, který řadiči umožňuje skrýt část disku před pohledem operačního systému. Když byla HPA před lety zavedena, jejím primárním použitím bylo zařídit, aby se velké disky (podle tehdejších standardů) tvářily jako malé a určité zastaralé operační systémy jimi nebyly zmateny. Linux přirozeně nikdy takové problémy neměl, takže linuxová IDE vrstva tradičně HPA vypíná při procesu vyhledávání zařízení. V dané době to byla správná věc; umožňovala linuxovému systému využít celý disk.

Uběhl již nějaký pátek od doby, kdy musely být operační systémy chráněny před šokem z toho, že vidí příliš velký disk. HPA nicméně zůstává z jiných důvodů: Výrobci ji využívají, aby na ni uložili například informace o RAIDu. Systémy s Windows jsou často dodávány s obnovovacím obrazem pro „reinstalaci systému od začátku“ – což je pro tuto platformu zjevně užitečná vlastnost. Rootkity tam občas schovávají informace. A tak dále. Ve všech případech kromě posledního je pravděpodobně chyba, když operační systém na současných strojích HPA přepíše. Vypínání ochrany HPA ve výchozím nastavení již tedy není správná věc.

Subsystém ovladačů libata HPA dodržoval od počátku, ale kód IDE zachovává staré výchozí nastavení. To by se však mohlo změnit se sadou patchů, které zaslal Bartlomiej Zolnierkiewicz. Tyto patche způsobí, že IDE vrstva HPA ve výchozím nastavení dodrží – kromě případů, kdy již disk má oddíly, které leží na HPA. Tento test by měl být dostatečný k tomu, aby se zajistilo, že budou starší systémy nadále fungovat a že na novějších discích nebude HPA zničena. U systémů, které nejsou touto změnou správně pokryty, lze využít parametr modulu nohpa a chování ohledně HPA řídit přímo.

reflink()

Je zde další návrh reflink() (vizte API reflink()). Tento trochu zjednodušuje parametr preserve, nahrazuje sadu příznaků volbou vše, nebo nic. reflink() lze tedy použít v plně snímkovacím režimu (s dostatečnými právy), nebo v režimu referenční odkaz jako kopie, ale s žádnými možnostmi mezi tím.

Řízení ID procesů

Navrhovaná vlastnost „kontrolní bod/restart“ má mnoho problémů, které je potřeba překonat. Jedním z nich je to, že procesy mohou být velmi zmateny tím, že se jejich ID najednou změní. Proces restartu od kontrolního bodu tedy vyžaduje, aby se ID procesu také obnovilo. Použití jmenných prostorů PID může pomoci zajistit, že bude požadované ID k dispozici, ale v Linuxu není možnost, jak spustit proces se specifickým ID.

Sukadev Bhattiprolu má návrh nového systémového volání, které tento problém řeší: clone_with_pid(). Chovalo by se jako běžné clone(), ale přebírá dodatečný argument, kterým je pole ID procesů. Pole obsahuje jedno požadované ID procesu pro každý jmenný prostor v současné hierarchii, přičemž první je globální jmenný prostor. Hluboce vnořené procesy tedy mohou být vytvořeny se specifickým ID v každém jmenném prostoru, ve kterém se objevují.

Patch byl „jemně otestován“ a nebyl zaslán mimo konferenci kontejnerů, takže zatím obdržel jen málo revizí. Očekávejme změny, jak se tento kód začne blížit hlavní řadě.

Kolik příznaků stránek opravdu máme?

Nedávno diskutovaný patch asanace jaderné paměti byl kritizován z mnoha důvodů, jedním z nich bylo používání zvláštního příznaku stránky. Patch HWPOISON Andiho Kleena (který povoluje novou vlastnost CPU Intelu, která řeší chyby paměti) narazil na problémy z podobných důvodů. Na zoufalý nedostatek příznaků stránek si jaderní vývojáři stěžují již léta, ale, což je zajímavé, ne všichni tvrdí, že problém existuje, a téměř nikdo nedokáže odpovědět na jednoduchou otázku, kolik příznaků je vlastně k dispozici. Pohled na problém příznaků stránek v Linuxu se tedy zdá být na místě.

„Příznaky stránek“ jsou jednoduché bitové příznaky, které popisují stav stránky ve fyzické paměti. Jsou definovány v <linux/page-flags.h>. Existují příznaky, které označují „rezervované“ stránky (jaderná paměť, I/O paměť, neexistující), zamčené stránky, stránky, pro které právě probíhá I/O zpětného zápisu [writeback], ty, které jsou částí složené stránky [compound page], stránky spravované alokátorem SLAB a další. V závislosti na cílové architektuře a vybraných konfiguračních volbách jádra může být definováno až 24 jednotlivých příznaků.

Tyto příznaky žijí v členské proměnné flags struktury struct page. Tato proměnná je definována jako unsigned long, takže by si jeden myslel, že přijít na to, kolik místa zbývá pro nové příznaky, je jednoduchý úkol. Běžnému pozorovateli by se mohlo zdát, že na 32bitovém systému je použito 24 příznaků, takže k dispozici je jich osm:

Jenže když jde o struct page, jednoduché je jenom máloco. Pro každou fyzickou stránku v systému existuje jedna tato struktura; na systému s 4 GB paměti jich bude milion. Vzhledem k tomu, že se každý byte přidaný do struct page znásobí milionkrát, není překvapení, že je silná motivace zabránit zvětšení této struktury za každou cenu. struct page tedy obsahuje ne méně než tři sjednocení (union) a je obklopeno složitými pravidly, která popisují, kdy jsou která pole platná. Změny v tom, jak se k této struktuře přistupuje, se musí provádět velmi opatrně.

Sjednocení nejsou jedinou technikou, která se používá, aby se do této struktury namačkalo tolik informací, kolik jenom jde. Systémy s neuniformním přístupem k paměti (NUMA) musí sledovat, ke kterému uzlu patří která stránka, a stejně tak do jaké zóny v uzlu. Místo toho, aby do struct page vkládali další pole, hackeři NUMA vzali volné bity na vrcholku pole flags, takže vzniklo něco jako je toto:

Na 32bitovém systému s 24 definovanými příznaky (pesimistická varianta) je pro informace o uzlu a zóně k dispozici 8 bitů; to prakticky omezuje 32bitové NUMA systémy na 64 uzlů, což je téměř určitě adekvátní. Přidání dalších příznaků stránky by nicméně přišlo za cenu podpory menšího počtu uzlů a to by bylo nevítané.

Věci se ještě zhoršují na systémech se složitým rozvržením paměti. Na takových systémech není paměť organizována do jediného spojitého rozsahu fyzických adres; místo toho je rozprostřena s dírami uprostřed. Správa paměti na těchto systémech s „řídkou pamětí“ vyžaduje, aby bylo s každou stránkou spojeno číslo „sekce“. Toto číslo sekce je uloženo – to byste neuhodli – ve volných bitech pole flags. Pokud dochází místo, jádro přesune číslo uzlu do zvláštního pole, čímž se věci zpomalí. Tak jako tak se zdá být jasné, že na takovýchto systémech není v proměnné flags příliš mnoho místa navíc.

Skutečná odpověď na otázku „kolik příznaků stránek je volných?“ je z praktického hlediska „nula“, alespoň na 32bitových NUMA systémech. Udělat místo pro další by znamenalo rozšířit struct page, což by dost stálo. Vývojáři by proto neměli být překvapeni, když jejich návrhy na použití nového příznaku stránky narazí na tuhý odpor. Jedná se vždy o jediný bit, ale tento bit leží uprostřed jednoho z nejvyhledávanějších pozemků v celém jádře.

V případě patche HWPOISON od Andiho přišla opozice v podobě mnoha alternativních návrhů. Jeden je jednoduše použít bit „rezervováno“, ale to by mohlo vést k potížím v těch částech kódu, kde se toto použití neočekává. Pak bylo navrženo, že by otrávenou stránku mohly indikovat příznaky „rezervováno“ a „zpětný zápis“, ale Andi tvrdí, že tento přístup fungovat nemůže. Andrew Morton navrhl, že HWPOISON by mohla být vlastnost pouze pro 64bitové systémy; Andi uznává, že to by mohlo být možné, ale tento nápad se mu rozhodně nelíbí.

Místo toho Andi zaujal postoj, že nedostatek příznaků stránky ve skutečnosti neexistuje. Na 64bitových systémech to vůbec není problém, protože unsigned long je dvakrát tak široká. Počet 32bitových systémů s velkými NUMA uzly je malý a zmenšuje se; není to něco, čím by se vývojáři museli zabývat. A, říká Andi, pokud se věci opravdu zhorší, číslo sekce v řídké paměti lze přesunout do samostatného pole stejně jako číslo NUMA uzlu. Vzhledem k tomuto pohledu na problém není potřeba při přidávání nové užitečné vlastnosti mít obavy kvůli jedinému bitu mezi příznaky stránky.

Nikdo nezpochybnil Andiho pohled, že problém není tak vážný, jak si většina lidí myslí, i když Andrew Morton naznačil, že by Andi měl pokračovat a dokázat své nápady o přesouvání čísla sekce mimo strukturu page. To by nemusel být špatný nápad. I kdyby příznaků stránky bylo více, než si většina vývojářů myslí, není těžké si představit dobu, kdy dojdou, alespoň na 32bitových systémech. Návrhy zahrnující nové příznaky stránky nejsou tak ojedinělé; pokud nebudeme chtít omezit přidávání vlastností, které potřebují příznak stránky, na 64bitové systémy, budeme muset v brzké době zpřístupnit více příznaků.

Zase Xen

Jonathan Corbet, autor tohoto článku, je široce znám svými správnými a neomylnými předpověďmi. Takže by určitě neřekl něco jako tohle:

V historii Xenu možná došlo k chybám, ale jde o projekt, který je stále naživu a má zjevně důvody k existenci. Autor článku předvídá, že kód Dom0 se setká v začleňovacím okně 2.6.30 jenom s malým odporem.

OK, každý, kdo by potřeboval další důkazy a autorově schopnosti předvídat budoucnost, se může podívat na jeho investice… nebo spíše jejich doutnající pozůstatky. Netřeba říci, že nejenom že podpora Xen Dom0 neprošla přes začleňovací okno 2.6.30, ale navíc to nevypadá dobře ani pro 2.6.31.

Vzpomeňme, že Dom0 je hypervizor systému Xen; je to Jeden prsten, který všechny váže. Na rozdíl od podpory pro DomU (používané pro běžné uživatele), Dom0 zůstává mimo hlavní řadu jádra. Každý, kdo ho dodává, ho musí patchovat odděleně; a když jde o patch tak velký a invazivní, jako je Dom0, není to příjemný úkol. Je nicméně nutný, Xen má spoustu uživatelů. Jak to vyjádřil vývojář Xenu Jeremy Fitzhardinge:

Xen je velmi široce využíván. Je nejméně 500k serverů, které používají Xen v komerční sféře (a kdovíkolik menších serverů a domácích uživatelů); na těchto serverech běží miliony domén virtuálních hostů. Jestliže se šířeji projdete po netu, pravděpodobně využijete na Xenu založený server; například celý Amazon běží na Xenu. Mozilla a Debian jsou hostovány na systémech s Xenem.

Vývojáři i uživatelé Xenu by byli rádi, kdyby byl tento kód začleněn do hlavní řady. Mnoho jinak nezaujatých vývojářů jádra také argumentovalo pro začlenění tohoto kódu. Jeden by se tedy mohl ptát, proč stále existuje opozice.

Jedním problémem je základní neshoda ohledně návrhu Xenu, který vyžaduje oddělenou komponentu hypervizoru v uživatelském prostoru. Některým vývojářům se to zdá jako nešťastné míchání kódu v hlavní řadě, specifického jaderného kódu Xenu a kódu v uživatelském prostoru – samozřejmě s ABI zalitým do betonu mezi tím. Mnoha vývojářům se více zamlouvá přístup s hypervizorem zcela v jádře, jako je to v KVM. Thomas Gleixner má obavy z možných výsledků začlenění kódu Xen Dom0 (mezi jinými) obzvláště z tohoto důvodu:

A krom toho může bránit vývoji správně navrženého hypervizoru v Linuxu: ,proč se obtěžovat s tou novou věcí, může sice být hezčí a čistší, ale my už máme tenhle Xen dom0?‘

Stevenu Rostedovi, který na Xenu v minulosti pracoval, se také nelíbí návrh hypervizoru a vliv, který má na vývoj jádra:

Hlavní rozdíl mezi KVM a Xenem je v tom, že KVM je součástí Linuxu. Xen ne. Důvod, proč na tom záleží, je, že když budeme chtít udělat změnu v tom, jak Linux funguje, můžeme jednoduše donutit KVM změnu zvládnout. To znamená, že ho můžeme považovat za Dom0 a hypervizor, které jsou vždy synchronní.

Kdybychom Xenu rozbili rozhraní s Dom0, pak bychom měli spoustu lidí, kteří by křičeli, že jsme rozbili definované API. Jednou z Thomasových námitek (která je platná) je, že jakmile Linux jednou podporuje externí API, musí ho vždy udržovat kompatibilní. To bude bránit dalšímu vývoji Linuxu, když se API rozhází po celém jádře bez přemýšlení.

Steven navrhuje, aby byl hypervizor Xenu začleněn do hlavní řady, aby byl celý součástí Linuxu a aby jeho ABI bylo interní a tudíž měnitelné rozhraní. Někteří další vývojáři – obecně ti, kteří jsou nejvíce nepřátelští k začlenění Dom0 v jeho současné podobě – tento návrh podpořili. Rozhodně to není poprvé, kdy se tento návrh objevil. Nicméně i přes časté volání po tom, aby byla část „instalatérské vrstvy“ do jádra zavedena správně, se tak ještě nestalo; zdá se nepravděpodobné, že by něco tak velkého jako Xen byla první komponenta z uživatelského prostoru, která by tuto bariéru prolomila – i když vývojáři Xenu byli tomuto návrhu přístupní.

Návrh hypervizoru by pravděpodobně sám o sobě nebyl nepřekonatelnou překážkou, jsou zde ale další stížnosti. Správcům architektury x86 se nelíbí změny, které patche Dom0 dělají v jejich kódu. Podle jejich soudu je v nich příliš mnoho podmínek „if (xen)...“ a příliš mnoho #ifdefů. Chtěli by, aby byl kód Xenu pročištěn tak, aby méně narušoval vnitřní kód x86. V tomto bodu je Linus podporuje:

Faktem je (a jedná se o fakt): Xen je z vývojářského pohledu naprostý hnus. Soukromě jsem o tom mluvil s Jeremym. Xen znečišťuje kód architektury takovými způsoby jako ŽÁDNÝ JINÝ subsystém. A vůbec NIKDY jsem neviděl, že by vývojáři Xenu tento fakt uznali a pokusili se to spravit.

Případu Xen nepomohla ani čísla ohledně výkonnosti, která zaslal Ingo Molnár. Pokud zvolíte správný benchmark, zdá se, že vrstva paravirt_ops v jádře o 1 % zvyšuje režii, což má dopad na výkonnost. Pravirt_ops je kód, který abstrahuje nízkoúrovňové strojové operace: umožňuje, aby mohlo stejné jádro běžet na „čistém železe“ nebo virtualizované pod hypervizorem. Přidává vrstvu nepřímých volání funkcí tam, kde se předtím používaly inline funkce. Cenu za tato volání funkcí nyní Ingo kvantifikoval (na druhou stranu je třeba podotknout, že Rusty Russel ukázal, že se správným benchmarkem má mnoho dalších běžných konfiguračních voleb mnohem vyšší cenu).

Problém zde není v tom, že mají uživatelé Xenu pomalejší jádro; skutečný problém je, že jakékoliv jádro, které kdy může být spuštěno pod Xenem, musí být přeloženo s povolenými paravirt_ops. Je jenom pár věcí, které distributorům znepříjemňují život víc, než když je něco nutí přeložit, dodat a podporovat další konfiguraci jádra. Většina distribučních jader tedy běží s povolenými paravirt_ops; to znamená, že všichni uživatelé bez ohledu na to, jestli chtějí Xen používat, cenu platí. V některých případech je přitom cena příliš vysoká; Nick Piggin řekl:

Ve výchozím jádře SLES11 jsme museli paravirt zakázat (uznávám, že to bylo předtím, než byly provedeny nedávné změny). Je totiž jenom konečný počet jednoprocentních výkonnostních regresí, které můžete zavést, aniž by zákazníci přestali upgradovat (a prodejci zveřejňovat benchmarky s novým softwarem).

Ingo je také velmi kritický k vnímané ceně paravirt_ops, ale také navrhuje řešení:

Všimněte si, že je akceptovatelné a proveditelné být trochu vynalézavější, když na nás házíte tuto v současnosti drahou paravirtualizaci. Moje zpráva lidem od Xenu je: Použijte dynamické patchování, opravte si hypervizor a prostě používejte staromódní sebekázeň a selský rozum, když něco navrhujete. A pro dobrá nebesa, dávejte pozor na výkonnost nativního jádra, protože v dlouhodobém měřítku je to i vaše živobytí.

Pokračuje tím, že začlenění Dom0 by nyní věci jenom zhoršilo; vývojáři Xenu by měli menší motivaci opravit problémy a distributorům by to zároveň ztížilo vypnout paravirt_ops ve svých jádrech.

A to pravděpodobně vede k základní neshodě v této diskuzi. Jsou tu dva oddělené názorové proudy, které se týkají toho, kdy by měl být začleněn kód se známými problémy:

• Někteří vývojáři poukazují na to, že kódu, který je v hlavní řadě, se dostává více pozornosti od mnohem většího počtu vývojářů, takže se rychleji zlepšuje. Je snadné najít příklady kódu, který se po mnoha letech chřadnutí mimo hlavní řadu po začlenění rychle zlepšil. To je důvod pro existenci stromu -staging a obecné politiky začlenit ovladače dříve než později.

• Někteří vývojáři – a občas ti samí vývojáři – místo toho říkají, že nejlepší čas pro odstranění základních problémů je před začleněním. Pro problémy s ABI v uživatelském prostoru je to určitě pravda; ty často nemohou být po vydání ve stabilním jádře opraveny vůbec. Držet kód mimo hlavní řadu je ale také mocná páka, kterou mohou správci subsystému použít k tomu, aby vývojáře motivovali k opravě problému. Jakmile je kód začleněn, tento konkrétní nástroj již není k dispozici.

Obě tyto linie se v diskuzi o Xenu objevily. Není pochyb o tom, že kód Xen Dom0 uvidí víc očí – a přibude patchů – až bude začleněn. Mnoho vývojářů si tedy myslí, že správná věc je začlenit tuto velmi žádanou vlastnost a poté ji spravit. Chris Mason to řekl takto:

Myšlenka, že bychom měli převzít kód, který se značně využívá, je důležitá. Nejlepší místo, kde opravit xen, je v jádře. A vždy bylo; držet ho venku znamená ztěžovat život všem zúčastněným.

Silněji se ale ozývá hlas, který říká, že problémy je nejprve potřeba opravit. Rozhodujícími faktory se zdají být (1) ABI v uživatelském prostoru a (2) vliv na vnitřní kód x86; tyto problémy odlišují Xen od ovladače nebo souborového systému. A z toho vyplývá, že kódu Dom0 není předurčeno dostat se do hlavní řady nijak brzo. Místo toho se od vývojářů Xenu očekává, že se vrátí a opraví seznam problémů – spousta práce, na jejímž konci je nejistý výsledek.

Čištění stránek, část druhá

Bezpečnostní rubrika LWN se minulý týden zabývala nedávno navrženými patchi, které by „čistily“ jadernou paměť jejím vynulováním při uvolnění. V té době byla obecně dobře přijata druhá verze patchů, která bezpodmínečně nulovala paměť při uvolnění v závislosti na bootovacím parametru sanitize_mem. Lidé ale možná prostě neměli čas se na to podívat – během minulého týdne bylo vzneseno několik námitek, které se většinou setkaly s agresivními odpověďmi vývojáře Larryho Highsmithe. V mnoha ohledech to začíná vypadat jako další lekce z „jak nepracovat s jadernou komunitou“.

Základní problém je, že ještě dlouho poté, co byla paměť uvolněna, v ní mohou zůstat data. Někdy tato data obsahují hesla, kryptografické klíče, důvěrné dokumenty atd. Jádro však obecně nemůže vědět, které stránky citlivá data obsahují; jejich životnost lze ale omezit tím, že se paměť vynuluje, když je dealokována. Výzkumná zpráva popisuje experimenty, které prokázaly, že na linuxových systémech mohou data v paměti zůstat několik dní a dokonce i týdnů; chyba v jádře, která by zpřístupnila paměť, by mohla útočníkovi k těmto datům poskytnout přístup.

Larry tedy navrhl přidat čištění stránek, což je vlastnost, která je již dlouho součástí patchů vkládaných do jádra projektem PaX security. Jde zde zjevný dopad na výkonnost, když je znovuzískávána paměť, ale vzhledem k tomu, že je paměť nulována při alokacích (aby se zamezilo zjevným únikům informací), na první pohled tento dopad nemusí být tak velký. Jak upozorňuje Arjan van de Ven:

… a když budeme nulovat při uvolňování, nemusíme uvolňovat při alokaci. I když je to trochu kontroverzní, znamená to, že přinejmenším část z ceny se pouze přesouvá v čase, což znamená, že by to snad nemělo být PŘÍLIŠ špatné...

Peter Ziljstra má obavy z dopadů na cache: Nulování při alokaci má výhodu v tom, že se ohřeje cache; ta paměť se bude používat, protože proč ji jinak alokovat? [...] nulování při uvolnění způsobí jenom vytěsňování z cache bez žádného zisku. Arjan nicméně popisuje, jaké vidí dopady na cache, a uzavírá: Nepochop to špatně, netvrdím, že nulování při uvolnění je lepší, jenom se snažím upozornit na to, že ,výhoda‘ nulování při alokaci není ani náhodou tak velká, jak si lidé občas myslí...

Další, jako například Alan Cox, si myslí, že dopad na výkonnost je nepodstatný: Pokud potřebuješ toto promazávání dat, pak je výkonnostní dopad v podstatě irelevantní, bezpečnost je na prvním místě. Peterovi a dalším se nelíbí to, že by tuto cenu platili všichni uživatelé jádra, i ti, kteří nepovolili sanitize_mem. Poznamenává, že tyto patche přidávají volání funkcí a větvení, i když tato vlastnost není zapnutá. Padly návrhy udělat benchmarky navrhovaného kódu proti existující implementaci, ale tady konverzace vykolejila.

Larry byl zjevně frustrován směrem diskuze, ale místo toho, aby byl trpělivý, vypěnil. Ve vlákně se rozhodně objevily provokace, Peterův komentář fakt, se prober, opravuj skutečné chyby, nezpomaluj nám jádro kvůli tomu, abys ses mohl chlubit, že v něm máš kód, rozhodně nepomohl. Larry si nicméně musí uvědomit, že on je ten, kdo se snaží něco přidat do jádra, takže „důkazní břemeno“ je na něm. Místo toho se z jeho blahosklonného chování zdá, že má dojem, že jaderné komunitě předkládá dar – a oni jsou příliš hloupí na to, aby to pochopili.

Důležitá vlastnost pro přispěvatele do jádra je, aby se zbytkem komunity spolupracovali: Odpovídali na otázky, reagovali na revize kódu, návrhy, atd. Když se tak nestane, patche bývají ignorovány bez ohledu na jejich technickou hodnotu; a zdá se, že Larry zamířil touto cestou. Když bylo navrženo použít kzfree() pro specifické jaderné alokace pro citlivá data – které by paměť vynulovalo, pak uvolnilo – Larry odpověděl:

To nemá cenu a kzfree nefunguje. Jak jsem říkal ve své dřívější odpovědi, otestujte si to, prosím, sami a uvidíte. Kdokoliv to napsal, ignoroval, jak funguje SLAB/SLUB, a pokud bylo kzfree v jádře někdy použito, všimli bychom si toho už dávno.

Vzhledem k tomu, že Larry reagoval na návrh správce SLAB Pekky Enberga, nebyla tato odpověď – i kdyby byla pravdivá – pravděpodobně nejlepší. Pekka a další se ptali na specifické problémy kzfree(), ale Larryho odpověď byla vágní a blahosklonná. Když se Pekka a Ingo Molnár pokusili identifikovat, v čem spočívají problémy, Lerry pokračoval kázáním o paměťovém alokátoru SLOB.

Krom toho Ingo poukázal na fakt, že stejná citlivá data mohou dlouho zůstat na jaderném zásobníku:

Dlouho běžící úlohy, které se dotkly jakékoliv cesty crypto (nebo jiných citlivých dat v jádře) a tato data jim unikla na zásobník, je zde mohou držet donekonečna (obzvláště pokud se tyto informace náhodou dostaly hluboko do kontextu zásobníku) – až do ukončení úlohy. Tato informace přežije uvolňování a úklid původních citlivých dat.

Místo toho, aby to považoval za další nápad, který je potřeba řešit, pokračoval Larry ve své tirádě:

Jenže ty i zbytek party s vašimi neurčitými pochybami jste poslali jenom z větší části zbytečné komentáře, naprosto nezdvořilé odpovědi, zjevné pokusy podstrčit mi špatné informace, nepodloženou kritiku atd. Víc nesmyslů pohromadě jsem naposledy viděl, když jsem četl nezveřejněný scénář Jerryho Lewise.

Nápad nulovat paměť při jejím uvolňování s ohledem na příznak předaný v době bootu je sám o sobě rozumný. Několik hackerů jádra, včetně Alana Coxe a Rika van Riela, vyjádřilo zájem na tom, aby tato vlastnost byla přidána. Zdá se, že s trochou snahy by bylo možné snížit výkonnostní postih, když bude vypnutá, na rozumnou úroveň, ale pokud bude hlavní navrhovatel dál trávit čas hádkami a flamováním, je nepravděpodobné, že k nějakému začlenění dojde.

Novější sada patchů, která pouze používá kzfree() na specifických citlivých místech (správa tty bufferů, práce s klíči 802.11 a crypto API), byla také navržena Larrym, ale Linuse Torvaldse příliš neohromila. Není potřeba používat kzfree(), protože jednoduché memset() dostačuje. Linus příliš nevěří, že jsou tyto patche zapotřebí, ani se mu nelíbí, jakým způsobem Larry reagoval na revize:

Zcela upřímně o těchto patchích vůbec nejsem přesvědčen.

Také se mi moc nezamlouvá, jak snadno máváš rukou nad připomínkami všech ostatních.

Na patche byly také další technické stížnosti, konkrétně na využití kzfree() všude v patchi crypto API. Správce crypto API Herbert Xu poznamenal: Nulování metadat je zbytečné. Všeobecně to vypadalo tak, že byly patche vytvořeny s nechutí – jako kdyby udělat to znamenalo prokazovat někomu službu.

Kudy se věci budou ubírat dále, není jasné. Larry, zdá se, s diskuzí končí svojí odpovědí Linusu Torvaldsovi: Až se příště v jádře objeví bezpečnostní slabina, která bude jenom trochu podobná některému z naznačených útoků, o kterých jsem psal, bude užitečné mít možnost odkázat se na tyto reakce. Larryho frustrace je částečně opodstatněná, ale je třeba, aby si uvědomil, že mu (ani jádru) nebude k ničemu.

Přispěvatelé do jádra, obzvláště nováčci, musí uznat, že v komunitě jsou lidé alespoň stejně chytří jako oni. V tomto případě se někteří z těchto vývojářů nezaměřují na bezpečnost tak jako Larry, ale to nijak nesnižuje jejich znalost jádra ani zájem o to, aby do něj byly přidány patche bezpečnost zlepšující. Bylo by nešťastné, kdyby tato vlastnost, která by v některých prostředích mohla být velmi užitečná, zůstala ležet na kraji cesty.

       

Komentáře

[trekker.dk]

Mozilla a Debian jsou hostovány na systémech s Xenem.

Od jisté doby stránka pro vyhledávání balíčků pro Debian (http://www.debian.org/distrib/packages) chodí neskutečně pomalu, stejně tak i vyhledávání. Zajímalo by mě, jestli je tu nějaká souvislost.

[Jendа]

Pomalost jsem si vysvětloval rostoucí popularitou Linuxu

[jano]

Xen je moloch a aj RedHat sa ho pomaly vzdava a inklinuje ku kvm,.. takze ja som za to nechat Xen umriet.

[geebranz]

Updated one

metalbuildingsbatonrouge.com