Jaderné noviny - 17. 11. 2016: Témata v patchování jádra za chodu

4. 12. 2016 | Redakce | Jaderné noviny | 2019×

Stav vydání jádra. Citáty týdne: David Miller, Peter Zijlstra, Ingo Molnár. Témata v patchování jádra za chodu.

Stav vydání jádra

Současný vývojový kernel je 4.9-rc5, vydaný 13. listopadu. Linus k tomu řekl: „Objem nových věcí se rozhodně zmenšil, takže klasické vydání (kde by rc7 bylo poslední) je stále na pořadu dne, navzdory velikosti 4.9. Ale uvidíme, jak se věci vyvinou v následujících pár týdnech. Do té doby to bude spousta běžných oprav a potřebujeme více testovat.“

Stabilní aktualizace: 4.8.7 a 4.4.31 byly vydány 10. listopadu, pak následovaly 4.8.8 a 4.4.32 15. listopadu.

Citáty týdne

Rozhraní síťových ovladačů od Microsoftu jsou zdokumentována tisíckrát lépe než ta v Linuxu.

-David Miller

Nikdy nešetřete na seznamu změn. Dokumentaci nikdo nečte.

-Peter Zijlstra

Co bych znovu rád měl v jádře, je volba, která by vrátila některé historické rootovací (a jiné) „díry“, které by se daly deterministicky využít – samozřejmě by byla ve výchozím stavu vypnutá.

Omezil bych to na rozumně „deterministické“ díry a exploity samotné by mohly být někde v tools/. (Samozřejmě pouze tehdy, pokud by správci souhlasili se zahrnutím takového kódu.)

-Ingo Molnár

Témata v patchování jádra za chodu

Snaha o zavedení live patchingu – patchování jádra za běhu systému – do upstreamu jádra byla úkolem na několik let. Základní podpora byla začleněna ve vydání 4.0, ale další práce se zasekly kvůli neshodám, jak by měl fungovat model konzistence, tj. kód, který zajišťuje, že patch je bezpečné aplikovat na běžící systém. Přidání validace jaderného zásobníku pomohlo vyřešit stěžejní námitku, takže se dá říct, že přišel čas posunout se kupředu. Na letošní konferenci Linux Plumbers se sešli vývojáři pracující na patchingu za chodu, aby společně probrali současné výzvy a budoucí směřování projektu.

Tento článek není pokusem o souhrnný přehled půldenní bouřlivé diskuze. Místo toho je jeho cílem pokrýt některá ze zajímavějších témat a ukázat výzvy, které musí vývojáři pracující na patchování za chodu překonat a jak mají v plánu to udělat.

Neužitečné optimalizace

Chytře optimalizující překladač je nezbytný pro každého, kdo od svého kódu očekává rozumný výkon. Jenže když je překladač až příliš chytrý, vyvstávají komplikace. Vývojáři, kteří pracují s paralelismem v jádře, si z agresivních optimalizací musejí dělat hlavu už delší dobu. Podle Miroslava Beneše by se měli obávat i vývojáři funkcionality patchování za chodu. Optimalizace překladače mohou vést k drobným změnám v procesu překladu kódu, což může při aplikaci patche způsobit chaos.

Počínaje těmi nejjednoduššími problémy, než se přesuneme k tě složitějším, Beneš poznamenal, že automatické převedení funkcí na inline může vést k problému v případě, že je potřeba inline funkci změnit patchem. V takovém případě je řešení relativně snadné, musí se změnit všechna volání dané funkce ve výsledném patchi určeném k aplikaci za chodu. Volba -fpartial-inlining může věci zkomplikovat tím, že dojde k převedení pouze části funkcí na inline, leč podstata problému zůstává stejná.

Volba -fipa-src je o něco zrádnější v tom, že může vést k odstranění nepoužívaných parametrů funkcí nebo změnit způsob, jakým jsou parametry funkci předávány. Jiný slovy mění ABI funkce podle toho, jak funkce funguje. Patch takové funkce, který se má aplikovat za chodu, by mohl ovlivnit způsob provádění této optimalizace, což by vedlo k překvapivé změně v ABI. Dobrou zprávou je, že když se to stane, změní GCC jméno překládané funkce, takže narušení ABI je na první pohled zjevné. Jenže tím se může zabránit přímému patchování chybné funkce, takže je nutné opravit i místa, odkud je volána.

Kód přeložený s -fipa-pure-const se může změnit podle toho, jak funkce pracuje. Pokud je považována za takovou, která nepřistupuje k paměti, překladač bude předpokládat určité věci o stavu paměti před voláním funkce a po něm. Jestliže patch změní chování funkce, tyto předpoklady již nemusí platit, takže opět bude nutné patchem opravit také místa volání.

„Ještě šílenější“ je volba -fipa-icf, která skládá identický kód. Může způsobit úplné nahrazení funkce ekvivalentem nalezeným někde jinde v kódu. Takovou změnu je přitom složité detekovat. Skládání kódu (code folding) je problém také při odvíjení jaderného zásobníku. K jiným případům odstranění kódu může dojít v případě, že si GCC myslí, že se určitá globální proměnná během volání dané funkce nezmění. Jestliže dojde k opatchování funkce tak, že bude nově měnit globální proměnnou, může být kód volání nesprávný. Také tento druh změny je těžké detekovat. Beneš řekl, že by bylo pěkné mít možnost chtít po GCC, aby zaznamenávalo provedené optimalizace.

Snad nejděsivější volba je -fipa-ra, která sleduje registry používané volanými funkcemi a zabraňuje ukládání těch, které se nemění. Patch volané funkce by mohl způsobit použití nového registru, což by vedlo k poškození dat ve volajících funkcích a pravděpodobně také výraznému zkrácení nepřerušeného běhu systému, o který uživatelé patchování za chodu tolik stáli. Tuto optimalizaci je velmi těžké detekovat. Může totiž být považována za změnu ABI volané funkce, ale bez změny názvu. To podle Beneše „nejsou dobré zprávy.“ Prozatím tuto optimalizaci GCC vypíná, je-li zároveň povolena volba -pg, přičemž subsystém Ftrace, který je potřeba při patchování za chodu, -pg vyžaduje. Není ovšem žádný zásadní důvod, proč by tyto dvě volby nemohly být kompatibilní, takže ke změně chování může dojít kdykoli.

Tento seznam je podle Miroslava jen malou podmnožinou optimalizací, které mohou způsobovat problémy patchům, které mají být aplikovány za běhu. Vzhledem k tomu, že se vývojáři překladačů snaží o čím dál tím agresivnější optimalizace, bude se situace jen zhoršovat.

Poznámka redakce: Další témata včetně sestavování patchů nebo závislostí modulů jsou rozebrána v původním článku.

       

Komentáře

[Karry]

Osobně mám pocit že pokud někdo přemýšlí o patchování za běhu, dělá někde něco špatně. Posledních několik let když jsem se podílel na návrhu nového systému vždy jsme to dělali tak aby výpadek jednoho stroje neohrozil běh systému jako celku...

[Michal Kubeček]

Někde těch strojů mají tisíce - a u enterprise hardware se pět minut dá považovat za docela rychý boot.

[b*d]

To se u host OS, ktery bezi dalsich X 'microservice' containeru / virtualu dela dost blbe. Proto nemusi byt rychly, ale nemel by byt deravy.

Ale pravdepodobne to neni u Linuxu optimatni nasazeni a lepsi bude sahnout po OS k tomu delana.

[cronin]

...a lepsi bude sahnout po OS k tomu delana.

A to sú?

[Sten]

Třeba u QNX, pokud není chyba v mikrojádře, tak jakýkoliv jaderný server (např. souborový systém či správce paměti) lze restartovat, takže není třeba měnit kód za běhu, prostě se starý zahodí a zavede nový. Ale nevím, jak je na tom s virtualizací.