Meltdown & Spectre: Sicherheitsrisiken durch Spekulation bei aktuellen Prozessoren [Archiv] - Seite 9

Linmoum

2018-05-08, 19:24:47

Zu Spectre: Es wird mit Zen2 hardwareseitig entsprechende Anpassungen für solche Sicherheitslücken geben.

We continue to believe that Variant 2 of Spectre is difficult to exploit on AMD processors. However, we are deploying CPU microcode patches that in combination with OS updates provide additional mitigation steps. Longer term, we have included changes in our future processor cores, starting with our Zen 2 design, to further address potential Spectre like exploits. We continue to collaborate closely with the industry on these vulnerabilities and are committed to protecting AMD users from these and other security threats as they arise.
https://www.computerbase.de/2018-01/amd-quartalszahlen-ryzen-radeon-mining/

Zu Spectre-NG: Ist noch recht unübersichtlich und nach aktuellem Kenntnisstand auch unklar, ob Ryzen davon betroffen ist. Stand jetzt erst einmal Intel, alles weitere wird man dann zu entsprechender Zeit sicherlich auch öffentlich mitbekommen.

maximus_hertus

2018-05-08, 19:49:02

Da du einen Hersteller nicht verpflichten kannst ein Produkt auf Lebenszeit zu unterstützen, geht schon das mit der "Frist setzen" nicht.

Es geht nicht um eine "Standard-Unterstützung", es geht um elementare Eigenschaften. Das Produkt ist jetzt ein komplett anderes (bei Nutzung von VMs möglicherweise unbrauchbar) als ursprünglich im "Kaufvertrag".

Effe

2018-05-08, 19:51:03

Für die neuen Spectre Ableger hätte ich noch schöne Namen im Angebot: Blinky, Pinky, Inky & Clyde. ;)
Ich warte auf „Goldfinger“ und „Fireball“.

Ganon

2018-05-08, 20:03:53

Es geht nicht um eine "Standard-Unterstützung", es geht um elementare Eigenschaften. Das Produkt ist jetzt ein komplett anderes (bei Nutzung von VMs möglicherweise unbrauchbar) als ursprünglich im "Kaufvertrag".

Auch solche Dinge gelten nicht auf Lebenszeit. Microsoft patcht ja auch keine Lücken mehr in alten Windows-Versionen. Die Hersteller von Smartphones und Tablets liefern dir keine Updates mehr nach gewisser Zeit. Damit werden all diese Produkte auch unbenutzbar für bestimmte Einsatzzwecke. Und die Lücken die dort in Hard- und Software gefunden werden, bestehen ja auch schon seit Anbeginn.

Nebenbei besteht auch weiterhin bereits ein umfassender Schutz in Linux, vollkommen ohne irgendwelche Microcode-Updates.

D.h. auch die Leute die Aktionen von Intel fordern werden immer weniger je näher du das eigentliche Problem betrachtest.

Ätznatron

2018-05-08, 20:49:47

Witzig, dass erstmal Software wie Linux (Verbreitungsgrad im nichtkommerziellen Bereich?) Intels elementare Hardwareschwäche ausgleichen muss.

Ganon

2018-05-08, 20:51:34

Mehr Infos zu SpectreNG (?) aus einem Patch für DragonflyBSD:

https://www.phoronix.com/scan.php?page=news_item&px=DragonFly-Spectre-CVE-2018-8897
http://anzwix.com/a/DragonFlyBSD/Kernel%20-%20Fix%20CVE-2018-8897,%20Debug%20Register%20Issue

CVE-2018-8897 isn't yet public and given it was part of this other Spectre activity makes us wonder if this is part of what was recently rumored as "Spectre-NG" for a new class of CPU vulnerabilities.
The patch in question does credit Microsoft for coordinating the vendor response (a.k.a. just not a DragonFly kernel security issue) and that the original reporter to this CPU issue was an Everdox Tech LLC

kernel - Fix CVE-2018-8897, debug register issue

- #DB can be delayed in a way that causes it to occur on the first instruction of the int $3 or syscall handlers. These handlers must be able to detect and handle the condition. This is a historical artifact of cpu operation that has existed for a very long time on both AMD and Intel CPUs.

- Fix by giving #DB its own trampoline stack and a way to load a deterministic %gs and %cr3 independent of the normal CS check. This is CVE-2018-8897.

Ätznatron

2018-05-08, 20:55:54

Ändert doch nichts an der Intelschwäche.

LadyWhirlwind

2018-05-08, 20:59:58

Wobei man auch sagen muss, Lücken in der Hardware zu suchen wird erst Interessant, wenn man nicht mehr so einfach Lücken in der Software findet, die man nutzen kann. Und ja, Linux als relativ sichere Software ist da natürlich gefährdeter als ein OS das sowieso löcherig wie ein Emmentaler ist.

Was meiner Meinung nach im Moment ein bisschen zu fest vermischt wird, sind konkrete Lücken und theoretische Möglichkeiten wie man einen Prozessor angreifen könnte. Seitenkanalattacken sind schon seit einigen Jahren bekannt, aber es hat bis vor ein paar Monaten gedauert, bis man damit bei CPUs Schaden anrichten konnte. Im Moment wissen wir nicht, ob Spektre.NG auf neuen Prinzipien beruht oder ob es sich dabei um eine weitere Variante bestehender Angriffe handelt die sich effektiv umsetzten lässt. Zwischen theoretischen Möglichkeiten und praktischer Anwendung steht ja je nach dem immer noch eine gewisse Hürde.

maximus_hertus

2018-05-08, 21:04:27

Auch solche Dinge gelten nicht auf Lebenszeit. Microsoft patcht ja auch keine Lücken mehr in alten Windows-Versionen. Die Hersteller von Smartphones und Tablets liefern dir keine Updates mehr nach gewisser Zeit. Damit werden all diese Produkte auch unbenutzbar für bestimmte Einsatzzwecke. Und die Lücken die dort in Hard- und Software gefunden werden, bestehen ja auch schon seit Anbeginn.

Nebenbei besteht auch weiterhin bereits ein umfassender Schutz in Linux, vollkommen ohne irgendwelche Microcode-Updates.

D.h. auch die Leute die Aktionen von Intel fordern werden immer weniger je näher du das eigentliche Problem betrachtest.

Zu MS: Da gibt es dann (schon lange) Nachfolger, die entsprechend gepatcht sind. By the way, es gibt monatliche Updates für mindestens 10 Jahre und selbst darüber hinaus werden sehr kritische Lücken durchaus gefixt.

Dazu kommt das Intel Versprechen von Anfang Januar, dass bis Ende Januar alles gefixt ist. Stand heute ist das nicht wirklich der Fall, gerade "altere" CPUs (vor 2015) sahen bzw. sehen keine EFI/Microcode-Updates (durch die Hersteller/OEMs).

Zu Linux kann ich nicht so viel sagen, abgesehen von der ein oder anderen (Test)VM habe ich damit bisher weniger Berührung. Mein Kentnisstand ist noch dieser hier:

Retpoline funktioniert aber nicht in allen Fällen. Besonders beim Wechsel zwischen virtuellen Maschinen müssen stattdessen die von Intel bereitgestellten Flags verwendet werden, etwa IBPB, die nicht nur von Linux 4.16rc1, sondern auch von 4.15.2 und 4.14.18 genutzt werden, sofern Intel einen funktionierenden Microcode bereitstellt. Seit dem 8. Februar 2018 gibt es Microcode-Updates für Sky-Lake-Prozessoren, nachdem Intel zuvor fehlerhafte Aktualisierungen wieder zurückgezogen hatte.

Aber ich will da kein zu großes Fass aufmachen, da ich mich damit wohl auf sehr brüchigem Eis begebe ;)

Ich bin gespannt wie es weitergeht und vor allem wie die Medien damit umgehen.

Edit: Danke für die Links bzw. Quotes.

Ganon

2018-05-08, 21:11:24

Zu MS: Da gibt es dann (schon lange) Nachfolger, die entsprechend gepatcht sind. By the way, es gibt monatliche Updates für mindestens 10 Jahre und selbst darüber hinaus werden sehr kritische Lücken durchaus gefixt.

Auch für Intel CPUs gibt's Nachfolger ohne Lücken ;) Und das MS alte Windows-Versionen die aus dem Support längst raus sind ist _sehr_ selten. Normalerweise ist alles tot ohne Support. Also z.B. XP oder Vista.

Dazu kommt das Intel Versprechen von Anfang Januar, dass bis Ende Januar alles gefixt ist. Stand heute ist das nicht wirklich der Fall, gerade "altere" CPUs (vor 2015) sahen bzw. sehen keine EFI/Microcode-Updates (durch die Hersteller/OEMs).

Wenn Intel ein Microcode Update bereitstellt, dann hat Intel seine Bringschuld getan. Wenn dein Board-Hersteller es dir nicht gibt, dann ist das nicht Intels Schuld. Nebenbei kannst du das Microcode Update auch über das OS einspielen. "Neuerdings" sogar unter Windows. Ich glaube aktuell zurück bis Haswell aus dem Jahr 2013.

Ansonsten zu der VM-Geschichte bin ich auch nicht mehr auf dem aktuellen Stand. Es gab verdammt viele Updates in KVM/QEMU hinsichtlich der ganzen Lücken und es folgen immer weitere Updates und Optimierungen rund um Meltdown/Spectre.

LadyWhirlwind

2018-05-08, 21:17:23

Ich bin auch gar nicht so sicher, ob es bei Server-Systemen auch so schlecht aussieht, oder ob es halt "nur" "Consumer"-Geräte sind die, wenn sie ein bisschen älter sind, keine Patches mehr erhalten.

Edit: Hat wahrscheinlich nichts direkt damit zu tun, taucht nur heute auf, weil MS die Veröffentlichung für den heutigen Patch-Day koordiniert hat.
A statement in the System Programming Guide of the Intel 64 and IA-32 Architectures Software Developer's Manual (SDM) was mishandled in the development of some or all operating-system kernels, resulting in unexpected behavior for #DB exceptions that are deferred by MOV SS or POP SS, as demonstrated by (for example) privilege escalation in Windows, macOS, some Xen configurations, or FreeBSD, or a Linux kernel crash. The MOV to SS and POP SS instructions inhibit interrupts (including NMIs), data breakpoints, and single step trap exceptions until the instruction boundary following the next instruction (SDM Vol. 3A; section 6.8.3). (The inhibited data breakpoints are those on memory accessed by the MOV to SS or POP to SS instruction itself.) Note that debug exceptions are not inhibited by the interrupt enable (EFLAGS.IF) system flag (SDM Vol. 3A; section 2.3). If the instruction following the MOV to SS or POP to SS instruction is an instruction like SYSCALL, SYSENTER, INT 3, etc. that transfers control to the operating system at CPL < 3, the debug exception is delivered after the transfer to CPL < 3 is complete. OS kernels may not expect this order of events and may therefore experience unexpected behavior when it occurs.
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-8897

Complicated

2018-05-08, 23:02:34

Wenn Intel ein Microcode Update bereitstellt, dann hat Intel seine Bringschuld getan. Wenn dein Board-Hersteller es dir nicht gibt, dann ist das nicht Intels Schuld.
Wenn das bereitgestellte Update fehlerhaft ist und zurückgezogen wird, dann kann man nur noch Intel für die entstandene Verzögerung verantwortlich machen, bis das korrigierte Update beim Kunden ankommt.

StefanV

2018-05-09, 00:34:49

Beschreibt zu 100% exakt genau das was ich geschrieben hat.
Du hast meine Frage nicht beantwortet!
Zeige doch mal eine Demonstration, die auf AMD Hardware durchgeführt wurde!

Denn bisher gibt es ausschließlich Demonstrationen auf Intel Hardware, keine zu AMD.
Und solange nicht bewiesen ist, dass das auch auf AMD ausgeführt werden kann, ist deine Behauptung Käse!

Und dass da irgendwas, irgendwo irgendwie sein kann und das auch vom Hersteller bestätigt wird, ist kein Beweis, das ist "Whataboutism", oder mit dem Finger auf andere zeigen, um vom eigentlichen Thema abzulenken.

Oder um es mal ganz deutlich zu sagen:
schau mal, ein 3 Köpfiger Affe!!!!111
Es wird behauptet, dass AMD auch betroffen ist, um von der Schwere bei Intel abzulenken. Nicht mehr ist das.
Und solange du nicht belegen kannst, dass diese Lücke auch bei AMD ausgenutzt werden kann (was bisher nicht passierte), solltest du den Ball flach halten!
Zumal auch AMD sich eher selbstbewusst gibt und deinen Behauptungen so gut es möglich ist, widerspricht!!

Und es ist durchaus möglich, dass AMD an einer Intelschen Sprungvorhersage gearbeitet hat, damit "rumgespielt" hat, es am Ende aber verworfen hat, weil es mehr Probleme schafft als es löst.

Und noch einmal:
Wenn es (einfach) möglich wäre, das ganze auf AMD Produkten auszunutzen, hätten wir schon vor Monaten davon gehört!
Denn Intel hätte ein Interesse dran, solche Dinge zu veröffentlichen. Und was haben wir seit der Spectre/Meltdown Veröffentlichung auf AMD Seite zu dem Theama gesehen? Nix, nur irgendeinen Bullshit!
Ryzenfall lässt eher darauf schließen, dass die AMD CPUs halbwegs sicher wären, sonst hätte man was zum Thema Spectre/Meltdown veröffentlicht - hat man aber nicht.

Rancor

2018-05-09, 09:52:33

Du hast meine Frage nicht beantwortet!
Zeige doch mal eine Demonstration, die auf AMD Hardware durchgeführt wurde!

Denn bisher gibt es ausschließlich Demonstrationen auf Intel Hardware, keine zu AMD.
Und solange nicht bewiesen ist, dass das auch auf AMD ausgeführt werden kann, ist deine Behauptung Käse!

Und dass da irgendwas, irgendwo irgendwie sein kann und das auch vom Hersteller bestätigt wird, ist kein Beweis, das ist "Whataboutism", oder mit dem Finger auf andere zeigen, um vom eigentlichen Thema abzulenken.

Oder um es mal ganz deutlich zu sagen:
schau mal, ein 3 Köpfiger Affe!!!!111
Es wird behauptet, dass AMD auch betroffen ist, um von der Schwere bei Intel abzulenken. Nicht mehr ist das.
Und solange du nicht belegen kannst, dass diese Lücke auch bei AMD ausgenutzt werden kann (was bisher nicht passierte), solltest du den Ball flach halten!
Zumal auch AMD sich eher selbstbewusst gibt und deinen Behauptungen so gut es möglich ist, widerspricht!!

Und es ist durchaus möglich, dass AMD an einer Intelschen Sprungvorhersage gearbeitet hat, damit "rumgespielt" hat, es am Ende aber verworfen hat, weil es mehr Probleme schafft als es löst.

Und noch einmal:
Wenn es (einfach) möglich wäre, das ganze auf AMD Produkten auszunutzen, hätten wir schon vor Monaten davon gehört!
Denn Intel hätte ein Interesse dran, solche Dinge zu veröffentlichen. Und was haben wir seit der Spectre/Meltdown Veröffentlichung auf AMD Seite zu dem Theama gesehen? Nix, nur irgendeinen Bullshit!
Ryzenfall lässt eher darauf schließen, dass die AMD CPUs halbwegs sicher wären, sonst hätte man was zum Thema Spectre/Meltdown veröffentlicht - hat man aber nicht.

Ändert nichts daran, das es theoretisch möglich ist :cool: Und spar die den Flame, ich habe selber ne Ryzen CPU im Rechner und bin damit absolut zufrieden ;)

HOT

2018-05-09, 09:53:57

Theoretisch sind noch ganz andere Sachen möglich. Ne theoretische Lücke, mit der du in der Praxis nichts anfangen kannst ist wohl kaum relevant.

StefanV

2018-05-09, 10:17:43

Ändert nichts daran, das es theoretisch möglich ist :cool:
Richtig
Und theoretisch könntest du, sobald du die Hütte verlässt von 'nem Auto/LKW/Trecker überfahren werden.
Und theoretisch könnte dir die Hütte aufn Kopf fallen.

Das alles ist theoretisch möglich. Und solange niemand nachgewiesen hat, dass es möglich ist, ist es einfach an den Haaren herbei gezogen.

Du fährst ja sicher auch (E-)Auto, obwohl es theoretisch möglich ist, dass es explodiert, richtig?!

Es gibt 'nen ganzen Haufen an theoretischer Möglichkeiten, wie jedem hier in den nächsten 5 Minuten was unschönes passieren könnte. Das heißt aber noch lange nicht, dass das auch passieren wird oder dass es wahrscheinlich ist, dass etwas passieren würde!!

Und damit sind wir wieder beim Thema dreiköpfige Affen!!!!1111
Weil nix anderes ist das. Ein Versuch zu relativieren, mit dem Finger auf andere zu zeigen, um Intel in einem besseren Licht darstehen zu lassen!

Wenn du der Meinung bist, dass es bei AMD auch der Fall sein könnte, dann mach dich doch mal auf die Suche nach einer praktischen Anwendung und schaue, wie man das ausnutzen könnte...

Aber dass wir bis heute nix davon gehört haben, deutet eher darauf hin, dass die Ausnutzung auf AMD gar nicht so einfach ist, wie es bei Intel der Fall ist.
Denn, wie oben geschrieben, hat Intel ein sehr starkes Interesse daran, entsprechende Anwendungen zu finden. Aber es gibt kein Proof Of Concept für die Ausnutzung von Spectre auf AMD!
Stattdessen gab es irgendeinen anderen Bullshit, der nichts mit Spectre und Meltdown zu tun hat.
Sollte einem das nicht zu denken geben?!
Und dazu führen, mit dem Blödsinn "abba AMD is auch betroffen!!11" gerede erst einmal aufzuhören, bis bewiesen ist, dass man das auch bei AMD machen könnte?!

Sollte man nicht die Unschuldsvermutung hier verwenden?! Also das, was man bei Intel macht...

gbm31

2018-05-09, 10:42:03

lumines

2018-05-09, 10:42:10

Wieso diese künstliche Unterscheidung zwischen Theorie und Praxis? Die Lücken der Intel-CPUs galten auch lange Zeit als reine Theorie.

Generell finde ich Theorie / Praxis dabei aber auch nicht hilfreich, um das zu beschreiben, was da passiert ist. Seitenkanalangriffe sind ja eigentlich pure Praxis, welche die gesamte Theorie über die Funktionsweise von CPUs auf den Kopf stellen.

Insofern ist das eher ein Gespenst aus der Praxis, welche die Theorie heimsucht.

Complicated

2018-05-09, 10:59:36

Aber es gibt kein Proof Of Concept für die Ausnutzung von Spectre auf AMD!
Nur um es zu präzisieren: Es gibt kein PoC für Spectre 2, für Spectre 1 ist eines vorhanden, welches jedoch mutwillig (EBF JIT) aktiv geschaltet werden muss beim kompilieren der verwendeten Software, da der Interpreter per default deaktiviert ist. Spectre 1 wird entsprechend auch nicht in der Hardware gefixed (Microcode), sondern in OS und Software.

Wieso diese künstliche Unterscheidung zwischen Theorie und Praxis? Die Lücken der Intel-CPUs galten auch lange Zeit als reine Theorie.Wo ist denn die Unterscheidung künstlich? Bei den einen lässt es sich ausnutzen und bei den anderen nicht. Das ist eine ganz natürliche Unterscheidung, da es ja offensichtlich einen ANDEREN Code und nicht diesen benötigt, der Spectre 2 genannt wird, um die Theorie zu bestätigen.
Das eine ist ein Konzept (Concept) und das andere ist der Beweis (Proof), dass dieses Konzept funktioniert (Proof of Concept).
Ohne den Beweis ist eine theoretische (erfundene/zusammengereimte/vermutete) Lücke noch lange nicht tatsächlich vorhanden.

Ganon

2018-05-09, 11:08:07

für Spectre 1 ist eines vorhanden, welches jedoch mutwillig (EBF JIT) aktiv geschaltet werden muss

Nur wenn es darum geht Kernel-Speicher auszulesen. Spectre V1 ist eine recht allumfassende Lücke und nicht nur auf einen bestimmten Anwendungsfall ausgelegt. Zuletzt (https://www.phoronix.com/scan.php?page=news_item&px=Linux-Spectre-Sound-Drivers) wurden z.B. die Audio-Treiber gegen Spectre V1 im Linux-Kernel abgesichert.

Dass Spectre V1 nur mit OS und Software-Aktualisierungen anzugehen ist, ist aber auch schon von Anfang an bekannt. Deswegen wurde ja auch gesagt, dass uns Spectre noch eine ganze Weile begleiten wird.

Rancor

2018-05-09, 11:41:00

Richtig
Und theoretisch könntest du, sobald du die Hütte verlässt von 'nem Auto/LKW/Trecker überfahren werden.
Und theoretisch könnte dir die Hütte aufn Kopf fallen.

Soll schonmal vorgekommen sein.

Das alles ist theoretisch möglich. Und solange niemand nachgewiesen hat, dass es möglich ist, ist es einfach an den Haaren herbei gezogen.

An den Haaren herbei gezogen wäre es, wenn es theoretisch nicht möglich wäre ;)

Du fährst ja sicher auch (E-)Auto, obwohl es theoretisch möglich ist, dass es explodiert, richtig?!

Genau deshalb fahre ich kein E-Auto :rolleyes: Nicht alles was hinkt, ist ein Vergleich ;)

Es gibt 'nen ganzen Haufen an theoretischer Möglichkeiten, wie jedem hier in den nächsten 5 Minuten was unschönes passieren könnte. Das heißt aber noch lange nicht, dass das auch passieren wird oder dass es wahrscheinlich ist, dass etwas passieren würde!!

Ändert alles nichts daran das AMD auch betroffen ist, nur eben theoretisch.
Deal with it :cool:

Und damit sind wir wieder beim Thema dreiköpfige Affen!!!!1111
Weil nix anderes ist das. Ein Versuch zu relativieren, mit dem Finger auf andere zu zeigen, um Intel in einem besseren Licht darstehen zu lassen!

In welchem Licht Intel darsteht ist mir persönlich herzlich egal. Ich habe ne AMD CPU und bin somit theoretisch auch betroffen. Das Anwender mit Intel CPUs wesentlich krasser am Arsch sind interessiert mich auch nur am Rande dabei.

Wenn du der Meinung bist, dass es bei AMD auch der Fall sein könnte, dann mach dich doch mal auf die Suche nach einer praktischen Anwendung und schaue, wie man das ausnutzen könnte...

Was für ein Quatsch du hier jabbelst. AMD sagt doch selber das es ist theoretisch möglich. Sie fixen es und gut ist.

Aber dass wir bis heute nix davon gehört haben, deutet eher darauf hin, dass die Ausnutzung auf AMD gar nicht so einfach ist, wie es bei Intel der Fall ist.
Denn, wie oben geschrieben, hat Intel ein sehr starkes Interesse daran, entsprechende Anwendungen zu finden. Aber es gibt kein Proof Of Concept für die Ausnutzung von Spectre auf AMD!
Stattdessen gab es irgendeinen anderen Bullshit, der nichts mit Spectre und Meltdown zu tun hat.
Sollte einem das nicht zu denken geben?!
Und dazu führen, mit dem Blödsinn "abba AMD is auch betroffen!!11" gerede erst einmal aufzuhören, bis bewiesen ist, dass man das auch bei AMD machen könnte?!

Niemand hat gesagt das es auf AMD einfach möglich ist oder praktisch ausgenutzt wird. Sondern nur das es theoretisch möglich ist. :freak: Ich wiederhole mich...

Sollte man nicht die Unschuldsvermutung hier verwenden?! Also das, was man bei Intel macht...
Hier redet doch niemand von Schuld. Ey was gehtn bei dir ab ? Krasser AMD Fanboy. :crazy: Fühlst du dich persönlich angegriffen, wenn jemand etwas gegen AMD sagt? Sic...

Schnoesel

2018-05-09, 11:48:43

Gott wie viel nichtssagendes Gedöns hier.

Für mich lässt sich das so zusammenfassen.

Stand jetzt anhand der Faktenlage:

AMD Prozessoren sind sicherer als Intel Prozessoren.

Rancor

2018-05-09, 11:50:23

Gott wie viel nichtssagendes Gedöns hier.

Für mich lässt sich das so zusammenfassen.

Stand jetzt anhand der Faktenlage:

AMD Prozessoren sind sicherer als Intel Prozessoren.

Zusammengefasst, ja :)

StefanV

2018-05-09, 12:14:17

Genau deshalb fahre ich kein E-Auto :rolleyes:
Deshalb das E in Klammern, weil es auch bei Verbrennungsmotoren vorkommen kann, die ja bekanntlich Explosionsmotoren sind...

Gott wie viel nichtssagendes Gedöns hier.

Für mich lässt sich das so zusammenfassen.

Stand jetzt anhand der Faktenlage:
AMD Prozessoren sind sicherer als Intel Prozessoren.
Zusammengefasst, ja :)
Öhm, worüber streiten wir eigentlich, Rancor, wenn wir beide die gleiche Meinung zu dem Thema haben??

Es ist ja nicht so, dass du mit dem "ABBA AMD PROZESSOREN SIND MINDESTENS GENAU SO UNSICHER" angefangen hast ;)

Wolfram

2018-05-09, 15:02:35

Ich hab bei euren hitzigen Diskussionen bissle den Überblick verloren...

Sorry, wenn ich jetzt blöd frage:

- i7-3770K auf Asrock Z68 Pro3-M, Windows 10 mit aktuellsten Updates.

- Asrock hat ein Beta-BIOS mit Microcode-Update online gestellt, Datum 16.04.18.

Muss ich das aufspielen oder regelt Windows das? (also Lücken schließen, nicht BIOS aufspielen...)

Wo gibt es denn das BIOS? Ich sehe es weder auf der Produktseite noch unter "Latest Beta BIOS Update". Habe nämlich auch noch drei ASRock Z68/H61-Boards, die ein Update vertragen könnten.

exzentrik

2018-05-09, 15:42:42

Wo gibt es denn das BIOS? Ich sehe es weder auf der Produktseite noch unter "Latest Beta BIOS Update". Habe nämlich auch noch drei ASRock Z68/H61-Boards, die ein Update vertragen könnten.

Hier (https://www.asrock.com/mb/Intel/Z68%20Pro3-M/index.asp#BIOS).

Wolfram

2018-05-09, 15:44:56

Hier (https://www.asrock.com/mb/Intel/Z68%20Pro3-M/index.asp#BIOS).
Ok, ich geh zu Augenarzt. Danke!

Ganon

2018-05-16, 10:43:57

Microcodes per Windows-Updates jetzt auch zurück bis Sandy-Bridge:

https://support.microsoft.com/en-us/help/4100347/intel-microcode-updates-for-windows-10-version-1803-and-windows-server

vanquish

2018-05-16, 10:52:54

Vielleicht sollte man noch erwähnen, dass diese Updates ausschließlich für Windows 10 verteilt werden. Zudem erhält nicht jede Version von Windows 10 alle Microcodes. Sandy Bridge und Ivy Bridge werden z. B. nur mit v1803 und höher bedient. v1511 erhält gar keine Microcode Updates.
https://www.computerbase.de/2018-03/intel-microcode-updates-windows-10-coffee-kaby-lake/

SKYNET

2018-05-16, 11:11:34

aufkrawall

2018-05-16, 11:37:51

Wenn man auf Frametime-Spikes mit Nvidia steht, sind die Builds nach 1607 natürlich kein Problem. Merkt nur nicht jeder, Glück für Nvidia...

SKYNET

2018-05-16, 14:30:21

Wenn man auf Frametime-Spikes mit Nvidia steht, sind die Builds nach 1607 natürlich kein Problem. Merkt nur nicht jeder, Glück für Nvidia...

kommts evtl. nicht auch auf auflösung, game und weitere kriterien an?

Razor

2018-05-16, 19:14:33

Mit Sicherheit sogar!
Wer's "statisch" haben will, soll sich 'ne Konsole kaufen...
(oder aber lernen, wie man das ganze Win10-Gedöhns abschalten kann ;-)
Microcodes per Windows-Updates jetzt auch zurück bis Sandy-Bridge:
https://support.microsoft.com/en-us/help/4100347/intel-microcode-updates-for-windows-10-version-1803-and-windows-server
Na ja... wird doch!

Allerdings hilft das meinem guten alten "Penryn-3M" SU9400 (ULV Core2 im Acer TimelineX Notebook) auch nicht weiter :(
Ansonsten rennt das Ding unter Win10 wie Sau - mit einer (immer noch) Akku-Lebensdauer von satten 6,5h!

Razor

aufkrawall

2018-05-16, 19:27:45

kommts evtl. nicht auch auf auflösung, game und weitere kriterien an?
Das Problem ist immer da, es liegt nur an der Kombi Win 10 Speicherverwaltung ab CU1 und NV-Treiber. Es betrifft nur nicht alle Spiele gleich stark bzw. viele wohl auch quasi gar nicht. BF1 etwa ist aber unschön:

AU:
uR0IFUSN5dQ

ab Creators Update:
pCp2ASrsBpk

Sind nicht unbedingt Monsterstocker, weshalb es viele es für noch normal halten werden oder es gar nicht merken. Wenn man natürlich weiß, dass etwas nicht optimal läuft...

Rampage 2

2018-05-16, 21:14:33

Vielleicht sollte man noch erwähnen, dass diese Updates ausschließlich für Windows 10 verteilt werden.

Diese News gibt es bereits und ist schon einige Tage alt - ist M$ denn nicht verpflichtet, diese Updates auch für Win 7/8.1 User bereitzustellen? Schließlich gilt der Security-Support noch bis 2020 bzw. 2023 und diese Updates sind Sicherheitsupdates:mad:

Diese Firma ist sich für keine Frechheit zu schade...

R2

Lehdro

2018-05-16, 22:39:10

Diese Firma ist sich für keine Frechheit zu schade...

Ich würde meinen Ärger lieber Richtung Intel lenken. MS muss die Scheiße ausbaden die Intel gebaut hat - wieder mal.

vanquish

2018-05-16, 23:20:44

Ganon

2018-05-17, 00:14:26

Vielleicht ist auch einfach nur das ganze Ökosystem rund um geschlossene Firmware/Software und Sicherheit à la "dude trust me" auch einfach nur verkorkst und das Problem zeigt einfach mal wie groß dieser Clusterfuck eigentlich allgemein ist.

Vollkommen egal wer ursprünglich dafür verantwortlich ist, wenn Updates nicht beim Kunden ankommen ist einfach mal der ganze Hardware/Software-Stack daran Schuld und nicht nur eine einzelne Firma.

Genauso könnte man auch Qualcomm dafür verantwortlich machen, dass so viele Android-Telefone weiterhin unsicher sind, weil sie mal eine Sicherheitslücke in ihren Treiber gebaut haben und der Telefonhersteller die Patches nicht ausliefert. Ist hier prinzipiell nichts anderes. Ob du die Firmware nun in die CPU lädst oder in die Netzwerkkarte oder Grafikchip ist da nicht so viel Unterschied.

lumines

2018-05-17, 00:29:35

StefanV

2018-05-17, 02:44:45

Hatten wir das nicht schon? Auch ARM und Co. waren von einigen der Lücken betroffen. Mit der Monopolstellung von Intel hat das genau nichts zu tun.
PoC für ARM??
Aber eben nicht in dem Ausmaß wie es bei Intel der Fall ist...

Korfox

2018-05-17, 07:18:50

Ganon

2018-05-17, 07:48:53

PoC für ARM??

Die Lücken sind so ziemlich die Gleichen, wie bei Intel, außer dass im Falle von Meltdown noch ein "Variant 3a" hat, wo Register-Werte geleakt werden.

https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability

https://github.com/lgeek/spec_poc_arm

Wie du der ARM-Seite entnehmen kannst, hilft hier auch Retpoline nicht. Firmware-Update ist nötig.

Aber eben nicht in dem Ausmaß wie es bei Intel der Fall ist...

Außer, dass ARM CPUs in so ziemlich der gesamten Smartphone-Welt verbaut sind... Glücklich können sich nur die schätzen, die ein Billig-Smartphone mit reinen A53 CPUs haben. Die sind so simpel, dass sie immun sind.

Dorn

2018-05-17, 08:03:50

Microcodes per Windows-Updates jetzt auch zurück bis Sandy-Bridge:

https://support.microsoft.com/en-us/help/4100347/intel-microcode-updates-for-windows-10-version-1803-and-windows-server
Danke für den Link, so mein altes Notebook ist jetzt auch gegen Spectre besser geschützt.

vanquish

2018-05-17, 10:04:11

Vollkommen egal wer ursprünglich dafür verantwortlich ist, wenn Updates nicht beim Kunden ankommen ist einfach mal der ganze Hardware/Software-Stack daran Schuld und nicht nur eine einzelne Firma.

Genauso könnte man auch Qualcomm dafür verantwortlich machen, dass so viele Android-Telefone weiterhin unsicher sind, weil sie mal eine Sicherheitslücke in ihren Treiber gebaut haben und der Telefonhersteller die Patches nicht ausliefert. Ist hier prinzipiell nichts anderes. Ob du die Firmware nun in die CPU lädst oder in die Netzwerkkarte oder Grafikchip ist da nicht so viel Unterschied.

Rly? Intel wird gerne deiner Argumentation folgen. Genauso wie jeder Vorstandsvorsitzende der das zig-fache seiner Angestellten/Arbeiter verdient und seine "Millionen-Bonus" mit seiner großen Verantwortung begründet. Die er, wenn es gar nicht anders geht, gegebenenfalls mit einer hohen Millionen-Abfindung "übernimmt" indem er geht.

Die Gewinne werden gerne genommen. Die "Verluste" durch eigene Fehler/Verschulden der Allgemeinheit aufgezwungen: Banken, Diesel, BER. usw. Klar hat Intel das Problem nicht alleine. Die Forderung nach Übernahme der Verwantwortung bezieht sich auf alle Teilnehmer (Boardhersteller, OEMs, Intel, AMD, Microsoft, Google, Samsung, etc.) Wenn sie ihrer Verantwortung gerecht geworden wären, hätten sie ihre Produkte regelmäßig selbst überprüft. Das passiert in vielen anderen Branchen automatisch. Auch bei Intel. Nur hat man das Thema Sicherheit beiseite gewischt. Kostet ja Geld. Die Sicherheit der Gesellschaft ist ihnen schlichtweg egal gewesen (auch den Anderen). Jetzt hat Google das, als altbekannter Altruist, für Intel übernommen.

Der Begriff Corporate Responsibility (CR) bzw. Unternehmensverantwortung, auch unternehmerische Verantwortung beschreibt den Grad des Verantwortungsbewusstseins eines Unternehmens, wo immer seine Geschäftstätigkeit Auswirkungen auf die Gesellschaft, die Mitarbeiter, die Umwelt und das wirtschaftliche Umfeld hat.

Für die Textilfabriken in Asien, die Menschen und Umwelt vergiften. Foxconn Mitarbeiter die sich aus Verzweiflung aus dem Fenster stürzen ... Für all das will niemand die Verantwortung übernehmen. Warum auch ... Jedes Jahr ein neuer Rechner/Handy und zu jeder Saison die passenden Klamotten und alle sind glücklich.

Wen interessieren die Millionen Geräte die nicht mehr mit Updates versorgt werden schon. Es muss erst mal richtig geknallt haben bevor sich etwas ändert und man merkt wie wichtig sichere und funktionierende Technik ist. Dazu passt dann auch, dass nicht nur der Bundestag gehackt wird sondern auch AKWs in den U.S.A. Nur in Deutschland hat es noch keiner gemerkt. Das dauert noch ... Wer übernimmt dafür die Verwantwortung? Die Politik? Der Techniker vor Ort? Der Lieferant der Computertechnik? Der Chiphersteller (der ggf. schon länger von einer Lücke wusste)? Der OS-Hersteller (der ggf. auch schon länger von einer Lücke wusste). Wird wohl der Stuerzahler werden ...

Am Ende ist es IMO eben nicht egal wer Schuld daran hat. Irgendwer muss die Verwantwortung übernehmen und für die Beseitigung dieser Sicherheitslücken bezahlen. Da nehme ich Android & Co. nicht aus. Intel hat die Mainboardhersteller beliefert. Sollen sie diese für den Update-Dienst bezahlen und eine Update-Software schreiben die jeder DAU von Windows aus bedienen kann. So, dass es auch jeder bekommt. Und nur weil Qualcomm seine Sicherheitslücken nicht beseitigt, rechtfertigt das noch lange nicht, dass es andere ihnen gleichtun. Ich würde auch VW & Co. in die Pflicht nehmen und in "Hardware" zahlen lassen. Nach einem Jahr Entwicklungszeit hat Bosch jetzt (oh Wunder) die Technik um den Diesel sauber zu machen (40 Milligram/km Stickoxid; 1/10 des Grenzwerts der für 2020 vorgesehen ist). Dass hierbei noch der Betrug mit im Spiel war, macht es für mich fast noch unterträglicher, dass niemand zur Verantwortung gezogen wird bzw. diese niemand einfordert.

Razor

2018-05-17, 18:59:58

Diese News gibt es bereits und ist schon einige Tage alt - ist M$ denn nicht verpflichtet, diese Updates auch für Win 7/8.1 User bereitzustellen? Schließlich gilt der Security-Support noch bis 2020 bzw. 2023 und diese Updates sind Sicherheitsupdates:mad:
Sind sie nicht, tun sie aber in Ausnahmefällen.
"Verpflichtet" ist einzig der Hersteller der Hardware.

Dass sie allerdings keine Updates für Win7/8/8.1 bereit stellen, ist pures Interesse daran, diese Systeme "noch schneller" vom Markt zu bekommen.
Oder wie ist es zu erklären, dass "es" die Hardware-Unterstützung für den Meltdown-Patch nur Windows10 spendierte?
Kann man sich drüber "aufregen"... kann man aber auch sein lassen... ein Tribut an den Kapitalismus, gell?
Ich würde meinen Ärger lieber Richtung Intel lenken. MS muss die Scheiße ausbaden die Intel gebaut hat - wieder mal.
Nun überteib' mal nicht... der Mechanismus, Microcode-Updates beim Systemstart zu laden, ist nicht nur seit Urzeiten (mindestens seit WinXP!) im Betriebssystem vorhanden, sondern wurde auch schon immer genutzt.
M$ aktualisiert die CPU-Patches nur nach Vorgabe der Hersteller... und das auch nur, wenn es unbedingt sein muss, weil man so ja auch die Verantwortung für die Verteilung und etwaig auftretende Probleme übernimmt.
Der Fehler wird seit 20 Jahren in Hardware gegossen. Ich würde für dieses Versäumnis wohl hauptsächlich Intel verantwortlich machen.
Meiner Güte wird hier ein Unfug gelabert... sorry.
Als ob Intel so etwas absichtlich "einbaut" und 20 Jahre "bibbert", dass es keiner finden möge :rolleyes:
Denk' doch mal nach, warum es erst heute "auftaucht".
Geschnallt?
Microsoft ist sicher nicht der weiße Ritter, aber hier... is es schwer, ihnen etwas vorzuwerfen, finde ich.
Einerseits ja, andererseits nein... siehe Antwort auf 1. Zitat.
Genauso könnte man auch Qualcomm dafür verantwortlich machen, dass so viele Android-Telefone weiterhin unsicher sind, weil sie mal eine Sicherheitslücke in ihren Treiber gebaut haben und der Telefonhersteller die Patches nicht ausliefert. Ist hier prinzipiell nichts anderes. Ob du die Firmware nun in die CPU lädst oder in die Netzwerkkarte oder Grafikchip ist da nicht so viel Unterschied.
That's it.

Mein Galaxy S4 mini (ich bin "anspruchslos" ;-) ist von 2014, hat bereits einen neuen Akku bekommen (ja, damit geht das ;-), läuft mit Android 4.4 und ist seither NIE gepatcht worden! Da kam dann irgendwann die Meldung, dass MMS "böses" tun können und was habe ich gemacht? MMS "automatisch laden" = aus... fertich.

Klar ist das "gepatche" - egal auf welcher Ebene - vollkommener Nonsens, aber das Thema "Virtualisierung" ist eben im Consumer-Markt noch nicht wirklich angekommen. OK, zumindest die Apps werden "virtualisiert" (laufen in sog. Java-VM's), aber auch nur, um das Betriebssystem wenigstens einigermaßen vor diesem ganzen "Müll" (der durchaus auch "Böses" will) zu schützen. Sicherheitsprobleme bei Konsolen? Fehlanzeige! Warum? Weil's keinen interessiert (steckt die gleiche "Hardware" drin)... oder sieht das hier wer anders?

"Sicher" ist gar nichts und dieser "Aufreger" hier, war und ist "Absicht".
Nur eine Mutmaßung von mir, aber passt absolut ins Gesamtbild.

Razor

aufkrawall

2018-05-17, 19:06:59

Nun überteib' mal nicht... der Mechanismus, Microcode-Updates beim Systemstart zu laden, ist nicht nur seit Urzeiten (mindestens seit WinXP!) im Betriebssystem vorhanden, sondern wurde auch schon immer genutzt.

Dumm nur, dass für Spectre durch das Laden des Mikrocodes allein noch gar nichts erreicht ist, sondern der Kernel die Schutzfunktion dann überhaupt erst umsetzen kann und muss.

Sorgen sollte einem zudem besonders machen, dass Microsoft selbst die Meltdown-Patches für < Win 10 1803 verkackt hatte (angeblich wirkungslos) und für Windows 7 sogar eine viel schlimmere Lücke dadurch gerissen hatte.
Wenn die jetzt noch weniger QA-Zeit für bestimmte Versionen hätten...

Alles scheiße außer Linux, simple as that.

Razor

2018-05-17, 19:15:21

Dumm nur, dass für Spectre durch das Laden des Mikrocodes allein noch gar nichts erreicht ist, sondern der Kernel die Schutzfunktion dann überhaupt erst umsetzen kann und muss.
Irgendetwas fehlt an Deiner Feststellung... und?
Soll M$ etwa auch die Microcodes selber entwickeln?
:confused:
Sorgen sollte einem zudem besonders machen, dass Microsoft selbst die Meltdown-Patches für < Win 10 1803 verkackt hatte (angeblich wirkungslos) und für Windows 7 sogar eine viel schlimmere Lücke dadurch gerissen hatte.
Wenn die jetzt noch weniger QA-Zeit für bestimmte Versionen hätten...
Klar... beim Patchen ist ja auch noch nie etwas anderes "kaputt" gegangen.
Sag mal, auf welcher Wolke lebst Du eigentlich?
:rolleyes:

Alles scheiße außer Linux, simple as that.
Oh mann... wer hat die größten Performance-Probleme mit den Patches?
Rischtisch.

Razor

aufkrawall

2018-05-17, 19:24:02

Irgendetwas fehlt an Deiner Feststellung... und?
Soll M$ etwa auch die Microcodes selber entwickeln?
:confused:

Du tust so, als ob durch das Verteilen des MCs das Problem gelöst wäre. Was Quatsch ist, da nützt auch deine ins Nichts gehende Frage zur Ablenkung nichts.

Klar... beim Patchen ist ja auch noch nie etwas anderes "kaputt" gegangen.
Sag mal, auf welcher Wolke lebst Du eigentlich?
:rolleyes:

Die Frage geb ich zurück und verbinde sie mit den Zusatz, wo denn bei Linux die Probleme durch KPTI oder Retpoline gewesen sein sollen?

Oh mann... wer hat die größten Performance-Probleme mit den Patches?
Rischtisch.

Blödsinn, Retpoline kostet weniger Leistung als die Mitigations via Microcode.

Birdman

2018-05-17, 20:02:06

Blödsinn, Retpoline kostet weniger Leistung als die Mitigations via Microcode.
Diese Aussage müsste man etwas revidieren, denn mit Retpoline alleine ist es nicht getan.
Für einen nach aktuellem Stand der Erkenntnisse maximalen (optimalen?) Schutz, wird nebst Retpoline auch das via Microcode Update dazugekommene IBPB Prozessor Feature benötigt.
Das wird unter Linux aktuell auch so für Intel und AMD Systeme genutzt, entsprechender Kernel und Microcode vorausgesetzt.

aufkrawall

2018-05-17, 20:06:03

Da gehen die Meinungen in der Linux-Welt auseinander, Fedora nutzt Retpoline gar nicht. Der allgemeine Usus ist, dass Retpoline allein schon einen guten Schutz darstellt. sysfs meldet nichts zurück, was einen anderen Schluss nahe legen würde.

Edit: Das bez. Fedora versuch ich aber gerade sicherheitshalber nochmal lieber zu recherchieren.
Edit 2: Muss ich morgen mal in einer VM nachsehen...

Birdman

2018-05-17, 20:28:37

Rampage 2

2018-05-19, 02:33:27

Na ja, wann wurde jemals ein Softwareunternehmen für fehlende Patches drangekriegt? Diese Möglichkeit wird gerne als großer Vorteil kommerzieller Software genannt, aber praktisch passiert da nie etwas.

Grundsätzlich ist MS sicher auch nicht dazu verpflichtet Fehler in der Hardware auszubügeln. Die stammt ja nicht von MS. Wünschenwert wäre es natürlich schon, weil anders (wie Ganon schon gesagt hat) die allermeisten Nutzer sonst solche Patches niemals zu sehen bekommen werden.

Spielt es vertragsrechtlich eine Rolle, von wem (Intel) oder was (Hardware) die Lücke stand, wenn in den Support-Richtlinien von M$ klar und deutlich angegeben ist, dass das OS weiterhin mit Sicherheitsupdates versorgt wird? Spectre ist eine Sicherheitslücke und soweit ich es verstanden habe, reichen BIOS/Microcode-Updates NICHT aus, um ausreichend sicher davor zu sein - zumindest bei Spectre sind Microcode-Updates UND Betriebssystem-Updates erforderlich! Und da Spectre eine Sicherheitslücke ist und dessen Betriebssystem-Teil mit Sicherupdates gestopft werden kann (und muss), muss M$ diese Updates auch liefern.

Nach eurer Logik müsste M$ auch für W10 keine Patches herausbringen, da es ja nicht "ihre" Lücke ist - komischerweise wird W10 trotzdem versorgt... (oder soll zumindest versorgt werden)

Ich würde meinen Ärger lieber Richtung Intel lenken. MS muss die Scheiße ausbaden die Intel gebaut hat - wieder mal.

Der Fehler wird seit 20 Jahren in Hardware gegossen. Ich würde für dieses Versäumnis wohl hauptsächlich Intel verantwortlich machen. Aber auch den Konsumenten der dieses Monopol befördert hat. Gleichwohl stünde es auch Microsoft zu, mehr Verantwortung zu übernehmen und nicht nur aktuellste Systeme zu patchen. Zwei Riesenkonzerne die Millionen "ungepatchte" Systeme in unserer Infrastruktur zurücklassen. \o/

Da sieht man mal, wie gut Intels Masche funktioniert.
Der, der es repariert, muss auch verantwortlich sein. Böses Microsoft! :eek:

Microsoft ist sicher nicht der weiße Ritter, aber hier... is es schwer, ihnen etwas vorzuwerfen, finde ich.

Ich habe nicht behauptet, dass M$ die Schuld an der Sache trägt - aber sie machen sich schuldig, indem sie ihren Teil (den sie in ihren eigenen Support-Richtlinien zugesichert haben!) nicht einlösen... und das offensichtlich nicht aus technischen Gründen sondern aus politischen Motiven!

Ebensowenig trägt M$ die Hauptverantwortung dafür, das Problem zu lösen - aber sie tragen Verantwortung dafür, ihre Zusicherungen (ihr Teil des Problems - denn gegen Spectre sind auch OS-Patches nötig) einzulösen.

R2

Razor

2018-05-19, 07:19:58

Du tust so, als ob durch das Verteilen des MCs das Problem gelöst wäre. Was Quatsch ist, da nützt auch deine ins Nichts gehende Frage zur Ablenkung nichts.
Eine Annahme Deinerseits... Dein Problem.
Außerdem lehne ich es ab, mit jemanden "zu diskutieren", der offenbar Probleme hat Unix und Linux auseinander zu halten...
EOD.

Spielt es vertragsrechtlich eine Rolle...
Ja.

Razor

LadyWhirlwind

2018-05-19, 08:26:54

Spielt es vertragsrechtlich eine Rolle, von wem (Intel) oder was (Hardware) die Lücke stand.

R2

Wo steht in den Richtlinien das sie Sicherheitslücken in Produkten von dritten behen bzw. Helfen zu beheben? Die Lücke ist nicht in Windows.

aufkrawall

2018-05-19, 18:37:14

Ähh ja, "Linux" war definitiv eine falsche Wortwahl meinerseits....ich sollte da nicht alles in einen Topf schmeissen.

Einige Distributionen haben zu Spectre ja durchaus abweichende Meinungen und Ansätze, wie das ganze Mitigation doch bitte auszusehen hat.
Wobei das ganze natürlich auch mit dem Timing zusammenhängt, die Softwarepatches welche die Mitigation via IBPB+IBRS+STIBP erreichen wollen, waren ja da bevor es Retpoline gab und da sind einige Distis halt bereits auf den Zug aufgesprungen und haben es auf diese Weise umgesetzt.

Ob oder wann diese auf Retpoline + IBPB umswitchen, entzieht sich im Detail auch meinen Kenntnissen.
Muss mich korrigieren, Fedora setzt doch auf Retpoline + IBPB.
Google (das Unternehmen) meint aber weiterhin, dass Retpoline allein ausreichend ist, oder nicht (Edit: Für KVM werden sie wohl auch IBPB nutzen.)? Man muss halt auch sehen, dass auch Retpoline + IBPB zusammen kein Fix sind, sondern auch immer noch nur Mitigations. Für den Endanwender würd ich das für Overkill halten. Allerdings hab ich auch noch keine Performanceprobleme bemerkt, in der Praxis zerstört Linux auch so Windows weiterhin bei I/O (Beispiel (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11691995&postcount=710)).
Die Windows-Lösung mit IBRS + IBPB ist so oder so langsamer als Retpoline + IBPB.

Außerdem lehne ich es ab, mit jemanden "zu diskutieren", der offenbar Probleme hat Unix und Linux auseinander zu halten...

Was ist denn das jetzt für eine aus der Luft gegriffene Quatschunterstellung? ;D
Konzentrier dich mal besser auf deine eigenen Fails...

Complicated

2018-05-20, 09:16:41

Oder wie ist es zu erklären, dass "es" die Hardware-Unterstützung für den Meltdown-Patch nur Windows10 spendierte?

Gar nicht. Einfach weil du Unfug erzählst.

Der erste Meltdown-Patch für Win 7 im März hat sogar noch weitere Lücken geöffnet weil er fehlerhaft war. Die sind mittlerweile korrigiert worden. Keine Ahnung wo du deine Infos her hast.

Vor allem von welcher Hardwareunterstützung seitens Microsoft du redest im Bezug zu Meltdown ist unklar.

Rooter

2018-05-20, 09:28:52

Microcodes per Windows-Updates jetzt auch zurück bis Sandy-Bridge:

https://support.microsoft.com/en-us/help/4100347/intel-microcode-updates-for-windows-10-version-1803-and-windows-serverSchnapsidee: Könnte man diesen Microcode irgendwie entpacken und in Win7 verwenden? Oder hätte das eh keinen Effekt weil der Kernel es nicht nutzen kann?

MfG
Rooter

kruemelmonster

2018-05-20, 09:46:37

aufkrawall

2018-05-20, 11:46:59

Unter Linux ist man jetzt auch mit Ryzen und Bulldozer nicht mehr auf OS- oder Bios-Updates für Schutzfeatures gegen Spectre im MC angewiesen:
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Zen-Linux-Firmware-Add

Ganon

2018-05-22, 09:37:03

Es wurden ja nun eine weitere (zwei?) neue "Variants" veröffentlicht. Bei 3a bin ich mir gerade unsicher, aber bisher hatte nur ARM davon geredet. Aber scheinbar ist auch Intel von Variant 3a betroffen (was wohl die Neuheit hier ist?). Das ist dieses "Rogue System Register Read", was eben genau das erlaubt was es aussagt. Man kann Systemregister auslesen und somit mehr über das laufende OS herausfinden.

Dann kam noch Variant 4 hinzu. Es sagt aus:
Systems with microprocessors utilizing speculative execution and speculative execution of memory reads before the addresses of all prior memory writes are known may allow unauthorized disclosure of information to an attacker with local user access via a side-channel analysis.

Intel liefert hierzu Microcode Updates: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html

AMD ist wohl von Variant 3a nicht betroffen, Variant 4 aber wohl auch, wenn auch wohl nicht ganz so intensiv wie Intel (?): https://www.amd.com/en/corporate/security-updates

ARM, IBM POWER und SystemZ Systeme sind aber wohl auch betroffen: https://access.redhat.com/security/vulnerabilities/ssbd

Jedenfalls scheinen aber die Abwehrmaßnahmen in Software hier schon teilweise zu greifen (Site Isloation im Browser, schlechtere Timings über API, ...).

Sowohl Intel und als auch AMD sagen, dass man "Memory Disambiguation" zwar an lassen sollte, aber es im Zweifel auch deaktivieren kann. Bei AMD ist dies wohl schon jetzt möglich, bei Intel liefert das Microcode Update das nach. Es gibt wohl hierzu auch noch keinen sinnvollen PoC Code, der auf Allerwelts-Systemen funktionieren würde, von daher ist das eine präventive Maßnahme. Darum wird das nicht per-default abgeschaltet.

https://newsroom.intel.com/editorials/addressing-new-research-for-side-channel-analysis/

Sollte man sich für eine Abschaltung entscheiden kostet das bei Intel, laut Intel, wohl 2-8% Performance. AMD hat keine Aussage dazu getroffen, glaube ich. Die Performance-Einbußen gegen die Absicherung gegen Variant 3a kostet laut Intel <1% Performance.

So, das war jetzt eine oder zwei neue Lücken, fehlen ja noch ein paar, aber das dauert ja noch bis August.

Schnoesel

2018-05-22, 11:29:23

Hier nochmal zusammengefasst:

https://www.computerbase.de/2018-05/spectre-3a-4-details-patches/

Scheinen sich nur um die mittelschweren Lücken zu handeln und die kritischen vor allem für Cloudanbieter folgen noch.

vanquish

2018-05-22, 16:40:38

Am interessantesten finde ich die gewählte Nomenklatur und die Tatsache, dass Intel Meltdown 3a mittels Software _und_ Microcode Update begegnen möchte. Bin gespannt wie kommenden Prozessoren aussehen werden und ob es dabei einen ganzheitlichen Ansatz braucht oder die Prozessorhersteller das alleine fixen können.

Nakai

2018-06-13, 21:37:46

https://blog.fefe.de/

Wieso würden AES-Keys in FPU-Registern liegen? Mir fällt da höchstens MMX ein, die ersten Vektorinstruktionen von Intel, bei denen sich MMX und die FPU die selben physischen Register teilen. Ansonsten wüsste ich gerade nicht. Hat jemand ne Idee?
Update: Ooooh, Einsender weisen darauf hin, dass bei AES-NI die Schlüssel in den FPU-Registern liegen! Das wusste ich gar nicht. Oh wow. Das ist ja dann natürlich echt krass problematisch, wenn man das per Side Channel auslesen kann.

Ganon

2018-06-14, 00:49:08

Hier mal ein paar mehr Quellen und nicht nur ein Link irgendwohin mit einem Quote der nur Fragen stellt :D

https://blog.fefe.de/?ts=a5df921a

http://seclists.org/oss-sec/2018/q2/189

https://marc.info/?l=openbsd-cvs&m=152818076013158&w=2

http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/e5aace14a443f92cdfe7f6d36df9f7dc6f86b76b / http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/9474cbef7fcb61cd268019694d94db6a75af7dbe

https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00145.html

tl;dr: Intel CPUs ab der "Core" Serie können Floating-Point Register Inhalte per Side-Channel leaken. Anscheinend liegen dort bei der Verwendung von AES-NI die Schlüssel drin. Ist jetzt nicht allzu einfach anzuwenden, aber das Risiko besteht. Einstufung: "Moderat".

Patch des Betriebssystems reicht, kein Microcode Update nötig.

Alle anderen CPUs, auch die anderer Hersteller und Architekturen scheinen nicht betroffen zu sein.

Kriton

2018-06-14, 12:28:30

Das liest sich mal wieder wie: Wir haben Security für Performance geopfert und das holt uns jetzt ein.

Leonidas

2018-06-21, 06:40:25

OpenBSD schaltet HyperThreading wegen Spectre NG ab:
https://www.heise.de/security/meldung/Spectre-NG-Luecken-OpenBSD-schaltet-Hyper-Threading-ab-4087035.html
https://www.golem.de/news/sicherheitsbedenken-openbsd-deaktiviert-intels-hyper-threading-technik-1806-135050.html

Jetzt darf man wirklich "OMG" sagen ...

Pirx

2018-06-21, 09:37:47

bei Intel CPUs

Lurtz

2018-06-21, 09:49:24

Ouch, jetzt wirds wirklich böse.

Ganon

2018-06-21, 10:04:26

Anscheinend ist die Grundlage eine Lücke namens "tlbleed", die später noch an die Öffentlichkeit kommt: https://www.mail-archive.com/source-changes@openbsd.org/msg99159.html

Thanks to Ben Gras of VUSec for sharing an early version the research paper
with us. More details will be made public soon as 'tlbleed'.

Man hat sich für die Abschaltung entschieden, da OpenBSD nicht mit in dem geheimen Kreis der Eingeweihten mit drin ist und nicht weiß ob Intel nicht noch eine bessere Lösung hat: https://www.mail-archive.com/source-changes@openbsd.org/msg99161.html

However we wanted to get a usable mitigation for the problem into
public. Maybe Intel has solutions with less overhead. But Intel
excluded us from conversation so we don't know what those solutions
might be. So we follow a pattern of immediately releasing a rough
solution, which we can retract if a cheaper solution becomes published.

vanquish

2018-06-21, 14:29:24

Der 27. Juni wird als Release für die noch ausstehenden Lücken kolpotiert.

Our TLBleed exploit successfully leaks a 256-bit EdDSA key from libgcrypt (used in e.g. GPG) with a 98% success rate after just a single observation of a signing operation on a co-resident hyper-thread and just 17 seconds of analysis time.

:biggrin:

Jetzt weiß ich auch warum die harte große Keule von den BSD-Leuten geschwungen wird.

fondness

2018-06-21, 16:26:49

Es wurden ja nun eine weitere (zwei?) neue "Variants" veröffentlicht. Bei 3a bin ich mir gerade unsicher, aber bisher hatte nur ARM davon geredet. Aber scheinbar ist auch Intel von Variant 3a betroffen (was wohl die Neuheit hier ist?). Das ist dieses "Rogue System Register Read", was eben genau das erlaubt was es aussagt. Man kann Systemregister auslesen und somit mehr über das laufende OS herausfinden.

Dann kam noch Variant 4 hinzu. Es sagt aus:

Intel liefert hierzu Microcode Updates: https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00115.html

AMD ist wohl von Variant 3a nicht betroffen, Variant 4 aber wohl auch, wenn auch wohl nicht ganz so intensiv wie Intel (?): https://www.amd.com/en/corporate/security-updates

ARM, IBM POWER und SystemZ Systeme sind aber wohl auch betroffen: https://access.redhat.com/security/vulnerabilities/ssbd

Jedenfalls scheinen aber die Abwehrmaßnahmen in Software hier schon teilweise zu greifen (Site Isloation im Browser, schlechtere Timings über API, ...).

Sowohl Intel und als auch AMD sagen, dass man "Memory Disambiguation" zwar an lassen sollte, aber es im Zweifel auch deaktivieren kann. Bei AMD ist dies wohl schon jetzt möglich, bei Intel liefert das Microcode Update das nach. Es gibt wohl hierzu auch noch keinen sinnvollen PoC Code, der auf Allerwelts-Systemen funktionieren würde, von daher ist das eine präventive Maßnahme. Darum wird das nicht per-default abgeschaltet.

https://newsroom.intel.com/editorials/addressing-new-research-for-side-channel-analysis/

Sollte man sich für eine Abschaltung entscheiden kostet das bei Intel, laut Intel, wohl 2-8% Performance. AMD hat keine Aussage dazu getroffen, glaube ich. Die Performance-Einbußen gegen die Absicherung gegen Variant 3a kostet laut Intel <1% Performance.

So, das war jetzt eine oder zwei neue Lücken, fehlen ja noch ein paar, aber das dauert ja noch bis August.

Und wieder ist AMD am wenigsten betroffen^^.

Th3o

2018-06-21, 16:53:57

Bei Intel rächt sich jetzt das ewige Festhalten an dem alten Design. Ich nehme an, dass viele diese Probleme AMD bewusst oder bekannt waren und beim Zen-Design berücksichtigt wurden.

StefanV

2018-06-21, 20:15:46

Bei Intel rächt sich jetzt das ewige Festhalten an dem alten Design. Ich nehme an, dass viele diese Probleme AMD bewusst oder bekannt waren und beim Zen-Design berücksichtigt wurden.
Es ist nicht zwangsläufig das "alte Design" sondern schlicht die Entscheidung für Performance - ohne Rücksicht auf Verluste.

Und die Verluste sind eben die hier aufgedeckten Lücken.

Dass Intel davon nicht wusste ist unglaubwürdig. Da wird es mit Sicherheit einige Leute gegeben haben, die gesagt haben "ähm, Leute, das is 'ne doofe Idee, weil unsicher" und "von oben" überstimmt wurden...

kruemelmonster

2018-06-21, 21:44:18

Schnapsidee: Könnte man diesen Microcode irgendwie entpacken und in Win7 verwenden? Oder hätte das eh keinen Effekt weil der Kernel es nicht nutzen kann?

MfG
RooterAndere Idee: Patch' dir mit dem UBU den aktuellen Microcode selbst in dein Bios rein. Hab ich mit dem Asus P8Z68-V Pro schon durch, klappt problemlos.

Sorry, hatte den Link vergessen: https://www.win-raid.com/t154f16-Tool-Guide-News-quot-UEFI-BIOS-Updater-quot-UBU.html , sowie zu erwähnen dass UBU für "UEFI BIOS Updater" steht.

Ganon

2018-06-21, 23:43:52

Dass Intel davon nicht wusste ist unglaubwürdig. Da wird es mit Sicherheit einige Leute gegeben haben, die gesagt haben "ähm, Leute, das is 'ne doofe Idee, weil unsicher" und "von oben" überstimmt wurden...

Und dann hat man noch Saboteure in alle anderen betroffenen CPU-Hersteller eingeschleust, damit sie leicht abgewandelt ähnliche Fehler einbauen, damit Intel dann bei etwaiger Entdeckung nicht so alleine da steht...

Complicated

2018-06-22, 01:00:00

Nein, AMD benutzt vollständige Adressen in der branch prediction und hat mit seinen HSA Anforderungen für Kohärenz einiges sicherer konzipiert beim Cache.

Intel steht alleine da mit dem Ausmaß der Sicherheitslücken. Das zeigt auch das deaktivieren von HT bei OpenBSD.

Ganon

2018-06-22, 01:14:50

Es gibt nur weitaus mehr CPU-Hersteller als "Intel" und "AMD". Ich weiß ich weiß, wurde im Thread bisher nur 282384 mal erwähnt, das überliest man schnell.

StefanV

2018-06-22, 01:59:16

Und dann hat man noch Saboteure in alle anderen betroffenen CPU-Hersteller eingeschleust, damit sie leicht abgewandelt ähnliche Fehler einbauen, damit Intel dann bei etwaiger Entdeckung nicht so alleine da steht...
Bei welchen anderen Herstellern ist denn Meltdown noch implementiert? (OK; gibt Berichte dass ein ARM Design dafür auch anfällig sein soll)
Worte Leuten in den Mund zu legen ist ganz schlechter Stil...

Bisher ist Intel von dem ganzen Zeugs am schlimmsten betroffen, warum versuchst du diese Bude zu verteidigen, mit Finger auf andere zu Zeigen?!

Es gibt nur weitaus mehr CPU-Hersteller als "Intel" und "AMD". Ich weiß ich weiß, wurde im Thread bisher nur 282384 mal erwähnt, das überliest man schnell.
dann zeig mal Proof of Concept Exploits auf ARM, IBM Power und PowerPC, MIPS, SPARC und co...

gravitationsfeld

2018-06-22, 05:25:06

Es ist trotzdem unwahrscheinlich, dass es Vorwand war.

urpils

2018-06-22, 06:34:31

Bei welchen anderen Herstellern ist denn Meltdown noch implementiert? (OK; gibt Berichte dass ein ARM Design dafür auch anfällig sein soll)
Worte Leuten in den Mund zu legen ist ganz schlechter Stil...

gesetzt dem Fall dass du Meltdown und verwandte Angriffe meinst:

Apple (https://support.apple.com/en-us/HT208394)
ARM in unterschiedlichem Maße - aber quer durch die Bank (https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability)
Qualcomm und Samsung halten sich da sehr bedeckt - wegen obigem ARM-Link kann man aber von einer Betroffenheit ausgehen - ansonsten hätten sie diverse "wir sind besser"-Pressemitteilungen rausgehauen ;)

StefanV

2018-06-22, 06:39:16

Es ist trotzdem unwahrscheinlich, dass es Vorwand war.
Richtig, aber man hat es "billigend in Kauf genommen" aka grob fahrlässig gehandelt.

Complicated

2018-06-22, 07:34:18

aber quer durch die Bank (https://developer.arm.com/support/arm-security-updates/speculative-processor-vulnerability)
- wegen obigem ARM-Link kann man aber von einer Betroffenheit ausgehen - ansonsten hätten sie diverse "wir sind besser"-Pressemitteilungen rausgehauen ;)
Zeig mal wo AMDs derartige Pressemitteilung ist. Die hätten allen Grund dazu. Von "einer Betroffenheit auszugehen" ändert nichts daran, dass Intel damit die größten Probleme hat. PoCs sind im Umlauf zu JEDEM der Exploits.

Ganon

2018-06-22, 08:26:00

Bei welchen anderen Herstellern ist denn Meltdown noch implementiert? (OK; gibt Berichte dass ein ARM Design dafür auch anfällig sein soll)

Meltdown ist nicht "implementiert"... es ist das Konzept einer Sicherheitslücke die sich je Prozessor anders zeigen kann. ARM, Apple und IBM sind ebenso betroffen. Warum sollten all diese Hersteller sagen, dass sie betroffen sind und Fixes in ihre Betriebssysteme einbauen und/oder neue Firmware rausbringen, wenn es doch angeblich nur Intel ist?

Variant 3a wurde sogar zuerst auf ARM entdeckt und konnte erst später auf Intel CPUs nachgewiesen werden.

Bisher ist Intel von dem ganzen Zeugs am schlimmsten betroffen, warum versuchst du diese Bude zu verteidigen, mit Finger auf andere zu Zeigen?!

Es ist einfach nur Quatsch anzunehmen, dass Intel den Kram absichtlich eingebaut hat oder sogar (langfristig) davon gewusst hat. Was ist so schlimm daran anzunehmen, dass Sicherheitslücken einfach gefunden werden und der Hersteller davon nichts wusste? Weil man Intel sonst nicht ins schlechtere Licht rücken kann?

Dass Intel hier Mist gebaut hat, ist klar... aber gleich verschwörerisch Vorwand da reinzuinterpretieren ist einfach albern.

dann zeig mal Proof of Concept Exploits auf ARM, IBM Power und PowerPC, MIPS, SPARC und co...

Sorry, aber was soll der Quatsch jetzt wieder? Wie oft denn noch bitte? Du fragst dauernd nach PoC und wenn man sie dir gibt, gehst du 0 darauf ein... dann fragst du wieder nach PoC?

Das sind einfach Sachen die vom Hersteller _bestätigt_ sind.

Pirx

2018-06-22, 08:41:46

...
... Was ist so schlimm daran anzunehmen, dass Sicherheitslücken einfach gefunden werden und der Hersteller davon nichts wusste? Weil man Intel sonst nicht ins schlechtere Licht rücken kann?
...
Das ist nicht schlimm, aber es ist bei den Koryphäen, die dort seit Jahrzehnten am CPU-Design arbeiten sehr wahrscheinlich, daß auch einigen diese Auswirkung der Designentscheidung bewusst war.

Lowkey

2018-06-22, 08:52:44

Neues Bios für den z270 samt ME Update uuuund:

https://abload.de/img/specmeltquke1.jpg

Vorher lief das Tool nicht richtig.

fondness

2018-06-22, 08:55:47

Es gibt nur weitaus mehr CPU-Hersteller als "Intel" und "AMD". Ich weiß ich weiß, wurde im Thread bisher nur 282384 mal erwähnt, das überliest man schnell.

Richtig, IBM und ARM sind bsw. auch deutlich stärker betroffen als AMD. Was meine Aussage noch untermauert, AMD baut die sichersten CPUs am Markt.

Ganon

2018-06-22, 09:30:00

Das ist nicht schlimm, aber es ist bei den Koryphäen, die dort seit Jahrzehnten am CPU-Design arbeiten sehr wahrscheinlich, daß auch einigen diese Auswirkung der Designentscheidung bewusst war.

Wie wir ja schon mal diskutiert hatten. Die Lücken sind ja teilweise schon ewig drin (zurück bis zum Pentium). Die Idee, dass man Seitenkanal-Angriffe auf CPUs ausführen könnte, ist aber noch gar nicht sooo alt. Die erste Überlegung dazu auch erst nach dem Jahr 2000 (hab das genaue Jahr nicht mehr im Kopf), konnte aber es aber praktisch nicht beweisen, dass diese Idee umsetzbar ist.

Erst seit kurzem kam dieser Beweis. Natürlich wissen die Intel Mitarbeiter wie ihre CPUs funktionieren. Aber die Verbindung "der Prozessor arbeitet so und so" und "das ist ein Sicherheitsproblem" muss meiner Meinung nach nicht unbedingt vorhanden gewesen sein.

Richtig, IBM und ARM sind bsw. auch deutlich stärker betroffen als AMD. Was meine Aussage noch untermauert, AMD baut die sichersten CPUs am Markt.

Kann man so sagen, ja. Leider halten mich dort (https://community.amd.com/thread/225795) anderweitig (https://bugzilla.redhat.com/show_bug.cgi?id=1548961) Dinge (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085) ab, (https://www.reddit.com/r/Amd/comments/85fp06/ryzen_low_power_state_soft_lock_still_ongoing/) zuzugreifen (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11705500&postcount=1653).

Loeschzwerg

2018-06-22, 09:34:56

Kann man so sagen, ja.

Bezogen auf den Massenmarkt ;)

fondness

2018-06-22, 09:35:25

Kann man so sagen, ja. Leider halten mich dort (https://community.amd.com/thread/225795) anderweitig (https://bugzilla.redhat.com/show_bug.cgi?id=1548961) Dinge (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1690085) ab, (https://www.reddit.com/r/Amd/comments/85fp06/ryzen_low_power_state_soft_lock_still_ongoing/) zuzugreifen (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11705500&postcount=1653).

Eine Folge des trägen Linux-System in Kombination mit einer neuen CPU-Architektur. Ganz davon abgesehen, dass man mit Sicherheit auch zu Intel-CPUs solche Dinge finden wird können.

Ganon

2018-06-22, 09:41:02

Eine Folge des trägen Linux-System in Kombination mit einer neuen CPU-Architektur. Ganz davon abgesehen, dass man mit Sicherheit auch zu Intel-CPUs solche Dinge finden wird können.

Ich will das Thema auch gar nicht so breit treten hier. Aber das Problem betrifft nicht nur Linux (https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-BSD-Lock-Ups-2018). Da bisher niemand weiß wo das Problem eigentlich genau liegt und AMD das ganze totschweigt kaufe ich aktuell einfach gar kein x86 System.

Dient nur zum Verständnis, warum ich jetzt auch nach der ganzen Intel Misere keine Loblieder auf AMD singe.

vanquish

2018-06-22, 10:46:26

AMD has identified an issue with the Linux cpuidle subsystem whereby a system using a newer kernel(4.13 or newer) with SMT enabled (BIOS default) and global C state control enabled (also BIOS default) may exhibit an unexpected reboot. The likelihood of this reboot is correlated with the frequency of idle events in the system. AMD has released updated system firmware to address this issue. Please contact your system provider for a status on this updated system firmware. Prior to the availability of this updated system firmware, you can work around the issue with the following option:

Boot the kernel with the added command line option idle=nomwait

Wenn ich mir das andere so ansehe sind das die "üblichen" Bugs heutzutage, die auch Intel hat/hatte. Sie sind leider unvermeidlich. Da brauch ich auch nicht auf andere/neuere x86-CPUs warten.

Ich für meinen Teil habe meinen i3 und i5 Haswell bereits ersetzt. Der i7 Haswell fliegt mit Zen2 raus. Mein HP Haswell i3 Notebook wird mir wohl bis zu dessen Tod erhalten bleiben. Bei meinem HP Skylake i5 Notebook bin ich mir noch nicht sicher was ich machen soll. Aber je mehr schwerwiegende Lücken hinzukommen, desto wahrscheinlicher wird es das ich das Ding auch "entsorgen" werde.

Es mag sein, dass AMD noch andere Bugs für mich bereit hält. Bisher hatte ich mit meinem 2600 keinerlei Probleme. Der 2200g hingegen benötigte 2 Bios Updates von ASUS bis CPU und GPU "einwandfrei" (unter Linux) liefen. Ganz bugfrei ist die Linux Unterstützung der GPU leider noch nicht (zwei Grafikkarten stören sich). Da der 2200g bei mir aber ohnehin nur als Server läuft, und die GUI nur zu Spiel-/Testzwecken lief, ist mir das eigentlich egal.

Ganon

2018-06-22, 11:14:38

Bezogen auf den Massenmarkt ;)

Eher bezogen auf leistungsfähige Systeme :D Dagegen immune Prozessoren sind natürlich weiterhin wesentlich sicherer, aber wer will schon auf Billig-Smartphone Prozessoren umsteigen? So ein 2 Ghz 8-Core ARM A53 klingt natürlich erst mal verlockend, ist aber trotzdem lahm ohne Ende.

@vanquish

Ja letztendlich muss jeder für sich selbst entscheiden. Mir persönlich ist gerade die Lücke die Intel gerne bis August verschwiegen haben will viel zu heiß. Auf der anderen Seite hat AMD Probleme ihre Prozessoren auf Nicht-Windows dauerhaft stabil zum Laufen zu kriegen. Und ich hab halt weder Lust auf große Sicherheitskatastrophen, noch auf instabile Systeme.

Vielleicht wird ja Zen 2 was, in der Hoffnung, dass AMD hier auch auf Nicht-Windows testet.

fondness

2018-06-22, 11:28:46

Auf der anderen Seite hat AMD Probleme ihre Prozessoren auf Nicht-Windows dauerhaft stabil zum Laufen zu kriegen.

Eine maßlose Übertreibung.

eratte

2018-06-22, 11:48:38

Eine maßlose Übertreibung.

Wundert mich als meist nur Lesender nicht, alleine das hier zu thematisieren abseits des eigentlichen Topics spricht Bände.

StefanV

2018-06-22, 11:58:09

Eine maßlose Übertreibung.

Man muss sich halt, wie immer, die AMD Prozessoren schlecht und die Intel Prozessoren schön reden.
Das hat schon beim K8 damals geklappt, als wir noch mit Single Core CPUs unterwegs waren und Intel 'ne SMT Variante implementiert hat.

Das klappt auch jetzt ganz gut, leider.

Warum man diese Fehler so klein redet und sie als "überhaupt kein Problem" versucht darzustellen, verstehe ich nicht...
Man stelle sich mal die Situation umgekehrt vor. Wie die Leute dann drüber reden würden...

Dabei sprachen wir noch eine Seite vorher oder so darüber, dass die BSD Entwickler aufgrund der nächsten Nachwehen zu diesem Thema "erst einmal" SMT abgeschaltet haben, weil man das auch für den Zugriff auf Daten von der anderen Hälfte des Kerns nutzen kann...

da wird einem schon ganz mulmig, was sonst noch so auf uns zu kommen wird...

aufkrawall

2018-06-22, 12:11:59

Nicht "die BSD-Entwickler", sondern "die Open BSD-Entwickler". Die haben übrigens auch gesagt, HTT würd meist nichts bringen...

Wie schlimm der C6-Bug von AMD unter Linux wirklich ist, ist schwer einzuschätzen. Btw. ist es eine Unsinnsbehauptung, dass Linux da irgendwie träge wäre. Der schwarze Peter liegt dafür komplett auf AMD-Seite.
Edit: Evtl. noch bei den Boards, wo AMD durch Agesa aber auch einen großen Teil der Verantwortung trägt.

Megamember

2018-06-22, 13:11:55

Man muss sich halt, wie immer, die AMD Prozessoren schlecht und die Intel Prozessoren schön reden.
.

Zum Glück bist du neutral und redest nie irgendwas schlecht was nicht gerade von Amd kommt.:wink:

lumines

2018-06-22, 13:24:01

Dabei sprachen wir noch eine Seite vorher oder so darüber, dass die BSD Entwickler aufgrund der nächsten Nachwehen zu diesem Thema "erst einmal" SMT abgeschaltet haben, weil man das auch für den Zugriff auf Daten von der anderen Hälfte des Kerns nutzen kann...

da wird einem schon ganz mulmig, was sonst noch so auf uns zu kommen wird...

Die Leute bei OpenBSD gehen praktisch immer den Weg, dass sie Performance im Zweifelsfall gegen ein simpleres Design tauschen. Auch LibreSSL ist verglichen mit OpenSSL unglaublich langsam. Das zieht sich durch das gesamte System. OpenBSD ist teilweise massiv langsamer als vergleichbare Software. Manchmal bringt das was, aber manchmal auch nicht. Auch der gute Theo ist kein Heiliger. OpenBSD nennt sich nicht umsonst proaktiv sicher. Viele Entscheidungen haben auch einfach keinen praktischen Nutzen, sondern sind einfach nur eine Vorsichtsmaßnahme. Das funktioniert für sie gut, weil das eben ihr einziges großes Ziel ist, aber hinter den Entscheidungen stecken nicht immer 100% rationale Gründe.

Du suchst immer nach Verschwörungen, aber Seitenkanalangriffe sind eben unglaublich schwierig zu vermeiden und eher der Normalzustand, den man aber natürlich irgendwie vermeiden will. Da entscheidet sich niemand bewusst bestimmte Lücken einzubauen um mehr Performance rauszukitzeln.

Dass Intel davon nicht wusste ist unglaubwürdig. Da wird es mit Sicherheit einige Leute gegeben haben, die gesagt haben "ähm, Leute, das is 'ne doofe Idee, weil unsicher" und "von oben" überstimmt wurden...

Du stellst dir das ein bisschen zu einfach vor. Der Witz bei Seitenkanalangriffen ist ja gerade, dass die sich nicht isoliert im Design der Software oder CPU zeigen. Ansonsten wäre es ja kein Seitenkanal.

Du denkst, dass das klare Probleme sind, wo jemand einmal mit dem Finger draufgezeigt hat und dann wurde das in Kauf genommen. So funktionieren diese Lücken aber nicht. Das sind einfach Konsequenzen daraus, wie CPUs heute ganz fundamental funktionieren.

Rabiata

2018-06-22, 14:08:46

Meltdown ist nicht "implementiert"... es ist das Konzept einer Sicherheitslücke die sich je Prozessor anders zeigen kann. ARM, Apple und IBM sind ebenso betroffen. Warum sollten all diese Hersteller sagen, dass sie betroffen sind und Fixes in ihre Betriebssysteme einbauen und/oder neue Firmware rausbringen, wenn es doch angeblich nur Intel ist?

Variant 3a wurde sogar zuerst auf ARM entdeckt und konnte erst später auf Intel CPUs nachgewiesen werden.
Ahem...

<korinthenkack>
Apple verwendet auf breiter Front Intel-CPUs. Sogar ich als bekennender Apple-Nichtuser habe das mitbekommen. Damit sind sie natürlich mitbetroffen, aber nicht durch eigene "Schuld".
</korinthenkack>

Ansonsten sind Sicherheitslücken bei ARM und IBM grundsätzlich ein Thema, aber 3DCenter befaßt sich hauptsächlich mit Gaming-tauglicher PC-Hardware.
Das bedeutet in der Praxis x86, da andere Architekturen in diesem Bereich keine nennenswerte Rolle spielen. Wenn ARM und IBM hier im Forum ignoriert werden, so ist das aus der Perspektive der Forenteilnehmer legitim.

Ganon

2018-06-22, 14:21:16

<korinthenkack>
Apple verwendet auf breiter Front Intel-CPUs. Sogar ich als bekennender Apple-Nichtuser habe das mitbekommen. Damit sind sie natürlich mitbetroffen, aber nicht durch eigene "Schuld".
</korinthenkack>

Ich hoffe du konntest dich beim Kacken angenehm erleichtern... ich rede nämlich von Apples eigenen A CPUs in iPhone und iPad...

Wenn ARM und IBM hier im Forum ignoriert werden, so ist das aus der Perspektive der Forenteilnehmer legitim.

Die Leute dürfen gerne Fakten ignorieren wie sie wollen, ändert aber schlicht nichts daran, dass das hier alles kein Intel-Only Problem ist. Und ARM Prozessoren sind hier sehr wohl ein Thema.
Vielleicht wird tlbleed das erste Intel Only Problem, da es nur relativ wenige Hyper Threading CPUs gibt (bleibt nur noch Intel, AMD und IBM). Das werden wir dann ja sehen, wenn Details veröffentlicht werden.

aufkrawall

2018-06-22, 14:40:34

Es will auch irgendwie nicht verfangen, dass AMD vor Zen sehr lange Zeit eben nicht als Alternative zu Intel in Servern existierte, weil die Produkte schlicht Müll waren...

Opprobrium

2018-06-22, 14:48:44

Es will auch irgendwie nicht verfangen, dass AMD vor Zen sehr lange Zeit eben nicht als Alternative zu Intel in Servern existierte, weil die Produkte schlicht Müll waren...
Was a) jeder weiß und b) Null mit dem Thema zu tun hat :cool:

Pirx

2018-06-22, 14:51:28

Es will auch irgendwie nicht verfangen, dass AMD vor Zen sehr lange Zeit eben nicht als Alternative zu Intel in Servern existierte, weil die Produkte schlicht Müll waren...
Du scheinst nur Extreme zu kennen.

Birdman

2018-06-22, 14:56:04

dass AMD vor Zen sehr lange Zeit eben nicht als Alternative zu Intel in Servern existierte
Ist heute noch so, darum interessiert es auch keinen, dass es für Ryzen, bzw. Epyc noch keinerlei Spectrev2 Schutz unter Windows Serverbetriebssystemen gibt.

Ob man nun für aktuelle AMD CPU's überhaupt einen entsprechenden Patch braucht oder nicht, darüber lässt sich wohl streiten.
Im professionellen Server/Virtualisierung Umfeld halte ich es aber für gefährlich, hier keine Absicherung zu haben - und sei dies nur aus rechtlicher Sicht. (aka, das möglichste getan zu haben, was man zum Zeitpunkt X machen kann)

aufkrawall

2018-06-22, 14:59:56

Du scheinst nur Extreme zu kennen.
Du scheinst den Marktanteil von AMD bei Servern nicht zu kennen.
Der ist übrigens extrem niedrig.

vanquish

2018-06-22, 15:14:27

@vanquish

Ja letztendlich muss jeder für sich selbst entscheiden. Mir persönlich ist gerade die Lücke die Intel gerne bis August verschwiegen haben will viel zu heiß. Auf der anderen Seite hat AMD Probleme ihre Prozessoren auf Nicht-Windows dauerhaft stabil zum Laufen zu kriegen. Und ich hab halt weder Lust auf große Sicherheitskatastrophen, noch auf instabile Systeme.

Vielleicht wird ja Zen 2 was, in der Hoffnung, dass AMD hier auch auf Nicht-Windows testet.

Ja, letztendlich muss das jeder für sich selbst bewerten. Ich habe mir gedacht, dass ich für die Haswell Systeme derzeit noch in etwa die Hälfte dessen bekomme was die neuen Systeme kosten. Was einem die Speicherpreise leider zunichte machen. Mit 8 GB stimmt die Rechnung aber noch. ;)

Meine Überlegung ist halt, dass vor Ende/2019 keine dieser Lücken (auch die die noch kommen) jemals in Hardware als Fix zur Verfügung stehen werden. Wahrscheinlicher ist sogar (meine persönliche Einschätzung), dass es bei Microcode Fixes bleibt bis vielleicht Ende 2021 / Anfang 2022 (wenn es denn so schnell geht) eine überarbeitete Architektur bei Intel an den Start geht. Daher gibt es für mich keinen optimalen Umstiegszeitpunkt mehr. Ich hatte vor meine Systeme mit erscheinen des Zen 2 zu ersetzen. Jetzt sammle ich halt schon etwas früher Erfahrung mit AMD Systemen und habe gleichzeitig etwas mehr Sicherheit. Was dann 2021/22 passiert wird sich zeigen. Dann sind meine "neuen" Systeme auch schon wieder ~3 Jahre alt und man kann über einen erneuten Wechsel nachdenken.

DrumDub

2018-06-22, 15:18:55

lustig. acer versteckt die bios updates bzgl. meltdown. & spectre auf ner eigenen seite (https://in.answers.acer.com/app/answers/detail/a_id/53107/~/meltdown-and-spectre-security-vulnerabilities). beim produkt selber findet man die nicht.

sieht jetzt so aus (wegen windows 7) nach dem bios update:
https://abload.de/img/specj5jzt.jpg

Ganon

2018-06-22, 15:46:34

Meine Überlegung ist halt, dass vor Ende/2019 keine dieser Lücken (auch die die noch kommen) jemals in Hardware als Fix zur Verfügung stehen werden.

Ja, auf ein Hardware-Fix kann man vermutlich noch lange warten. Aktuell geht's mir halt nur um das was jetzt "angekündigt" ist. Und jetzt nehmen wir mal an man würde jetzt einen Intel i7 holen, nur um dann in 1-2 Monaten festzustellen, dass Intel partiell Hyper Threading deaktivieren muss. Der Fix kann natürlich anders aussehen, aber es zeichnet sich halt ab, dass da irgendwas kaputt ist.

"Nach dem Sturm" kann man dann neu bewerten :D

lustig. acer versteckt die bios updates bzgl. meltdown. & spectre auf ner eigenen seite (https://in.answers.acer.com/app/answers/detail/a_id/53107/~/meltdown-and-spectre-security-vulnerabilities). beim produkt selber findet man die nicht.

Ich hab gerade mal bei ASRock nachgesehen. Für mein 5 Jahre altes Mainboard gab es anscheinend Ende Mai ein BIOS Upgrade: https://www.asrock.com/mb/Intel/Fatal1ty%20H87%20Performance/index.de.asp?cat=Beta#BIOS

=Floi=

2018-06-22, 15:55:18

ich finde ehrlich gesagt die intel ME viel gefährlicher. Hier hofft man doch auch alles per software fixen zu können und ich als user kann nichts daran machen.

gravitationsfeld

2018-06-22, 18:40:45

Richtig, aber man hat es "billigend in Kauf genommen" aka grob fahrlässig gehandelt.
Nein. Man hat sehr wahrscheinlich einfach nichts davon gewusst. Der Exploit ist extrem esoterisch, da hat keiner dran gedacht.

lumines

2018-06-22, 19:18:47

Nein. Man hat sehr wahrscheinlich einfach nichts davon gewusst. Der Exploit ist extrem esoterisch, da hat keiner dran gedacht.

Von außen ist das allerdings auch schwierig nachzuvollziehen. Die Komplexität moderner CPUs (und Software) macht es praktisch unmöglich alles zu überblicken, aber nach außen hin wird durch Marketing und die Kultur der meisten Unternehmen natürlich der Eindruck erweckt, dass irgendwer, irgendwo schon weiß, was er da macht. Praktisch ist es aber wahrscheinlich unmöglich, dass überhaupt ein einziges Unternehmen das jemals alleine in den Griff bekommen wird.

TGKlaus

2018-06-22, 19:36:11

Auf der anderen Seite hat AMD Probleme ihre Prozessoren auf Nicht-Windows dauerhaft stabil zum Laufen zu kriegen.

Kommt hier auch irgendein Nachweis, das Ryzen 2 irgendwelche entsprechenden Probleme hat oder bleibt dieser Lügenmist so stehen?

aufkrawall

2018-06-22, 20:12:30

https://bugzilla.kernel.org/show_bug.cgi?id=196683
Man kann sich sicherlich auch noch bei Gentoo durchwühlen und mehr finden...

Denniss

2018-06-22, 23:33:04

Schon komisch, da entfernt einer vom IBM CONFIG_RCU_NOCB_CPU_ALL und zwei verwandte Befehle aus dem Kernel (werden nur zum Testen verwendet ......) und AMD bekommt Probleme mit der Stabilität. Scheinbar ohne das auf einer Vielzahl von Systemen zu testen.
Ein Schelm wer da was Böses denkt

gravitationsfeld

2018-06-23, 08:29:31

Von außen ist das allerdings auch schwierig nachzuvollziehen. Die Komplexität moderner CPUs (und Software) macht es praktisch unmöglich alles zu überblicken, aber nach außen hin wird durch Marketing und die Kultur der meisten Unternehmen natürlich der Eindruck erweckt, dass irgendwer, irgendwo schon weiß, was er da macht. Praktisch ist es aber wahrscheinlich unmöglich, dass überhaupt ein einziges Unternehmen das jemals alleine in den Griff bekommen wird.
Ich weiss nich wie ich das rueberbringen soll, aber ich kenne keinen Programmierer, der den Exploit auf Anhieb nachvollziehen konnte. Es braucht schon ziemlich viel kreative Energie um darauf zu kommen die spekulative Ausfuehrung so auszunutzen. Das ist ausserhalb von Security-Research einfach nicht relevant.

Die Intel-Ingineure haben drei Vorgaben: Power runter, Performance rauf und die Instructions muessen das machen was spezifiziert ist. Und das ist alles gegeben. Keine der verwundbaren CPUs hat irgend eine Luecke in der Spec oder wie die Befehle ausgefuehrt werden. Das ist immer das Problem an Sidechannel-Attacks.

Der Grund warum Intel verwundbar ist, ist ironischerweise gerade weil sie so gut daran sind spekulative Ausfuehrung so sehr ausnutzen. Sie haben es soweit getrieben, dass sie selbst bei Zugriffen auf den Kernel vom Userspace die Pipeline nicht leeren muessen. Das ist was Performance angeht gerade bei I/O lastigen Angelegenheiten super und auf Chip eben echt nicht einfach zu machen. Deshalb ja auch die komischen Fixes wie "Retpolines", wo einfach so lange ueber Indirektionen gesprungen wird bis die CPU die Spekulation aufgibt.

Ich bleibe dabei, ich seh da null Vorsatz. Die Erklaerung, dass solche Luecken einfach nicht in ihren Sinn kamen ist nach Ockhams Rasiermesser die viel schluessigere Erklaerung.

Armaq

2018-06-23, 09:45:49

Ich weiss nich wie ich das rueberbringen soll, aber ich kenne keinen Programmierer, der den Exploit auf Anhieb nachvollziehen konnte. Es braucht schon ziemlich viel kreative Energie um darauf zu kommen die spekulative Ausfuehrung so auszunutzen. Das ist ausserhalb von Security-Research einfach nicht relevant.

Die Intel-Ingineure haben drei Vorgaben: Power runter, Performance rauf und die Instructions muessen das machen was spezifiziert ist. Und das ist alles gegeben. Keine der verwundbaren CPUs hat irgend eine Luecke in der Spec oder wie die Befehle ausgefuehrt werden. Das ist immer das Problem an Sidechannel-Attacks.

Der Grund warum Intel verwundbar ist, ist ironischerweise gerade weil sie so gut daran sind spekulative Ausfuehrung so sehr ausnutzen. Sie haben es soweit getrieben, dass sie selbst bei Zugriffen auf den Kernel vom Userspace die Pipeline nicht leeren muessen. Das ist was Performance angeht gerade bei I/O lastigen Angelegenheiten super und auf Chip eben echt nicht einfach zu machen. Deshalb ja auch die komischen Fixes wie "Retpolines", wo einfach so lange ueber Indirektionen gesprungen wird bis die CPU die Spekulation aufgibt.

Ich bleibe dabei, ich seh da null Vorsatz. Die Erklaerung, dass solche Luecken einfach nicht in ihren Sinn kamen ist nach Ockhams Rasiermesser die viel schluessigere Erklaerung.
Ich stimme dir komplett zu. Nur ist die Frage wie lange sie von dieser Art von Angriff schon wussten und so getan haben, als wäre nichts.

Problem dabei ist doch, dass es leider pfiffige Kerlchen gibt, die diese Attacken jetzt in Software umsetzen.

Pirx

2018-06-23, 10:12:46

...
Der Grund warum Intel verwundbar ist, ist ironischerweise gerade weil sie so gut daran sind spekulative Ausfuehrung so sehr ausnutzen. Sie haben es soweit getrieben, dass sie selbst bei Zugriffen auf den Kernel vom Userspace die Pipeline nicht leeren muessen. Das ist was Performance angeht gerade bei I/O lastigen Angelegenheiten super und auf Chip eben echt nicht einfach zu machen. Deshalb ja auch die komischen Fixes wie "Retpolines", wo einfach so lange ueber Indirektionen gesprungen wird bis die CPU die Spekulation aufgibt.

Ich bleibe dabei, ich seh da null Vorsatz. Die Erklaerung, dass solche Luecken einfach nicht in ihren Sinn kamen ist nach Ockhams Rasiermesser die viel schluessigere Erklaerung.
Wenn sich absolute Top-Fachleute, die sicher auch sehr früh Kenntnis von dieser Art der Angriffsmöglichkeit hatten, so sehr mit der Materie auseinandersetzen, ist es doch sehr wahrscheinlich, daß der eine oder andere darauf kommt, daß hier eine Gefahr vorliegt. Vorsatz sehe ich erstmal auch nicht, ist aber auch nicht ausgeschlossen.

fondness

2018-06-23, 10:55:12

https://bugzilla.kernel.org/show_bug.cgi?id=196683
Man kann sich sicherlich auch noch bei Gentoo durchwühlen und mehr finden...

Wenn ich da nach Intel suche finde ich auch so einiges. Darüber hinaus: Warum tritt es dann unter Windows nicht auf? Könnte genauso gut ein Linux-Problem sein bzw. was am wahrscheinlichsten ist ein komplexes Zusammenspiel von Hard- und Software, das unter ganz bestimmten Bedingungen bla... Generell zu behaupten die CPU sei instabil, weil eine beschränkte Anzahl an Usern offenbar nach Tagen Abstürze hat, welche an allem möglichen liegen kann, halte ich jedenfalls für maßlos übertrieben.

Der Grund warum Intel verwundbar ist, ist ironischerweise gerade weil sie so gut daran sind spekulative Ausfuehrung so sehr ausnutzen. Sie haben es soweit getrieben, dass sie selbst bei Zugriffen auf den Kernel vom Userspace die Pipeline nicht leeren muessen. Das ist was Performance angeht gerade bei I/O lastigen Angelegenheiten super und auf Chip eben echt nicht einfach zu machen. Deshalb ja auch die komischen Fixes wie "Retpolines", wo einfach so lange ueber Indirektionen gesprungen wird bis die CPU die Spekulation aufgibt.

Selbst ARM ist deutlich stärker betroffen als AMD und die sind jetzt nicht unbedingt für High-Performace-CPUs bekannt. Von daher scheint AMD entweder deutlich schlechte bei speculative Execution zu sein (und damit die Performance woanders raus zu holen), oder AMD war sich dessen bewusst oder es ist wirklich nur Zufall.

lumines

2018-06-23, 11:12:04

Ich stimme dir komplett zu. Nur ist die Frage wie lange sie von dieser Art von Angriff schon wussten und so getan haben, als wäre nichts.

Vielleicht war es auch eher so:

https://abload.de/img/dzky_yzxuaeozfcquslo.jpeg

Das moderne Gegenstück: https://twitter.com/dakami/status/1010451182962130944

aufkrawall

2018-06-23, 11:18:42

Wenn ich da nach Intel suche finde ich auch so einiges.

Ich habe für non-Mobile CPUs von Intel nichts gefunden.

fondness

2018-06-23, 11:19:42

Ich habe für non-Mobile CPUs von Intel nichts gefunden.

Was hat das mit mobile vs. non-mobile zu tun?

aufkrawall

2018-06-23, 11:25:09

Was hat das mit mobile vs. non-mobile zu tun?
Weil Mobile einen riesigen Rattenschwanz zusätzlicher Probleme bereitet, siehe Raven Ridge.

Complicated

2018-06-23, 12:06:26

AMD benutzt vollständige Speicheradressen in der branch prediction im Gegensatz zu Intel. Daher sind diese Sidechannel-Attacken fast unmöglich.

Bartfratze

2018-06-23, 12:17:18

Könnte genauso gut ein Linux-Problem [1] sein [...] Generell zu behaupten die CPU sei instabil, weil eine beschränkte Anzahl [2] an Usern offenbar nach Tagen [3] Abstürze hat, welche an allem möglichen [1] liegen kann, halte ich jedenfalls für maßlos übertrieben.

[1] Deswegen tritt es auch unter verschiedenen Distributionen mit unterschiedlich konfiguriert komplilierten Kerneln auf und unter FreeBSD? :rolleyes:
[2] Weil ja auch alle Betroffene in Bugtracker schreiben. Immer. :rolleyes:
[3] Meinten Sie "Nach Minuten"?

Du relativierst schon gar nicht mehr, du untertreibst bereits. Warum ziehst du dich eigentlich an @Ganons Aussage so auf? Er schrieb doch lediglich, dass für ihn beide Hersteller zur Zeit unzumutbar verbuggte CPUs anbieten und er diesen Scheiß nicht kauft. IMO vernünftig.

StefanV

2018-06-23, 12:27:14

[1] Deswegen tritt es auch unter verschiedenen Distributionen mit unterschiedlich konfiguriert komplilierten Kerneln auf und unter FreeBSD? :rolleyes:
Kernel und systemd sind halt die gleichen.
Und abschreiben ist ja erlaubt...

Aber ist doch nix neues, dass die Leute versuchen Intels Fehler unter den Teppich zu kehren und was auch immer AMD macht, wird gleich aufgebauscht.

Und woher weißt du, dass der Bug in Linux nicht von Intel verursacht wurde? Und Intel 'nen paar Groschen springen lassen hat, um das so hin zu biegen, dass es gerade nicht gut auf AMD läuft??

Monsta

2018-06-23, 12:38:30

Kernel und systemd sind halt die gleichen.
Und abschreiben ist ja erlaubt...

Aber ist doch nix neues, dass die Leute versuchen Intels Fehler unter den Teppich zu kehren und was auch immer AMD macht, wird gleich aufgebauscht.

Und woher weißt du, dass der Bug in Linux nicht von Intel verursacht wurde? Und Intel 'nen paar Groschen springen lassen hat, um das so hin zu biegen, dass es gerade nicht gut auf AMD läuft??

Kernel können unterschiedlich sein trotz gleicher Versionsnummer.

Als ob Intel so etwas nötig hätte. Halte ich für total den Schwachsinn, wenn so etwas an die Öffentlichkeit kommt, gibt das richtig Ärger. Ich halte das für ausgeschlossen.

StefanV

2018-06-23, 13:12:34

Als ob Intel so etwas nötig hätte.
Intel hat niemals zu unlauteren Mitteln gegriffen, um den Wettbewerb auszuschalten.

Sie haben niemals System Integratoren erpresst, keine AMD Chips zu verwenden und auch keine 1,07Mrd Euronen zahlen dürfen.

Unter Windows gehts ja ohne Probleme, scheint also mal wieder ein Linux/BSD Problem zu sein...

Ist ja nicht so, dass es in den letzten Jahren keine größeren Böcke von der Open Source Seite gab, nicht?

aufkrawall

2018-06-23, 13:38:34

Kernel und systemd sind halt die gleichen.

Bei FreeBSD? Aha. :freak:
Und wie kommst du jetzt auf systemd? Buzzword-Bingo?

Und nein, Linux hatte schon ewig keine nennenswerten Instabilitäten-Fails mehr auf Intel-CPUs. Die Misere bei AMD und den C6-States ging afaik mit Kaveri los. Und in wie fern der Kernel schuld sein soll, wenn die CPU sich einfach nicht mehr ansprechen lässt, kannst du ja auch mal erklären (wobei eher nicht).

Skysnake

2018-06-23, 13:57:42

Lehdro

2018-06-23, 14:21:31

Und nein, Linux hatte schon ewig keine nennenswerten Instabilitäten-Fails mehr auf Intel-CPUs.
Jetzt untertreibst du aber wieder: Den Skylake HT "bug" schon vergessen?

https://lists.debian.org/debian-devel/2017/06/msg00308.html

Mal ein bisschen den Ball flachhalten, momentan bekleckert sich keiner von beiden mit Ruhm. Intel hat zudem auch seine Fails mit den Meltdown Patches am Anfang gehabt...

aufkrawall

2018-06-23, 14:22:54

Jetzt untertreibst du aber wieder: Den Skylake HT "bug" schon vergessen?

Der fiel Jahre lang nicht auf und wurde behoben. Der AMD C6 Bug fällt schon Jahre lang auf und ist immer noch nicht behoben oder es gibt zumindest keine abschließende Bestätigung dafür.

eratte

2018-06-23, 14:52:25

Wäre nett wenn das OffTopic und verwässern des Themas ein Ende findet.

"Meltdown & Spectre: Sicherheitsrisiken durch Spekulation bei aktuellen Prozessoren"

Und nicht wer hat welche Bugs die NICHTS mit dem Thema zu tun haben.

lumines

2018-06-23, 14:59:01

Und abschreiben ist ja erlaubt...

Dir ist schon klar, dass die BSDs keinen GPL(v3)-Code einfach so integrieren können, oder?

Und nein, der Kernel in FreeBSD hat mit Linux nichts am Hut. Auch der Kernel von OpenBSD und Co. hat wiederum nichts mit FreeBSD zu tun, auch wenn die BSDs untereinander teilweise Patches übernehmen können, weil die Lizenz kompatibel ist. "BSD" heißt aber nicht, dass die alle untereinander automatisch codetechnisch kompatibel sind oder gar ähnlich funktionieren. Da gibt es schon heftige Unterschiede.

Und woher weißt du, dass der Bug in Linux nicht von Intel verursacht wurde? Und Intel 'nen paar Groschen springen lassen hat, um das so hin zu biegen, dass es gerade nicht gut auf AMD läuft??

Aluhut glüht. Wie stellst du dir das konkret vor? Alle Projekte sind korrupt und integrieren unabhängig voneinander in ihre Kernel wildfremden Code vom Höchstbietenden? Glaubst du nicht, dass da mindestens ein Projekt vielleicht nicht mitgespielt hätte?

Jetzt untertreibst du aber wieder: Den Skylake HT "bug" schon vergessen?

https://lists.debian.org/debian-devel/2017/06/msg00308.html

Der Bug wurde bei Debian das erste Mal gesichtet, hat Windows aber genau so betroffen.

Gipsel

2018-06-24, 17:47:55

Nakai

2018-06-25, 01:31:16

Also gerade Intel hat sich mit der aktuellen Gen nicht gerade mit Ruhm bekleckert, was die Stabilität anbelangt.

So viel Arbeit wie die Generation gab es schon sehr sehr sehr lange nicht mehr mit Intel systemen laut ADMINs. Und ein wir reden hier nicht von vier oder fünfs servern, sondern von tausenden. Die Leute wissen also was Sie tun.

Das SMT-Problem bei OpenBSD ist für Intel richtig scheiße, wenn es so auf Linux migriert wird. Das wird richtig übel.

Sind ja noch 7 to-go, aber da kommt noch ein großer Haufen Scheiße auf Intel zu.

hilo

2018-06-25, 02:31:33

Leonidas

2018-06-25, 17:08:48

Heise schreibt über TLBleed:
https://www.heise.de/security/meldung/TLBleed-Luecke-verraet-geheime-Schluessel-4091114.html

Armaq

2018-06-25, 18:42:14

Zur Frage, ob Intel schon länger "was" gewußt hat bezüglich Meltdown und Spectre, (rück)verweise ich mal auf die Posts Nr. 329 (Pirx) und vor allem Armaqs Post Nr. 791 (Zitat aus "Der Spiegel": "Wir sind auf das Thema aufmerksam geworden, weil es großes Interesse von Intel an einem Patch von uns, nämlich dem KAISER-Patch, gab", erklärt Daniel Gruss, wie er und seine Kollegen dem "Meltdown"-Angriff auf die Spur kamen. "Als Konsequenz haben wir uns gesagt: Wir müssen uns anschauen, was hinter diesem Interesse steckt.") und Nr. 934 (LadyWhirlwind; auf einer Intel(!)veranstaltung) in diesem Thread. Ockhams Rasiermesser ist unter diesen Umständen nicht mehr wirklich scharf. Die wußten schon, daß da Leichen begraben liegen, hatten aber keine Lust die unbedingt auszugraben, wenn sie nicht müssen.
Sie wissen es länger als sie zugeben. Daran besteht kein Zweifel. Boshaftigkeit bei der "Implementierung" sehe ich persl. nicht, aber der Intel CEO hat alle Aktien verkauft die er verkaufen konnte, die steigen eigentlich nur im Wert, warum macht man sowas. Jetzt wird er mit einem fadenscheinigen Grund gegangen, da ist mir alles klar, auch ohne Aluhut.

hilo

2018-06-25, 19:57:59

Naja, die "Boshaftigkeit" seh' ich halt nicht in der Implementierung, sondern daß man mittlerweile ab 2012(!) von Diskussionen unter den Blackhats ausgehen muß (siehe Post Nr. 934) und sie in all den Jahren sich einen Dreck um die Frage gekümmert haben (ich vermute mal, die haben vor der Aufgabe einfach kapituliert). Spätestens mit der Veröffentlichung von Coffee Lake ist Vorsatz ohnehin nicht mehr nur diskutabel, sondern vielmehr definitiv manifest.

Ganon

2018-07-11, 09:24:46

Es gibt neue Varianten von Spectre V1. V1.1 und V1.2.

https://people.csail.mit.edu/vlk/spectre11.pdf

https://01.org/security/advisories/intel-oss-10002

We introduce Spectre1.1, a new Spectre-v1 variant that
leverages speculative stores to create speculative buffer overflows.
Much like classic buffer overflows, speculative out-of-bounds
stores can modify data and code pointers.

We also present Spectre1.2: on CPUs that do not enforce
read/write protections, speculative stores can overwrite readonly
data and code pointers to breach sandboxes

edit: (Ich suche gerade mal die Patches)

Hier für ARM64: https://lkml.org/lkml/2018/7/10/594

Microsoft sagt (ganz unten), dass ihnen keine eigene Software bekannt ist, die davon betroffen ist, Bounty-Program gilt weiterhin: https://support.microsoft.com/mk-mk/help/4072698/windows-server-guidance-to-protect-against-the-speculative-execution

Lehdro

2018-07-14, 13:13:15

Spectre V4 auf einem 8700k benchmarked:
E_WPU6fVsO8

TL;DR: 1-3% Leistungseinbruch.

DrumDub

2018-07-18, 10:55:10

ist das thema mit den ganzen patches jetzt eigentlich durch?

vanquish

2018-07-18, 22:36:09

Nein, leider nicht. Intel hat gerade erst begonnen die Microcodes für ihre aktuellsten CPU Generationen an ausgesuchte "Partner" zu verteilen. Soweit mir bekannt, erfordert sowohl Variante 3a als auch Variante 4 ein Microcode Update. Variante 4 erfordert zusätzlich eine Anpassung in Form eines Kernel Patches. Für Variante 4 gibt es daher auch ein neues CPU-Flag/Befehlssatz SSBD.

vanquish

2018-07-19, 12:12:51

Ich hab's am Haswell Notebook grad' mal getestet. Intel hat den Fix wohl schon länger eingebaut. Den Microcode aber erst jetzt der breiteren Öffentlichkeit zukommen lassen. Leider nur Linux, da auf dem Notebook kein Windows installiert ist (macht ohnehin keinen Sinn, da der Microcode bei HP leider nicht ins Bios integriert werden kann). Aber auch dort sollte der Software Patch schon ausgerollt worden sein.

TGKlaus

2018-07-21, 12:38:31

Unsere Backup-Server werden ab nächsten Monat auf AMD umgestellt.

Die Einbrüche der gepatchten Intelsysteme um bis zu 55% sind durch nichts ( was von "diversen Firmen" versucht wurde) auch nur ansatzweise "reparierbar".

Hart wie das Ganze totgeschwiegen wird und Hilfe nur nach "gewissen Unterschriften" versprochen wird.

Dummerweise wertlose Versprechen!

Wake

2018-07-24, 04:48:51

Und wohl wieder einer mehr, auch schon mit tollen Namen "SpectreRSB": New Spectre-Level Flaw Targets Return Stack Buffer (https://threatpost.com/new-spectre-level-flaw-targets-return-stack-buffer/134299/)

Bisherige Fixes wie Microcode-patches von Intel oder Googles Retpoline sollen dagegen nicht schützen.

Pirx

2018-07-27, 12:27:33

"Netspectre"
https://arstechnica.com/gadgets/2018/07/new-spectre-attack-enables-secrets-to-be-leaked-over-a-network/

Isen

2018-07-27, 14:48:16

Hart wie das Ganze totgeschwiegen wird und Hilfe nur nach "gewissen Unterschriften" versprochen wird.
Dummerweise wertlose Versprechen!

Bei mir freuen sich alle wie Bolle. Sind ja schon letztes Jahr bereits umgestiegen und haben die ganzen Probleme die weiterhin auf Intel sitzengeblieben sind nicht, bekommen das aber volle Breitseite mit, wie das da abgeht. Man schiebt die Schuld halt auf Intel, intern allerdings werden die Verantwortlichen die auf Intel bleiben wollten bereits in die Ecke gestellt, da rollen eh noch Köpfe.
Das darüber nicht berichtet wird liegt auf der Hand: Daran hängen Jobs.
Aber indem man nicht darüber berichtet macht es dies nicht besser. Am Ende sind die eh weg, nur halt etwas später.
Wenn AMD nun wie angekündigt liefert, kracht das eh überall zusammen. Spätestens dann sollte man sich Gedanken darüber machen, was für Scheinheiligkeiten da draußen so rum laufen.

Birdman

2018-07-27, 15:22:48

"Netspectre"
https://arstechnica.com/gadgets/2018/07/new-spectre-attack-enables-secrets-to-be-leaked-over-a-network/
- die selben Massnahmen die schon gegen Spectrev1/v2 helfen, verhindern auch hier einen Exploit
- Over a remote network to a system hosted in Google Cloud...the data rate dropped to one byte every eight hours for the cache side channel, every three hours for the AVX2 one

Sicher insgesammt ein interessanter Aspekt (vor allem der Punkt mit den AVX Einheiten), dass dies auch übers Netz klappt, aber in der Praxis vom Sicherheitsstandpunkt her für die meisten ohne wirkliche Relevanz.

vanquish

2018-07-31, 21:57:38

https://www.theregister.co.uk/2018/07/26/meldown_spectre_batters_hpc/

Benchmarks am "Großrechner":

The tests were run on Intel Xeon E5-2683 v3 Haswell servers with 256 GB of system RAM, and a 10PB Lustre storage system using Seagate ClusterStor CS9000s.

Network connection establishment – "With all mitigations enabled, the mainline kernel is slowed down by approximately 15 per cent without and 21 per cent with the User-Based Firewall. The GRSecurity-enabled kernel is also slowed down by 15 per cent without, but 67 per cent with the User-Based Firewall."

Disk access – "With all mitigations enabled, the mainline kernel is slowed down by approximately 50 per cent on local disk and 33 per cent on Lustre. The GRSecurity-enabled kernel is slowed down by 90 per cent on local disk and 33 per cent on Lustre."

Computationally intensive code – Kernel changes had little effect, "as they make few requests for kernel services". That's the good news. The bad news? "A noticeable slowdown was seen with the microcode updated... These slowdowns were measured at 21 per cent for pMatlab and 16 per cent for TensorFlow for the baseline kernel with all mitigations and 19 per cent and 15 per cent respectively with just the microcode."

Ich weiß zwar nicht was GRSecurity alles in den Kernel "patcht", aber die 90% sind heftig. Mathlab und DeepLearning sind auch nicht unbedingt die Standard-Aufgaben eines Servers. Aber so bekommt man wenigstens mal einen Eindruck wie groß der Hit bei anderen Systemen so ist.

Hier das PDF: https://arxiv.org/abs/1807.08703

TGKlaus

2018-08-01, 00:15:25

Bestätigt ganz klar, was ich hier seit Monaten, aus (leider) eigener Erfahrung schreibe.

Zu einer sachlichen Diskussion ist es aber durch das whitewashing von Usern wie Ganon nicht gekommen.
Ebenso wie die "Fachpresse" komplett versagt hat.

Die bejubelt lieber die kommenden i9 Prozessoren, anstatt die desaströsen Bugs zu thematisieren und INTEL ganz klar die rote Karte zu zeigen, weil man einfach "neue Generationen" an verbuggten SchrottCPUs auf den Markt bringt, anstatt Hardwarefixes zu integrieren.

aufkrawall

2018-08-01, 00:18:44

Wann gab es jemals eine nennenswerte Fachpresse, die Server-CPUs und -Workloads thematisiert hat?

Ganon

2018-08-01, 01:26:28

Ich weiß zwar nicht was GRSecurity alles in den Kernel "patcht", aber die 90% sind heftig.

GRSecurity ist ein (umstrittenes) Patchset für den Kernel was allerhand Sicherheits-Technologie in den Kernel einfügt (z.B. PaX). Das reicht dann von "ist sinnvoll" bis hin zu "Paranoia im Stil von OpenBSD". Einige Sachen sind auch schon in einem aktuellen Mainline Kernel einschaltbar und in etwaigen -hardened Konfigurationen aktiv.

Der Hit ist hier vermutlich am Größten weil GRSecurity noch allerhand Roundtrips im Kernel hinzufügt (sämtlicher Datenzugriff läuft noch mal über Wrapper von GRSecurity), ebenso die Personal Firewall. Das mögen die CPUs dann jetzt nicht mehr allzu sehr. Haswell und davor afaik sogar am Wenigsten.

Die 50% bei Disk-Access sind ja an sich nichts Neues. 10MB Daten in 1 Byte Häppchen in eine Datei schreiben triggert das natürlich hart. Wenn GRSecurity hier jetzt auch noch zig Tests und Säuberungen hinzufügt, dann kracht's natürlich ordentlich.

Zu einer sachlichen Diskussion ist es aber durch das whitewashing von Usern wie Ganon nicht gekommen.

Hab dich auch lieb, Schnuckipups.

Menace

2018-08-01, 07:45:02

Hab dich auch lieb, Schnuckipups.

Ich habe die Sache nicht weiterverfolgt, kann mich aber an den Anfang der Diskussion erinnern. Damals hast du behauptet, dass es intel nicht so schlimm trifft und AMD wohl im gleichen Maße betroffen sein wird. Das hast du doch sinngemäß immer wieder betont. Stimmt den diese Einschätzung aktuell noch?

Dorn

2018-08-01, 07:53:50

Stimmt den diese Einschätzung aktuell noch? Natürlich nicht. Wer konnte schon Ahnen das die Büchse der Pandora noch weitere "Spectres" hat :freak:

Ganon

2018-08-01, 08:32:15

Ich habe die Sache nicht weiterverfolgt, kann mich aber an den Anfang der Diskussion erinnern. Damals hast du behauptet, dass es intel nicht so schlimm trifft und AMD wohl im gleichen Maße betroffen sein wird. Das hast du doch sinngemäß immer wieder betont. Stimmt den diese Einschätzung aktuell noch?

Du darfst diese angebliche Behauptung von mir gerne erst mal raussuchen. Mir wäre nicht bewusst, dass ich sowas je gesagt habe.

Natürlich nicht. Wer konnte schon Ahnen das die Büchse der Pandora noch weitere "Spectres" hat :freak:

Lustiger Weise hatte ich das sogar erwartet. Hatte ich auch, glaube ich, irgendwo geschrieben. Glaube auch weiterhin, dass da noch so einiges kommen wird.

Menace

2018-08-01, 11:21:16

Du darfst diese angebliche Behauptung von mir gerne erst mal raussuchen. Mir wäre nicht bewusst, dass ich sowas je gesagt habe.

Beantwortet jetzt meine Frage mal wieder nicht. Also gibst du zu, dass vor allem intel betroffen ist und AMD User relativ fein raus sind?

Und ja, mache ich sobald ich wieder zu Hause bin. Mit dem Handy ist das total nervig. Beginnt aber ab Seite 2.

Ganon

2018-08-01, 12:20:50

Beantwortet jetzt meine Frage mal wieder nicht. Also gibst du zu, dass vor allem intel betroffen ist und AMD User relativ fein raus sind?

Äh, ja? Das sind doch simple Fakten. Wüsste auch nicht, was es da "zuzugeben" gibt.

Complicated

2018-08-01, 14:24:58

GRSecurity ist ein (umstrittenes) Patchset für den Kernel was allerhand Sicherheits-Technologie in den Kernel einfügt (z.B. PaX). Das reicht dann von "ist sinnvoll" bis hin zu "Paranoia im Stil von OpenBSD". Einige Sachen sind auch schon in einem aktuellen Mainline Kernel einschaltbar und in etwaigen -hardened Konfigurationen aktiv.

Der Hit ist hier vermutlich am Größten weil GRSecurity noch allerhand Roundtrips im Kernel hinzufügt (sämtlicher Datenzugriff läuft noch mal über Wrapper von GRSecurity), ebenso die Personal Firewall. Das mögen die CPUs dann jetzt nicht mehr allzu sehr. Haswell und davor afaik sogar am Wenigsten.
Na und? Es bleibt bei diesem ungeliebten Workload ein Performanceverlust von 90% zwischen gepachtem System vs. ungepatched.

Du hast eine seitenlange Relativerungsdiskussion im Sinne der Intel-PR hier im Thread geführt und willst jetzt plötzlich davon nichts mehr wissen?

Ganon

2018-08-01, 14:27:52

Na und?

Ich hab erklärt was GRSecurity macht und warum es wohl solche Auswirkungen hat. Den Rest hast du da wieder reingedichtet.

lumines

2018-08-01, 14:44:47

Beantwortet jetzt meine Frage mal wieder nicht. Also gibst du zu, dass vor allem intel betroffen ist und AMD User relativ fein raus sind?

Stand das überhaupt jemals zur Debatte? Hier wurden haufenweise seltsame Behauptungen in den Thread geworfen, aber so weit sollte man das noch unterscheiden können, was davon wieder untergegangen ist.

Na und? Es bleibt bei diesem ungeliebten Workload ein Performanceverlust von 90% zwischen gepachtem System vs. ungepatched.

Vielleicht ist das einigen nicht ganz klar, aber GRSecurity hat so direkt sehr wenig mit dem Mainline-Kernel zu tun. Einige Distributionen wie Alpine Linux benutzen die Patches, aber ansonsten gibt es keine größere Distribution, welche die Patches 1:1 übernimmt.

Du hast eine seitenlange Relativerungsdiskussion im Sinne der Intel-PR hier im Thread geführt und willst jetzt plötzlich davon nichts mehr wissen?

War Ganon hier jemals auf Intels Seite?

Einige scheinen hier die subtilen Implikationen dieser Lücken nicht so ganz zu verstehen. Diese Lücken sind ja das Ergebnis von einer bis vor kurzem relativ wenig beachteten Forschung. Jetzt hat man gesehen, dass das alles sehr praxisrelevant sein kann und plötzlich will natürlich jeder ähnliche Lücken finden, weil die extrem prestigeträchtig sind.

Das ist nicht auf Intel beschränkt. Intel hat nur besonders tief ins Klo gegriffen. Man muss aber schon sehr naiv sein, wenn man denkt, dass alle anderen Architekturen von ähnlichen Lücken komplett ausgenommen sind. Das sind so hochkomplexe Zusammenhänge, die sich erst in der Praxis zeigen und nur mit ganz heftiger, hirnverdrehender Theorie erschlossen werden können, dass man vielleicht komplett neu überdenken muss, wie CPUs entworfen werden müssen.

Einige stellen sich CPU-Entwicklung wahrscheinlich noch immer wie eine Art Handwerk vor, in der irgendwer schon weiß, was er da macht und irgendein seltsamer Masterplan von einem Großmeister der CPUs existiert. Praktisch kann aber wahrscheinlich kein einziger Mensch alleine genau erklären, wie heutige CPUs im Detail genau funktionieren. Bei der heutigen Komplexität ist das schlicht unmöglich. Man kann das Verhalten nur ganz abstrakt modellieren und anhand dessen dann Entscheidungen treffen. Wie soll das bei den heutigen Transistorzahlen und Instruktionen auch anders funktionieren? Da sitzt niemand alleine in seiner Bude und schmiedet Pläne, wie die nächste CPU aussehen könnte. Das ist ein unbeschreiblich langer Prozess, bei dem dutzende und hunderte Leute auf der Arbeit ihrer Vorgänger aufbauen und sie dann eben selbst ihre kleinen Beiträge leisten. Das ist ganz weit entfernt von z.B. der Arbeit eines Tischlers, der vom Anfang bis zum Ende die Produktion im Blick halten kann. So stellen sich das einige vielleicht vor, aber das ist nicht die Praxis.

Fusion_Power

2018-08-01, 14:51:26

Complicated

2018-08-01, 15:09:25

Ich hab erklärt was GRSecurity macht und warum es wohl solche Auswirkungen hat. Den Rest hast du da wieder reingedichtet.
Ja sicher. Nur die Frage ist warum das relevant sein soll in diesem Kontext. Der Performanceverlust ist 90% in diesem Anwendungsszenario.

Auf Seite 2

Und Andere versuchen hier gerade ein Super GAU daraus zu machen. Ich bin in dem Umfeld tätig. Vor Sicherheits-GAU kann ich gerade nur schmunzeln bei all den Lücken in all der Hard- und Software die letzten Jahre. Performance-GAU muss sich erst zeigen, wie gesagt... abseits von Edge-Cases. I/O-lastiges Datawarehousing hat vielleicht ein paar relevante Messwerte dann. Bei 08/15 WebApps ist es relativ egal ob die Query 1ms oder 5ms läuft, wenn der fette App-Stack oben drauf eh noch mal 400ms hinzufügt.
Es ist ja kein Problem wenn man aus der Branche ist und die Tragweite nicht gleich abschätzen konnte. Doch die ist nun mal jetzt deutlich anders als du es damals eingeschätzt hast. Kein Problem, doch so zu tun als wäre das nicht so gewesen erzeugt eben wenig Glaubwürdigkeit.

lumines

2018-08-01, 15:18:20

Der Performanceverlust ist 90% in diesem Anwendungsszenario.

Wer die GRSecurity-Patches benutzt, der hat seine Hardware wahrscheinlich bewusst etwas großzügiger ausfallen lassen.

Ich möchte einmal die Schnappatmung einiger hier im Thread sehen, wenn sie die Performance von LibreSSL auf OpenBSD sehen und dann mit OpenSSL auf Linux sehen würden. Der Unterschied ist wie Tag und Nacht, aber eins der beiden Projekte interessiert sich für Performance auch nicht die Bohne. Sind eben unterschiedliche Ziele.

Man muss schon mit den Maßstäben aufpassen, die man da ansetzt. Einige Patches sind bewusst nicht optimiert und eher ein Rundumschlag.

Ganon

2018-08-01, 15:29:59

Ja sicher. Nur die Frage ist warum das relevant sein soll in diesem Kontext. Der Performanceverlust ist 90% in diesem Anwendungsszenario.

Es wurde indirekt gefragt, ich habe es beantwortet, du machst daraus ein Intel vs. AMD bla bla.

Es ist ja kein Problem wenn man aus der Branche ist und die Tragweite nicht gleich abschätzen konnte. Doch die ist nun mal jetzt deutlich anders als du es damals eingeschätzt hast. Kein Problem, doch so zu tun als wäre das nicht so gewesen erzeugt eben wenig Glaubwürdigkeit.

Das was da steht unterschreibe ich auch heute noch. Rein vom Sicherheitsproblem halte ich das auch weiterhin für nicht so extrem, wie es viele hinstellen. Es ist keine Remote-Lücke und VM-Anbieter haben Probleme dieser Art dauernd.

Und wie da steht, Performance-Probleme mussten sich zu dem Zeitpunkt erst noch zeigen.

maximus_hertus

2018-08-01, 15:30:47

kruemelmonster

2018-08-01, 15:30:54

Was mich einfach nur interessiert: wird es bald sichere Prozuessoren geben die schon "by design" nicht angreifbar sind oder bauten die Chiphersteller weiterhin auf vorhandenen/verwundbaren Architekturen auf? Weil so kanns ja nicht weiter gehen, das wäre ja dann wie z.B. Adobe Flash, was by design unsicher und nicht fixbar ist, egal wie viele Patches man nachschmeißt. Und ich werd mir sicher keine "Adobe Flash CPU" mehr kaufen. Ich erwarte sichere Hardware, so wie sie sein sollte.

Sicherheit ist nie ein Zustand, sondern ein Prozess. Falls es irgendwann Spectre-sichere CPUs (nach heutigem Verständnis) geben sollte, dann könnte trotzdem irgendwer mit anderen, zz noch unbekannten Methoden diese CPU knacken. Ob eine aktuelle CPU nun Spectre-anfällig ist, oder eine Spectre-sichere CPU dann xyz-anfällig ist, macht letztlich keinen Unterschied. lumines hat das bereits beschrieben, ich versuchs auch nochmal: du kannst keinen Impfstoff entwickeln ohne Krankheitserreger.

Imo extrem wichtig ist dass der CPU-Hersteller dann genügend Ressourcen (Zeit, Geld, Manpower, Beziehung zu OEMs) bereitstellt um das Problem in Software zu fixen, so wie in diesem Fall geschehen.

Ganon

2018-08-01, 15:33:35

ich versuchs auch nochmal: du kannst keinen Impfstoff entwickeln ohne Krankheitserreger.

Na es gibt ja immune CPUs. Nur ist die Performance halt gering. Für etwaige sicherheitskritische Bereiche könnte es aber durchaus eine ordentliche Option sein. Muss man halt etwas länger warten.

Für VM-Anbieter ist das natürlich nichts. Ansonsten müsste man mit der 10 bis 100fachen CPU-Anzahl ankommen.

aufkrawall

2018-08-01, 15:59:39

Die (bisher wohl auch eher nur theoretisch nötigen) Spectre-Mitigations kosten auf Zen doch fast gar nichts und Meltdown gibt es nicht?

Ganon

2018-08-01, 16:03:08

Die (bisher wohl auch eher nur theoretisch nötigen) Spectre-Mitigations kosten auf Zen doch fast gar nichts und Meltdown gibt es nicht?

Spectre V1 (und, ... war es 4?) gibt's weiterhin. Wie gefährlich das ist, hängt dann halt von der angegriffenen Software ab. Wenn's der Kernel ist, ist's übel. Wenn's der Bildbetrachter ist, dann eher nicht.

Aber ja, es geht jetzt auch mehr um eine theoretische Immunität ohne, dass man die Software mit Workarounds zupflastert.

aufkrawall

2018-08-01, 16:16:48

Spectre V1 (und, ... war es 4?) gibt's weiterhin.
Ja, aber die MC-Mitigations kosten fast nix. Bei Intel summiert sich der Crap aus allen Lücken, und besonders Meltdown ist fies für IO.

kruemelmonster

2018-08-01, 16:26:30

Na es gibt ja immune CPUs.

Mein Punkt war folgender: du kannst nur immunisieren gegen etwas Bekanntes. Insofern wird sich der Wunsch von Fusion_Power, keine "Adobe Flash CPU" kaufen zu müssen, schwer erfüllen lassen da man eben nicht vor der Lücke Maßnahme gegen die Lücke aufbieten kann (oder nur in begrenztem Umfang, was dann wieder Raum für ungewöhnliche Attacken wie eben Spectre lässt).

iuno

2018-08-01, 16:27:34

Na es gibt ja immune CPUs. Nur ist die Performance halt gering. Für etwaige sicherheitskritische Bereiche könnte es aber durchaus eine ordentliche Option sein.
Zum Thema moegliche sicherere Prozessoren sei auch mal gesagt, dass die Inder jetzt ihre eigene RISC-V CPU fertig haben. Die bricht logischerweise zwar weder Rekorde in Sachen Leistung noch Kompatibilitaet oder sonst irgendwas, aber es zeigt natuerlich, dass es anders geht, wenn man will und auch kann, also entsprechend Ressourcen hat und halt wichtigere Anforderungen hat als die absolute Leistungskrone. Die Abhaengigkeit von Intel oder auch x86 muss nicht auf ewig in jedem Bereich so weitergehen.

Ganon

2018-08-01, 16:43:18

Ja, aber die MC-Mitigations kosten fast nix. Bei Intel summiert sich der Crap aus allen Lücken, und besonders Meltdown ist fies für IO.

Wie gesagt, es geht jetzt mehr um die Sicherheit und nicht um die Performance. Das was jetzt aktuell gilt, kann in 6 Monaten schon wieder ganz anders sein. Wer weiß was noch alles für Spectre-Varianten in den CPUs so drin sind, oder vielleicht sogar ganz neuer Kram, alles basierend auf spekulativer Ausführung. Dazu noch die Frage wie viele ungefixte Spectre-Lücken in kritischer Software noch drin sind. Meltdown ist auch irgendwann bei Intel wieder vorbei, mit kommenden Hardware-Revisionen. Spectre V2 und Co. sehr wahrscheinlich auch. Dann ist das alles kalter Kaffee. Aber Spectre V1 bleibt.

Jetzt auf immer und ewig die Software auf Spectre-Lücken abzuklopfen und weiter an den Compilern zu schrauben, damit diese keinen Spectre-anfälligen Code erzeugen ist halt auch nicht so wahnsinnig toll.

Sicherheitsrelevante Software zu schreiben ist auch ohne den ganzen Scheiß schon schwer genug.

Mein Punkt war folgender: du kannst nur immunisieren gegen etwas Bekanntes.

Das ist schon richtig. Wenn deine CPU aber "so dumm" ist, dass sie nur das tut, was ihr gesagt wird und auch nur genau das, dann ist die Möglichkeit einer Hardware-Sicherheitslücke doch eher gering.

Denken wir mal in eine andere Richtung: Hat natürlich niemand intensiv geprüft, aber die Itanium CPUs sollen ja angeblich auch immun gegen Spectre sein. Diese sind aber für sich gesehen nicht unbedingt langsam (mal im Vergleich zu einem popeligen ARM A53). Die CPU aber selbst frisst nicht unbedingt gerne den 08/15 Scheißcode, den die Compiler damals so ausgespuckt haben.

Kann also vermutlich alles gehen, muss natürlich nicht.

Complicated

2018-08-01, 16:59:09

Es wurde indirekt gefragt, ich habe es beantwortet, du machst daraus ein Intel vs. AMD bla bla.Wo denn?
Ich sagte du hast die Lücken als zu harmlos eingeschätzt. Dass Intel mehr betroffen ist, ist ein unbestrittener Fakt. Das haben dir im Verlauf des Threads auch mehrere User mitgeteilt. Alles auch kein Problem, hat jeder ein Recht auf seine Meinung. Nur später dann die Änderung der Meinung zu negieren, nachdem eben alles nicht so harmlos ist und tatsächlich ein Super-GAU eingetreten ist, ist halt auffällig.

Ganon

2018-08-01, 17:16:01

Wo denn?

"Ich weiß zwar nicht was GRSecurity alles in den Kernel "patcht", aber die 90% sind heftig."

Ich mein, ich hab's direkt zitiert, nicht?

Ich sagte du hast die Lücken als zu harmlos eingeschätzt.

Ich hab mich anfangs sogar aktiv dafür eingesetzt, dass die Leute die Sicherheitspatches einspielen... :ugly:

Dass Intel mehr betroffen ist, ist ein unbestrittener Fakt.

Das hab ich auch nie anders behauptet.

Das haben dir im Verlauf des Threads auch mehrere User mitgeteilt.

Meinst du die Leute, die mir erzählen wollten, dass es alles eine Intel-Only Geschichte ist, oder die Leute, die erzählen Intel hätte das bewusst gemacht?

Alles auch kein Problem, hat jeder ein Recht auf seine Meinung. Nur später dann die Änderung der Meinung zu negieren, nachdem eben alles nicht so harmlos ist und tatsächlich ein Super-GAU eingetreten ist, ist halt auffällig.

Nur habe ich hab meine Meinung nicht negiert.

Fusion_Power

2018-08-01, 17:21:22

Wenn du mit "bald" irgendwann Richtung 2025 meinst, dann ja, da könnte es passen.

Meinst du mit bald in den kommenden Monaten, dann sehr wahrscheinlich nein. Die Probleme sind so tief in der Architektur / Funktionsweise drin, dass wird man nicht "mal eben" komplett fixen können.
Schade, dachte Intel und AMD hätten da was angedeutet, schon als die ersten Spectre/meltdown Probleme publik wurden.

Sicherheit ist nie ein Zustand, sondern ein Prozess. Falls es irgendwann Spectre-sichere CPUs (nach heutigem Verständnis) geben sollte, dann könnte trotzdem irgendwer mit anderen, zz noch unbekannten Methoden diese CPU knacken. Ob eine aktuelle CPU nun Spectre-anfällig ist, oder eine Spectre-sichere CPU dann xyz-anfällig ist, macht letztlich keinen Unterschied. lumines hat das bereits beschrieben, ich versuchs auch nochmal: du kannst keinen Impfstoff entwickeln ohne Krankheitserreger.

In dem Fall ist es umso seltsamer, dass Jahrelang quasi nichts diesbezüglich unternommen wurde. Soweit ich gelesen hab sind die Probleme wirklich nicht neu. Intel & Co. hatten Jahre lang zeit, etwas diesbezüglich zu tun, passiert ist gefühlt 20 Jahre nichts. Warum?

Mein Punkt war folgender: du kannst nur immunisieren gegen etwas Bekanntes. Insofern wird sich der Wunsch von Fusion_Power, keine "Adobe Flash CPU" kaufen zu müssen, schwer erfüllen lassen da man eben nicht vor der Lücke Maßnahme gegen die Lücke aufbieten kann (oder nur in begrenztem Umfang, was dann wieder Raum für ungewöhnliche Attacken wie eben Spectre lässt).
Für mich sind das Scheunentor große Lücken, zumindest die sollte man fixen und unmöglich machen, und das in Hardware, also ohne Performanceverlust. Als Privatmensch brauch ich gar keine 100% sichere CPU, halt nur was, dass man als halbwegs sicher ansehen kann fürn täglichen Gebrauch.

Complicated

2018-08-01, 17:31:12

Das hab ich auch nie anders behauptet.Deshalb verwende ich das Wort "unbestritten" :freak:
Du sagtest es gäbe Leute "die tun so als sei es der Super-GAU" und nun ist es der Super-Gau. Eines davon ist eben falsch. Ich nenne das negieren der nun beannten Fakten und der Änderung deiner Einschätzung. Es sei denn du bist NACH WIE VOR der Meinung manche täten nur so...

Das hat weder mit Intel noch mit AMD etwas zu tun.

Ganon

2018-08-01, 17:46:39

Du sagtest es gäbe Leute "die tun so als sei es der Super-GAU" und nun ist es der Super-Gau. Eines davon ist eben falsch. Ich nenne das negieren der nun beannten Fakten und der Änderung deiner Einschätzung. Es sei denn du bist NACH WIE VOR der Meinung manche täten nur so...

Es sind einfach zwei verschiedene Meinungen. Für mich ist eine Lücke die lokalen Zugriff auf den Rechner braucht, gerade bei einem Server, eher im Medium-Bereich anzusiedeln. Mal von VM-Betreibern abgesehen, wie ich ja mehrfach sagte.

Birdman

2018-08-01, 18:35:51

Du sagtest es gäbe Leute "die tun so als sei es der Super-GAU" und nun ist es der Super-Gau.
Und wo ist es ein Super-Gau?
Ich jedenfalls sehen keinen der nun reihenweise Server ausbaut oder tauscht.
Was Du in deiner Bubble fühlst ist nicht unbedingt das Weltbild da draussen...

Nur weil man mit Spectre-Aware Software bei gewissen theoretischen Anwendungsszenarien, bzw. Benchmarks bis zu 90% verlieren kann, heisst das nicht dass man sowas im Praxisbetrieb auch nur annähernd sehen wird.

Complicated

2018-08-01, 19:10:16

Die Performanceverluste sind doch schon längst im Praxisbetrieb zu sehen.

kruemelmonster

2018-08-01, 19:18:47

In dem Fall ist es umso seltsamer, dass Jahrelang quasi nichts diesbezüglich unternommen wurde. Soweit ich gelesen hab sind die Probleme wirklich nicht neu. Intel & Co. hatten Jahre lang zeit, etwas diesbezüglich zu tun, passiert ist gefühlt 20 Jahre nichts. Warum?

Schau dir Posting #2117 hier im Thread an.

Für mich sind das Scheunentor große Lücken, zumindest die sollte man fixen und unmöglich machen, und das in Hardware, also ohne Performanceverlust. Als Privatmensch brauch ich gar keine 100% sichere CPU, halt nur was, dass man als halbwegs sicher ansehen kann fürn täglichen Gebrauch.

Das hast du afaiu bereits heute mit aktuellem Microcode und OS-Patchstand. Und eine Spectre-sichere CPU kann wie bereits geschrieben dann künftig gegen irgendwas neues verwundbar sein, dass ist das Gleiche Katz-und-Maus-Spiel wie zwischen Malware-Autoren und AV-Programmen.

Wie gesagt, Sicherheit ist kein Zustand sondern ein fortlaufender Prozess.

Complicated

2018-08-01, 19:43:21

Es sind einfach zwei verschiedene Meinungen. Für mich ist eine Lücke die lokalen Zugriff auf den Rechner braucht, gerade bei einem Server, eher im Medium-Bereich anzusiedeln. Mal von VM-Betreibern abgesehen, wie ich ja mehrfach sagte.
Es geht doch nicht um die schwere der Lücken. Es geht um die Performance die durch die Patches verloren geht. Solche Konsequenzen hatte noch keine Sicherheitslücke zuvor.

Ganon

2018-08-01, 20:15:07

Es geht doch nicht um die schwere der Lücken. Es geht um die Performance die durch die Patches verloren geht.

Und um den Performance-Verlust zu verdeutlichen braucht man Benchmarks wie "Kopiere 10MB in 1 Byte Häppchen"? Ich bestreite keine Performance-Verluste. Die Frage ist, wie stark es nun wirklich ist und ob das irgendjemanden bewegt was dagegen zu tun. Gerade Systeme die keinen Fremdcode ausführen können z.B. die Sicherheitsfixes einfach deaktiviert werden. Darum kann man den Kram ja auch überhaupt erst deaktivieren, ganz einfach weil die Angriffsfläche im typischen Serverbereich sehr sehr sehr klein ist.

Aber mal eine andere Frage:

Gibt's eigentlich irgendwo aktuelle Benchmarks wie weit AMD jetzt vor Intel ist in typischer Server-Software? Also mal ein paar Apache, MySQL, PostgreSQL, nginx etc. Benchmarks?

Ich persönlich kenne nur diese hier (https://www.phoronix.com/scan.php?page=article&item=linux-retpoline-benchmarks&num=1) vom Januar, aber das ist "nur" Phoronix und naja... schaue es dir selbst an.

Solche Konsequenzen hatte noch keine Sicherheitslücke zuvor.

Hast du jeden Sicherheits-Fix mit Benchmarks versehen? Aber "Hardware-Fehler" die zur Abschaltung von Features geführt haben, gab es auch schon vorher. Intels TSX Bug oder AMDs TLB Bug. Kostete im jeweiligen Fall auch Leistung. Klar, sind keine "Sicherheitslücken", aber halt Fehler, die zu Abstürzen oder Fehlberechnungen führten.

Complicated

2018-08-02, 18:12:34

Aber mal eine andere Frage:

Gibt's eigentlich irgendwo aktuelle Benchmarks wie weit AMD jetzt vor Intel ist in typischer Server-Software? Also mal ein paar Apache, MySQL, PostgreSQL, nginx etc. Benchmarks?Sag mal ist dir eigentlich nicht klar, dass wir genau über aktuelle Benchmarkergebnisse reden? Vor 2 Seiten sind sie gepostet worden und du diskutierst immer noch in der "könnte" Version.
https://www.theregister.co.uk/2018/07/26/meldown_spectre_batters_hpc/

They conducted their experiments on a real HPC environment: MIT Lincoln's "Green-500" listed TX-Green Supercomputer. The tests were run on Intel Xeon E5-2683 v3 Haswell servers with 256 GB of system RAM, and a 10PB Lustre storage system using Seagate ClusterStor CS9000s.
They used six compilations of the Linux kernel (using the GridOS 26 Red Hat-derived distribution), with GRSecurity kernel enhancements enabled and disabled, bringing the total number of configurations to 10.
Network connection establishment – With all mitigations enabled, the mainline kernel is slowed down by approximately 15 per cent without and 21 per cent with the User-Based Firewall.
Disk access –With all mitigations enabled, the mainline kernel is slowed down by approximately 50 per cent on local disk and 33 per cent on Lustre.
Computationally intensive code – Kernel changes had little effect, "as they make few requests for kernel services". That's the good news. The bad news? "A noticeable slowdown was seen with the microcode updated... These slowdowns were measured at 21 per cent for pMatlab and 16 per cent for TensorFlow for the baseline kernel with all mitigations and 19 per cent and 15 per cent respectively with just the microcode."
Zum Paper:
https://arxiv.org/abs/1807.08703

Gipsel

2018-08-02, 18:20:33

Complicated

2018-08-02, 18:25:49

Ja er ist der einzige der über AMD vs. Intel Vergleiche redet. Ist aber nicht mein Thema. Ich rede hier im Thread über die Auswirkungen von Spectre und Meltdown. Und es ging einem anderen User darum, dass Ganon diese von Anfang an relativiert hatte und klein redet.

Ganon

2018-08-02, 20:03:31

Sag mal ist dir eigentlich nicht klar, dass wir genau über aktuelle Benchmarkergebnisse reden? Vor 2 Seiten sind sie gepostet worden und du diskutierst immer noch in der "könnte" Version.
https://www.theregister.co.uk/2018/07/26/meldown_spectre_batters_hpc/

Joahr, ich habe dazu auch schon was gesagt. Ich halte weiterhin Microbenchmarks wie eben nicht für sinnvoll. Niemand kopiert Dateien in 1 Byte Häppchen. Das einzig sinnvolle aus dem Paper ist imo der Matlab/Tensorflow Kram.

Ich hab einfach noch eine weitere Frage gestellt, weil ich ja nach all den "Intel verliert XYZ%" jetzt mal gerne wüsste wie weit denn jetzt AMD vor Intel ist. Von mir aus auch gerne Mikrobenchmarks, aber auch gerne vernünftige.

Du musst diese Frage auch nicht beantworten, ich hab sie einfach nur in den Raum gestellt. Es interessiert mich halt einfach. Dass Intel durch Meltdown/Spectre Leistung verliert ist ja klar. Aber gerade in einer Diskussion rund um das Thema "Super GAU durch Performance Verlust" wäre doch jetzt mal echt interessant wie viel der Wechsel zu AMD bringt.

Wenn du es nicht weißt, ist es ja auch nicht so schlimm.

vanquish

2018-08-02, 20:26:57

Der Artikel den ich zitiert habe, basiert nicht ausschließlich auf Benchmarks. In die Bewertung sind reale Werte mit eingeflossen. Was kann man dabei auch falsch machen wenn man von z. B. Mathlab/Keras ein Szenario vorher und nachcher durchrechnen lässt. Da lässt sich der Workload einer dynamischen Datenbank in einem großen Betrieb viel schwerer nachstellen und vergleichen. Sie sind ein Anhaltspunkt um die Leistung zu bewerten. IMO sogar ein sehr guter, da man hier sehr schön vorher und nacher vergleichen kann. Vor dem Kauf hat man ja z. B. auch die Sysmark Werte u. ä. (k. A. was da angesagt ist) angesehen. Bestimmt hat sich jmd. der GRSecurity in seinen Kernel patcht davor auch Gedanken gemacht und muss jetzt feststellen, dass seine Berechnungen nichts mehr Wert sind.

"We show that the impact can be significant on both synthetic and realistic workloads. We also show that the performance penalties are difficult to avoid even in dedicated systems where security is lesser concern."

Man kann aus dem Artikel auch Dinge ableiten, wenn man den Mainline-Kernel, der ja auch bewertet wurde, als Vergleich heranzieht.

Mich würde es auch interessieren, wie groß die Auswirkungen auf "normale/realere" Server-Systeme mit extra SSD-Cache-Platten sind. Zumal die eigentlichen Daten-Fesplatten heutzutage oft gar nicht mehr direkt an den Server angeschlossen werden, sondern über das Netzwerk angebunden sind und das auch noch über ein oder mehrere Overlays und "exotischeren" Dateisystemen (ZFS, Lustre o. ä.). Oder sie sind gleich direkt an die Amazon Cloud angebunden. Aber auch das ergibt mit dem Netzwerk-Hit und dem Performance-Hit auf den eigenen Systemen und den Amazon-Servern einen Leistungsverlust. Ob er sich "nur" addiert oder gar multipliziert ... wer weiß das schon.

Das interessanteste für mich an diesem Dokument ist, dass die Herrschaften festgestellt haben, dass der Performance-Hit gleich bleibt, sobald man den Microcode für die CPU geladen hat. Ein deaktivieren aller in Software implempentierten Fixes hatte keinerlei Auswirkungen. Klar, dass PTI hier den Hauptanteil am Performance-Verlust trägt und die Drops bei Dateioperationen nicht mehr so signifikant sind. Man kann sich aber ausmalen, was passiert, wenn der Support-Vertrag einem das Einspielen des Microcodes/System Patches aufzwingt. Eventuelle Haftungsgründe einmal aussen vor. Hierzu würde mich auch ein Vergleich zu AMD interessieren, das ja von PTI nicht betroffen ist.

Es wird auch betont, dass es sich hier um "nicht optimierten" Code handelt. Eine optimierte Datenbankanwendung, Dateisystem, o. ä. kann das ggf. also (fast) wieder wett machen. Es wird aber auch darauf hingewiesen, dass es Aufgrund der größe vieler Software-Projekt heutzutage kaum machbar/sinnvoll ist die Software entsprechend anzupassen. Langfristig wird man sich überlegen ob man ein so komplexes Gebilde wie z. B. von SAP, das man in vielen Firmen antrifft, anpasst oder auf die "fehlerfreie" Generation von Prozessoren wartet. Diese Aussage mit der Optimierung passt auch zu der von den Linux-Entwicklern getroffenen Aussage, dass der durchschnittliche (über alle Bereiche) im Kernel erzielte Performance-Gewinn von ~ 15% aus den letzten 10 Jahren von Spectre/Meltdown aufgefressen wurde.
Ich denke, dass dieser Wert gut zu dem Dokument passt und als Richtwert dienen kann. Allerdings ist alles im Fluss und die Entwickler verbessern die Performance ständig. Wodurch dieser Wert über die Zeit stetig sinkt. Oder auch nicht, wenn weitere Lücken weitere Maßnahmen erfordern. ...

Ganon

2018-08-03, 11:09:37

Phoronix hat jetzt mal ein paar Benchmarks gemacht, jedoch kein Vergleich mit/ohne Fixes, sondern einfach nur AMD & Intel mit einem aktuellen System (inkl. BIOS-Patches und Microcode Updates). Und ja, es ist Phoronix... man muss diese Werte immer mit Vorsicht betrachten, darum würde ich mir eine andere Quelle wünschen.

http://openbenchmarking.org/result/1808019-RA-LINUX418H13&obr_sor=y&obr_rro=y

Aber ich würde sagen.... mixed? Der Ryzen 7 2700X liegt so um den Performance Wert des i7 8700K. Mal gewinnt der Eine, mal der Andere, oft mehr oder weniger gleich auf. Der Core i9 gewinnt oft gegenüber Threadripper, manchmal auch Threadripper.

Es dürfen gerne andere Vergleichs-Benchmarks gepostet werden, aber ich sehe weiterhin leider keinen enormen Performance-Vorteil von AMD gegenüber Intel, auch mit Meltdown und Spectre. Also entweder wurden die Performance-Einbußen gefixt, oder es ist doch alles nicht so schlimm wie behauptet?

Complicated

2018-08-03, 14:58:13

Bucklew

2018-08-03, 15:28:27

Ich verstehe ehrlich gesagt nicht die Relevanz zu dem Thema hier.
Weil zur Einschätzung (und Diskussion) der Lage einzig und allein die RealWorld-Performance interessant ist. Und wenn nach "50% I/O Einbruch" hier und "75% Network Performance" dort eben nur 5 oder 10% Perfverlust übrig bleiben - so überhaupt - dann wird dafür sicherlich niemand seine Server wegwerfen und durch neue ersetzen.

Ganon

2018-08-03, 15:29:18

Ich verstehe ehrlich gesagt nicht die Relevanz zu dem Thema hier. AMD vs. Intel Vergleiche werden nicht die Performance-Einbußen aktuell eingesetzter Systeme der letzten 2-3 Generationen abbilden. Ryzen und Threadripper sind auch keine Server-CPUs ebenso wie die eingesetzten Intels und auch die Workloads sind nicht entsprechend abzubilden. Irgendwie habe ich eher den Eindruck als ob hier nun die Moderation auf biegen und brechen eine Fanboy-Diskussion starten will, Weshalb?
Ich würde den Offtopic über Vergleichbarkeit und Aussagekraft von Benchmarks und das darauf typischerweise folgende exzessive posten von Balken-Diagrammen hier gerne vermeiden und in einen der vielen Benchmark-Threads verweisen.

Hmm.... Sicherheit ist nicht relevant, Performance ist jetzt auch nicht mehr relevant... was ist dann jetzt relevant? Du redest von Performance Super GAU, meinst ich hätte die Auswirkungen total unterschätzt... und jetzt suche und frage ich nach entsprechenden (Gegen-)Beweisen und nun ist das auch wieder Off-Topic und nicht relevant? Benchmark A ist für dich total aussagekräftig, aber Benchmark B ist nicht relevant und Off-Topic. Weil, weißt du... Benchmarks resultieren oft in Balken-Diagrammen und wenn es hier um Performance geht, dann ist das auch irgendwo unausweichlich, nicht?

Was denn nun?

Tut mir ja leid, dass AMD Intels momentan einziger Konkurrent in dem Bereich ist. Ich würde ja auch eine andere Meltdown/SpectreV2 immune CPU heranziehen, aber leider (oder eher zum Glück) ist AMD der einzige Hersteller auf den das zutrifft. Und wenn Intel jetzt nach all den Fixes und den angeblich "massiven" Slowdowns immer noch in vielen Tests vor AMD CPUs oder auf Augenhöhe ist, dann ist das imo schon relevant, um festzustellen wie schwerwiegend die Performance-Einbußen wirklich sind und was ein betroffener Kunde nun für Möglichkeiten hat.

Sorry, aber wenn mir nicht erlaubt ist, meine Argumente zu belegen, dann kann ich dir da leider nicht weiterhelfen. Ich kann mir jetzt leider auch keine Palette an Intel CPUs aus dem Hintern ziehen, um die Benchmarks selbst zu machen.

Complicated

2018-08-03, 15:39:27

Weil zur Einschätzung (und Diskussion) der Lage einzig und allein die RealWorld-Performance interessant ist. Und wenn nach "50% I/O Einbruch" hier und "75% Network Performance" dort eben nur 5 oder 10% Perfverlust übrig bleiben - so überhaupt - dann wird dafür sicherlich niemand seine Server wegwerfen und durch neue ersetzen.
Völlig daneben wieder. Um die Realworldperformance der Patches bei Servern zu untersuchen muss keiner Intel vs. AMD mit Ryzen/TR und i7 machen. Null Ergebnis zur relevanten Fragestellung hier im Thread.

Es wurde ein Umfangreicher Test der Realworldperformance hier verlinkt und dann werden AMD vs. Intel Fragestellungen untergemischt, die keinerlei Relevanz dafür haben ob da nun ein Super-GAU für die IT vorliegt oder nicht.
Das nenne ich typisches Derailen eines Threads. Der Thread beschäftigt sich explizit NICHT mit der Konkurrenzsituation.

Ganon

2018-08-03, 15:52:06

Es geht mir bei dem Benchmark auch nicht darum zu zeigen wie toll/nicht toll AMD oder Intel ist. Er dient einfach dazu, die Performance-Einbußen bei Intel einzuordnen. Du gehst jetzt davon aus, dass Intel bei IO-Lastigen Sachen ~50% Performance verliert. Jetzt siehst du aber ein Benchmark bei der eine vergleichbare AMD CPU im Vergleich auf Augenhöhe ist. Was sagt uns das jetzt?

1. AMD war vorher schon mies in der IO-Performance, dass Intel jetzt auf AMD-Niveau eingebrochen ist?

oder nicht eher

2. der Performance-Einbruch ist gar nicht so stark wie der eine Benchmark dort zeigt?

Ich hab jetzt 2 Benchmarks verlinkt die 1. und 2. etwas beleuchten, leider gut ein halbes Jahr auseinander. Und es sieht sehr sehr stark nach #2 aus, meinst du nicht auch? Es kann natürlich auch sein, dass spezifische CPU-Generationen unterschiedlich betroffen sind, aber die Daten habe ich leider nicht.

Setsul

2018-08-03, 19:10:05

Man könnte natürlich auch Intel pre-patch mit Intel post-patch vergleichen, aber das wäre zu einfach, oder?

Lieber ein bisschen raten.

TGKlaus

2018-08-03, 23:17:32

Wie üblich, Ganon, ganz toll:

von dir kommen nur irgendwelche absolut irrelevanten Benches, wie beispielsweise "RAMspeed"

Bleiben wir doch einfach mal bei Realanwendungen, wie dem von mir genannten commvault.

Performanceeinbrüche über 50% durch die für Intel benötigten Patches sind einfach mal Tatsache.

Und Tatsache ist genauso, das deshalb die BackupServer in der DACH-Region gegen AMD getauscht werden.
Resteuropa startet damit auch noch in Q3.

Dein Whitewashing kannst du auch endlich mal sein lassen.

Ganon

2018-08-04, 00:00:29

Man könnte natürlich auch Intel pre-patch mit Intel post-patch vergleichen, aber das wäre zu einfach, oder?

Lieber ein bisschen raten.

Hab ich ja zuerst hier (https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11758571&postcount=2186) verlinkt. Sind leider schon ein halbes Jahr alt.

Wie üblich, Ganon, ganz toll:

Freut mich :)

von dir kommen nur irgendwelche absolut irrelevanten Benches, wie beispielsweise "RAMspeed"

Ein Benchmark aus 100 gefällt dir nicht, also sind die anderen 99 auch schlecht?

Und Tatsache ist genauso, das deshalb die BackupServer in der DACH-Region gegen AMD getauscht werden.
Resteuropa startet damit auch noch in Q3.

Na das ist doch schön für AMD. Wie ich ja schon sagte, Konkurrenz zu Intel ist wichtig.

Dein Whitewashing kannst du auch endlich mal sein lassen.

Magst du jetzt noch auf die Benchmark-Ergebnisse eingehen oder bleibt es bei deiner niedlichen Fehde gegen mich?

bbott

2018-08-04, 14:18:17

Es sind einfach zwei verschiedene Meinungen. Für mich ist eine Lücke die lokalen Zugriff auf den Rechner braucht, gerade bei einem Server, eher im Medium-Bereich anzusiedeln. Mal von VM-Betreibern abgesehen, wie ich ja mehrfach sagte.

Also inzwischen läuft auf ziemlich vielen Servern VMware, in den letzten Serverräumen in denen ich war und auch betreue es es fast VMware only Serverräume.

Beim Thema Meltdown & Spectre sthen wir erst am anfang, die IT-Sicherheitsforscher haben neue Angriffsszenarien enteckt und suchen nun nach weiteren.

Ein rein lokales Problem?! Also es gibt schon den ersten Angriff über das Netzwerk.
https://www.heise.de/security/meldung/NetSpectre-liest-RAM-via-Netzwerk-aus-4121831.html
Die Variante ist langsam, allerdings wer sagt denn das es nicht noch schnellere Variante kommen werden?

Keine Auswirkungen auf die Performance?
http://www.linux-magazin.de/news/openbsd-schaltet-hyperthreading-ab/
HTT abzuschalten macht aus fast allen I7

Das Damokles-Schwert wurde doch gerade erst entdeckt, das ist noch nicht wirklich gesichert, dass es herunterfällt und HTT und Ou-of-Order abgeschalter werden muss.

Ganon

2018-08-04, 14:35:29

Also inzwischen läuft auf ziemlich vielen Servern VMware, in den letzten Serverräumen in denen ich war und auch betreue es es fast VMware only Serverräume.

Beim Thema Meltdown & Spectre sthen wir erst am anfang, die IT-Sicherheitsforscher haben neue Angriffsszenarien enteckt und suchen nun nach weiteren.

Ja, das ist ja schon klar. Aber ich rede ja natürlich auch nur vom aktuellen Status, weil glaskugeln kann man halt viel.

Ein rein lokales Problem?! Also es gibt schon den ersten Angriff über das Netzwerk.
https://www.heise.de/security/meldung/NetSpectre-liest-RAM-via-Netzwerk-aus-4121831.html
Die Variante ist langsam, allerdings wer sagt denn das es nicht noch schnellere Variante kommen werden?

NetSpectre basiert auf Spectre V1, betrifft damit alle spekulativ ausführenden CPUs und muss per Software gefixt werden. Da gibt's nichts an oder abzuschalten. Rede entsprechend von Meltdown und Spectre V2.

Keine Auswirkungen auf die Performance?
http://www.linux-magazin.de/news/openbsd-schaltet-hyperthreading-ab/
HTT abzuschalten macht aus fast allen I7

Ich sage nicht, dass es keine Auswirkung auf die Performance hat. Es geht um die _schwere_ des Performance-Einbruchs. Dass OpenBSD HT abgeschaltet hat, hatten wir ja schon diskutiert. Das ist ja aktuell noch eine Maßnahme, weil es noch keinen offiziellen Fix für TLBleed gibt. Afaik ist demnächst die BlackHat und dort gibt's dann mehr Infos. Ob das Abschalten von HT die einzige Möglichkeit ist, ist halt noch nicht bekannt.

Complicated

2018-08-04, 16:31:52

NetSpecrte halte ich für harmlos, da ja schon ein üblicher DDOS Schutz das ganze verhindert. Das ausmessen von Latenzen der Pakete ist in einem produktiven Netzwerk mit sagen wir mal 20% Last ebenfalls schon unmöglich.

Setsul

2018-08-04, 17:42:44

Der große Einbruch sind immernoch KPTI bei I/O. Ein Fileserver der sonst nichts macht hat natürlich keinen Spaß mehr.

Retpoline und ähnliche Sachen kosten hier ein paar hunder Takte, da ein paar hundert Takte. Isoliert sind die schwer zu messen weil das natürlich irgendwo im Bereich 1-3% ist, die Schwankung hat man bei den meisten Tests auch so.

Interessant wäre es komplett ohne Patches und dann mit allen zu testen wenn diese Welle auch angekommen ist. Wenn sich das aufsummiert auf 7% oder so, dann merkt man das schon.

Achill

2018-08-14, 19:55:16

New Kid on the Block: L1 Terminal Fault

Ich habe es gerade auf phoronix gelesen: https://www.phoronix.com/scan.php?page=news_item&px=L1-Terminal-Fault

Die CVEs sind reserviert aber noch nicht veröffentlicht: CVE-2018-3615, CVE-2018-3620, and CVE-2018-3646

L1TF, aka L1 Terminal Fault, is yet another speculative hardware
engineering trainwreck. It's a hardware vulnerability which allows
unprivileged speculative access to data which is available in the
Level 1 Data Cache when the page table entry controlling the virtual
address, which is used for the access, has the Present bit cleared or
other reserved bits set.

If an instruction accesses a virtual address for which the relevant
page table entry (PTE) has the Present bit cleared or other reserved
bits set, then speculative execution ignores the invalid PTE and loads
the referenced data if it is present in the Level 1 Data Cache, as if
the page referenced by the address bits in the PTE was still present
and accessible.

While this is a purely speculative mechanism and the instruction will
raise a page fault when it is retired eventually, the pure act of
loading the data and making it available to other speculative
instructions opens up the opportunity for side channel attacks to
unprivileged malicious code, similar to the Meltdown attack.

While Meltdown breaks the user space to kernel space protection, L1TF
allows to attack any physical memory address in the system and the
attack works across all protection domains. It allows an attack of SGX
and also works from inside virtual machines because the speculation
bypasses the extended page table (EPT) protection mechanism.

The assoicated CVEs are: CVE-2018-3615, CVE-2018-3620, CVE-2018-3646

The mitigations provided by this pull request include:

- Host side protection by inverting the upper address bits of a non
present page table entry so the entry points to uncacheable memory.

- Hypervisor protection by flushing L1 Data Cache on VMENTER.

- SMT (HyperThreading) control knobs, which allow to 'turn off' SMT
by offlining the sibling CPU threads. The knobs are available on
the kernel command line and at runtime via sysfs

- Control knobs for the hypervisor mitigation, related to L1D flush
and SMT control. The knobs are available on the kernel command line
and at runtime via sysfs

- Extensive documentation about L1TF including various degrees of
mitigations.

Laut phoronix (leider keine Quelle) sind nach bisherigen Stand nur neuere Intel CPUs betroffen.

Es gibt dann noch eine Info von RedHat:

"Red Hat has been made aware of a new microarchitectural (hardware) implementation issue which, similar to Spectre and Meltdown, is affecting x86 microprocessors manufactured by Intel. Unprivileged attackers can use this flaw to bypass conventional memory security restrictions in order to gain access to memory resources that would otherwise be inaccessible. CVE-2018-3620 is the identifier assigned to the operating system vulnerability for this issue. CVE-2018-3646 is the identifier assigned to the virtualization aspect of the flaw. A third aspect of the flaw is referred to as 'Foreshadow;' this affects Intel Secure Enclave or SGX, which Red Hat does not ship...Red Hat rates this issue as having a security impact of IMPORTANT severity. This flaw requires an attacker to have local access to the affected host or virtualized guest system in order to exploit it."

maguumo

2018-08-14, 20:32:00

https://www.redhat.com/en/blog/understanding-l1-terminal-fault-aka-foreshadow-what-you-need-know

Unicous

2018-08-14, 20:38:51

Provides protections against a new speculative execution side-channel vulnerability known as L1 Terminal Fault (L1TF) that affects Intel® Core® processors and Intel® Xeon® processors (CVE-2018-3620 and CVE-2018-3646). Make sure previous OS protections against Spectre Variant 2 and Meltdown vulnerabilities are enabled using the registry settings outlined in the Windows Client and Windows Server guidance KB articles. (These registry settings are enabled by default for Windows Client OS editions, but disabled by default for Windows Server OS editions.)

https://support.microsoft.com/en-us/help/4343909/windows-10-update-kb4343909

Birdman

2018-08-14, 21:10:37

Hui, der nächste Exploit der ziemlich sicher nur das abschalten von HyperThreading als vollständige Absicherung nach sich zieht.
Betrifft aber mehr oder weniger nur CloudHoster, auf dem Privat- oder Firmenrechner spielt das ganze keine Rolle.

chaospanda

2018-08-15, 10:25:08

CB hat das ganze Thema auch einmal auf Deutsch zusammengefasst: https://www.computerbase.de/2018-08/foreshadow-l1tf-intel-sicherheitsluecke/

Complicated

2018-08-15, 10:25:20

Gerade die betroffenen Bereiche sind der am größten wachsende Markt derzeit. SaaS und IaaS sind davon ebenso betroffen wie sämtliche normalen Webseiten-Hoster. Und wie viele Firmenrechner sind schon umgestiegen auf Office365 (SaaS)? Im Oktober 2017 waren das immerhin schon 120 Mio. geschäftliche Nutzer. Dazu noch 28 Mio. Privatnutzer. Entsprechend groß ist die virtualisierte Infrastruktur, die betroffen ist.

Eldoran

2018-08-15, 15:43:48

Mich würde interessieren warum AMD nicht betroffen ist, also welcher Schritt in dem Exploit bei AMD nicht funtioniert (von SGX einmal abgesehen).
Zumindest bezüglich SMT wäre einmal eine Gegenüberstellung interessant, ob es da Unterschiede bei der Art der Partitionierung der Ressourcen von intels oder AMDs SMT gibt (von AMD gibt es dazu zumindest detaillierte Diagramme vom Launch). Und ggf. welche Partitionieren bei speculative execution bei intel ignoriert werden.

Setsul

2018-08-15, 16:07:20

@Eldoran:
Ist genau das gleiche wie bei Meltdown.
AMD checkt erst die valid/supervisor/sonstige bits ob man auf das zugreifen darf und wenn nicht kommen die Daten nie in den Kern und es wird nie etwas damit spekulativ ausgeführt.
Intel lässt alles erstmal laufen und prüft erst beim Retirement und dann ist es zu spät.

Ist nicht überraschend, dass Intel das immer so macht. Wenn man die "Optimierung" verwendet, dann für alles.

maguumo

2018-08-15, 16:07:57

UaQpvXSa4X8
29:05
EDIT: Zu spät, er sagt das gleiche wie Setsul.

Eldoran

2018-08-15, 16:38:06

@Setsul, maguumo: Danke. Damit ist klar, dass diese Klasse an Exploits wohl bei AMD nicht funktionieren werden.

fondness

2018-08-16, 08:34:53

CB hat das ganze Thema auch einmal auf Deutsch zusammengefasst: https://www.computerbase.de/2018-08/foreshadow-l1tf-intel-sicherheitsluecke/

LOL, ich verfolge das Thema nur am Rande, aber schön langsam wird es wirklich albern. Man hat das Gefühl eine Intel-CPU ist eine einzige Sicherheitslücke. Immer neue Lücken werden entdeckt, und die einzige konstante ist, Intel ist mit Sicherheit betroffen.

Birdman

2018-08-16, 15:29:50

So, VMWare deaktiviert* nun auch Hyperthreading auf ESXi Servern, wenn die aktuellen Patches installiert und die entsprechende Mitigation aktiviert wird :D

*
a) der Scheduler wird angepasst, sodass immer nur max 1 Thread pro Core läuft
b) in der Anzeige der logischen Prozessoren werden die HTs nun nicht mehr dazugezählt.
c) man kann keine VM mehr starten, welche mehr virtuelle Cores zugewiesen hat als es physische gibt (bisher konnte man so viele haben wie es logische cores gab)

Eldoran

2018-08-16, 21:09:34

Was ich im Zusammenhang mit Hyperthreading und VMs nicht so ganz verstehe - wo ist das Problem beide Threads der selben VM zuzuweisen?

Brillus

2018-08-16, 21:24:45

Was ich im Zusammenhang mit Hyperthreading und VMs nicht so ganz verstehe - wo ist das Problem beide Threads der selben VM zuzuweisen?

Zumindest bei der aktuellen Lücke, schützt das. Ich könnte mir vorstellen das man sicher gehen will das nicht durch irgendeine seltsame Bios-Einstellung o.ä. das Erkennen welcher Thread zu welchem Kern gehört falsch ist.

Lehdro

2018-08-23, 11:23:21

Intel mit der nächsten Dreistigkeit:
Intel untersagt eigene Benchmarks mit L1TF (https://www.computerbase.de/2018-08/l1-terminal-fault-intel-cpu-benchmark/)
You will not, and will not allow any third party to [...](v) publish or provide any Software benchmark or comparison test results.

Kriton

2018-08-23, 11:25:38

Gibt wohl ein paar "kleine" Performanceeinbußen bei Intel mit dem neuen Microcode. Aber Intel hat dafür natürlich eine passende Lösung :unono:

You will not, and will not allow any third party to [...] (v) publish or provide any Software benchmark or comparison test results.

https://perens.com/2018/08/22/new-intel-microcode-license-restriction-is-not-acceptable/

Menace

2018-08-23, 13:10:07

Schon allein deshalb sollte man solche Firmen nicht unterstützen. Tja, allgemeine NDAs everywhere.

Birdman

2018-08-23, 13:13:44

ähm, ich weiss nicht genau was dieser Passus in der Lizenz soll.
Denn der untersagt ja nicht direkt Vergleichsbenchmarks zwischen System mit/ohne Fixes, sondern ganz allgemein jegliche Benchmarks mit einem (Intel) System welches diesen Microcode eingespielt hat.

Aka, wir sehen in Zukunft keinerlei Benchmarks mehr von Intel Systemen? nVidia stellt ihre neuen Grafikkarten in Zukunft auf AMD Plattformen vor oder was?

Dino-Fossil

2018-08-23, 13:58:48

Ich glaube, man muss auf Groß/Kleinschreibung achten:

You will not, and will not allow any third party to (i) use, copy, distribute, sell or offer to sell the Software or associated documentation; (ii) modify, adapt, enhance, disassemble, decompile, reverse engineer, change or create derivative works from the Software except and only to the extent as specifically required by mandatory applicable laws or any applicable third party license terms accompanying the Software; (iii) use or make the Software available for the use or benefit of third parties; or (iv) use the Software on Your products other than those that include the Intel hardware product(s), platform(s), or software identified in the Software; or (v) publish or provide any Software benchmark or comparison test results.

Man darf also keine (Vergleichs-)Benchmarks der Software mit großem S veröffentlichen. Damit ist, vermute ich, der Microcode gemeint. In Abgrenzung dazu gibt es software mit kleinem s. :ugly:
Damit wären wohl normale Benches weiterhin ok, insofern man sie nicht mit den Microcode-Updates in Verbindung bringt.

aufkrawall

2018-08-23, 14:06:57

Bestimmt hat Phoronix schon prophylaktisch Post erhalten. ;D
Na ja, häufig übt ein Verbot ja auch einen gewissen Reiz aus, es zu missachten...

Skysnake

2018-08-23, 14:09:17

Was aber auch schon ein noGo wäre...

Vor allem bei den ganzen Hyperscalern und HPC Center frage ich mich so langsam ob die weiterhin die Patches nicht einspielen oder die Leistungseinbußen hinnehmen.

Vor allem das ist ja inzwischen so ein Wust das man gar nicht mehr den Überblick behalten kann was man jetzt an fixes hat die Leistung kosten oder eben nichz

gravitationsfeld

2018-08-23, 19:05:46

Das ist in der EU eh nicht durchsetzbar. Wahrscheinlich einfach nur ihre generische EULA die irgend welche Juristen zusammenfasziniert haben.

maguumo

2018-08-23, 19:22:25

Bestimmt hat Phoronix schon prophylaktisch Post erhalten. ;D
Na ja, häufig übt ein Verbot ja auch einen gewissen Reiz aus, es zu missachten...
https://www.phoronix.com/scan.php?page=article&item=l1tf-foreshadow-xeon&num=2
Hat nicht geholfen...

Th3o

2018-08-23, 19:31:21

Kein Wunder, dass Intel mauert. Das ist mehr als heftig.

Sephiroth

2018-08-23, 22:06:13

du meinst sicher die werte für "full mitigation" aber das bedeuetet eben auch kein SMT/HT mehr, was dann wiederum nicht verwunderlich ist.

w0mbat

2018-08-23, 22:56:18

Ändert ja nichts daran, dass man für volle Sicherheit extrem viel Leistung einbüßt.

Birdman

2018-08-23, 23:44:19

@Dino-Fossil

Ist mir nicht aufgefallen aber Du scheinst damit wirklich recht zu haben.
Wenn ich mir das nun mit diesem Wissen nochmals durchlese, dann sieht es tatsächlich so aus als ob das grossgeschriebene Software explizit den CPU Microcode meint - und somit wären dann auch klar Vergleichsmessungen mit/zwischen diesem und andern/älteren Microcodes gemeint.

Harter Tobak und etwas das denen (Intel) ganz bestimmt noch auf die Füsse fällt...

vanquish

2018-08-23, 23:55:46

Quasi ein Hardwaredowngrade (tm), das nicht als solches betitelt werden darf. Bestimmt ist man bereits fieberhaft auf der Suche nach einem positivem Ersatzwort für das Wort Microcode-Update (tm). Werden diese seit Spectre/Meltdown doch eher negativ wahrgenommen. Bin gespannt ob und wann sich jemand traut Intel "anzugreifen". Jetzt kann sich die "freie" Presse, die NDA's nicht unterschreibt, beweisen.

gravitationsfeld

2018-08-24, 04:19:11

Th3o

2018-08-24, 06:51:34

Dass die spekulative Ausführung problematisch ist weiß man schon länger und Keller ist ein schlauer Kopf.

Pirx

2018-08-24, 06:56:45

Ganon

2018-08-24, 08:40:04

Ich frage mich langsam wirklich warum gerade Intel-Prozessoren so anfaellig sind. Ist AMD wirklich nicht anfaellig oder schauen nur alle nur bei Intel so genau hin wegen dem Marktanteil?

Die Prozessoren arbeiten ja alle ungefaehr nach dem gleichen Prinzip.

Einige Lücken greifen auch spezifische Intel Hardware an (SGX z.B.)

Im Grunde basiert ja alles darauf, dass CPUs blöd spekulieren. Die ganzen Fixes sind ja Software-Fixes und wenn der Software-Fix eine Ecke vergessen hat, dann ist der Prozessor natürlich weiterhin über die alten Lücken anfällig. Die entsprechenden Flags müssen ja alle aktiv gesetzt werden und arbeiten nicht autark.

Ob und wie weit AMD auch noch seine eigenen Lücken hat (ähnlich Intels SGX) hat afaik aber noch niemand geprüft.

Menace

2018-08-24, 09:40:29

Ich habe die Sache nicht weiterverfolgt, kann mich aber an den Anfang der Diskussion erinnern. Damals hast du behauptet, dass es intel nicht so schlimm trifft und AMD wohl im gleichen Maße betroffen sein wird. Das hast du doch sinngemäß immer wieder betont. Stimmt den diese Einschätzung aktuell noch?
Du darfst diese angebliche Behauptung von mir gerne erst mal raussuchen. Mir wäre nicht bewusst, dass ich sowas je gesagt habe.

Ob und wie weit AMD auch noch seine eigenen Lücken hat (ähnlich Intels SGX) hat afaik aber noch niemand geprüft.

Siehst Du, ich brauch gar nicht an den Anfang des Threads gehen. :smile: Zwar nicht so extrem, wie ich es geschrieben hat, aber Zweifel säst Du immer bei AMD, wenn wieder was von intel raus kommt.

Ganon

2018-08-24, 09:49:03

Siehst Du, ich brauch gar nicht an den Anfang des Threads gehen. :smile: Zwar nicht so extrem, wie ich es geschrieben hat, aber Zweifel säst Du immer bei AMD, wenn wieder was von intel raus kommt.

Ich hab seine Frage beantwortet... :facepalm:

Kriton

2018-08-24, 09:58:27

War es nicht so, dass Intel mit Teilwerten arbeitet und deswegen anfälliger ist?

Menace

2018-08-24, 09:58:52

Ich hab seine Frage beantwortet... :facepalm:

Ja, dass sie bei AMD nicht geschaut haben. Dass es an eine andere Herangehensweise von AMD liegen könnte...

Übrigens hat intel ihren Lizenz zum Microcode schon überarbeitet (https://www.planet3dnow.de/cms/40057-intel-ueberarbeitet-fragwuerdige-lizenz-fuer-microcode-updates/).

Es war ein "Versehen". :freak:

Ganon

2018-08-24, 10:08:45

Ja, dass sie bei AMD nicht geschaut haben. Dass es an eine andere Herangehensweise von AMD liegen könnte...

Und nur weil du und ein paar andere hier euch ein paar "Fakten" über mich zusammengesponnen habt, müsst ihr echt nicht jeden Post von mir auf's Kleinste auseinanderpflücken und uminterpretieren, nur damit eure Spinnereien irgendwie doch stimmen könnten. Irgendwann ist auch mal gut mit dem Kleinkinder-Blödsinn hier.

Die letzten Paper erwähnen nicht mal AMD... ja warum wohl? Weil es Lücken spezifisch für Intel Hardware ist. Niemand dort hat sich AMDs SGX Alternative (heißt, glaube ich, SEV) angesehen. Und nichts weiter hab ich gesagt. edit: Und das muss hier auch nicht weiter ausgebreitet werden, nur damit ihr so tun könnt, als wenn ich darauf rumreiten würde.