![[Příznaky stránek]](http://lwn.net/images/ns/kernel/page-flags.png)
Portál AbcLinuxu, 5. května 2025 17:27
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á.
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.
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í“ 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.
[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.
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.
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ě.
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:
![[Příznaky stránek]](http://lwn.net/images/ns/kernel/page-flags1.png)
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ů.
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:
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:
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:
Stevenu Rostedovi, který na Xenu v minulosti pracoval, se také nelíbí návrh hypervizoru a vliv, který má na vývoj jádra:
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:
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:
Ingo je také velmi kritický k vnímané ceně paravirt_ops, ale také navrhuje řešení:
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:
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.
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:
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:
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:
Místo toho, aby to považoval za další nápad, který je potřeba řešit, pokračoval Larry ve své tirádě:
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:
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.
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.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
29.6.2009 14:28
Pomalost jsem si vysvětloval rostoucí popularitou Linuxu 