Portál AbcLinuxu, 25. dubna 2024 09:39
Aktuální verze jádra: 2.6.33. Citáty týdne: Zachary Amsden, Linus Torvalds. Otevírání podle manipulátoru. Rezervované síťové porty. Novinky u kontrolních bodů/restartu. Kontrolní body. Restart. Bezpečnost. Jak si věci stojí.
Aktuální verze jádra: 2.6.33. Citáty týdne: Zachary Amsden, Linus Torvalds. Otevírání podle manipulátoru. Rezervované síťové porty. Novinky u kontrolních bodů/restartu. Kontrolní body. Restart. Bezpečnost. Jak si věci stojí.Jádro 2.6.33 je venku, vydáno bylo 24. února. Linus říká:
Mezi další zajímavé věci v 2.6.33 patří dynamické sledování, řadič blokového I/O a mechanismus komprimované cache.
Více informací o této verzi najdete na stránce o 2.6.33 na KernelNewbies.
Současné stabilní jádro je 2.6.32.9 vydané 23. února. V této aktualizaci je 93 oprav, mnoho z nich je spojeno s bezpečností. Detailní popis této verze vizte v článku na LWN.net.
Jonathan Corbet, 23. února
Většina uživatelů Linuxu nikdy s manipulátory [handle] nepracuje přímo; většina z nich dokonce možná ani neví, že existují. Z toho zbytku budou zkušenosti většiny lidí omezeny na veselé zprávy „stale file handle“, které uživatelé NFS většinou vidí v tu nejnevhodnější dobu. Manipulátor je ve skutečnosti jenom prostředek, kterým lze identifikovat soubor v souborovém systému. V NFS se manipulátory používají například k tomu, aby reprezentovaly otevřený soubor, takže server může být téměř zcela bezestavový. Aplikace v uživatelském prostoru manipulátory normálně nepoužívají, ani jim nejsou dostupné.
Aneesh Kumar se pokouší tuto situaci změnit krátkou sérií patchů, které přidávají dvě nová systémová volání:
int name_to_handle(const char *name, struct file_handle *handle); int open_by_handle(struct file_handle *handle, int flags);
První přebere name (jméno) a podle něj vyhledá odpovídající manipulátor souboru, který je vrácen ve struktuře handle. Tu je poté možné předat open_by_handle() a získat otevřený popisovač souboru. open_by_handle() může zavolat jenom privilegovaný uživatel, jinak by s její pomocí mohl škodící lokální uživatel obejít kontroly oprávnění přístupu k adresářům nadřazeným danému souboru.
Proč by vývojář aplikací chtěl otevírat soubor ve dvou krocích místo prostého volání open()? Týká se to možnosti napsat servery pro souborový systém, které běží v uživatelském prostoru. Takový server by mohl použít name_to_handle() a vygenerovat manipulátory souborů na souborovém systému, se kterým pracuje; manipulátory je poté možné předat klientům souborového systému. Klient poté může předat manipulátor zpátky a soubor otevřít. Vlastnost podobného typu se také používá u souborového systému XFS pro zálohování a obnovování dat a u systému pro hierarchickou správu úložišť.
O těchto systémových voláních se zatím diskutovalo jen minimálně. Podle všeho se zdá, že bude potřeba trochu zapracovat na lepším popisu toho, co je manipulátor souboru, a konkrétně jaká je jeho očekávaná životnost. Dokud to nebude jasné, bude jenom obtížné napsat aplikace, které používají manipulátory správně.
Jonathan Corbet, 24. února
U síťových aplikací není neobvyklé, že se potřebují navázat na specifický port. Takové požadavky většinou vycházejí z konfigurace firewallu, který umožňuje příchozí spojení jenom na konkrétní port, ale důvodů může být více. Při spuštění takové aplikace může být nepříjemné zjistit, že někdo jiný má dlouhodobě otevřené ssh spojení, které náhodou použilo požadovaný port. Bylo by hezké se takovému konfliktu vyhnout, pokud je to možné.
Tato sada patchů, jejichž autorem je Octavian Purdila, se to snaží zajistit. Přidává novou konfigurační položku pro sysctl (nazvanou ip_local_reserved_ports do /proc/sys/net/ipv4. Pokud správce systému zapíše do tohoto souboru čárkami oddělený seznam portů (nebo rozsahů portů oddělených pomlčkou), síťová vrstva se jim při vybírání portu pro nový socket bude vyhýbat. Rezervace portů tímto způsobem přitom nebude bránit žádné aplikaci vybrat si daný port explicitně.
Tento patch prošel překvapivým počtem revizí; je docela možné, že se objeví v hlavní řadě poté, co se otevře začleňovací okno 2.6.34.
Jonathan Corbet, 24. února 2010
Je to přesně rok, co se Jaderné noviny naposledy dívaly na sadu patchů kontrolních bodů/restartu. Kód byl právě znovu zaslán s požadavkem na začlenění do stromu -mm, což se zdá být dobrá příležitost podívat se na něj znovu. Během uplynulého roku došlo v této oblasti k velkému pokroku, ale kontrolní body/restart jsou stále složitý úkol a pravděpodobně je nikdy nebude možné implementovat úplně.
Vytvoření kontrolního bodu [checkpointing] znamená uložení stavu skupiny procesů do souboru s úmyslem tyto procesy někdy v budoucnu restartovat. Již mnoho let se kontrolní body používají k uložení stavu dlouhodobě běžících výpočtů, aby se neztratily výsledky, pokud systém spadne. V nedávné době se staly žádanou součástí sady nástrojů pro virtualizaci, protože by umožnily živou migraci procesů mezi fyzickými hostiteli. Vývojáři kontrolních bodů/restartu v nich spatřují i další potenciální výhody, jako je možnost na vyžádání rychle spustit sadu procesů z obrazu kontrolního bodu.
Tato sada patchů se zabývá kontrolními body/restartem v kontextu kontejnerů. V případě plné virtualizace je vytvoření kontrolního bodu poměrně jednoduché; systému stačí uložit celý obraz paměti spojené s virtuálním strojem a pár s tím spojených dat. „Kontejnerový“ model virtualizace bývá zmatenější téměř ve všech ohledech a kontrolní body nejsou žádnou výjimkou. Neexistuje žádný obraz paměti, který by šlo uložit jako jeden kus; místo toho musí jádro vysledovat všechny stavové informace spojené s procesem, jehož kontrolní bod je vytvářen, a uložit je nezávisle. Když to funguje, může to být rychlejší a efektivnější než vytvoření kontrolního bodu kompletního virtuálního stroje; obraz je mnohem menší. Ale dospět do stavu, kdy to bude fungovat, je mnohem větší výzva. Složitost tohoto úkolu lze vidět ze současného stromu kontrolních bodů/restartu, což je, ačkoliv má daleko ke kompletnímu řešení problému, diff o 27 000 řádcích oproti 2.6.33-rc8.
K vytvoření kontrolního bodu skupiny procesů se používá následující nové systémové volání:
int checkpoint(pid_t pid, int fd, unsigned long flags, int logfd);
Parametr pid identifikuje proces na nejvyšší úrovni, jehož kontrolní bod má být vytvořen; do výsledného obrazu kontrolního bodu se uloží také všichni jeho potomci; obraz je zapsán do souboru fd. Hodnota příznaku v současnosti může obsahovat pouze CHECKPOINT_SUBTREE, což vypne požadavek na to, aby byl vytvořen kontrolní bod celého kontejneru jako celku. Vytvoření kontrolního bodu podstromu je riskantnější než vytvoření kontrolního bodu celého kontejneru, protože je obtížnější zajistit, aby byly uloženy všechny potřebné zdroje. Parametr logfd je popisovač souboru otevřený pro zápis; jádro do něj zaznamená relevantní informace. Existuje totiž mnoho možností, jak může vytvoření kontrolního bodu selhat; logující soubor má uživatelům pomoci zjistit, co se děje, když kontrolní bod odmítne fungovat. Pokud logování není zapotřebí, logfd může být -1.
Sada procesů, jejichž kontrolní bod má být vytvořen, by před voláním checkpoint() měla být zmrazena. Jednou výjimkou z tohoto pravidla je proces, který volá checkpoint(); tato výjimka umožňuje procesům vytvořit kontrolní bod sebe sama.
Interně je proces vytvoření kontrolního bodu implementován ve dvou fázích:
Jádro projde strom procesů a „sesbírá“ všechny objekty, které budou součástí výsledného obrazu. „Sesbírání“ v podstatě znamená vytvoření hash tabulky se záznamem pro každý proces, každý otevřený soubor, každou oblast virtuální paměti, každý otevřený socket atd. Prohledání stromu tímto způsobem pomáhá jádru zastavit vytváření kontrolního bodu velmi brzy, pokud se narazí na něco, co jeho vytvoření brání. Neméně důležité je, že tento proces také systému umožňuje sledovat objekty, které mají několik odkazů, a zajistit, že budou do obrazu zapsány jen jednou.
Ve druhé fázi se projdou všechny sesbírané objekty, každý je serializován a zapsán do obrazu.
Tím je kontrolní bod vytvořen. Procesy, jejichž kontrolní bod byl právě vytvořen, poté mohou běžet dál, nebo být zabity, záleží na důvodu, proč byl kontrolní bod vytvářen.
Tyto dvě fáze se odrážejí ve změnách, které byly provedeny na nižších úrovních systému. Například struktura file_operations, která nikdy nebyla zrovna štíhlá, získává dvě nové operace.
int collect(struct ckpt_ctx *ctx, struct file *filp); int checkpoint(struct ckpt_ctx *ctx, struct file *filp);
Operace collect() by měla identifikovat všechny objekty, které je potřeba uložit, a každý předat ke sledování ckpt_obj_collect() (nebo některému z několika rozhraní na vyšší úrovni.) Později je voláno checkpoint(), čímž se zažádá, aby byl daný filp serializován pro uložení do obrazu kontrolního bodu. Podobné metody byly přidány do mnoha dalších typ struktur včetně vm_operations_struct a proto_ops.
Proces serializace vyžaduje zkopírování dat z jaderných datových struktur do série speciálních struktur, které mají být zapsány do obrazu. Například popisovač souboru si najde svou cestu z struct fdtable někam sem:
struct ckpt_hdr_file_desc {
struct ckpt_hdr h;
__s32 fd_objref;
__s32 fd_descriptor;
__u32 fd_close_on_exec;
} __attribute__((aligned(8)));
Vytvoření této kopie vyžaduje funkci o 75 řádcích, která sesbírá potřebné informace a velmi pečlivě zkontroluje, jestli lze bezpečně vytvořit kontrolní bod. V tomto případě vytváření selže, pokud je přítomen zámek u souboru nebo u vlastníka (který je upozorňován pomocí SIGIO). Pokud se žádné překážky neobjeví, dokončená struktura je předána kódu kontrolních bodů, který ji uloží do obrazu.
Proces serializace je jedna z děsivějších částí celého konceptu kontrolních bodů/restartu. Jakékoliv změny struct fdtable téměř určitě tuto serializaci rozbijí, dost pravděpodobně takovým způsobem, na který se nepřijde, dokud nějaký uživatel nenarazí na problém. I kdyby se vývojář VFS staral o vytváření kontrolních bodů, nemusí pomyslet na to, aby se podíval na kód v checkpoint/files.c a zjistil, jestli tam není potřeba něco změnit. Podobné závislosti jsou vytvořeny pro každou jadernou datovou strukturu, jejíž kontrolní bod je potřeba vytvořit. Celé to vypadá poměrně křehce; udržet to v chodu bude téměř určitě vyžadovat trvalou údržbu.
Na straně restartu se od aplikace provádějící restart očekává, že vytvoří sadu procesů, které budou rozhýbány pomocí informací z kontrolního bodu. Vytvoření zajistí tolikrát revidované systémové volání „rozšířené close()“, které v současné iteraci vypadá takto:
int eclone(u32 flags_low, struct clone_args *cargs, int cargs_size,
pid_t *pids);
S eclone() lze vytvářet procesy se specifickými pids a rozšířenou sadou příznaků.
Jakmile existuje hierarchie procesů, lze použít systémové volání restart():
int restart(pid_t pid, int fd, unsigned long flags, int logfd);
Obraz kontrolního bodu nalezený na fd bude obnoven do hierarchie procesů počínaje pid. logfd lze opět použít k získání informací o tom, jak celý proces proběhl. Definováno je několik příznaků flags:
Při úspěšném návratu z restart() by měla být hierarchie procesů připravena k běhu.
Restart také vyžaduje podporu na nižších úrovních jádra. Dlouhodobě trpící struktura file_operations získává další funkci:
int restore(struct ckpt_ctx *, struct ckpt_hdr_file *);
Tato funkce (společně se všemi analogiemi jinde v jádře) je pověřena oživením daného objektu ze souboru obsahujícího kontrolní bod.
Není těžké si představit, že tato nová systémová volání mohou mít mnoho důsledků ovlivňujících bezpečnost, takže je poněkud překvapivé, že v současné implementaci jsou checkpoint() i restart() neprivilegované operace. To je úmyslné, má to vývojáře nutit od začátku myslet na bezpečnost.
Největší potenciální problém je u checkpoint() pravděpodobně vyzrazení informací. Aby se tento problém obešel, checkpoint() může vytvořit kontrolní bod jenom u takového procesu, na který volající může zavolat ptrace(). Zde by se tedy neměl objevit způsob, jak by nepřátelský uživatel mohl získat informace, ke kterým by neměl přístup jiným způsobem.
Restart je poněkud děsivější; umožňuje volajícímu nahrát do jaderných struktur potenciálně libovolná data. Riziko je, doufejme, sníženo tím, že všechny operace probíhají v kontextu volajícího procesu – pokud volající nemůže přímo otevřít soubor, nemůže ho otevřít ani pomocí zmanipulovaného obrazu kontrolního bodu. Tento způsob znemožní některé způsoby použití, jako je například vytvoření kontrolního bodu procesu, který běžel se setuid, ale pak svá práva zahodil; toto ale pravděpodobně není možné bezpečně rozběhat pro neprivilegované uživatele.
Aby to měli ještě náročnější, vývojáři kontrolního bodu/restartu také implementovali vytvoření kontrolního bodu bezpečnostních značek [security label] objektů. Ve výchozím nastavení tyto značky nebudou při restartu použity, ale příznak RESTART_KEEP_LSM to může změnit. Značky jsou opět vytvářeny v kontextu volajícího procesu, takže aktivní bezpečnostní modul by měl zabránit vytvoření značek, které porušují bezpečnost systému.
I s těmito opatřeními se jeden musí ptát na bezpečnost tohoto procesu jako celku. Jádro vyplňuje širokou oblast datových struktur ze vstupu, který může být pod kontrolou nepřátelského uživatele; není tak těžké si představit, že někde mezi desítkami tisíc řádků kódu kontrolních bodů/restartu chybí nějaká důležitá kontrola. Možná v reakci na tyto obavy přidává sada patchů pomocí sysctl možnost zabránit neprivilegovaným uživatelům tyto operace volat.
Podle nejnovější verze patche:
Sada patchů tedy vypadá dostatečně funkční k tomu, aby byla nějak užitečná. Mnoho věcí nicméně stále může zabránit úspěšnému vytvoření kontrolního bodu; jsou shrnuty na této stránce. Problémové oblasti zahrnují privátní připojení souborových systémů, síťové sockety v některých stavech, otevřené, ale smazané [unlinked] soubory, používání kteréhokoliv z rozhraní pro upozorňování na události týkající se souborů, otevřené soubory na síti nebo na souborových systémech FUSE, používání netlink, ptrace(), asynchronního I/O a další. Na některé z těchto problémů existují patche; ostatní vypadají problematicky.
V době psaní tohoto článku vývojáři nereagovali na požadavek na začlenění do stromu -mm. V minulosti panovaly obavy o to, kolik práce bude potřeba k tomu, aby byla tato funkcionalita dokončena. Během uplynulého roku byla odvedena spousta práce, ale kontrolní body/restart vypadají jako něco, co nebude nikdy dokončeno úplně. Z větší části je zde nyní otázka, jestli to, co je již hotovo, vypadá dostatečně dobře, aby se to dalo použít pro nějakou skutečnou práci, a jestli stojí za to platit cenu na údržbu tohoto kódu.
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.