Jaderné noviny - 26. 4. 2006

9. 5. 2006 | Robert Krátký | Jaderné noviny | 5248×

Aktuální verze jádra: 2.6.16.11. Co nového se splice(). OpenVZ a checkpointing za běhu. Začíná diskuze o AppArmor. vmsplice() versus COW. Komu patří stack?

Aktuální verze jádra: 2.6.16.11

Aktuální verze stabilního jádra je 2.6.16.11. Byla vydána 24. dubna. Jedinou změnou je oprava bezpečnostní chyby v souborvém systému CIFS. 2.6.16.10 byla také vydána 24. dubna, ale obsahovala větší množství důležitých oprav.

Aktuální předverze je 2.6.17-rc2; během minulého týdne nevyšly žádné nové -rc. V hlavním git repozitáři se však shromažďují patche; jde povětšinou o opravy, i když je mezi nimi i Trusted Platform Module (TPM) 1.2, podpora více velikostí stránek pro architekturu PA-RISC a systémové volání vmsplice() (viz níže).

V minulém týdnu nebyly vydány žádné -mm.

Co nového se splice()

Jens Axboe rozeslal mail, ve kterém popisuje stav splice(). Poznamenává, že rozhraní splice() a tee() by měla být - jak ze strany uživatelské, tak ze strany jádra - v současné době stabilní a neočekávají se žádné další změny. Systémové volání sendfile() bylo přepracováno tak, aby využívalo mechanismus splice(), ačkoliv tento proces nebude dokončen před začátkem vývojového cyklu verze 2.6.18.

Přestože je splice() možná stabilní, stále se toho děje dost. Konkrétně jde o další systémové volání, které přidal Jens:

    long vmsplice(int fd, void *buffer, size_t len, unsigned int flags);

Zatímco běžné volání splice() propojí rouru na soubor, toto volání je navrženo tak, aby předávalo paměť z uživatelského prostoru přímo do roury. Takže paměťový rozsah len bajtů začínajících na buffer bude natlačen do roury fd. Parametr flags se zatím nepoužívá.

Pomocí vmsplice() může aplikace generující data v paměťovém bufferu zmiňovaná data odeslat na místo určení bez jakéhokoliv kopírování. Při vhodně nastavené velikosti bufferu může aplikace snadno provádět dvojité bufferování [double-buffering]; polovina bufferu provádí I/O prostřednictvím vmsplice(), zatímco druhá polovina je naplňována. Je-li buffer dostatečně velký, stačí aplikaci volat vmsplice() vždy, když je zaplněna polovina bufferu - ostatní bude fungovat bez potřeby několika vláken nebo komplikovaných synchronizačních mechanismů.

Je však důležité správně nastavit velikost bufferu. Je-li buffer alespoň dvakrát tak velký jako maximální počet stránek, které může jádro do roury natáhnout, může být úspěšné provedení vmsplice() na polovině bufferu vyhodnoceno aplikací tak, že ta druhá polovina bufferu už neprovádí I/O. A protože polovina bufferu zcela zaplní dostupný prostor jaderné roury, nemůže být druhá polovina vložena dříve, než budou všechna ostatní data z roury zpracována - alespoň v jednoduchých situacích. Takže když vmsplice() uspěje, může aplikace bezpečně doplnit druhou polovinu novými daty. Podaří-li se však aplikaci zmást, mohlo by se stát, že by začala přepisovat data, která ještě jádro nezpracovalo.

Jensův patch přidává pár fcntl() operací, které by v této otázce měly pomoci. Operace F_GETPSZ vrátí maximální počet stránek, které mohou být vloženy do bufferu roury, což je zároveň maximální počet stránek, na kterých může operace vmsplice() provádět I/O. Další je F_SETPSZ pro změnu maximální velikosti - i když tato operace zatím vrací jen EINVAL. Linus má však obavy, že tyto informace nestačí k tomu, abychom věděli, že s danou stránkou už není prováděn I/O. V situacích, kdy jsou v jádře další buffery - třeba jen další roura v řadě - by mohlo mít jádro pořád odkazy na stránku, i když už by byla z původní roury zpracována. A síťování přidává další problémy: je-li stránka "vmsplicována" na TCP socket, nebude znovu použitelná, dokud vzdálený počítač nepotvrdí přijetí dat, která obsahovala. Toto potvrzení přijde dlouho poté, co byla stránka zpracována z bufferu roury.

Z toho všeho vyplývá, že na rozhraní vmsplice() je ještě potřeba trochu zapracovat. Pravděpodobně bude nutné přidat další systémové volání, které aplikaci umožní zjistit, jestli už jádro s danou stránkou skončilo. Současná implementace vmsplice()také neumí napojit příchozí rouru na uživatelskou paměť. Fungování i opačným směrem je dosti komplikovaná záležitost a v brzké budoucnosti se ho asi nedočkáme.

OpenVZ a checkpointing za běhu

Projekt OpenVZ je GPL částí proprietárního produktu Virtuozzo firmy SWSoft. Pomocí OpenVZ může linuxový systém implementovat vícero "virtuálních prostředí", z nichž každé se procesům v něm spuštěným jeví jako samostatný systém. Virtuální prostředí mohou mít své IP adresy a lze je podrobit různým omezením zdrojů. Jinými slovy, jde o implementaci kontejnerového konceptu, jednu z mnoha pro Linux. V poslední době začaly jednotlivé projekty zabývající se virtualizací a kontejnery projevovat větší zájem o začlenění alespoň části svého kódu do hlavního jádra, přičemž OpenVZ není výjimkou. Vývojáři OpenVZ jsou tedy v konferencích o vývoji jádra více vidět.

Projekt OpenVZ nedávno oznámil novou verzi, která přidává jednu zásadní funkci: checkpointing [záznam aktuálního stavu] a migrace virtuálních prostředí za běhu. Stav prostředí (kontejner plný linuxových procesů) může být uložen do souboru a díky tomu později opět nastartován. Ale je také možné vytvořit checkpoint běžícího virtuálního prostředí a přesunout jej bez přerušení provozu na jiný systém. Tato funkce, která chce zjevně konkurovat migračním možnostem Xenu, umožňuje za běhu vyrovnávat zátěž systémů.

OpenVZ patch není při svých 2,2MB pro slabé povahy; cena za tyto funkce je na první pohled zřejmá. Většina obsahu patche už tu byla probrána dříve; obsahuje například patche pro virtualizaci PID - každá součást jádra musí vědět, jestli pracuje se "skutečným" nebo "virtuálním" ID procesu. Bylo potřeba změnit i další rozhraní, aby podporovala virtualizační funkce OpenVZ; např. hodně ovladačů zařízení a souborových systémů vyžadovalo úpravy.

Jak by se dalo očekávat, kód checkpointování je z těch delších a komplikovanějších. Proces checkpointování začne pozastavením cílových procesů způsobem ne nepodobným tomu, co dělá kód software suspend. Pak přijde dlouhá řada rutin, které seřadí a vypíší každou datovou strukturu a kousek paměti spojený s virtuálním prostředím. Jsou uloženy ty zřejmé věci: paměť procesů, otevřené soubory atd. Ale kód musí uložit i kompletní stav každého TCP socketu (včetně seznamu struktur sk_buff, které čekají na zpracování), informace o sledování spojení, stav zpracování signálů, informace o SYSV IPC, popisovače souborů získané přes Unix-domain sockety, asynchronní I/O operace, mapování paměti, jmenné prostory souborových systémů, data v tmpfs souborech, nastavení tty, zámky souborů, popisovače souborů epoll() a další.

Pro každý uložený objekt je nutné vytvořit soubor s jadernou datovou strukturou. Všechny ukládací rutiny pak seřadí jednu nebo více datových struktur do správného formátu pro zápis do checkpoint souboru. Vypadá to, že všechno funguje, ale také to vypadá velmi křehce - téměř jakákoliv změna jaderných datových struktur pravděpodobně způsobí, že checkpointovací a obnovovací kód přestane být funkční. I kdyby byl tento kód začleněn do hlavního jádra, bylo by obtížné jej vývojářům vysvětlovat (a přimět je, aby se o něj zajímali). Udržování ve funkčním stavu je náročné, ať už je kód v jádře nebo ne.

Nemělo by to však být interpretováno tak, že funkce OpenVZ za tu námahu nestojí. Virtuální prostředí, checkpointování a migrace za běhu jsou mocné a užitečné funkce. Ale virtualizace všeho v jádře povede k větší komplexnosti a vyšším nárokům na správu. Bude zajímavé sledovat rozhodování o tom, kde bude stanovena hranice určující, které funkce začlenit, a které už ne.

Začíná diskuze o AppArmor

Novell v lednu oznámil vydání bezpečnostního modulu AppArmor. Pak vše ztichlo; především se nesnažili o začlenění AppArmor do hlavního jádra. Minulý týden však přinesl oživení v reakci na diskuzi o možném odstranění LSM API. Předložení kódu AppArmor mělo požadovaný krátkodobý efekt: diskuze se posunula od odstraňování rozhraní LSM k vlastnostem AppArmor. Vývojáři AppArmor však z toho posunu možná právě teď nebudou zrovna nadšeni.

AppArmor byl podle očekávání dosti kritizován. Za největší neduh je považována skutečnost, že AppArmor používá pro svou bezpečnostní politiku cesty k souborům. Při použití AppArmor může systémový administrátor sestavit seznam souborů, ke kterým má daná aplikace přístup; co není na seznamu, je nepřístupné. Konfigurovatelné jsou i další věci - například možnosti - ale kolem toho žádné neshody nejsou.

Hlavní věc je, že název souboru není soubor samotný. Takže i když /etc/shadow značí soubor se stínovými hesly, ten název není soubor se stínovými hesly. Dokáže-li útočník vytvořit pro tento soubor jiný název (třeba pomocí odkazů nebo jmenných prostorů), mohl by ten jiný název být cestou, po které se útočník k souboru s hesly dostane. Takže přestože AppArmor nepovoluje dané aplikaci přístup k /etc/shadow, může mít ta samá aplikace přístup k jiným názvům souborů, které by mohly ukazovat na stejný soubor.

AppArmor se tedy liší od přístupu SELinuxu, který objektům přiřazuje značky a dodržování pravidel pro přístup zajišťuje na základě těchto značek. V případě SELinuxu má soubor se stínovými hesly stejnou značku (a tím pádem stejná omezení přístupu) bez ohledu na název, přes který je k němu přistupováno. SELinux se tedy vyhýbá selhání (obejití pravidel pomocí jiného názvu souboru), které je u AppArmor možné. Každý administrátor SELinuxu však ví, že udržování značek v aktuálním stavu je samo o sobě dost náročné.

Další problém s přístupem, který využívá AppArmor, je to, že LSM API není pro bezpečnostní politiku založenou na názvech souborů příliš vhodné. Kvůli tomu musí AppArmor často překonávat (potenciálně náročné) překážky, aby zjistil odpovídající názvy souborů. Tento nesoulad mezi AppArmor a LSM není obecně považován za důvod, proč ponechat AppArmor mimo jádro, ale vedl k návrhům, že by vývojáři AppArmor měli buď rozšířit LSM tak, aby podporovalo politiky založené na názvech souborů, nebo by prostě měli poslat své patche a LSM úplně vynechat. Přežije-li AppArmor ostatní námitky, bude určitě potřeba se této otázce věnovat.

V tuto chvíli není zdaleka jasné, jak bude dosaženo rozhodnutí o tom, jestli bude AppArmor začleněn. Nezůstalo bez povšimnutí, že nejtvrdší kritika se ozývá z tábora SELinuxu; vývojář SELinuxu Stephen Smalley tuto kritiku obhajoval takto:

Nebojíme se alternativ. Starosti nám dělá nesprávný technický přístup. Argumenty stavěné proti kontrole přístupu založené na názvech souborů jsou o správnosti technického přístupu, ne o tom, jestli by měly existovat alternativy k SELinuxu.

Příznivci AppArmor tvrdí, že přístup je správný. Na rozdíl od SELinuxu se AppArmor nesnaží být jediným bezpečnostním řešením pro všechny situace. Místo toho prostě odřízne aplikace, které by mohly být útočníkem napadeny. AppArmor se stará o omezení toho, co může nefunkční aplikace dělat; nesnaží se o regulaci interakce všech aplikací a každého objektu v systému. Tento přístup je podle jejich tvrzení dostatečný na to, aby výrazně zvýšil bezpečnost systému, ale přitom zachoval administrační rozhraní přístupné obyčejným smrtelníkům. Co se přístupu týče, tak kontrolní mechanismus založený na názvech souborů je prý dostatečně dobrý. Pravděpodobně bude chvíli trvat, než bude jasné, jestli s tímto tvrzením vývojářská komunita souhlasí.

(Viz také tuto podrobnou kritiku kontroly přístupu založené na názvech souborů od Joshua Brindleho).

---

Následující obsah je © KernelTrap

vmsplice() versus COW

21. dub, originál

V rámci vysvětlování nových systémových volání splice() a tee() se Linus Torvalds zmínil o možných budoucích rozšířeních, včetně vmsplice(), které implementoval Jens Axboe. To vedlo ke srovnání se ZERO_COPY_SOCKET na FreeBSD, které používá COW (Copy On Write - kopírovat při zápisu).

Linus vysvětlil, že ačkoliv při určitých výkonnostních testech to může ukazovat dobré výsledky, je s tím ve skutečnosti spojená extra režie: Problém je, že cenou za označení věcí jako COW není jen počáteční zneplatnění tabulky: je tu také cena za chybu, když nakonec začnete na stránku zapisovat, i když už se v tu chvíli rozhodnete, že stránka není sdílená a chyba stránku pouze označí jako zapisovatelnou. A pokračoval: COW přístup může vygenerovat pěkná čísla při výkonnostních testech, protože tahle věc se testuje tak, že na uživatelskou stránku se vůbec nezapisuje. Takže skončíte s pěknou nekonečnou smyčkou, která musí zneplatnění TLB provést jen napoprvé, a pak už nemusí dělat nic. A nebral si servítky, když zakončil:

Tvrdím, že lidi kolem Mach (a zjevně i FreeBSD) jsou nekompetentní idioti. Zahrávání si s VM je špatné. Kopírování paměti je taky špatné, ale upřímně lze říci, že kopírování paměti má často méně mínusů než hrátky s VM. A větší keše to budou jen potvrzovat.

A přestože s ním pak Piet Delaney pokračoval v diskuzi o výhodách a nevýhodách obou přístupů, reagoval později Linus sám na svůj mail:

> Tvrdím, že lidi kolem Mach (a zjevně i FreeBSD) jsou nekompetentní idioti.

A taky tvrdím, že lidi, kteří chodí na Slashdot, většinou páchnou a jedí vlastní nudle z nosu.

A dále tvrdím, že každý, kdo si ještě nevšiml, že jsem umíněný parchant, a že "neslušný" je moje druhé jméno, má pěkně dlouhé vedení.

A nakonec je jasné, že nejenže jsem tu ten nejchytřejší, ale také nejlíp vypadám, a mému nevadnoucímu šarmu se vyrovná jen moje elegantní skromnost.

Takže tak. To jen pro ujasnění.

      Linus "klaňte se přede mnou, verbeži" Torvalds

Komu patří stack?

26. dub, originál

V krátké diskuzi mluvil Linus Torvalds o nedávno přidaném hacku, který má gcc zabránit v přepisování stacku parametrů u funkcí s asmlinkage na platformě x86. Tato oprava využívá prevent_tail_call() k předejití gcc optimalizace koncových volání [tail call]. Linus však poznamenal: Problém nejsou koncová volání, to je jen detail, díky kterému se to projevuje (umím si představit i jiné situace, které by to mohly působit). Koncová volání se říká tomu, že poslední řádek funkce vrací volání jiné funkce. Kompilátory to často optimalizují.

Linus uznal, že současný hack je ošklivý, a naznačil, že správný způsob opravení by spočíval v tom, kdyby tým gcc přidal atribut, který by kódu umožňoval říci gcc, že mu stack parametrů nepatří: Raději bych, kdyby se gcc rovnou od asmlinkage dozvěděl, že mu stack nepatří. Ale žádný takový atribut neexistuje, takže se zase musíme spokojit s makrem prevent_tail_call() (stejný problém jsme měli dříve s sys_waitpid() a sys_wait4()). Potom navrhl čistší hack, který by ten problém řešil obecnějším způsobem - ne pouze pro případ optimalizace koncových volání.

       

Komentáře

[k3]

hezke :)

AppArmor byl podle čekávání -> AppArmor byl podle očekávání

[Leoš Literák]

opraveno

[Dan Ohnesorg]

Videl jsem OpenVZ na prednasce na LinuxTagu a bylo to fakt tuze zajimave. Meli spustenou virtualni masinu, na ni Xvnc a v nem bezel screensaver, takove ty bublajici barevne bubliny. Reklo se tomu migruj a behem cca 5 vterin to naskocilo na jinem nodu (kazdy nod na jednom notebooku). Screensaver bublal od mista kde bublat prestal a tcp spojeni VNC na ten Xvnc server zustalo bez problemu zachovano. Vrele doporucuji k vyzkouseni.

[Mikos]

Paravirtualizace ala Xen je IMHO mnohem lepší řešení než všechny tyhle VServery, OpenVZ, Virtuozza, atp. A pokud se nepletu, měla by být i výrazně výkonnější

[miso]

Ano, niekde na strankach Novell-u je video, kde migruje Xen domena, na ktorej bezi stream video server (V podstate podobny pripad ako ten screensaver, ale myslim, ze Xen je na tom vykonnostne ovela lepsie)

[Honza Houštěk]

Xen poskytuje lepsi izolaci jednotlivych virtualnich systemu a hlavne umoznuje provozovat ruzne systemy. Co se tyka vykonu, rezie behu nad hypervisorem muze byt dost minimalni, co ovsem uz tak minimalni neni je spotreba pameti jednotlivymi virtualnimi stroji. Navic je nutno pamet natvrdo jednotlivym virtualnim strojum pridelit v okamziku jejich startu, takze nepripada v uvahu, aby se o tyto prostredky jednotlive virtualni systemy nejakym zpusobem delily dle potreby. Velke komplikace ma Xen s primym pristupem k hardware nebo s pouzitim vlastnosti jako DMA, coz je u OpenVZ trivialni.

Kdo tvrdi, ze virtualizace na urovni OS nema misto na pod Sluncem a lekem na vsechno je Xen, je ignorant.

[Mikos]

Já netvrdím že virtualizace na úrovni OS nemá místo pod Sluncem, já jen tvrdím, že Xen je celkově výrazně lepší řešení

[Kyosuke]

Jo, skoro tak dobrý, jako hardware s podporou virtualizace, třeba jako mají mainframy.

[Milan Jurik]

LT zase neudrzel svou nevymachanou hubu a nekdo mu decentne soukrome naznacil, ze to opet prepiskl? Uz ani ty jeho opravy nejsou vtipne... :-/

[zde]

,,zahrávání si s VM je špatné'' - huh, 2.6.17-rc4-git3 běží s vypnutým MMU? To jsem musel nějak přehlédnout. Inu každý den se dovídáme spoustu nového

[Jiří (BoodOk) Kadeřávek]

Nektere moralni kvality idealne vyhovuji pozadavkum na vyvoj jadra a mene pozadavkum na diplomacii

[zde]

Já mám raději když se věci říkají naplno. Ovšem v tomto případě Linus podle mne nemá úplně pravdu.

[Jiří (BoodOk) Kadeřávek]

To neni naplno. To je s prehankou, to je vulgarni hyperbola.