Forum: PC Hard- und Software [WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Intel Inside (Gast)


Bewertung
1 lesenswert
nicht lesenswert
[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading
https://lists.debian.org/debian-devel/2017/06/msg00308.html

von T.roll (Gast)


Bewertung
4 lesenswert
nicht lesenswert
So und jetzt liest du deinen Link und schreibst hier eine 
Zusammenfassung. Einfach einen Link ohne weitere Informationen 
reinklatschen ist nicht sehr nett.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Intel SKL150: "Problem: Under complex micro-architectural conditions, 
short loops of less than 64 instructions that use AH, BH, CH or DH 
registers as well as their corresponding wider register (e.g. RAX, EAX 
or AX for AH) may cause unpredictable system behavior. This can only 
happen when both logical processors on the same physical processor are 
active."

C/C++ Code neigt allerdings nicht zu häufiger Verwendung der H Register.

von Funkenflug (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Ich fands ne gute Info.
Danke.

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Nicht der erste Bug solcher Art, und wird auch nicht der letzte bleiben. 
Der Einsatz der ersten Generation einer neuen Mikroarchitektur ist schon 
seit langer Zeit mit gewissen Risiken behaftet. Die enorme Komplexität 
der Implementierungen bleibt nicht ohne Folgen. Bei Haswell durfte man 
die neuen TSX Befehle gleich wieder abschalten und über Ryzen konnte man 
postwendend auch etwas lesen.

Interessant hier ist allerdings die Verzögerung. Immerhin kam Skylake 
schon 2015 raus. Das spricht dafür, dass dieser Bug nur unter sehr 
speziellen und seltenen Randbedingungen auftritt, oder nur dann häufig 
genug auftritt um aufzufallen.

: Bearbeitet durch User
von Kaj (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> dass dieser Bug nur unter sehr
> speziellen und seltenen Randbedingungen auftritt, oder nur dann häufig
> genug auftritt um aufzufallen.
Der OCaml Compiler scheint es leicht genug triggern zu koennen.
1
On 2017-05-29, Mark Shinwell, a core OCaml toolchain developer,
2
contacted the Debian developer responsible for the intel-microcode
3
package with key information about a Intel processor issue that could be
4
easily triggered by the OCaml compiler.
5
6
...
7
8
We do not have enough information at this time to know how much software
9
out there will trigger this specific defect.
10
11
One important point is that the code pattern that triggered the issue in
12
OCaml was present on gcc-generated code.  There were extra constraints
13
being placed on gcc by OCaml, which would explain why gcc apparently
14
rarely generates this pattern.
15
16
The reported effects of the processor defect were: compiler and
17
application crashes, incorrect program behavior, including incorrect
18
program output.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Kaj schrieb:
> Der OCaml Compiler scheint es leicht genug triggern zu koennen.

Ja eben. Aber anscheinend nur der. Wär ja wohl sonst schon früher 
aufgefallen.

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Ausserhalb von OCaml finde ich die Möglichkeit interessant, ob sich 
dieser Bug gezielt für eine side channel attack nutzen lässt. Also ob 
man damit an Daten fremder Prozesse heran kommt, die auf dem anderen 
Thread eines Cores laufen.

: Bearbeitet durch User
von Kaj (Gast)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Ausserhalb von OCaml finde ich die Möglichkeit interessant, ob sich
> dieser Bug gezielt für eine side channel attack nutzen lässt. Also ob
> man damit an Daten fremder Prozesse heran kommt, die auf dem anderen
> Thread eines Cores laufen.
Ich wuerde es nicht ausschliessen.

Mich wuerde interessieren, ob Geheimdienste (NSA) davon wussten und 
vielleicht schon funktionierende Exploits dafuer haben.

Auch wenn die Folge moeglicherweise "nur" Programmabstuerze sind, so 
kann man auch das erfolgreich fuer ein DoS nutzen. Gerade im Zeitalter 
der digitalen Kriegsfuehrung recht interessant.


B2T:

Bugreport:
https://caml.inria.fr/mantis/view.php?id=7452

Interessant wird der Bugreport ab hier:
https://caml.inria.fr/mantis/view.php?id=7452#c17107
1
I indeed cannot reproduce after 1h with a runtime built with -O1,
2
while i can reproduce in less than 10 minutes with an -O2 runtime
3
(built with gcc 6.2)
4
This smells like an UB which is wrongly optimized by gcc and causing
5
issues on newer intel CPUs.
6
7
...

Hab jetzt noch nicht sehr viel weiter gelesen, aber sieht so aus, als ob 
der GCC da vielleicht irgendwo schmu erzeugt?!

https://caml.inria.fr/mantis/view.php?id=7452#c17114
1
To solve our issue in May, we went over from using clang instead of
2
GCC as the base compiler for OCaml and the other parts of our toolchain.
3
4
Since that switch, no such random crash came up (and we have one Skylake
5
machine that runs longer regression tests in an endless loop the whole
6
year, nothing to be seen after clang usage, daily crashs before)
7
8
The question is if it is feasible for you to:
9
10
a) try clang, too
11
b) if that works, try to search for the difference in e.g. the
12
produced assembly


https://caml.inria.fr/mantis/view.php?id=7452#c17834
1
This problem also affects Kaby Lake systems (erratum KBL095); however,
2
I'm unsure if a microcode fix has been released publicly for such
3
systems. The best solution is to disable hyperthreading for the moment.
4
5
Yesterday Fred and I experimented on a Kaby Lake machine by changing
6
the generated assembly from GCC for major_gc.c so that it didn't
7
reference registers such as %ah. The problem was not reproducible
8
after that change, whereas it was almost immediately reproducible before.

Ist an den H-Registern irgendwas besonderes dran?

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Kaj schrieb:
> Ist an den H-Registern irgendwas besonderes dran?

Sie sitzen nicht dort, wo alle anderen Register sitzen, nämlich ab Bit 0 
aufwärts im vollen Register.

Seit die H-Register nur noch selten direkt angesprochen werden, werden 
Operationen damit u.U. anders ausgeführt als mit dem L-Registern. Das 
vereinfacht die internen Operationen und kann zu zusätzlichen µOps 
führen.

Ein aktueller Compiler dürfte die üblicherweise nur verwenden, wenn eine 
Art Bitfeldoperation dadurch effizienter wird (egal ob echtes Bitfeld 
oder Shift&Mask). Zumal das u.U. zwar den Code verkürzt, aber die 
Laufzeit verlängert.

: Bearbeitet durch User
von Yalu X. (yalu) (Moderator)


Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Ein aktueller Compiler dürfte die üblicherweise nur verwenden, wenn eine
> Art Bitfeldoperation dadurch effizienter wird

Er könnte sie bspw. auch dann verwenden, wenn in einem Programmabschnitt
sehr viele 8-Bit-Variablen benötigt werden. Allerdings würde das die
Registerzuteilung für den Compiler verkomplizieren: Ohne die Verwendung
der H-Registerteile ist zu jedem Zeitpunkt ein Register entweder belegt
oder nicht. Mit Verwendung der H-Registerteile kann ein Register auch
doppelt, nämlich mit zwei 8-Bit-Werten, belegt werden. Da haben die
GCC-Entwickler wohl lieber auf die vier zusätzlichen Byte-Register
verzichtet.

Das heißt natürlich nicht, das dieses Feature nicht von anderen
Compilern gewinnbringend genutzt werden könnte. Der OCamL-Compiler ist
offensichtlich einer davon.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> Er könnte sie bspw. auch dann verwenden, wenn in einem Programmabschnitt
> sehr viele 8-Bit-Variablen benötigt werden.

Theoretisch ja, aber das dürfte kaum ein aktueller Compiler der 
32/64-Bit Klasse tun. Es wäre ein Schuss ins Knie, da in den internen 
Operationen der Prozessoren die einzelnen Teile eines Gesamtregisters 
auch ohne Überlappung voneinander abhängig sind.

Was genau OCaml da tut wird leider nicht berichtet.

von Kaj (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Steht zwar nichts genaueres drin, aber trotzdem:

Bug in aktuellen Intel-Prozessoren macht die Runde
https://www.heise.de/newsticker/meldung/Bug-in-aktuellen-Intel-Prozessoren-macht-die-Runde-3755660.html

von Nick S. (c0re)


Bewertung
0 lesenswert
nicht lesenswert
Kaj schrieb:
> Steht zwar nichts genaueres drin, aber trotzdem:
>
> Bug in aktuellen Intel-Prozessoren macht die Runde
> https://www.heise.de/newsticker/meldung/Bug-in-akt...

ist auch bei Golem angekommen
https://www.golem.de/news/skylake-und-kaby-lake-debian-warnt-vor-alptraum-bug-in-intel-cpus-1706-128582.html

von Da D. (dieter)


Bewertung
0 lesenswert
nicht lesenswert
Wie kann ich denn genau überprüfen, ob mein Prozessor betroffen ist?

von (prx) A. K. (prx)


Bewertung
2 lesenswert
nicht lesenswert
Da D. schrieb:
> Wie kann ich denn genau überprüfen, ob mein Prozessor betroffen ist?

http://ark.intel.com/products/codename/37572/Skylake
http://ark.intel.com/products/codename/82879/Kaby-Lake

Ausgenommen jene ohne Hyperthreading.

von Da D. (dieter)


Bewertung
0 lesenswert
nicht lesenswert
Ok, danke. Meine CPU gehört demnach zur Skylake Architektur. Da alle 
Prozessoren mit HT betroffen sind (das war mir vorhin noch nicht klar), 
bin ich also betroffen.

Ich schau da so genau hin, weil ich auf dem aktuellen Rechner immer 
wieder mal Bluescreens habe. Selbst mit Fabrikneuer Windows 
installation. Hardware wurde auch schon ausgetauscht. Evtl. hat ja ein 
Lenovotreiber auch eine kritische Codesequenz. Ich werd mal 
Hyperthreading abschalten, und schauen, ob sich was verbessert.

Wie groß ist denn die zu erwartende Leistungseinbuße, wenn 
Hyperthreading deaktiviert ist?

: Bearbeitet durch User
von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Da D. schrieb:
> Wie groß ist denn die zu erwartende Leistungseinbuße, wenn
> Hyperthreading deaktiviert ist?

Bei einem Dualcore mit 4 Threads wird das spürbarer sein als bei einem 
Quadcore mit 8 Threads. Ansonsten hängt das völlig von deinen 
Anwendungen ab. Wenn da keine dabei ist, die wirklich intensiv 
Multithreading macht, dann wirst du auf einem Quadcore praktisch nichts 
davon merken.

Beitrag #5055810 wurde vom Autor gelöscht.
von H-G S. (haenschen)


Bewertung
-4 lesenswert
nicht lesenswert
Vielleicht ist es ein "strategischer" Bug, mit dem Ziel bestimmte 
Entwicklungsumgebungen etc. zu bevorteilen.

von H. K. (spearfish)


Bewertung
0 lesenswert
nicht lesenswert
Ich halte diese Warnung von Debian massiv übertrieben. Scheinbar tritt 
der Fehler nur unter ganz bestimmten und speziellen Randbedingungen auf 
und es ist überhaupt nicht vorhersehbar, ob bestehende Systeme, die 
bisher funktioniert haben, nicht mehr funktionieren... HT abschalten und 
Performanceeinbußen zu riskieren ist wohl "schlimmer" als diesem Bug zu 
begegnen.

Wenn der Bug wirklich so schlimm wäre, müsste er ja in anderen komplexen 
Programmen (z.B. im Linux Kernel, Apache, GCC...) ja schon längst 
aufgefallen sein und reihenweise Systeme zum Absturz gebracht haben.

von (prx) A. K. (prx)


Bewertung
1 lesenswert
nicht lesenswert
H-G S. schrieb:
> Vielleicht ist es ein "strategischer" Bug, mit dem Ziel bestimmte
> Entwicklungsumgebungen etc. zu bevorteilen.

;-)

Solche Bugs geschehen einfach. Das ist unschön, aber angesichts der 
Komplexität sind Bugs unvermeidlich. Auch solche, die existierende 
Programme betreffen. Die meisten CPU-Bugs sind aber an sehr spezielle 
Randbedingungen gebunden, so dass sie in der Praxis meist nicht 
auftreten. Aber manche eben schon.

AMD hatte beim ersten K6 einen ziemlichen Bock geschossen, der erst 
auffiel, wenn die Kiste mindestens 32MB RAM hatte. Öffentlich wurde er, 
als die Leute beim Compilieren vom Linux-Kernel dermassen oft auf die 
Nase fielen, dass es zum Himmel stank.

Es stellte sich heraus, dass der Bug schon in AMDs Liste stand, aber arg 
subtil formuliert. Weil der nur im Zusammenhang mit der Erkennung von 
self modifying code aufträte. Und wer macht denn sowas? Nachdem die 
Nummer aufflog stand eine Weile lang ein etwas erhellenderer Text drin: 
Die Erkennung verwendet nur einen Teil der Adressbits, nimmt also 
Fehlerkennung in Kauf.

Peinlicher war freilich der bekannte Divisionsfehler von Intels Pentium. 
Der überhaupt erst dazu führte, dass Buglisten öffentlich wurden. Davor 
waren sie nur per NDA zu erhalten. Peinlich deshalb, weil der nicht 
durch unglückliches Zusammenspiel diverser Zustände auftrat, sondern ein 
dummer Flüchtigkeitsfehler war.

Dieser Bug kostete Intel ca 0.5 Mrd $. Nein, solche Bugs baut man 
definitiv nicht vorsätzlich ein. Den P90, mit dem ich an der Sache 
mitmischte, habe ich freilich nie getauscht. Der spielte später noch 
jahrelang einen DSL-Router.

: Bearbeitet durch User
von Yalu X. (yalu) (Moderator)


Bewertung
2 lesenswert
nicht lesenswert
H. K. schrieb:
> Ich halte diese Warnung von Debian massiv übertrieben.

Ob sich der Fehler bemerkbar macht, hängt halt davon ab, welche Software
du häufig benutzt. Wenn du bisher nie von sporadisch auftretenden,
unerklärlichen Fehlern betroffen warst, wird das wahrscheinlich auch in
Zukunft so bleiben. Bei den OCaml-Nutzern trat das Problem aber gehäuft
auf, was dann irgendwann schon etwas nervig werden kann.

Auch die Performanceeinbußen durch des Abschaltens des Hyper-Threading
sind stark von den Nutzungsgewohnheiten abhängig. Hast du bspw. einen
Prozessor mit vier Cores und verwendest kaum multi-threaded Programme,
so dass selten mehr als vier Threads simultan laufen, wirst du keinen
Unterschied merken.

Da muss also jeder für sich einen sinnvollen Kompromiss finden.

Auf der anderen Seite scheint das Problem ja für einige Prozessortypen
durch das aktuelle Microcode-Update von Intel bereits behoben zu sein.
Man kann wahrscheinlich davon ausgehen, dass entsprechende Updates auch
für die anderen betroffenen Typen folgen werden.

: Bearbeitet durch Moderator
von Intel Inside (Gast)


Bewertung
0 lesenswert
nicht lesenswert

von Erwin M. (nobodyy)


Bewertung
0 lesenswert
nicht lesenswert
Es gibt für viele Mainboards neue BIOSe/UEFIs. Nach dem Update von 
meinem, ein X11SAE, hat es mit neuem Microcode den Bugfix.

von H-G S. (haenschen)


Bewertung
-2 lesenswert
nicht lesenswert
Ist es vielleicht ein Obsoleszenz-fördernder Bug ?

Läuft alte Software noch ?

von Matthias S. (Firma: matzetronics) (mschoeldgen)


Bewertung
2 lesenswert
nicht lesenswert
H-G S. schrieb:
> Ist es vielleicht ein Obsoleszenz-fördernder Bug ?

Nein, es ist sicher keine Verschwörung. Intel weiss sehr wohl, das sich 
solche Hardware Bugs nicht positiv auf die Position eines Unternehmens 
an der Börse auswirken und war ja auch mit Microcode Updates nicht 
wirklich langsam.
Der FDIV Bug damals war wirklich eine Kleinigkeit und so gut wie kein 
User ausser ein paar Astronomen hat Schaden genommen (und nicht mal 
das), trotzdem machte er sich nicht gut im Portfolio des Unternehmens.

von (prx) A. K. (prx)


Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Der FDIV Bug damals war wirklich eine Kleinigkeit und so gut wie kein
> User ausser ein paar Astronomen hat Schaden genommen (und nicht mal
> das), trotzdem machte er sich nicht gut im Portfolio des Unternehmens.

Die Prozessoren wurden auf Anfrage kostenlos getauscht. Allerdings war 
etwas Überzeugungsarbeit nötig, es war nicht wirklich Intels Idee. Am 
ärgerlichsten fanden viele Leute freilich Intels Geheimniskrämerei und 
den fortgesetzten Verkauf trotz bereits bekanntem Defekt.

: Bearbeitet durch User
von Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Matthias S. schrieb:
> Der FDIV Bug damals war wirklich eine Kleinigkeit

Technisch gesehen war dies vielleicht so, aber damals hatte Apple diesen 
Bug in der Werbung ganz massiv ausgenutzt und damit Stimmung gegen 
x86-basierte Rechner verbreitet.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.