AMD untersucht eine mit Zen 3 eingeführte Spectre-like Schwachstelle

Im Gro­ßen und Gan­zen hat die neue Zen-3-Archi­tek­tur von AMD viel Lob ein­ge­heimst: aber­mals ver­bes­ser­te IPC bei gleich geblie­be­nem Takt, deut­lich ver­bes­ser­te Spie­le-Per­for­mance dank über­ar­bei­te­ter Cache-Archi­tek­tur, etli­che neue Fea­tures und Funk­tio­nen und das alles bei erheb­lich nied­ri­ge­rem Strom­ver­brauch trotz höhe­rer Anzahl an Ker­nen gegen­über den jüngs­ten Intel-CPUs.

Doch es gab auch ein paar schie­fe Zwi­schen­tö­ne. Da wäre zum einen die man­gel­haf­te Ver­füg­bar­keit der Ryzen 5000. Dafür zeig­ten Kun­den und Medi­en aller­dings wei­test­ge­hend Ver­ständ­nis. Wer fremd­fer­ti­gen lässt wie AMD es tut und sich im Vor­feld auf eine bestimm­te Anzahl an Wafer fest­le­gen muss, die er bucht, fin­det sich dann eben in der Fal­le, wenn ein Pro­dukt auf­grund guter Leis­tun­gen stär­ker nach­ge­fragt wird als vermutet/erhofft. Mit ein­zel­nen Model­len wird das erst jetzt, mehr als 4 Mona­te nach der Markt­ein­füh­rung, lang­sam bes­ser. Noch immer liegt der Stra­ßen­preis jedoch über der UVP.

Der zwei­te Punkt betrifft die Aspek­te WHEA-Errors im Event­log ggf. flan­kiert von Abstür­zen, sowie USB-Pro­ble­men mit den neu­en Chip­sät­zen der 500er Serie, die womög­lich ihren gemein­sa­men Ursprung in den erwei­ter­ten Strom­spar­tech­ni­ken haben, die mit Zen 3 ein­ge­führt wur­den. AMD unter­sucht das gera­de und die letz­ten AGE­SA-Ver­sio­nen brach­ten wohl Lin­de­rung, was zeigt, dass AMD auf der rich­ti­gen Spur ist.

Nun jedoch hat AMD selbst ein White­pa­per ver­öf­fent­licht, aus­ge­rech­net zur Markt­ein­füh­rung der Ser­ver-Ver­si­on von Zen 3 namens Milan, das eine mit Zen 3 neu ein­ge­führ­te Schwach­stel­le beschreibt, die ähn­lich wie Spect­re V4 ein­zu­stu­fen ist. Wir erin­nern uns: Anfang 2018 wur­de eine neue Klas­se an Schwach­stel­len in moder­nen Pro­zes­so­ren bekannt, die deren leis­tungs­stei­gern­de Fea­tures wie Spe­cu­la­ti­ve Exe­cu­ti­on, Branch Pre­dic­tion und Out of Order Exe­cu­ti­on für Sei­ten­ka­nal-Angrif­fe aus­nut­zen. Inzwi­schen sind ein Dut­zend die­ser Schwach­stel­len in bestimm­ten Vari­an­ten bekannt. Ziel ist es dabei stets, Daten eines Tasks, Pro­zes­ses oder einer Instanz abzu­grei­fen, auf den/die man eigent­lich kei­nen Zugriff haben sollte.

Wäh­rend Zen 3 und Zen 2 eini­ge Miti­ga­tio­nen in Hard­ware erhiel­ten zur Absi­che­rung gegen die alten, bekann­ten Spect­re-like Lücken, hat AMD bei Zen 3 offen­bar eine neue Schwach­stel­le auf­ge­ris­sen. Die Rede ist dabei von Pre­dic­ti­ve Store For­war­ding (PSF), eine Tech­no­lo­gie, die ein­ge­führt wur­de, um Abhän­gig­kei­ten zwi­schen Load und Store auf­zu­lö­sen und dem Pro­zes­sor damit die Mög­lich­keit zu eröff­nen, spe­ku­la­tiv wei­ter vor­aus­zu­rech­nen mit dem Ziel, die Leis­tung zu erhö­hen. Die­ses Fea­ture schafft jedoch laut AMD zwei Mög­lich­kei­ten für einen Angrei­fer ähn­lich wie bei Spect­re V4 über Umwe­ge an Daten zu gelan­gen, die ihn nichts angehen:

CAUSES OF INCORRECT PSF
Incor­rect PSF pre­dic­tions can occur due to at least the fol­lo­wing two reasons. First, it is pos­si­ble that the store/load pair had a depen­den­cy for a while but later stops having a depen­den­cy. This can occur if the address of eit­her the store or load chan­ges during the exe­cu­ti­on of the program.

The second source of incor­rect PSF pre­dic­tions can occur if the­re is an ali­as in the PSF pre­dic­tor struc­tu­re. The PSF pre­dic­tor is desi­gned to track stores/load pairs based on por­ti­ons of their RIP. It is pos­si­ble that a store/load pair which does have a depen­den­cy may ali­as in the pre­dic­tor with ano­ther store/load pair which does not. This may result in incor­rect spe­cu­la­ti­on when the second store/load pair is executed.

[..]
SECURITY ANALYSIS
Pre­vious rese­arch has shown that when CPUs spe­cu­la­te on non-archi­tec­tu­ral paths it can lead to the poten­ti­al of side chan­nel attacks. In par­ti­cu­lar, pro­grams that imple­ment iso­la­ti­on, also known as ‘sand­boxing’, enti­re­ly in soft­ware may need to be con­cer­ned with incor­rect CPU spe­cu­la­ti­on, which can occur due to bad PSF predictions.

Becau­se PSF spe­cu­la­ti­on is limi­t­ed to the cur­rent pro­gram con­text, the impact of bad PSF spe­cu­la­ti­on is simi­lar to that of spe­cu­la­ti­ve store bypass (e.g., Spect­re v4). In both cases, a secu­ri­ty con­cern ari­ses if code exists that imple­ments some kind of secu­ri­ty con­trol which can be bypas­sed when the CPU spe­cu­la­tes incor­rect­ly. This may occur if a pro­gram (such as a web brow­ser) hosts pie­ces of untrus­ted code and the untrus­ted code is able to influence how the CPU spe­cu­la­tes in other regi­ons in a way that results in data leaka­ge. This is simi­lar to the secu­ri­ty risk with other Spect­re-type attacks.

In dem White­pa­per beschreibt AMD auch, wie PSF per MSR-Regis­ter-Ände­run­gen deak­ti­viert wer­den kann, emp­fiehlt jedoch nicht, dies gene­rell zu tun.

In der Zwi­schen­zeit hat die auf Linux spe­zia­li­sier­te Web­sei­te Pho­ro­nix eini­ge Tests durch­ge­führt mit akti­vier­tem und deak­ti­vier­tem PSF. Die­se zei­gen im Mit­tel eine ver­nach­läs­sig­ba­re Aus­wir­kung auf die Per­for­mance (59,38 vs. 59,19, also nicht ein­mal 1 Pro­zent). Bei ein­zel­nen Auf­ga­ben kön­nen die Aus­wir­kun­gen aller­dings durch­aus grö­ßer sein, die Ein­zel­wer­te der Bench­mark-Suite hat Pho­ro­nix lei­der nicht ein­zeln aufgeschlüsselt.