Jaderné noviny - 21. 11. 2006

18. 12. 2006 | Robert Krátký | Jaderné noviny | 3851×

Aktuální verze jádra: 2.6.19-rc6. Citáty týdne: Greg Kroah-Hartman, Linus Torvalds. Shrnutí API změn v 2.6.19. Správa klíčů v jádře.

Aktuální verze jádra: 2.6.19-rc6

Aktuální předverze je 2.6.19-rc6, vydaná 15. listopadu. Obsahuje slušnou řádku oprav, ale doufejme, že většina problémů už byla vyřešena (i když poslední verze seznamu regresí v 2.6.19 (21. listopadu) pořád čítá devět položek). Podrobnosti v dlouhém changelogu.

Od vydání -rc6 bylo do hlavního git repozitáře zařazeno téměř 90 oprav. Zatím se nikdo nevyjádřil k tomu, jestli je to dost na vydání -rc7.

Během posledního týdne nevyšla žádná -mm verze.

Aktuální stabilní 2.6 jádro je 2.6.18.3, vydané 18. listopadu. Také obsahuje dost oprav, z nichž alespoň jedna řeší bezpečnostní problém.

Adrian Bunk vydal 2.6.16.32 a k dispozici je i 2.6.16.33-rc1.

Willy Tarreau vydal 2.4.33.4 se dvěma bezpečnostními patchi a množstvím dalších oprav. 2.4.34-pre6 už je také venku. Přidává jen několik patchů.

Citáty týdne: Greg Kroah-Hartman, Linus Torvalds

Nevím o tom, že by se o ovladačovém modelu mluvilo jako o "kompletním vzoru designu". Říkaly se o něm však hodně ošklivé věci.

-- Greg Kroah-Hartman

Nenachytejte se na "efekt druhého systému". Klasický důvod pro pokažení druhého systému je zaměření na věci, kvůli kterým si lidi stěžují, místo na ty, které fungují dobře (protože to, co funguje správně, není tolik na očích).

-- Linus Torvalds

Shrnutí API změn v 2.6.19

Jaderný cyklus verze 2.6.19 přinesl obvyklou várku změn, které pocítí vývojáři jádra. Následuje shrnutí nejvýraznější úprav API v 2.6.19.

• Prototyp funkcí zpracovávače přerušení doznal změn. Ve zkratce: byl odstraněn parametr regs, protože ho skoro nikdo nepoužíval. Pokud některý ze zpracovávačů přerušení potřebuje stav registru před přerušením, může k jeho získání použít get_irq_regs().
• Byl začleněn patch s infrastrukturou pro sledování latence.
• Metody readv() a writev() ve struktuře file_operations byly nahrazeny pomocí aio_readv() a aio_writev() (jejichž prototypy byly změněny). Vizte článek Změny API: zpracovávače přerušení a vektorované I/O.
• Byla přidána operace s adresním prostororem no_pfn().
• Bylo začleněno SRCU - verze read-copy-update, která umožňuje blokování na straně čtení. Podrobnosti v článku od Paula McKenney.
• Hodnota CHECKSUM_HW byla síťovým subsystémem dlouho využívána pro podporu hardwarového kontrolního součtu. Teď byla nahrazena hodnotou CHECKSUM_PARTIAL (určenou pro odchozí pakety, u kterých musí být práce hardwarem dokončena) a CHECKSUM_COMPLETE (pro příchozí pakety, které byly hardwarem kompletně zkontrolovány).
• Bylo začleněno množství změn ve správě paměti, včetně sledování nečistých stránek v mapováních sdílené paměti, volitelnosti zón DMA32 HIGHMEM a na architektuře nezávislého mechanismu pro sledování rozsahů paměti (a mezer mezi nimi).
• Makra pud_page() a pgd_page() teď vracejí ukazatel struct page místo virtuální jaderné adresy. Pokud by to nějaký kód potřeboval, může použít pud_page_vaddr() nebo pgd_page_vaddr().
• Množství změn v ovladačovém jádru, včetně experimentálního paralelního vyhledávání zařízení a několika vylepšení procesu uspávání/probouzení.
• Nový oznamovací řetězec pro situace, kdy je nedostatek paměti; záměrem je připravit funkce, které by mohly nějakou paměť uvolnit, když začne být příliš těsno.
• Sémantika API kmap() se trochu změnila: na architekturách s komplikovanými problémy souvislosti paměti se od kmap() a kunmap() očekává správa souvislosti mapovaných stránek, což odstraňuje nutnost explicitního výmazu stránek z keše.
• PCI vrstva teď podporuje PCI Express Advanced Error Reporting [pokročilé hlášení chyb].
• Ve snaze zmenšit strukturu inode bylo provedeno množství změn.
• Výrazně lepší podpora uspávání a probouzení v USB vrstvě.
• Byla přidána nová sada funkcí umožňující USB ovladačům rychle ověřit směr a režim přenosu koncového bodu.
• Poněkud ořezaná verze Wireless Extensions 21. Většina funkcí byla odstraněna, protože se předpokládá, že budou bezdrátová rozšíření nahrazena něčím jiným.
• Velké množství anotací umožňujících utilitě sparse detekovat big/little endian chyby.
• Pole flags v struct request bylo rozděleno na dvě nová pole: cmd_type a cmd_flags. První obsahuje hodnotu popisující typ požadavku (požadavek souborového systému, správa napájení atd.), zatímco druhé má příznaky, které upravují způsob funkce příkazu (čtení/zápis, bariéry atd.).
• Bloková vrstva může zcela vypnuta při konfiguraci jádra; může být užitečné pro některá embedded zařízení.
• Jádro teď má obecný boolean typ nazývaný bool; nahrazuje množství podomácku spíchnutých boolean typů, které se nacházejí v různých částech jádra.

• Nová funkce pro alokaci kopie bloku paměti:

      void *kmemdup(const void *src, size_t len, gfp_t gfp);
  

  Množství sekvencí alokuj-pak-kopíruj bylo aktualizováno, aby používaly právě kmemdup().

Správa klíčů v jádře

Souborové systémy, především pak vzdálené souborové systémy, mohou pro umožnění přístupu vyžadovat nějakou autentizaci nebo klíč; jaderné rozhraní pro správu klíčů poskytuje háčky [hooks] pro ukládání a správu tohoto druhu informací. Háčky jsou dvojího druhu: jeden využívá jádro k nalezení klíčů pro subsystémy, které je vyžadují, druhý využívají uživatelské programy pro správu klíčů. Účelem je poskytnout rychlý mechanismus, aby mohlo jádro přistupovat ke klíčům, které potřebuje, zatímco operace přidávání, úpravy a mazání jsou odsunuty do uživatelského prostoru.

Používá se termín 'klíč', ale nemusí se jednat o klíče v tradičním, šifrovacím smyslu. Jako klíč může být uložen jakýkoliv druh autentizační nebo přístupové informace; v podstatě se jedná o nečitelný kus dat, který je interpretován jaderným subsystémem, jehož se týká. Ačkoliv je API zaměřeno na souborové systémy, může ho využívat kterýkoliv jaderný subsystém, který vyžaduje tento typ informací.

Klíče jsou uloženy v příznačně pojmenované struct key, která má následující pole:

• jedinečné sériové číslo
• druh klíče, který může identifikovat souborový systém, ke kterému klíč náleží
• popisný řetězec, který se používá pro vyhledávání klíčů
• vlastní data klíče
• informace o uživateli a skupině, včetně práv
• doba platnosti
• stav klíče, který sleduje ustavení, zrušení, smazání atd.

Typy klíčů umožňují souborovým systémům konfigurovat svou vlastní sadu operací s klíči. Typ klíče může určit následující operace:

• instantiate - vytvořit klíč daného typu
• update - upravit klíče
• match - přiřadit klíč k popisu, který se používá při vyhledávání
• revoke - odstranit některá data klíče a změnit stav na KEY_FLAG_REVOKED
• destroy - odstranit všechna data klíče
• describe - popis klíče
• read - načíst data klíče
• request_key - voláno, není-li klíč k dispozici, aby byl klíč stažen odjinud

Jsou definovány dva standardní typy klíčů: key_type_user a key_type_keyring. Nové typy klíčů lze u souborových systémů registrovat pomocí:

    int register_key_type(struct key_type *type);

Když jádro potřebuje najít klíč, zavolá:

    struct key *request_key(const struct key_type *type,
                            const char *description,
                            const char *callout_string);

Předá type a description a funkce match z struct key_type je použita k nalezení odpovídajícího klíče. Není-li nalezen žádný a callout_string není NULL, spustí jádro /sbin/request-key, který se pokusí potřebný klíč získat z uživatelského prostředí.

K poli payload lze přistupovat po nalezení klíče, ale je-li komplexnější než obyčejné celé číslo, musí být postaráno o zabránění současnému čtení a zápisům. Ve struktuře klíčů je podpora semaforového zamykání a RCU; ty je potřeba vždy použít - kromě situace, kdy klíč nemá žádné metody pro úpravu. Jakmile souborový systém s klíčem skončí, měl by být uvolněn pomocí:

    void key_put(struct key *key);

Kroužky klíčů [keyrings] jsou, jak název napovídá, skupiny souvisejících klíčů a pro manipulaci s nimi jsou připravena různá volání. Každý proces je přiřazen ke třem specifickým kroužkům klíčů: kroužek specifický pro vlákno, kroužek specifický pro proces a kroužek specifický pro sezení. To jsou kroužky prohledávané při spuštění request_key.

Práva klíčů jsou uložena v bitovém poli, podobně jako práva linuxového souboru, ale daleko podrobněji. Každý klíč má id uživatele a skupiny a masku práv pro každého ze čtyř potenciálních zájemců: vlastník, uživatel, skupina a ostatní. Maska se skládá ze šesti bitů:

• view - umožňuje prohlédnutí atributů klíče nebo kroužku
• read - umožňuje prohlédnutí obsahu klíče nebo seznamu klíčů na kroužku
• write - umožňuje vytvoření nebo úpravu obsahu klíče nebo seznamu klíčů na kroužku
• search - umožňuje nalezení klíčů a prohledávání kroužků
• link - umožňuje nalinkování klíče nebo kroužku na jiný kroužek
• set attribute - umožňuje změnu uživatelského nebo skupinového id a masky práv klíče

Uživatelské API sestává ze tří hlavních systémových volání:

    key_serial_t add_key(const char *type, const char *desc,
                         const void *payload, size_t plen,
                         key_serial_t keyring);

    key_serial_t request_key(const char *type, const char *description,
                             const char *callout_info,
                             key_serial_t dest_keyring);

    key_serial_t keyctl(int cmd, key_serial_t id, int create);

add_key() přidává klíč na určený kroužek. request_key(), podobně jako jeho jaderný protějšek, vyhledává klíč na základě typu a popisu, případně volá uživatelský prostor, není-li callout_info NULL. Také může klíč připojit k určenému kroužku, je-li nalezen. keyctl() je rozhraní podobné ioctl, které zajišťuje správu klíčů. <linux/keyctl.h> obsahuje 17 samostatných příkazů pro aktualizaci, změnu práv, vyhledávání, linkování, čtení a podobně.

Utilita /bin/keyctl, která je součástí balíku keyutils, nabízí jednoduché rozhraní pro uživatelská systémová volání pro zajištění práce s klíči z uživatelského prostoru. Záznamy /proc/keys a /proc/key-users v procfs umožňují uživateli prohlížet klíče a uživatele klíčů, které jádro právě spravuje.

Jediný souborový systém v aktuálním jádře 2.6, který API pro správu klíčů využívá, je eCryptfs. Místo vytváření vlastního typu používá uživatelský typ klíče a přímo nepodporuje zpětná volání do uživatelského prostoru. Místo toho používá příkaz mount.ecryptfs, který se uživatele zeptá na heslo, jež je pak uloženo jako klíč.

Podle prezentace Davea Howellse na 2006 Ottawa Linux Symposium (zde) plánuje do budoucna využití API několik dalších souborových systémů (např. CIFS, NFSv4 a AFS). Více informací a podrobná dokumentace v Documentation/keys.txt a Documentation/keys-request-key.txt.

Celkově to vypadá jako užitečné rozhraní pro jaderné subsystémy, které potřebují klíče. V souladu s tradicí je většina částí týkajících se nastavení a správy odsunuta do uživatelského prostoru. Nabízí všechny možnosti, které by od toho člověk očekával a můžeme jen doufat, že ho v budoucnu začne využívat více subsystémů.

       

Komentáře

[Jan Kundrát (jkt)]

"Zatím se nikdo nevyjádřil k tomu, jestli je to dost na vydání -rc7."

[trekker.dk]

Vizte článek .

V značce <a href="..."></a> je URL, ale chybí text.

[Robert Krátký]

Dík, opraveno.

[CIJOML]

Keyrings - krouzky klicu boha!!! Ten clovek snad nikdy nechodil na nejakou IT skolu, aby vedel ze se to cesky nazyva klicove prstence :DDD

[Aleš Kapica]

Co se pohoršuješ? Překladatel použil polopatické přirovnání. Výraz "klíčový prstenec" mi v tomto významu přijde rozhodně méně srozumitelný, i když osobně bych asi zvolil úplně jiný překlad.

[Filip Jirsák]

Nad klíčovými prstenci bych tedy asi dumal, co to jako má být.

[Hynek (Pichi) Vychodil]

Já teda nevím jak ty, ale já nosím klíče na kroužku a ne na prstenci. Můžu ten tvůj prstenec vidět ať si udělám představu?

[eh]

OMG WTF? A Saturn ma podle Tebe co? Krouzky!? ROFL!

Ne, ale ted o neco vazneji. Je mi uplne fuk, zes nejspis vystudoval nejakou IT skolu, ale umet cesky je zaklad. Vyraz "klicove prstence" je proti duchu ceskeho jazyka a pokud se takovej paskvil nekde uci, asi bych uvazoval o zahozeni diplomu...

Na druhou stranu je jasne, ze jsi opet jen provokoval a ja a mnoho ostatnich se opet nechalo dozrat a vyprovokovat. Gratuluji ti uprimne k tomuto veleuspechu.

[_nxt_]

co takhle klíčenka?

[Michal]

Vyraz "Keyring" do cestiny prekladame jako "Uloziste klicu" a to jiz docela dlouho. Muzete pouzit i vyraz "klicenka", ale ten je ponekud zavadejici.

[petr_p]

A proc to neni anglicky key storage? Protoze zavadeni technickych terminu, kde existuje prirozeny vzor, zatezuje prijemce a tim ztezuje porozumeni.

[demeter]

Pripomina mi to "lord of war" vs. "warlord"

[David Ježek]

a me to zas pripomina "android bishop[eng]" vs. "druid biskup[nejmenovana ceska "taky-prekladatelka"]"

[Václav "Darm" Novák]

Kdysi byla v Ikarii rubrika Knihomorna... Tam se daly najít slušný hlody z překladů :)

[David Ježek]

ano hlody z prekladu byly luxusni, ale sarkasticke komentare pod nimi jeste luxusnejsi

[Non_E]

+1

[egg]

Na pgp.cz tomu opravdu říkají kroužek klíčů, ale mně to připadá příliš otrocký překlad. Na gpg.cz píšou klíčenka.

[Robert Krátký]

Rozhodl jsem se pro kroužek, protože mi význam slova klíčenka přijde trochu jiný. Klíčenka může obsahovat více kroužků s klíči.

[JaMa]

Množství změn v ovladačovém jádru, včetně experimentálního vyhledávání paralelních zařízení a několika vylepšení procesu uspávání/probouzení.
x
A number of driver core changes including parallel device probing and some improvements to the suspend/resume process.

Ja mel za to ze jde o paralelni vyhledavani zarizeni, narozdil od puvodniho sekvencniho, ale mozna se pletu. Ted koukam ze v detailu na ty zmeny (ze starsiho dilu novin) je to spravne jako paralelni vyhledavani.

[Robert Krátký]

Máš pravdu. Dík, opraveno.

[David Watzke]

Yep.

[AstorLights]

Nenachytejte se na "efekt druhého systému". Klasický důvod pro pokažení druhého systému je zaměření na věci, kvůli kterým si lidi stěžují, místo na ty, které fungují dobře (protože to, co funguje správně, není tolik na očích).

Tsche, no to je teda překlad ! Šmarjá, čtete to vůbec než to začnete trapně překládat ? Linus mluví o tom že lidi mají tendenci nadávat že je něco špatně jen proto že je to "jinak" než dotyčný zvyklej, je to "syndrom jiného způsobu". A "getting the second system wrong" NENÍ "pokažení druhého systému" ale špatné pochopení druhého způsobu.

P.S. Captcha jako aktuální rok, to je teda gól !

[Behold, AstorLights had spoken !]

[melkors]

Boha jeho, ono to je tady taky?

[AstorLights]

Ano, a opravuje to špatně přeložený citáty.

[Behold, AstorLights had spoken !]

[Robert Krátký]

Second-system effect

A "getting the second system wrong" NENÍ "pokažení druhého systému" ale špatné pochopení druhého způsobu.

Nesouhlasím. Přečti si znovu kontext.

P.S.:

[Behold, AstorLights had spoken !]

Past perfect?

[AstorLights]

Hehe, nesouhlasit si můžeš jak chceš, ale z toho kontextu to JASNĚ vyplývá, Linus odpovídá na to že je určitá skupina lidí zvyklá že příkaz "pull" se používá jinak než v tom jeho gitu a že je to prej matoucí.

"Pokažení druhého systému" to je překlad, tsche, za á to přímo bolí v uších a za bé je to kolosální nesmysl, přemejšlej, JAK by asi mohli ten systém POKAZIT, he ? Co by mohli pokazit, GIT ? Jak jako ? Nebo cogito by mohli pokazit ?

P.S. Ano, had spoken tam mám úmyslně, znamená to totiž trošku něco jiného :-P

[Behold, AstorLights had spoken!]

[Robert Krátký]

"Pokažení druhého systému" to je překlad, tsche, za á to přímo bolí v uších

To je pravda. "Pokažení" není moc hezké slovo.

za bé je to kolosální nesmysl, přemejšlej, JAK by asi mohli ten systém POKAZIT, he ? Co by mohli pokazit, GIT ? Jak jako ?

Mluví se o úpravách gitu. Linus odpovídá (člověku, který zmiňuje Hg Mercurial) na volání po změně význam příkazu git pull. Takže ano, pokazit by to mohlo git.

Dovol, abych ti citoval Wikipedii, na kterou jsem předtím jen odkazoval:

In computing, the second-system effect or sometimes the second-system syndrome is the tendency to design the successor to a relatively small, elegant, and successful system as an elephantine, feature-laden monstrosity.

Tj. Linusovi jde o to, aby další verze gitu neutrpěly kvůli tomuto efektu druhého systému. Nejedná se o žádné "nepochopení druhého způsobu".

[AstorLights]

Don't get me wrong, možná že slovo "způsob" nebylo nejvhodnější...přesnější by bylo "mít za to že je ten druhý systém špatně" - protože se člověk zaměří na věci na které si lidi stěžujou že v něm jsou "špatně".A lidi si často stěžujou že je něco "špatně" jen proto, že sou zvyklý na něco jiného.

Klasika - tak se to předělá podle nich, pak si jiná grupa lidí začne stěžovat že je zvyklá na to že jiný příkaz se chová jinak nebo že mu chybí nějaké features a zase se to předělá a tak dál a nakonec je z původně malého elegantního a úspěšného systému monstrum nacpané tisícem přepínačů a vychytávek z nichž je půlka nedodělaná a o druhé se linuxáči hádají jestli je ještě nepředělat. To je syndrom druhého systému, snažit se tam nakódit všechno (podle druhých systémů) a skončit s tím že to nic neumí.

Všechno je to votom že lidi nepochopí proč je to v tom systému tak jak to tam je.

[Behold, AstorLights had spoken !]

[xor]

V článku se píše "Aktuální stabilní 2.6 jádro je 2.6.18.3". Na kernel.org píšou: "The latest stable version of the Linux kernel is: 2.6.19.1 2006-12-11 19:40 UTC" Kde je pravda?

[AstorLights]

Chosé Armando Santibáňos už zná pravdu. Celou pravdu.

[Haaja]

A muzes se podivat k jakemu datu jsou to jaderne noviny? Treba v nadpisu tve diskuse, kterou jsi psal a zajiste i cetl.