Jaderné noviny – 19. 7. 2018: Jmenné prostory jaderných symbolů

1.8. | Redakce | Jaderné noviny | 1953×

Stav vydání jádra. Citáty týdne: Dave Täht, James Bottomley a Ted Ts'o. Jmenné prostory jaderných symbolů.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 18. července 2018

Současné vývojové jádro je 4.18-rc5, vydané 15. července. Linus řekl: „Tento týden mi z nějakého důvodu přišel docela rušný, ale čísla rc5 říkají něco jiného: je malý a klidný, pěkně to postupuje.“

Stabilní aktualizace: 4.17.7, 4.14.56, 4.9.113 a 4.4.141 byly vydány 17. července. O den později přišla aktualizace 4.17.8 s jednou opravou, která se nestihla dostat do 4.17.7.

Aktualizace 4.4.142 obsahuje trojici oprav a vyšla 19. července.

Citáty týdne

Quotes of the week. Jonathan Corbet. 18. července 2018

No tak, nepamatujete si doby, kdy se flashovalo jen tak, pro zábavu?

—Dave Täht

Tyto výsledky snad ukazují, že rozhodně je možné provozovat kontejnery bezpečnější než hypervizory, a konečně utnou debaty o tom, která technologie je bezpečnější.

—James Bottomley

Vychází to z předpokladu, že (aspoň pro americké výrobce CPU) je úsilí nutné k přidání zřejmého backdooru do, řekněme, souboru správy registrů a plánovače instrukcí tak velké, že by to nezvládl jeden osamocený inženýr, ani malá skupinka inženýrů. Muselo by o tom vědět dost lidí, nebo by byli schopni přijít na to, že něco nehraje, nebo by se na to přišlo z různých regresních testů, že by v CPU byl zjevný backdoor. To je dobře, protože nakonec univerzálnímu CPU věřit *musíme*. Pokud by CPU aktivně pracoval proti našim zájmům, to by byl konec veškerých nadějí.

—Ted Ts'o

Jmenné prostory jaderných symbolů

Kernel symbol namespacing. Jonathan Corbet. 18. července 2018

Jaderný modul, aby vůbec mohl něco dělat, musí získat přístup k funkcím a datovým strukturám ze zbytku jádra. Za toto povolení a řízení přístupu je odpovědný mechanismus exportu symbolů. Povolení sice nepochybně dává, ale s řízením to už tak jasné není: v současných jádrech mají všechny moduly přístup k téměř 30 tisícům symbolů, což mnoho vývojářů považuje za příliš vysoké číslo. Skupina patchů jmenných prostorů symbolů od Martijna Coenena ho nesnižuje, ale poskytuje mechanismus, který by měl pomoci udělat pořádek obecně v exportovaných symbolech.

Jaderný kód může symbol (funkci či datovou strukturu) zpřístupnit modulům, které lze načíst, makry EXPORT_SYMBOL() a EXPORT_SYMBOL_GPL() – to druhé symbol zpřístupňuje pouze modulům označených jako šířených pod licencí kompatibilní s GNU GPL. Dále existuje makro EXPORT_SYMBOL_GPL_FUTURE(), které označuje symboly, u nichž se do budoucna plánuje přechod na podporu pouze exportů kompatibilních s GNU GPL. Jeho využití je také otázkou budoucnosti, protože k němu nedošlo od zavedení v roce 2006. Když už symboly byly ve vzácných případech změněny k použití pouze s moduly pod GNU GPL, ukázalo se být snazší prostě je změnit bez ohlášení předem v kódu.

EXPORT_SYMBOL() pracuje tak, že se deklaruje struktura kernel_symbol:

struct kernel_symbol
{
    unsigned long value;
    const char *name;
};

Po slinkování tato struktura obsahuje ukazatel na jméno symbolu a adresu odpovídající symbolu. Všechny struktury, které odpovídají veškerým exportovaným symbolům, linker shromáždí do dvou sekcí ELF v binárce jádra (či modulu): __ksymtab a __ksymtab_gpl. Symboly nejsou ani v jedné z těchto sekcí uspořádány či odděleny – jsou prostě na jedné velké hromadě.

Ne všechny symboly jsou ale stejné. Obecně neplatí, že by všechny existovaly pro potřeby načítaných modulů, které je vyžadují pro svou činnost. Některé jsou totiž exportovány proto, aby zjednodušily ladění jaderného kódu. Další jsou součástí většího subsystému, který se skládá z více modulů, a neměly by se používat mimo tento subsystém. Tyto symboly není možné nijak označit nad rámec komentářů v kódu.

Coenenova skupina patchů se tento problém snaží řešit tak, že přidává exportovaným symbolům jednoduchou podobu jmenných prostorů. I když výchozí chování zůstává takové, že symboly budou v nepojmenovaném globálním jmenném prostoru, bude možné symboly izolovat do odděleného prostoru, kde bude nutné k jejich užití vyvinout explicitní úsilí. K exportování symbolů přibyla dvě nová makra:

EXPORT_SYMBOL_NS(symbol, namespace);
EXPORT_SYMBOL_NS_GPL(symbol, namespace);

Člověk by si mohl myslet, že tato nová makra pro symboly ve jmenných prostorech vytvářejí nové sekce, ovšem není tomu tak. Místo toho se název jmenného prostoru přidá ke jménu symbolu a výsledek se opět umístí do stejné sekce __ksymtab (či __ksymtab_gpl). Takže kdyby se kmalloc() měl exportovat do nového jmenného prostoru MM, ve výsledné binárce by se ukázal jako kmalloc.MM. (Dodejme, že v praxi by tak stěžejní symbol jako kmalloc() takto izolován nebyl.)

V případě, že modul bude chtít použít symboly z určitého jmenného prostoru, deklaruje přístup k tomuto jmennému prostoru pomocí:

MODULE_IMPORT_NS(namespace);

Tento mechanismus novou sekci ELF („__knsimport“) skutečně používá, aby si udržoval seznam jmenných prostorů importovaných daným modulem. V zásadě všechno, co dělá, je, že poskytuje seznam importovaných jmenných prostorů. Neřeší tedy nic hlubšího, než že modul chce přistupovat k určitému jmennému prostoru.

Vynucování mechanismu jmenných prostorů v praxi můžeme popsat jako „benevolentní“. Při překladu se nijak nedává najevo, že se používá symbol ze jmenného prostoru. Ve smyšleném příkladě uvedeném výše by kód mohl zavolat kmalloc(), aniž by byl býval importoval jmenný prostor MM, a překladač by na to nijak nereagoval. Situace se mění po překladu v kroku modpost, kdy se zahlásí varování o použití symbolů ze jmenného prostoru, který nebyl importován. Další varování se objeví při načtení modulu: jádro si všimne užití symbolu, který postrádá deklaraci importu příslušného jmenného prostoru, leč samotnému užití tohoto symbolu nic nebrání.

Skupina patchů vytváří pouze jeden jmenný prostor: USB_STORAGE pro skupinu symbolů USB. Jinak obsahuje mechanismus, který automaticky vytvoří patche pro další subsystémy, což je funkce, kterou Greg Kroah-Hartman popsal jako „fakt úžasnou.“ Všehovšudy je to skromný začátek mechanismu, který by jednou mohl jaderné komunitě pomoci zvládnout obrovitou hromadu neroztříděných symbolů, ale i samotné jádro začalo skromně. Pokud se tento mechanismus ukáže být užitečný, časem poroste a snad přinese řád do notoricky chaotické části jádra.

       

Komentáře

[pc2005]

C++?

[Michal Kubeček]

Ne tak úplně. Exportované symboly jsou zajímavé jen při linkování, ne při překladu.

[oux]

kdyz jmenne prostory tak me napadaji jine veci nez c++

[pc2005]

Mě napadl ještě bash, ale to by bylo až moc heretické