Portál AbcLinuxu, 24. prosince 2025 20:50
Aktuální verze jádra: 2.6.21-rc5. Citáty týdne: Andrew Morton, Rusty Russell, Greg Kroah-Hartman. Jaderná rozhraní přizpůsobená pro aplikace. Odložitelné časovače. Správa integrity v jádře.
Aktuální předverze řady 2.6 je (k 28. 3. 2007) 2.6.21-rc5, vydaná 25. března. Obsahuje dost oprav, včetně sady patchů týkajících se regresí způsobených změnami časovače. Linus to komentoval: Ty změny časovače byly nakonec daleko nepříjemnější, než bychom si bývali přáli. Velký dík patří Thomasu Gleixnerovi, který se zasloužil o to, že se seznam regresí neustále zmenšuje. Vizte dlouhý changelog, kde najdete všechny podrobnosti.
Od vydání -rc5 bylo do hlavního git repozitáře začleněno několik desítek dalších oprav.
Aktuální verze -mm stromu je 2.6.21-rc5-mm2. Mezi nedávné změny patří nový lumpy reclaim patch, aktualizovaný "deadline staircase scheduler" (dříve nazývaný RSDL), mnoho vylepšení futexů a patch pro správu integrity (vizte níže).
Aktuální stabilní jádro je 2.6.20.4, vydané 23. března.
Starší jádra: 2.6.16.45 bylo s několika opravami vydané 26. března. 2.4.34.2 bylo vydané 24. března; obsahuje pouze dvě změny. 2.4.35-pre2 má velké množství oprav.
Pokud ten patch neopravuje chybu, tak nemá zdaleka tak vysokou prioritu pro náš vzkvétající rej bugů [bugfest], kterému obvykle říkáme jádro. A proto ho nechci.
Do budoucna doporučuji přidat k podobně triviálnímu patchi vtipnou poznámku - to je jediný způsob, jak zařídit, aby se objevil mezi citáty týdne na LWN.
Při rozhovorech s mnoha různými firmami jsem dospěl k názoru, že bychom opravdu měli něco udělat s těmi, kdo porušují GPLv2 jádra. Často jsem se setkal s následující kritikou: "Naše společnost dodržuje GPL, protože vydáváme zdrojové kódy k našim jaderným modulům. Ale co všechny ty ostatní společnosti, které to nedělají?" Firmy, které jsou dobrými členy komunity, jsou od svých vlastních lidí pod tlakem přestat vydávat kód. Odůvodňováno je to ukazováním na společnosti, které kód nevydávají, a přitom nejsou nijak postihovány.
Funkce "hugetlb" aplikacím umožňuje vytvářet a používat obrovské [huge] stránky v paměti. Tyto stránky používají speciální režim, který jedinému záznamu v tabulce stránek umožňuje poskytovat překlady až pro 16 MB souvislé paměti (na některých architekturách). Výhoda takového přístupu spočívá v tom, že reference na celou tu obrovskou stránku zaberou jen jediné místo [slot] v translation lookaside buffer (TLB), a to může mít příznivý vliv na výkon.
Přístup k velkým stránkám zajišťuje souborový systém hugetlbfs. Je to virtuální souborový systém, podobně jako tmpfs, ale s malou změnou: mapování souborů v rámci systému používá velké stránky. S tímto souborovým systémem není možné provádět normální čtení a zápisy, ale je možné vytvořit soubor, rozšířit ho a použít mmap() k namapování daného souboru do virtuální paměti.
Toto rozhraní umí vše, co je třeba, ale zjevně je pro některé vývojáře aplikací dost komplikované.
Ken Chen navrhl věci zjednodušit zavedením /dev/hugetlb. Takové zařízení by bylo podobné /dev/zero, až na to, že by používalo velké stránky. Aplikace by mohly zařízení jednoduše otevřít a použít mmap() k vytvoření tolika anonymní paměti s velkými stránkami, kolik by potřebovaly. Patch je jednoduchý a patrně nekontroverzní, i když Andrew Morton poznamenal:
Jestli tomu dobře rozumím, tak hlavním důvodem je poskytnout jednoduchý a rychlý způsob pro privátní mapování hugetlb stránek. S důrazem na jednoduchost a rychlost.
To samé můžeme dělat s pomocí hugetlbfs, ale je to (děsná) otrava.
Způsob, jak se té otravy zbavit, je udělat to jednou a pořádně a strčit to do knihovny, kterou bude moci použít každý.
Uznává však, že zařídit širokou distribuci další knihovny by mohlo být obtížné - do té míry, že je možná snazší přidat novou funkci věc do jádra. Shrnul to slovy: Dochází k tomu často, což je dost smutné.
V jiné zprávě mluvil Andrew o tom, jak by měla být jaderná rozhraní obecně navrhována:
Skutečnost, že se jaderné rozhraní "těžko používá", by nás neměla moc trápit, protože to mohou řešit knihovny. Jaderná rozhraní by měla být dobrá, kompletní, udržovatelná atd. Pokud to znamená, že bude nakonec složité je používat, nemusí to být hned chyba. Neřekl bych, že bychom měli ve všech případech optimalizovat kód tak, aby šel snadno používat jen proto, že knihovny jsou složité.
V mnoha případech tuto funkci zastoupí C knihovna, která poskytne jednodušší rozhraní k jaderným voláním, aby je aplikace mohly použít. Ale vývojáři glibc do knihovny nechtějí cpát úplně všechno, takže věci jako přátelštější rozhraní pro velké stránky možná stojí za hranicí jejich zájmu. Správným řešením by mohla být samostatná knihovna pro vývojáře, kteří chtějí s jádrem provádět podivné a pokročilé věci.
Andrew navrhuje vytvoření API knihovny pro uživatelský prostor, která by byla spravována společně s jádrem. Tak by šlo udržovat přehled o API a zajistit správu knihovny i do budoucna, přičemž by se omezilo množství kódu, který jde do jádra jen kvůli zjednodušení rozhraní. Musel by se však najít někdo, kdo takovou knihovnu napíše a bude spravovat; zatím se moc dobrovolníků nehlásí.
Kód, který v nadcházejícím jádře 2.6.21 implementuje dynamický tik, se snaží předcházet probouzení procesoru vypínáním hodin, když se nic neděje. Než se zastaví, je nutné se rozhodnout, kdy se má opět probudit; to závisí na frontě časovače, kde se zjistí, kdy příští časovač vyprší. Pokud se nestane nic jiného (například hardwarové přerušení), bude systém spát až do chvíle, kdy se má spustit další časovač.
Mnohé z těchto časovačů by měly být spuštěny hned ve chvíli, kdy vyprší požadovaná doba. Jiné však nejsou tolik důležité - do té míry, že nestojí za to kvůli nim procesor budit. Tyto "nedůležité" mohou být spuštěny o zlomek vteřiny později (když se procesor vzbudí z jiného důvodu) a nikdo si ničeho nevšimne. Bylo by tedy fajn, kdyby existoval způsob, jak jádru říci, že konkrétní časovač nevyžaduje po vypršení okamžitou akci, a že by se procesor neměl probouzet jen kvůli tomu, aby se o něj postaral.
Venki Pallipadi takový způsob vytvořil: odložitelné časovače [deferrable timers]. Do interního API jádra přibude jediná nová funkce:
void init_timer_deferrable(struct timer_list *timer);
Takto inicializované časovače bude jádro považovat za odložitelné. Při rozhodování o tom, kdy přijde na řadu další přerušení časovače, nebudou brány v potaz. Je-li systém aktivní, spustí se v určený čas. Pokud systém odpočívá, počkají do chvíle, než procesor probudí něco důležitějšího.
Venki se velmi snažil, aby změny vyžadované pro tento patch byly minimální. Takže struktura timer_list se vůbec nemění. Místo toho je jako příznak "odložitelnosti" využit nízkořádový [low-order] bit na interním ukazateli (o kterém se ví, že je vždy nula). Výsledkem je, že struktura timer_list se nezvětší, aby novou funkci podporovala, což je vykoupeno tím, že všechen kód, který používá interní ukazatel base, musí bit "odložitelnosti" potlačit [mask out].
Patch se v současné verzi týká pouze časovačů v jádře; i když žádný kód zatím nebyl upraven tak, aby odložitelnost používal. Mohlo by být užitečné takové rozhraní rozšířit i do uživatelského prostoru. Máme spousty aplikací, které se čas od času potřebují probudit, aby zjistily, co se děje. Pro systémy s omezenými zdroji napájení jsou takové aplikace nepříjemné. Pokud by je nešlo opravit, aspoň by mohly projevit ochotu počkat, když se nic důležitého neděje.
Některé patche se v konferencích vývojářů jádra objevují (s přestávkami) i několik let. Taková je i sada patchů se správou integrity od IBM. Na LWN se o ní naposledy mluvilo v listopadu 2005. A teď se objevily znovu. Pořád to vypadá, že patche nejsou připraveny k začlenění do hlavního jádra, ale už se to blíží.
Hlavní myšlenkou správy integrity je poskytnutí nějaké záruky, že se v souborech na systému nikdo nehrabal. David Safford to popisuje takto:
Tento "poskytovatel" integrity je v podstatě navržen jako doplňující služba k systémům povinné kontroly přístupu [mandatory access control systems] jako SELinux nebo Slim. Tyto systémy mohou chránit před online, ale ne před offline útoky (nabootování Knoppixu a změnění spustitelných souborů nebo jejich selinuxových značek), případně útoky, které zneužívají slabiny jádra nebo samotného LSM.
Aktuální patche fungují na nejnižší úrovni tak, že definují novou sadu háčků [hooks] bezpečnostního modulu pro "poskytovatele integrity". Poskytovatel se může napojit na systémová volání, která k souborům přistupují nebo je spouštějí, a kontrolovat integritu těchto souborů; pokud usoudí, že se stalo Něco Špatného, může být přístup k daným souborům odmítnut. Nad tím je ještě kód EVM (extended verification module = rozšířený ověřovací modul), který integritu souborů (a jejich metadat) kontroluje pomocí kontrolních součtů porovnáním s hodnotou uloženou jako rozšířený atribut. Modul IBAC (integrity-based access control = kontrola přístupu založená na integritě) pak může použít EVM a LSM háčky, aby umožnil nebo zamezil přístupu k souborům podle toho, jakého výsledku se dobrala kontrola integrity.
To vše může fungovat s passphrase [heslová fráze], kterou dodá administrátor systému, ale zamýšlený režim provozu používá TPM (trusted platform module = modul důvěryhodné platformy), který je zabudovaný do stále většího množství počítačů. TPM také provádí základní šifrovací funkce jako podepisování kontrolních součtů používaných k ověřování integrity souborů. Klíčovým aspektem systému je však to, že TPM může být nakonfigurován tak, aby tyto podpisy vytvořil, pouze pokud kontrolní součty běžícího systému odpovídají přednastaveným hodnotám. Výsledkem je, že kontrolní součty připojené k souborům nemohou být změněny na jiném systému nebo při nabootování jiného jádra - přinejmenším ne tak, aby si zachovaly hodnotu kontrolního součtu. Pokud to bude fungovat tak, jak se očekává, může se zabránit útokům založeným na změně souborů, které systém používá.
Kromě toho je podporováno vzdálené potvrzení: mechanismus poskytne kontrolní součet podepsaný TPM, který potvrzuje, že na systému běží pouze schválený software.
Má to jasné výhody. Například linuxový volební přístroj nebo bankomat by mohly zaručit, že nikdo nenaruší jejich bezpečnost, a prokázat svou integritu v rámci sítě. Administrátoři, kteří se starají o webové servery, mohou kód ověřující integritu použít podobným způsobem. Obecně lze říci, že správa integrity může být dobrým pomocníkem pro ty, kdo si chtějí být jisti, že systémy, které spravují, nebyly za jejich zády překonfigurovány na spam servery.
Druhou stranou mince je skutečnost, že správa integrity může být mocným nástrojem pro ty, kdo by chtěli ovládat systémy, které jim nepatří. Pokud budou patche začleněny, bude jádro obsahovat nástroje potřebné k vytvoření uzamčeného systému. Jak se tyto moduly blíží k zařazení do hlavního jádra, objevují se lidé, kteří z nich nejsou nadšeni. Dost vývojářů by se mohlo postavit licenčním podmínkám určeným k zabránění "tivoizace", i když to neznamená, že by takové využití jádra aktivně podporovali. Bylo by těžší argumentovat proti prodeji uzavřených linuxových přístrojů, když by samotné jádro nabízelo k takovému využití nástroje.
Prozatím není nutné se tomuto tématu věnovat, protože je s kódem pořád dost obyčejných problémů. Ale dříve nebo později se vývojářům správy identity podaří nízkoúrovňové potíže vyřešit; nedá se jim upřít vytrvalost. Podle dřívějších výroků to nevypadá, že by se Linus bránil začlenění modulů, až budou připravené. Jestli bude tak vstřícný i zbytek komunity, to se uvidí.
...než procesor produbí...Aneb jádro sazečem stromů
19.4.2007 01:29
Prcek | skóre: 43
| Jindřichův Hradec / Brno
www.kernel.org.
Pokud vám jde o ty, kdo budou článek číst o měsíc později, budete se do této diskuse pravidelně vracet a doplňovat informace, kdykoli vyjde nová verze jádra?Tohle byl poslední díl JN?
Údaj v článku, byť starší, bude mít ale vypovídací hodnotu v tom, že se jedná o údaj odpovídající době, ke které se vztahuje text tohoto dílu Jaderných novin. Měsíc starý údaj v komentářích bude naprosto k ničemu.To je vcelku nesmysl... Oba údaje budou mít naprosto stejnou vypovídací hodnotu - oba říkají, jaká byla aktuální verze jádra v určité době. Nevidím důvod, proč by údaj z doby psaní článku měl být více nebo méně užitečný, než údaj z doby vydání článku.
Pouhé uvedení verze mi ale připadá bezpředmětné,...No vidíš, mě se to hodilo... čekám na 2.6.21 a ušetřil jsem si kouknutí na kernel.org
19.4.2007 18:34
Prcek | skóre: 43
| Jindřichův Hradec / Brno
Díky za upozornění, všechno je snad opraveno.
19.4.2007 11:18
Marek Bernát | skóre: 17
| blog: Arcadia
ze zadnou jiz overenou cast neni mozne napadnout.Pokud je dobre udelana separace opravneni procesu, pripadne je udelana blbe ale je mozno spoustet jen podepsany kod, tak je opravdu napadeni mozne zabranit.
20.4.2007 19:38
Bluebear | skóre: 30
| blog: Bluebearův samožerblog
| Praha
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.