Jaderné noviny – 24. 1. 2013: Řešení nejednoznačných chybových kódů

11. 2. 2013 | Luboš Doležel | Jaderné noviny | 2970×

Aktuální verze jádra: 3.8-rc4. Citáty týdne: Alan Cox, Steven Rostedt, Tom St Denis, Arnd Bergmann. Vydáno jádro řady 3.4 z iniciativy dlouhodobé údržby. Přátelštější EPERM.

Obsah

• Aktuální verze jádra: 3.8-rc4
• Citáty týdne: Alan Cox, Steven Rostedt, Tom St Denis, Arnd Bergmann
• Vydáno jádro řady 3.4 z iniciativy dlouhodobé údržby
• Přátelštější EPERM

Aktuální verze jádra: 3.8-rc4

Aktuální vývojová verze jádra je 3.8-rc4 vydaná 17. ledna. Linus se s vydáním o den „opozdil“, což ho dovedlo k otázce, který den v týdnu vycházejí nové verze nejčastěji (v neděli). Ale zpět k tématu, navzdory jednomu dni navíc s radostí oznamuji, že -rc4 je menší než -rc3, i když ne o moc. Nic nevybočuje z řady: kromě nového bezdrátového ovladače (Atheros Wilocity) a nějakých změn v OMAP drm, jinak diffstat vypadá rovnoměrně. Což znamená spoustu drobných změn všude možně.

Stabilních aktualizací nebylo tento týden málo. Verze 3.7.3, 2.4.26, 3.0.59 a 2.6.34.14 vyšly 17. ledna; součástí oznámení verze 2.6.34.14 bylo upozornění, že tato řada už nebude dlouho udržována. Verze 3.7.4, 3.4.27 a 3.0.60 vyšly 21. ledna.

Citáty týdne: Alan Cox, Steven Rostedt, Tom St Denis, Arnd Bergmann

Na nějaký čas z rodinných důvodů opouštím svět Linuxu a Intel. Jsem si vědom, že „rodinné důvody“ je obvykle manažerský výraz pro „myslím si, že můj šéf je vůl“, ale rád bych všechny ujistil, že ačkoliv si často o Linusovi myslím, že je vůl (a je tedy velmi dobrým jaderným diktátorem), odcházím skutečně z rodinných důvodů, nikoliv proto, že bych se nepohodl s Linusem nebo s někým v Intelu nebo někým dalším.

-- Hodně štěstí, Alane Coxi, budeš nám scházet

Ano, je to velmi nepravděpodobné, ale máme v popisu práce velmi nepravděpodobné věci řešit. To proto, že v našem oboru se nepravděpodobné stává velmi pravěpodobným. Kruci, měl bych si jít vsadit do loterie!

-- Steven Rostedt

Snad to jediné, na čem se jaderní vývojáři shodnou, je to, že používají C a nepíšou komentáře.

-- Tom St Denis

Dokumentace je obecně považována za dobrou věc, ale jen málo lidí má náladu na to ji psát a jen málo z těch ostatních, co by ji číst měli, tak skutečně činí.

-- Arnd Bergmann

Vydáno jádro řady 3.4 z iniciativy dlouhodobé údržby

Long-Term Support Initiative usiluje o podporu vybraných jader po dobu dvou let. Mezi záměry projektu je ale i vydávání dodatečných jader zaměřených na potřeby výrobců z oblasti elektroniky. Tak tomu je v případě oznámení vydání jádra LTSI 3.4. Je založené na 3.4.25, ale má vylepšený alokátor CMA, implementaci protokolu AF_BUS udržovanou mimo hlavní větev a backport algoritmu CoDel pro správu front spolu s různými ovladači a dalším kódem.

Přátelštější EPERM

Hlášení chyb z jádra (a nízkoúrovňových systémových knihoven jako libc) bylo už od nejstarších UNIXových systémů primitivní. Jedním z důsledků tohoto je to, že uživatelé a systémoví administrátoři často narážejí na chybové zprávy, které o povaze chyby informují jen velice stroze, což komplikuje diagnostiku. Vývojáři, kteří by chtěli, aby jádro poskytovalo podrobnější chybové informace, pak stojí za nedávnými diskuzemi na libc-alpha a LKML.

Tradiční UNIXový (a linuxový) způsob oznamování chyb je přes globální proměnnou errno (ale každé vlákno má svou vlastní). Obalující funkce libc, které uskutečňují systémová volání, indikují chybu vrácením -1 a nastavením errno na kladné číslo označující příčinu chyby.

Skutečnost, že errno je globální proměnná, je zdrojem komplikací pro aplikace. Protože každé systémové volání může tuto hodnotu přepsat, je někdy nutné si uložit její kopii, zatímco se uskuteční volání jiné. Globální errno také znamená, že obsluha signálů, ve které dochází k systémovým voláním, by měla na začátku uložit hodnotu errno a na konci ji zase obnovit, aby se předešlo riziku přepsání errno, které bylo nastaveno v hlavním programu.

Jiným problém s errno je to, že obsažená informace je skutečně minimalistická: jedna z něco přes sto číselných hodnot. Vzhledem k tomu, že jádro poskytuje stovky systémových volání a řada z nich má více chybových situací, mapování těchto chyb na hodnoty errno nevyhnutelně vede ke ztrátě informace.

Ztráta informace může být obzvláště vážná, pokud se jedná o některé často využívané hodnoty errno. Dan Walsh ve zprávě na mailing listu libc-alpha vysvětlil problém týkající se dvou chyb, na které často narážejí uživatelé:

Pokud se proces pokusí o zakázanou operaci, pak je errno pro toto vlákno nastaveno na EACCES nebo EPERM a volání strerror() vrátí lokalizovanou verzi „Permission Denied“ nebo „Operation not permitted“. Tento řetězec se objevuje napříč uživatelskými rozhraními a systémovými logy. Například se objevuje v nástrojích pro příkazovou řádku, ve výjimkách ve skriptovacích jazycích apod.

Tyto dvě chyby jsou na UNIXových systémech definovány už od počátků. POSIX definuje EACCES jako pokus o přístup k souboru, který je zakázán oprávněními u tohoto souboru a EPERM jako pokud o operaci vyhrazenou procesům s příslušnými oprávněními nebo vlastníkům souboru či jiného prostředku. Tyto definice byly vcelku srozumitelné na raných UNIXových systémech, kde jádro bylo mnohem méně složité, jediným způsobem řízení přístupu k souborům byla klasická práva rwx a jediným oddělením práv bylo přes ID uživatelů a skupin a logiky superuživatel versus ti ostatní. Na moderních UNIXových systémech je ale život poněkud složitější.

Celkově je v Linuxu 3.7 EPERM a EACCES vraceno z více než 3000 míst. Problémem ale není počet míst. Pro koncové uživatele je to spíše odhalování příčiny, která se za vrácenou chybou skrývá. Příčin může být mnoho, například odepření přístupu kvůli klasickým právům nastaveným u souboru nebo právům nastaveným přes ACL, chybějící capability, odepření operace z Linux Security Module nebo mechanismem seccomp a z řady dalších důvodů. Dan shrnul problém, kterému uživatelé čelí:

Ačkoliv do jádra přidáváme další způsoby, jak může jádro odmítnout přístup, administrátor/uživatel obdrží stále jen hlášku „Přístup odepřen“. Jen pokud má administrátor dostatek štěstí nebo má dost zkušeností, že ví, kam se podívat, tak možná porozumí tomu, proč byl procesu přístup odepřen.

Danův mail odkazoval na wiki stránku („Přátelský EPERM“) s návrhem, jak problém řešit. Návrh zahrnuje změny v jádře i v glibc. Změny v jádře by přidaly mechanismus, pomocí kterého by se do uživatelského prostoru dostávala „cookie s chybou“ s podrobnější informací o chybě předávané do errno. Na straně glibc by strerror() a příbuzná volání (jako perror()) přistoupila k této cookie, aby získala informace vedoucí k podrobnějšímu popisu chyby uživateli.

Ronald McGrath rychle upozornil, že řešení není tak jednoduché. Problém je v tom, že je u aplikací obvyklé volat strerror() až po nějaké době od systémového volání, nebo mohou dělat věci jako si třeba uložit hodnotu errno a pak ji zase vrátit zpět. Je pravděpodobné, že aplikace mezitím udělá další systémová volání, která mohla hodnotu cookie změnit.

Ronald pak označil další překážky bránící rozšíření existujících standardizovaných rozhraní za účelem poskytnutí užitečných informací uživatelům:

To, že je hlášení chyb omezeno na jediné číslo, je samozřejmě nešťastné omezení POSIXových rozhraní. Je to ale velmi hluboce zakořeněno do základů všech unixových rozhraní.

Po pravdě nevidím žádný praktický způsob, jak dosáhnout toho, co chcete. Ve většině případů nemůžete ani přidat odlišné kódy errno pro různé druhy chyb souvisejících s právy, protože byste rozbili jak soulad se standardy, tak všechny aplikace, které rozlišují mezi standardními kódy errno a chyby pak řeší specifickými způsoby.

Eric Paris, další z přívrženců myšlenky s „cookie s chybou“, uznal to, co Roland napsal, ale řekl, že protože standardní API není možné rozšiřovat, každá aplikace mající zájem o dodatečné chybové informace by musela být upravena.

Eric následně poslal do LKML mail s návrhem změn v jádře potřebných pro rozšířené hlášení chyb. V zásadě navrhuje exportování nějaké binární struktury do uživatelského prostoru, ta by popisovala původ poslední chyby EPERM nebo EACCES vrácené procesu jádrem. Tato struktura by mohla být vracena například souborem v /proc specifickým pro vlákno.

Struktura by měla pole označující subysystém, jenž vyvolal chybu – kupříkladu capabilities, SELinux nebo práva u souborů – následované strukturou obsahující podrobnosti o okolnostech, jež k chybě vedly. U chyby s právy souborů by taková struktura mohla vrátit efektivní UID a GID procesu, UID a GID souboru a bity oprávnění u souboru. Na úrovni uživatelského prostoru by binární struktura byla přečtena a převedena na řetězec s popisem pro uživatele, třeba ve funkci v glibc, která by se podle Erica mohla jmenovat get_extended_error_info().

Každé místo, kde se vrací EPERM nebo EACCES, by pak muselo být upraveno. To by ale k užitečnosti této funkce bylo potřeba.

Ale doplnění jen na pár častých místech by bylo velkým úspěchem. Dal bych to do capable(), háčků LSM, systémového volání open() a kódu, co prochází cesty.

Ericův návrh vyvolal různé komentáře. V reakci na obavy Stephena Smalleyho, že by přes tuto funkci mohly unikat informace (jako atribury souborů), jež by mohly na systémech s přísnou bezpečnostní politikou (vynucovanou LSM) být považovány za citlivé, Eric odpověděl, že by v systému mohlo být sysctl pro zákaz této funkce:

Vím, že mnoho lidí má obavy o únik informací, takže narovinu říkám přidejme sysctl pro zákaz tohoto rozhraní pro ty, kdo mají strach z úniku metadat. Pro většinu z nás bych ale chtěl údaje hned v moment, kdy k problému dojde, aby bylo možné je zveřejnit, použít a reagovat na ně.

Casey Schaufler navrhl, že by místo toho měly být použity záznamy pro audit:

Řetězec vrácený z get_extended_error_info() by měl být záznamem pro audit, co by toto volání vygenerovalo, ať už by jej subsystém pro audit vygeneroval, nebo ne. Pokud záznam pro audit nemá ty informace, co potřebujeme, tak bychom měli opravit tento subsystém. Každý střípek informace v záznamu pro audit by měl být relevantní a váš admin nebo uživatel ho může potřebovat vidět.

Eric vyjádřil obavy, že kopírování záznamu pro audit do task_struct tohoto procesu může představovat větší dopad na výkon než kopírování pár čísel do struktury.

Nevidím problém v ukládání posledního záznamu pro audit, pokud existuje, ale nechce se mi dělat z auditu běžnou součást fungování volání. Pokud se to tak ale líbí ostatním, udělám to.

Jakub Jelínek měl pochyby o tom, ke kterému systémovému volání by Ericův mechanismus měl vracet informace, a zda by stav byl resetován, pokud by další volání uspělo. V mnoha případech není mezi funkcemi glibc a systémovými voláními vztah 1:1, takže některé knihovní funkce mohou udělat jedno volání, uložit errno, pak udělat jiné systémové volání (které může, ale nemusí také selhat) a pak obnovit errno prvního volání před návratem do volající funkce. Jiné funkce glibc dokonce nastavují errno samy. Kdy by tedy bylo bezpečné tuto novou funkci get_extended_error_info volat a jak poznat, kterého volání se týká?

Ericův názor je takový, že tento mechanismus by měl vracet informace o posledním systémovém volání. Bylo by opravdu pěkné, aby libc mělo způsob, jak ukládat a obnovovat rozšířenou informaci o chybě, nebo dokonce dodat vlastní, pokud došlo k rozhodnutí v uživatelském prostoru, ale to se zdá být pro první verzi dost náročné.

Takový zjednodušený přístup má ale vážné nedostatky. Pokud hodnota vrácená z get_extended_error_info(), odpovídá poslednímu systémovému volání a ne hodnotě errno vrácené do uživatelského prostoru, je tu riziko zmatení aplikací (a uživatelů). Carlos O'Donell, který dokonce ještě dříve než Jakub vznesl některé otázky a poukázal na potřebu korektně řešit rozšířenou informaci o chybě při obsluze signálů, souhlasil s Caseyho názorem, že by get_extended_error_info() mělo vždy vracet hodnotu odpovídající aktuálnímu obsahu errno. To znamená mít funkci pro uložení a obnovu rozšířené informace o chybě.

David Gilbert pak navrhl, že by bylo prospěšné rozšířit Ericův návrh i na další chyby kromě EPERM a EACCES. Hledáním důvodů, proč mi (například) mmap vrací EINVAL, jsem strávil až příliš mnoho času; je tam až moc chybových situací.

Během několika posledních dnů diskuze na toto téma utichla. Je ale jasné, že se Danovi i Ericovi podařilo identifikovat skutečný a praktický problém (na který upozorňovali už jiní). Případné řešení by se muselo vypořádat se všemi nedostatky nadhozenými v diskuzi – především aby get_extended_error_info() vždy odpovídalo aktuální hodnotě errno – a snad by mohlo být zobecněno i mimo navrhované chyby EPERM a EACCES. To vše by ale mělo být proveditelné, pokud si někdo vezme na svá bedra úděl nemalé dřiny spojené s návrhem a implementací. Pokud se to stane skutečností, mělo by to ulehčit život všem administrátorům a uživatelům při diagnóze původu chyb.

       

Komentáře

[Michal Kubeček]

Skutečnost, že errno je globální proměnná

Ona to tak úplně globální proměnná není, na příklad má na rozdíl od "normálních" globálních proměnných každý thread svou vlastní hodnotu.

[Luboš Doležel (Doli)]

V originále to bylo, vypadlo mi to. Opravím to.

Ale ona to dokonce ani není proměnná, ale jen makro na volání funkce.

[Michal Kubeček]

Ono je to vlastně něco jako reference:

  #   define errno (*__errno_location ())

Funkce vrací pointer na int, takže aplikací hvězdičky se z toho stane int, ale díky tomu, že je to použité takhle přes makro, lze errno použít jako l-value.

[little.owl]

Ano, errno je thread local.

[frr]

Když si vzpomenu, jak vypadá výpis strace nějakého user-space programu, kolik syscallů končí chybou, tak trochu váhám, jaký výkonnostní dopad by mělo poskytování podrobně rozpitvaných chybových informací (= nějaké složitější datové struktury) ke každému uprdnutí... Ale z druhé strany je fakt, že by to posunulo luštění záhad typu "proč to kruci nechodí" o *veliký* kus dál