[WARNING] Intel Skylake/Kaby Lake processors: broken hyper-threading https://lists.debian.org/debian-devel/2017/06/msg00308.html
So und jetzt liest du deinen Link und schreibst hier eine Zusammenfassung. Einfach einen Link ohne weitere Informationen reinklatschen ist nicht sehr nett.
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.
Ich fands ne gute Info. Danke.
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
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. |
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
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
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?
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
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.
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.
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
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
Wie kann ich denn genau überprüfen, ob mein Prozessor betroffen ist?
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.
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
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.
Vielleicht ist es ein "strategischer" Bug, mit dem Ziel bestimmte Entwicklungsumgebungen etc. zu bevorteilen.
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.
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
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
CPU-Bug: Wie der Albtraum-Bug in Skylake gefunden wurde https://www.golem.de/news/cpu-bug-wie-der-albtraum-bug-in-skylake-gefunden-wurde-1706-128662.html Skylake bug: a detective story https://medium.com/ahrefs/skylake-bug-a-detective-story-ab1ad2beddcd
Es gibt für viele Mainboards neue BIOSe/UEFIs. Nach dem Update von meinem, ein X11SAE, hat es mit neuem Microcode den Bugfix.
Ist es vielleicht ein Obsoleszenz-fördernder Bug ? Läuft alte Software noch ?
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.
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
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.