Jaderné noviny – 6. 3. 2014: Zhroucení souborů

24. 3. 2014 | Luboš Doležel | Jaderné noviny | 4372×

Aktuální verze jádra: 3.14-rc5. Citáty týdne: Arnd Bergmann, Eric Biederman. Projekt dynamického patchování jádra od Red Hatu. Ředitel SUSE Labs o patchování jádra s kGraft. Broadcom vydal zdrojový kód grafických ovladačů. Hledání správného řešení pro zhroucení částí souborů.

Obsah

• Aktuální verze jádra: 3.14-rc5
• Citáty týdne: Arnd Bergmann, Eric Biederman
• Projekt dynamického patchování jádra od Red Hatu
• Ředitel SUSE Labs o patchování jádra s kGraft
• Broadcom vydal zdrojový kód grafických ovladačů
• Hledání správného řešení pro zhroucení částí souborů

Aktuální verze jádra: 3.14-rc5

Aktuální vývojová verze jádra je 3.14-rc5 vydaná 2. března. Linus k ní řekl: Nic moc tam není. A tak to mám rád. Ozkoušejte, jestli vám funguje.

Stabilní aktualizace: během minulého týdne žádné nevyšly. Aktualizace 3.13.6 a 3.10.33 se aktuálně revidují; jejich vydání můžeme očekávat 6. března nebo později.

Citáty týdne: Arnd Bergmann, Eric Biederman

Řekl bych, že tohle je ten zlom mezi „jsi blázen, že ukazuješ zdrojový kód pro své GPU a riskuješ soudní spory“ a „jak se chceš udržet na trhu bez svobodného ovladače“.

-- Arnd Bergmann

Jelikož nikdo nemá o tento kód takový zájem, aby jej udržoval, tak si myslím, že bychom jej měli vyhodit namísto toho, abychom uživatelský prostor uváděli v omyl, že tento kód funguje a fungovat bude nadále.

-- Eric Biederman

Projekt dynamického patchování jádra od Red Hatu

Zdá se, že i Red Hat má projekt pracující na patchování běžících jader. kpatch vám umožňuje patchovat jádro bez restartu systému nebo jakýchkoliv procesů. To umožňuje administrátorům nasadit do jádra kritické bezpečnostní záplaty ihned, bez nutnosti čekat na doběhnutí dlouho běžících úloh, odhlášení uživatelů nebo naplánovaný čas pro restart. Máte lepší možnost udržet si systém v provozu bez nutnosti obětovat bezpečnost či stabilitu. Vypadá to, že má blíže ke ksplice než SUSE kGraft, jelikož patchuje kompletní funkce.

Ředitel SUSE Labs o patchování jádra s kGraft

Libby Clark připravila rozhovor s Vojtěchem Pavlíkem, ředitelem SUSE Labs, a to na téma kGraft. V tomto rozhovoru se dozvíme více o projektu na patchování jádra za běhu kGraft od SUSE; jak se patche kGraft spojují s linuxovým jádrem; jak se odlišuje od jiných řešení pro patchování za běhu; jak budou moci vývojáři používat následující vydání; a jak projekt komunikuje s jadernou komunitou, aby byl přijat v upstreamu.

Broadcom vydal zdrojový kód grafických ovladačů

Broadcom oznámil vydání zdrojového kódu a dokumentace pro svůj grafický subsystém VideoCore IV. Tento subsystém je mimo jiné k nalezení v procesoru Raspberry Pi. Za poslední desetiletí se trend v oblasti desktopové grafiky naklonil k větší otevřenosti a nejinak je tomu v oblasti mobilní. Broadcom – lídr v oblasti grafických procesorů – stojí v čele těchto změn a snaží se k nim přispět.

Hledání správného řešení pro zhroucení částí souborů

Návrh systémových volání není nikdy snadný; často se najdou překvapivé krajní situace, na které vývojáři při přípravě rozhraní zapomněli. Obzvláště pak systémová volání pro práci se systémy souborů se zdají být k těmto problémům náchylná, jelikož složitost a rozmanitost implementací systémů souborů znamená, že se může objevit řada překvapení číhajících na vývojáře, který chce vytvořit novou operaci nad soubory. Některá tato překvapení se vynořila během diskuze o plánovaném rozšíření systémového volání fallocate().

fallocate() se zabývá alokací prostoru v souboru; jeho počátečním cílem bylo umožnit aplikaci alokovat bloky v souboru před zápisem. Tento způsob předalokace zajistí, že bude k dispozici dostatek místa, ještě než se pokusíme zapsat data; implementacím systémů souborů to také může pomoci efektivněji rozložit alokované místo na disku. Později byla přidána operace FALLOC_FL_PUNCH_HOLE pro dealokaci bloků v souboru, která po sobě nechává díry.

V únoru navrhl Namjae Jeon novou operaci fallocate(); jeho návrh obsahoval implementace pro ext4 a xfs. Podobně jako operace vytváření děr odstraňuje data ze souboru, ale je tu jeden rozdíl: místo zanechání díry tato operace přesune všechna data za dotčenou oblastí na její začátek, čímž je celý soubor zkrácen. Prvním případem využití by mohlo být rychlé a efektivní odstranění části video souboru. Pokud je odstraňovaná oblast zarovnaná na bloky (což by alespoň na některých systémech souborů bylo vyžadováno), pak by odstranění mohlo vést jen ke změně mapy extentů souboru bez jakéhokoliv kopírování dat. Jelikož soubory s videem mohou být velké, není divu, že by efektivní operace pro „vyjmutí“ byla zajímavá.

Nuže, jaké otázky vyplývají při takové operaci na povrch? Mohli bychom začít interakcí se systémovým voláním mmap(), které mapuje soubor do adresního prostoru procesu. Navržená implementace odstraňuje všechny stránky od dotčené oblasti až na konec souboru z cache stránek; špinavé stránky jsou nejprve zapsány na disk. Toto zabrání okamžité ztrátě dat, která mohla být zapsána přes mapování, a zbaví se jakýchkoliv stránek, které po dokončení operace budou za koncem souboru. Mohlo by to ale být překvapivé pro proces, který neočekává ve svém mapování posuny konce souboru; Dave Chinner ale říká, že aplikace používající operaci zhroucení souboru (collapse) obvykle ke svým souborům nepřistupují přes mmap(). Navíc by aplikace překvapené náhlým zkrácením souboru obvykle nebyly schopné řešit ani jiné úpravy, i kdyby tato operace nebyla k dispozici.

Jak ale Hugh Dickins upozornil, je tu jeden související problém: na systému souborů tmpfs jsou v cache stránek všechny soubory a vypadají dosti jako mapování do paměti. Jelikož cache stránek je pro tmpfs úložištěm, tak odstranění stránek z cache stránek nepovede ke šťastnému konci. Dříve než tedy tmpfs začne tuto operaci podporovat, bude nutné věnovat více úsilí do správné podpory cache stránek. Hugh si nebyl jist, jestli bude někdy potřeba tuto operaci na tmpfs podporovat, ale podle jeho vlastních slov vyřešení problémů s cache stránek na tmpfs pravděpodobně povede k robustnější implementaci i na jiných systémech souborů.

Hugh také dumal nad tím, zda bychom namísto jednosměrné operace „zhroucení“ neměli mít operaci obousměrnou:

Z názvu ZHROUCENÍ [collapse] jsem trochu smutný, ale po sedmi měsících je trochu pozdě si stěžovat. Překvapuje mě, že odvádíte všechnu tuto práci pro zmenšení souboru, aniž by existovala odpovídající operace nafouknutí – dá se čekat, že všichni inzerenti, jejichž reklamu umazáváte, se brzy vrátí s tím, že chtějí nafukování, aby ji měli zase kam vrátit.

Andrew Morton na to navázal návrhem, že byl bylo možná nejlepší všeobecné systémové volání přesuň tyto bloky odsud tam. Davevovi se to ovšem moc nezamlouvalo, má totiž obavy, že by to bylo složité a plné různých krajních situací:

Jinými slovy, zhroucení rozsahu je jednoduchá operace, „přesuň libovolné bloky odsud tam“ je noční můra jak z hlediska specifikace, tak implementace.

Andrew nesouhlasil; říká, že obecnější rozhraní by bylo lepší a že problémy je možné překonat, ale nikdo jej v tomto názoru nepodpořil. Proto je pravděpodobné, že operace zůstanou omezené na zhroucení částí souborů; dodatečná operace „vložení“ může být přidána v budoucnu, pokud by se pro ni našlo využití.

Mezitím se objevila další otázka ohledně chování volání; co se stane, pokud odstraňovaný obsah dosahuje konce souboru? Současná podoba patche v takovém případě vrací EINVAL s tím, že by místo toho měl být použit truncate(). Ted Ts'o se zeptal, zda by neměly tyto operace být převedeny přímo na volání truncate(), ale Dave je proti. Operace zhroucení, která zahrnuje konec souboru, je podle něj nepochybně chybou; v takové situaci je lepší chybu vrátit.

Jsou tu ale i zajímavé bezpečnostní problémy, pokud by operace zhroucení směla obsahovat konec souboru. Systémy souborů mohou alokovat bloky za koncem souboru; o toto lze požádat pomocí fallocate(). Tyto bloky obvykle nejsou systémem souborů vynulovány; místo toho jsou aplikacím nepřístupné, takže stará data tam uložená nejsou nikdy čtena. Pokud by si programátoři nedali pozor, pak by implementace zhroucení, která umožňuje jít za konec souboru, mohla zpřístupnit tato stará data, hlavně kdyby operace byla přerušena (například pádem systému). Než abychom na vývojáře systémů souborů líčili takovou past, Dave by raději riskantní operace rovnou zakázal, hlavně když není znám žádný důvod, proč je podporovat.

Výsledkem diskuze je tedy to, že operace FALLOC_FL_COLLAPSE_RANGE půjde do jádra v podstatě beze změny. Nebude mít všechny schopnosti, které by vývojáři rádi viděli, ale nabídne jednu užitečnou funkci, která by určitým aplikacím mohla pomoci na výkonu. Zda to bude stačit i do budoucna, se ještě ukáže; návrh API systémových volání je obtížný. Pokud by ale někdy byly potřeba dodatečné funkce, pak je můžeme zařadit pomocí nových povelů FALLOC_FL při současném zachování kompatibility.

       

Komentáře

[Michal Kubeček]

Linus k ní řekl: Nic moc. A tak to mám rád.

"Nic moc" zní jako že to RC nestojí za moc. V tomhle kontextu Linus IMHO myslel spíš něco jako "není toho moc" (změn oproti předchozímu RC).

Vypadá to, že více blíže ke ksplice než SUSE kGraft

více → má?

[Petr Ježek]

Asi tak :)

[little.owl]

Ja uz budu na toto tema radsi ticho.

[pavlix]

Pročpak?

[little.owl]

Nejake shrnuti kGraft versus kpatch by bylo? Vyhody, nevyhody, sance se prosadit?

[j]

To mas jednoduchy ... proc udelat neco jednou a poradne, kdyz si kazdej muze hrat na svym pisecku. Ucel byl splnen, muzes si vybrat ... ci chyby si nasadis do systemu, pripadne s jakym hlasenim se ti system zhrouti ;D.

Mezi nama, chtel bych videt silence, kterej by zcela jakkoli (a to mluvim samo i o aplikacich) patchoval produkcni system "za chodu". kdykoli cokoli patchuju ja, tak si to nejdriv vyzkousim na testovacim stroji ... a kdyz to projde, tak si pockam na nejaky volny dny ...

Tohle je neco na zpusob voodoo ... neco se ti vymeni, ale nemas moc moznosti zjistit, ze je vse OK. To zjistis az se neco podela, pripadne az ti po vypadku elektriky system nenastartuje (coz casto potesi jeste vic, jet nekam par set km ...)

[Max]

Jet někam kvůli sw chybě? Buď se pohybuješ jen v home sféře, nebo si sakra zaspal dobu .
Zdar Max

[j]

Ne kazdej je takovej blazen, aby poustel drac a podobny karty do netu, nemluve o tom, ze spousta zarizeni nic takovyho nema a nikdy mit nebude. Takze se trebas nejdriv musis dostat aspon do interni site, coz se trebas nedostanes, protoze prave ten srv kterej by ti to umoznil jaksi nenastartoval ...

[trekker.dk]

Takze se trebas nejdriv musis dostat aspon do interni site, coz se trebas nedostanes, protoze prave ten srv kterej by ti to umoznil jaksi nenastartoval ...

Ne každej je takovej blázen, aby takový server měl jenom jeden.

[Max]

Pokud k nim nechováš důvěru, tak si vždy můžeš na firewallu povolit jen přístup z nějaké tvé IP, kde se pohybuješ a jsi s bezpečností úplně někde jinde.
Zdar Max

[Michal Kubeček]

Každý paranoik časem přijde na to, že požadavky zabepečení ve smyslu "aby se tam nikdy nemohl dostat nikdo, kdo nemá" a zabezpečení ve smyslu "abych se tam dostal, kdykoli bude potřeba řešit problém" jsou v mnoha případech protichůdné, takže je potřeba stanovit si priority.

[Michal Kubeček]

Mezi nama, chtel bych videt silence, kterej by zcela jakkoli (a to mluvim samo i o aplikacich) patchoval produkcni system "za chodu".

Ve skutečnosti kGraft vznikl jako reakce na zcela reálnou a hmatatelnou poptávku ze strany významných enterprise zákazníků - a pochybuji, že v případě kpatch to bylo jinak.

Samozřejmě si to ale nelze představovat tak, že se bude za běhu patchovat všechno. Tohle je mechanismus primárně cílený na dočasné opravy nejkritičtějších chyb na systémech, u kterých by případný downtime byl velmi náročný a/nebo nákladný.

To zjistis az se neco podela, pripadne az ti po vypadku elektriky system nenastartuje (coz casto potesi jeste vic, jet nekam par set km ...)

U systémů, o kterých se bavíme, je samozřejmostí zálohované napájení a obvyklá je i remote console. Nemluvě o tom, že jakmile už by z jakéhokoli důvodu došlo k rebootu, je to příležitost nahradit live opatchované jádro řádným updatem.

[j]

Ve skutecnosti se casove kriticky zelezo zabezpecuje zcela jinak nez bezpecnosti vlastniho SW. A co sem mel tu cest ... dobre 50% nejnakladnejsich aplikaci (vyrobni linky ....) jede v ... DOSu. SW se pak vymenuje vyhradne pokud dochazi k nejaky zasadni prestavbe => stejne to musi byt cely odstaveny. Jinak na to nikdo nesaha. Prave proto, ze jakakoli odstavka = miliony skod.

Vymenovat kernel za chodu si muzu dovolit trebas u webu ... tam kdyz se to zhrouti, tak holt napisu nakej blabol na tema "admin nalil kafe do klavesnice".

[Michal Kubeček]

OK, zřejmě tomu rozumíte lépe než naši zákazníci. Teď jen doufám, že si to tu nepřečtou a nezjistí, že by vlastně měli místo SLESu používat DOS, jinak budu bez práce…

[nikdo]

kdykoli cokoli patchuju ja, tak si to nejdriv vyzkousim na testovacim stroji

A na téhle technice se s použitím jaderných patchů něco mění?

[j]

To ze ti neco projde na testu, jeste vubec neznamena, ze to stejne projde i naostro. Je to sice jednim z predpokladu, nikoli ale postacujicim.

[BrainLess]

Sakra a co ti brani jet ve stejnem modu. Proste budes mit stroj ( test ) na kterym to patchnes za chodu a udelas si par testu a pak to bez "vypadku sluzby, SLA" udelas na produkci.

[j]

Jop, a pak zjistis, ze se ti to na produkcnim stroji zhroutilo, trebas proto, ze je sitovka namapovana o mega vedle, a patch zpusobi, ze se uz na stroj nepripojis ...

[Filip Jirsák]

Když budete stroj restartovat kvůli aktualizaci jádra, dojde k výpadku určitě. Takže to patchování za běhu můžete brát tak, že když se povede, máte to bez výpadku, a když se nepovede, jste na tom stejně, jako bez patchování. Navíc riziko toho, že se patchování za běhu nepovede, je větší jen zpočátku, než se ta technologie odladí. Až to bude vyzkoušené, bude stejné riziko, ať už patch budete aplikovat online nebo offline.