AMD gibt Programmierleitfaden gegen Spectre heraus

Gestern hat Leser skel­le­tor im Forum ein neu­es White­pa­per von AMD ent­deckt, wel­ches Pro­gram­mie­rern und Com­pi­ler­ent­wick­lern eini­ge Tech­ni­ken an die Hand geben soll, wie die Angriffs­sze­na­ri­en Spect­re 1 und 2 auf AMD-Pro­zes­so­ren erschwert wer­den kön­nen. Von Melt­down ist AMD auf­grund der Archi­tek­tur-Unter­schie­de zu Intel bekannt­lich nicht betrof­fen. Bei Spect­re jedoch ist auch bei AMD-Pro­zes­so­ren zumin­dest die Mög­lich­keit gege­ben, die Lücke aus­zu­nut­zen, auch wenn AMD sie im Fal­le von Vari­an­te 2 mit “nahe Null” angibt.

Wer einen Blick in den Leit­fa­den wirft, fin­det eine gan­ze Palet­te an Vor­schlä­gen. So sol­len z.B. Regis­ter geleert wer­den sobald sie nicht mehr benö­tigt wer­den, der Befehl LFENCE soll genutzt wer­den, um Lade­ope­ra­tio­nen seri­ell durch­zu­füh­ren und es wird anhand eines Bei­spiels gezeigt, wie Ret­po­li­ne, Goo­gles Vor­schlag zur Mil­de­rung von Spect­re 2, in der Pro­gram­mier­pra­xis umge­setzt wer­den kann; im White­pa­per V2‑1 genannt.

Der Vor­teil von Ret­po­li­ne wäre, dass die AMD-Pro­zes­so­ren – im Gegen­satz zu Intel – ohne wei­te­re Micro­code-Updates aus­kä­men. Es müss­ten also weder BIOS-Updates gegen Spect­re 2 geschnürt und ver­teilt, noch Micro­code-Updates in Linux Repo­si­to­rys aus­ge­rollt wer­den. Es zeich­net sich ab, dass Ret­po­li­ne der bevor­zug­te Weg in der Linux-Welt wer­den wird, wäh­rend sich Micro­soft in sei­nen bis­he­ri­gen Win­dows-Updates auf eine ande­re Vari­an­te kon­zen­triert, im White­pa­per V2‑4 genannt. Die­se setzt neue CPU-Befeh­le vor­aus – Indi­rect Branch Rest­ric­ted Spe­cu­la­ti­on (IBRS), Sin­gle Thread Indi­rect Branch Pre­dic­tors (STIBP) und Indi­rect Branch Pre­dic­tor Bar­ri­er (IBPB) – ist damit nur mit­tels Micro­code-Update und/oder neu­er CPUs mach­bar und kos­tet je nach CPU-Gene­ra­ti­on mal mehr mal weni­ger an Leistung.

Aus die­sem Grund spricht sich AMD im Fazit deut­lich für Ret­po­li­ne als Lösungs­weg gegen Spect­re 2 aus, schließ­lich käme man dann ohne wei­te­re Micro­code-Updates aus:

AMD is ali­gned with the x86 com­mu­ni­ty that V1‑1 (lfence) is the pre­fer­red vari­ant 1 soft­ware solu­ti­on and that the V2‑1 (ret­po­li­ne) is the pre­fer­red vari­ant 2 soft­ware solu­ti­on. AMD con­ti­nues to eva­lua­te oppor­tu­ni­ties for new miti­ga­ti­ons in both the x86 ISA and micro-archi­tec­tu­re for future AMD processors.

Ob Micro­soft jedoch noch ein­mal umschwen­ken wird, darf zumin­dest bezwei­felt wer­den. Soll­te Intel jedoch sei­ne Micro­code-Updates nicht zeit­nah hin­krie­gen – der ers­te Ver­such muss­te nach Insta­bi­li­tä­ten bereits wie­der zurück­ge­zo­gen wer­den – wäre Micro­soft womög­lich gezwun­gen dazu. Ins­be­son­de­re Linux-Chef­stra­te­ge Linus Tor­valds hat sich kürz­lich deut­lich (“The patches are COMPLETE AND UTTER GARBAGE”) zu den bis­her abge­lie­fer­ten Patches geäußert.

Von Ker­nel­ent­wick­ler Ingo Molnár exis­tiert mitt­ler­wei­le noch ein wei­te­rer Vor­schlag, der der­zeit unter­sucht wird, eine Ergän­zung, um Ret­po­li­ne auch auf anschei­nend beson­ders gefähr­de­ten*) Intel-Sky­la­ke-CPUs nutz­bar zu machen. Die­ser käme ohne Micro­code-Updates aus und wür­de auf einen bereits in den meis­ten Ker­nels ent­hal­te­nen CONFIG_FUNCTION_TRACER fußen:

Note the huge num­ber of advantages:

— All dis­tro ker­nels alre­a­dy enable the mcount based patching opti­ons, so there’s lite­ral­ly zero over­head to any­thing except SkyLake.

— It is ful­ly ker­nel patching based and can be acti­va­ted on Sky­la­ke only

— It does­n’t requi­re any micro­code updates, so it will work on all exis­ting CPUs with no firm­ware or micro­code modificatons

— It does­n’t requi­re any com­pi­ler updates

— Sky­La­ke per­for­mance is very likely to be much less fra­gi­le than rely­ing on a hasti­ly deploy­ed micro­code hack

— The “Sky­La­ke stack depth tra­cer” can be tes­ted on other CPUs as well in debug builds, broa­de­ning the test­ing base

— The tra­cer is very obvious­ly simp­le and reviewa­ble, and we can for­get about it in the far future.

— It’s much more back­por­ta­ble to older ker­nels: should the­re be a new class of exploits then this machi­nery could be updated to cover that too — while upgrades to newer ker­nels would give the hig­her per­for­mant solution.

Der Lösungs­weg wird der­zeit noch eva­lu­iert und ist bis­her noch nicht imple­men­tiert worden.

*) David Wood­house: “Then there’s Sky­la­ke, and that gene­ra­ti­on of CPU cores. For com­pli­ca­ted reasons they actual­ly end up being vul­nerable not just on indi­rect bran­ches, but also on a ‘ret’ in some cir­cum­s­tances (such as 16+ CALLs in a deep chain).”