Jaderné noviny – 22. 3. 2018: Podivný příběh backportu opravy Meltdown na ARM

3. 4. 2018 | David Kolibáč | Jaderné noviny | 2684×

Stav vydání jádra. Představení nástěnky pro syzbot. Citáty týdne: Dave Chinner a Martin Uecker. Podivný příběh backportu opravy Meltdown na ARM.

Stav vydání jádra

Kernel release status. Jonathan Corbet. 21. března 2018

Současné vývojové jádro je 4.16-rc6, vydané 18. března. Zdá se, že tento cyklus směřuje k tomu, aby trval devět týdnů. „Jděte testovat, je to stabilní a není důvod k obavám, ale jako obvykle by se hodilo zběžně jádro sestavit a ověřit, že všechno bude všem fungovat. OK?“

V současném seznamu regresí pro 4.16-rc6 se nachází sedm problémů.

Stabilní aktualizace: 4.15.10 a 4.14.27 byly vydány 15. března. Následovaly je 18. března 4.9.88, 4.4.122 a 3.18.100, 19. března 4.15.11 a 4.14.28 a 21. března 4.15.12 a 4.14.29.

Představení nástěnky pro syzbot

Introducing the syzbot dashboard.

„Syzbot“ je automatizovaný systém, který nad jádrem spouští fuzzer syzkaller a hlásí výsledné pády. Dmitrij Vjukov oznámil zveřejnění stránky, která zobrazuje nevyřešená hlášení. „Nástěnka ukazuje informace o aktivních chybách nahlášených syzbotem. Je na ní ~130 aktivních chyb a myslím, že ~2/3 z nich je žádoucí řešit (stále se objevují, jsou reprodukovatelné nebo se ladí dostatečně snadno).“

Citáty týdne

Quotes of the week. Jonathan Corbet. 21. března 2018

První pravidlo smrskávačů (shrinkers): Smrskávače *nejsou snadno pochopitelné.*
Druhé pravidlo smrskávačů: Viz první pravidlo.

—Dave Chinner

Co tenhle nápad: test konstantních celočíselných výrazů, který vrací konstantní celočíselný výraz samotný, který by mělo být možné předat __buitin_choose_expr, by mohl vypadat takto:
#define ICE_P(x) (sizeof(int) == sizeof(*(1 ? ((void*)((x) * 0l)) : (int*)1)))

—Martin Uecker se nevzdává max()

Podivný příběh backportu opravy Meltdown na ARM

The strange story of the ARM Meltdown-fix backport. Jonathan Corbet. 15. března 2018

Řada patchů, kterou zaslal Alex Shi, backportující skupinu oprav zranitelnosti Meltdown na architekturu arm64 v jádře 4.9 se může zdát jako běžné cvičení v zajišťování dostupnosti důležitých bezpečnostních oprav ve starších jádrech. Ale tento případ vyvolal pár zajímavých otázek týkajících se toho, zda by mělo dojít ke zpětnému zařazení do jader s dlouhodobou podporou – jakožto i pár stejně zajímavých odpovědí, z nichž jedna byla přijata o poznání lépe než ta druhá.

Zranitelnost Meltdown se nejvýrazněji projevuje ve světě x86, ale není to problém pouze Intelu. Postihuje totiž i některé (ale ne všechny) 64bitové procesory ARM. Odpověď na Meltdown je ve světě ARM stejná jako v případě procesorů x86: izolace tabulek stránek jádra (KPTI), přestože některé podrobnosti se nutně liší. Patche KPTI pro arm64 se dostaly do hlavního stromu jádra během začleňovacího okna 4.16. Jenže systémy založené na ARM jsou proslulé tím, že používají starší jádra, takže přirozeně panuje zájem chránit i je před dotyčnými zranitelnostmi.

Když Shi zaslal backport do 4.9, správce stabilního jádra Greg Kroah-Hartman zareagoval dvojicí otázek: proč samostatný backport, když jaderný strom Android Common už práce na Meltdown obsahuje, a jakým testováním tento backport prošel? V obou případech odpověď poukázala na některé zajímavé stránky, jak funguje ekosystém dodavatelů systémů s ARM.

Jádra LTS a Android Common

Jádra Android Common v rámci Android Open-Source Project spravuje Google. Jsou zamýšlena, aby posloužila jako základ pro jádra konkrétních zařízení. Tato jádra začínají jako jádra s dlouhodobou podporou (LTS), k nimž ale přidávají řadu vlastností charakteristických pro Android, např. plánování beroucí ohled na spotřebu, funkcí, které se nedostaly do hlavního stromu jádra, atd. Také obsahují backporty důležitých funkcí a oprav – včetně oprav Meltdown.

Backport opravy Meltdown zabral docela kus práce a prošel rozsáhlým testováním v jádře Androidu. Kroah-Hartman se obával, že nový backport by nemusel pokrýt všechno nebo neprošel tak rozsáhlým prověřováním jako ten v Androidu, takže možná nepatří mezi to, co by se mělo objevit v LTS jádrech. Analogický případ s x86 by neměl být ukázkovým příkladem, řekl:

Ano, ubastlili jsme příšerný hack v rámci backportů pro x86 (se známými problémy, které tam jsou a které lidé zjevně ignorují, což je šílené) a doporučuji NEdělat stejný druh hacku pro ARM, ale radši si zkuste vzít strom, o kterém všichni víme, že funguje správně, když jste zaseknutí u těchto starých jader!

Háček v tomto podnětu je ten, že jednak ne na každém systému s ARM běží Android a jednak použití jádra Androidu nepomůže dodavatelům, jejichž jádra jsou blíž k hlavnímu stromu. Jak to formuloval Mark Brown:

I když jde o značnou část ekosystému ARM, není to úplně všechno. Navíc tu jsou dodavatelé čipů a integrátoři systémů, kteří cíleně omezují kód mimo hlavní strom, jak je k tomu pobízíme.

Tito dodavatelé by rádi verzi s dlouhodobou podporou omezení Meltdown, která by jim necpala všechny ostatní změny hromadící se v jádrech Androidu. Jak poukázal Brown, čím dál tím víc dodavatelů dělá to, oč je komunita dlouhá léta žádala, totiž drží se co nejblíž k hlavnímu stromu. Neposkytnutí řádného backportu těchto důležitých oprav by mohlo být považováno za porušení slibu, který komunita dala: používejte oficiálně podporovaná stabilní jádra a dostane se vám oprav podstatných problémů.

Je tu tedy pádný důvod, proč by se do LTS jader měly dostat pořádné backporty oprav Meltdown. Zbývá ale menší problém: o pořádném backportu by mělo být známo, že skutečně funguje.

Testování budiž volitelné

Shi odpověděl na Kroah-Hartmanovu otázku týkající se testování všehovšudy takto: „No, já nemám žádné CPU A73/A75, takže chybu meltdown nemůžu reprodukovat.“ Reprodukovat chybu na A73 by byla celkem výzva, protože tento procesor zranitelností Meltdown netrpí, ale A75 ano, takže dotazovat se na výsledky testování na tomto CPU se nezdá až tak zvláštní. Ovšem když Kroah-Hartman opakoval žádost o testování, odpověděl Ard Biesheuvel:

Pokud ARM Ltd. vydá doporučení, které metody PSCI firmwaru se mají zavolat při přepínání kontextu, nebo za jakých okolností se mají použít které instrukce bariér, činí tak proto, že určitá třída zařízení to může v některých případech vyžadovat. Není na mě, abych hledal nějaké exploity na GitHubu, pak je spouštěl před přidáním patche a po něm a na základě toho shledal, že problém je opravený. Místo toho bych měl potvrdit, že ze změn za patřičných okolností plyne provedení doporučených úkonů.

Když si to Kroah-Hartman přečetl, nad skupinou patchů zlomil hůl se stížností: „Nemůžu uvěřit tomu, že se dohadujeme o tom, ať ‚Otestujete, že vaše patche opravdu fungují.‘“ Později dodal, že pokud vývojáři, kteří na tom backportu pracují, nemají ani hardware, ani kód exploitu, „někdo něco dělá vážně špatně.“ Urgoval je, ať si stěžují u ARM Ltd., aby tento problém vyřešili.

V této fázi debata ustala. Není známo, zda je řešení problému s testování na cestě. Dává smysl, aby opravy byly začleněny do LTS jader, jinak se přísliby komunity týkající se těchto jader začnou jevit plané. Ale zároveň dodavatelé, kteří jsou závislí na těchto LTS jádrech, mají právo na opravy, které se někdo opravdu obtěžoval otestovat – každý, kdo někdy déle pracoval na systémovém softwaru, ví, že pouhé ověření, zda řešení odpovídá specifikaci, není zárukou funkčnosti.