Jaderné noviny – 26. 4. 2018: Hledání zranitelností Spectre pomocí smatch

6. 5. 2018 | David Kolibáč | Jaderné noviny | 2032×

Stav vydání jádra. Změna CLOCK_MONOTONIC vrácena zpět. Vetter: Statistiky správců jádra Linux. Citát týdne: David Miller. Hledání zranitelností Spectre pomocí smatch.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 25. dubna 2018

Současné vývojové jádro je 4.17-rc2, vydané 22. dubna. Citujeme Linuse: „Ještě nám tu zbývají nějaké známé dopady začleňovacího okna, ale většinu běžných konfigurací by to nemělo zasáhnout, takže jděte a testujte.“

Stabilní aktualizace: 4.16.3, 4.15.18 a 4.14.35 vyšly 19. dubna, o den později následovala aktualizace 4.9.95. Poté 24. dubna vyšly aktualizace 4.16.4, 4.14.36, 4.9.96, 4.4.129 a 3.18.106.

Upozorňujeme, že 4.15.18 je poslední aktualizace řady 4.15.x.

Aktualizace 4.16.5 a 4.14.37 byly v době psaní článku revidovány a vyšly 27. dubna.

Změna CLOCK_MONOTONIC vrácena zpět

CLOCK_MONOTONIC change reverted. Jonathan Corbet. 25. dubna 2018

Začleňovací okno 4.17 zahrnovalo změnu chování systémových hodin CLOCK_MONOTONIC. Konkrétně šlo o to, že tyto hodiny se měly po probuzení posunout, aby braly v potaz čas, kdy byl systém uspaný. Vývojáři tehdy brali v potaz, že změnu by mohlo být nutné vzít zpět, kdyby vedla k regresím. Zdá se, že nějaké takové regrese byly skutečně nahlášeny, takže vrácení zpět bylo nachystáno s tímto komentářem:

Jak nahlásilo několik lidí, systemd a další aplikace závisejí na zdokumentovaném chování CLOCK_MONOTONIC na Linuxu a výše uvedené změny je rozbijí. Byly pozorovány problémy typu, že démonům po probuzení vyprší čas a podobně.

Je to škoda, že tyto záležitosti nebyly zaznamenány ani v -next, ani lidmi, kteří o tuto změnu projevili zájem.

Vetter: Statistiky správců jádra Linux

Vetter: Linux Kernel Maintainer Statistics. Jonathan Corbet. 23. dubna 2018

Daniel Vetter se podíval na nějaké statistiky vývoje jádra se zaměřením na patche napsané správci, kteří je commitují. „Naivní extrapolace relativního trendu vede na předpověď, že kolem roku 2025 nebude velký počet správců jádra ničím jiným než úzkým hrdlem bránícím všem ostatním v tom, aby došlo k začlenění jejich práce, ani nebude sám přispívat ničím vlastním. Pravděpodobným výsledkem bude kolaps jaderné komunity pod vlastní byrokratickou zátěží. To je v dramatickém kontrastu s oslavnými výroky ‚všechno se zlepšuje, roste a jaderná komunita je velmi zdravá‘ z úvodních slov konferencí a ročenek jádra. Jsem názoru, že jaderná komunita vůbec nevypadá, že by se nějak skvěle vypořádávala se svým růstem, ani jako celkově zdravá komunita.“

Citát týdne

Quote of the week. Jonathan Corbet. 25. dubna 2018

Jakožto správce síťového kódu v Linuxu cítím potřebu zopakovat své vyjádření z minulého měsíce a podložit to dalšími fakty, aby v komunitě o těchto záležitostech nepanovala žádná nedorozumění.

Již nejsem nijak spojen ani s Netdev Society, ani s jejich konferencí NetDev.

Ani jedno nijak nepodporuji, ani nepropaguji.

—David Miller

Hledání zranitelností Spectre pomocí smatch

Finding Spectre vulnerabilities with smatch. Jonathan Corbet. 20. dubna 2018

Rozruch kolem zranitelností Meltdown a Spectre se – aspoň dočasně – uklidnil, ale to neznamená, že vývojáři už se o ně nestarají. Spectre 1. varianty (zranitelnost obejití kontroly mezí) je zvláště znepokojující, protože panují domněnky, že jádro je zranitelné na mnoha místech, ale nikdo pořádně neví, jak je všechny najít. Tím pádem byly dosud vyvinuté obranné techniky použity pouze na několika místech. Ovšem Dan Carpenter nedávno vylepšil nástroj smatch, aby potenciálně zranitelný kód v jádře dokázal najít.

1. varianta Spectre je výsledkem chybné predikce výsledků kontroly mezí v procesoru, který následně spekulativně provede kód s parametrem (např. indexem pole), který tak bude mimo povolený rozsah. Tento problém jde omezit tím, že se vypne spekulativní provádění kódu v případech, kdy potenciální útočník ovládá hodnotu indexu pole. V jádře se to dělá tak, že se nahradí kód

value = array[index];

následujícím

index = array_index_nospec(index, ARRAY_SIZE);
value = array[index];

To byla ta snadná část. To těžké spočívá v hledání míst v jádře, kde by se mělo použít makro array_index_nospec(). Dosud to šlo pouze pomocí proprietárního nástroje Coverity, který nebyl dostupný každému a nacházel docela hodně falešně pozitivních výsledků. Tím pádem je v současných jádrech jen pomálu volání array_index_nospec().

Carpenterův příspěvek do smatch situaci mění, poskytuje totiž svobodný nástroj, kterým jde hledat potenciální zranitelnosti Spectre 1. varianty. Algoritmus je v principu dost přímočarý:

To, co ten test dělá, je, že se podívá na přístupy do pole, u nichž uživatel určuje offset. Ptá se: „je to čtení?“ a použili jsme makro array_index_nospec()? Pokud jsou odpovědi ano a ne, pak vypiš varování.

Tento test vrací seznam asi 800 míst, kde by se mělo použít array_index_nospec(). Carpenter předpokládá, že velký podíl z toho budou falešně pozitivní nálezy, a žádá o návrhy, jak test učinit přesnějším. Jenže jak Thomas Gleixner, tak Peter Zijlstra, namísto aby poradili, rovnou potvrdili, že řada hlášení byla opravdu správná. Zijlstra řekl: „Obávám se, že hodně z toho ve skutečnosti chceme opravit.“ Následně dodal řadu patchů, která sedm případů opravuje – čímž počet volání array_index_nospec() v jádře takřka zdvojnásobil.

Jakmile se podaří vypořádat se s nízko visícím ovocem, pravděpodobně se dostane víc pozornosti vylepšování testů v smatch, aby se odfiltrovaly nevyhnutelné falešně pozitivní nálezy a naopak zranitelná místa neunikala pozornosti. Ale když je tady svobodný nástroj, který takovou kontrolu umožňuje, dá se očekávat, že pokrok v této oblasti zrychlí. Snad bude možné najít – a opravit – mnoho stávajících zranitelností Spectre, než se k nim dostanou útočníci.

       

Komentáře

[pc2005]

Následně dodal řadu patchů, která sedm případů opravuje – čímž počet volání array_index_nospec() v jádře takřka zdvojnásobil.

[1john2]

Jakmile se podaří vypořádat se s "nízko visícím ovocem"?

co tim chtel basnik rict?

[Fluttershy, yay!]

To nejsnáze řešitelné. Jde o rozšířený idiom. [google]