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

Rooter

2018-08-24, 20:02:00

Bull. Shit.+1

Der P4 hat wie verrückt alles mögliche spekulativ ausgeführt und dementsprechend viel Strom geschluckt.Nein, Netburst hatte vor allem eine elend lange Pipeline, damit sie den Takt hochjubeln konnten.

Auch bei den Sicherheitslücken scheinen alle Core-Architekturen AFAIK gleich stark betroffen zu sein, es gab hier also keine wesentliche Weiterentwicklung mehr.Sicher gab es die, z.B. wurde (und wird) die Sprungvorhersage mit jeder Generation noch treffsicherer (Zen nutzt iirc sogar KI dafür). Auch wurden die internen Caches immer weiter erhöht (ich meine Caches wie den TLB, nicht L1/2/3) und Einheiten mehrfach ausgeführt.
EDIT: Außer, du meinst Weiterentwicklungen bei der Sicherheit der Sprungvorhersage, dann hast du vermutlich Recht.

Intels Core Architektur ist 10 Jahre altUnd basierte auf dem Pentium Pro (Intel P6) von 1995. ;)

MfG
Rooter

Birdman

2018-08-25, 02:47:29

scheinen alle Core-Architekturen AFAIK gleich stark betroffen zu sein, es gab hier also keine wesentliche Weiterentwicklung mehr. Ich kann mir deshalb schon vorstellen, dass man sich bei einer neuen Architektur.
Du hast keine Ahnung?!?
Dass es bei der Sprungvorhersage klare Weiterentwicklungen gab, sieht man gerade an der Skylake Architektur im Zusammenhang mit Spectre sehr gut.
Diese ist mittlerweile so "gut", dass nicht mal mehr Retpoline was nutzt um die CPU vom spekulieren abzuhalten.

Das ist im aktuellen Falle natürlich schlecht, aber war im Kern natürlich top! - aka selbst bei Schrottcode der kaum/keine Vorhersagen erlaubt, schafft es die CPU noch die richtigen Berechnungen vorauszusagen.

fondness

2018-08-25, 09:25:14

Laber nich dumm rum. Du hast keine Ahnung von Microarchitektur. Null. Nada. Die Aussage ist so absurd das keine andere Reaktion ausreichend war.

Das wurde mir von einer Person die es wissen muss so mitgeteilt, und ich habe erstmal nicht den geringsten Grund ihr nicht zu glauben.

Nein, Netburst hatte vor allem eine elend lange Pipeline, damit sie den Takt hochjubeln konnten.

Der P4 hat vor allem auch jede Einheit die nicht ausgelastet war mit Berechnungen zugemüllt, die den potentiellen zukünftigen Stand des Programmflusses entsprechen könnten. Das hat zwar etwas Performance gebracht, aber vorallem viel Strom geschluckt.

Du hast keine Ahnung?!?
Dass es bei der Sprungvorhersage klare Weiterentwicklungen gab, sieht man gerade an der Skylake Architektur im Zusammenhang mit Spectre sehr gut.
Diese ist mittlerweile so "gut", dass nicht mal mehr Retpoline was nutzt um die CPU vom spekulieren abzuhalten.

Das ist im aktuellen Falle natürlich schlecht, aber war im Kern natürlich top! - aka selbst bei Schrottcode der kaum/keine Vorhersagen erlaubt, schafft es die CPU noch die richtigen Berechnungen vorauszusagen.

Dir ist schon klar, dass Sprungvorhersage etwas anderes ist als speculativ execution? Die Sprungvorhersage ist eines der größten Forschungsgebiete aktuell. Sprungvorhersage geht aber nur soweit, den nächsten bedingten Sprung vorherzusagen und die entsprechenden Instuctions zu laden, speculativ execution berechnet auf Basis von Dingen wie der Sprungvorhersage bereits die nächsten Ergebnisse.

Sei es wie es sei, um wieder zum Ursprungsthema zurück zu kommen: Die Fakten liegen eh am Tisch, offensichtlich hat AMD hier andere Ansätze gewählt, sonst wären die beiden Prozessorarchitekturen nicht so unterschiedlich stark anfällig für diese Sicherheitslücken.

iuno

2018-08-25, 10:45:05

Lehdro

2018-08-25, 11:10:29

AMD ist damit ja schon auf die Schnauze gefallen, als man verkuendet hat, man sei nicht von Meltdown und Spectre betroffen und dann teilweise zurueckrudern musste.
Das hätte ich immer noch gerne mal als erste Hand Quelle belegt.

blackbox

2018-08-25, 11:16:27

Sagt mal, wie real ist/sind diese Lücke(n) nun wirklich eine Gefahr für den Benutzer?
Wenn ich das richtig verstehe, dann braucht jemand/etwas Zugriff auf das System. Aber dann habe ich doch sowieso verloren, da brauche ich doch keine Lücken auszunutzen?!?

Th3o

2018-08-25, 11:30:00

AMD soll also seine Unschuld beweisen, weil Intel schludrig war? Das wird ja immer besser. In dubio pro reo!

Linmoum

2018-08-25, 11:35:05

AMD ist damit ja schon auf die Schnauze gefallen, als man verkuendet hat, man sei nicht von Meltdown und Spectre betroffen und dann teilweise zurueckrudern musste.
Das ist falsch und nie der Fall gewesen.

Meltdown wurde und wird von AMD (architekturbeding) kategorisch ausgeschlossen und bei Spectre hieß es "near zero risk". Da war nix mit zurückrudern.

iuno

2018-08-25, 11:37:08

Das hätte ich immer noch gerne mal als erste Hand Quelle belegt.
Was genau? Dir ist doch klar, dass AMD von Spectre betroffen ist?

AMD soll also seine Unschuld beweisen, weil Intel schludrig war? Das wird ja immer besser. In dubio pro reo!
Es geht nicht ums Beweisen irgendeiner "Unschuld", sondern um Abwaegungen zur Sicherheit, der Konzeption und Implementierung. Bei Software ist es ganz normal, dass audits oder pentests gemacht werden. Es gibt sonst ueberhaupt keinen Grund, closed source Software zu vertrauen. Warum sollte man denselben Standard nicht bei Hardware ansetzen?
Beweisen kann man eh nichts. Es wuerde aber (sowohl den Kunden als auch den Verkaufszahlen) helfen, wenn AMD mal im Voraus solche Infos* raus geben wuerde, anstatt nur hinterher jedes mal zu verneinen dass man betroffen ist.

*Infos, die belegen, dass man ganz grundsaetzlich weitaus weniger anfaellig gegen jegliche dieser Probleme ist. So stellen sich das ja einige hier ganz offensichtlich vor.
Das ist ja nicht meine Logik, sondern die der Leute im Thread die ein AMD-Intel fanboy Krieg draus machen wollen.

Das ist falsch und nie der Fall gewesen.

Meltdown wurde und wird von AMD (architekturbeding) kategorisch ausgeschlossen und bei Spectre hieß es "near zero risk". Da war nix mit zurückrudern.
Man hat erstmal verneint, dass man fuer alle drei Varianten (https://www.axios.com/massive-chip-flaw-not-limited-to-intel-1515111022-23827670-9ea6-4c08-a6e2-ba06dcfddae8.html) (Meltdown, Spectre variant1/2) anfaellig sei. Und "near zero risk" ist natuerlich Marketing-blabla deshalb sind auch mitigations in Betriebssystemen aktiv und es wurden microcode Patches ausgeliefert. Von Meltdown spricht ja hier keiner, man hat aber anfangs so getan, als sei Spectre auch kein Problem.
The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants. Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time.
Ich verstehe aber einfach nicht, warum man das ueberhaupt jetzt noch zum Thema machen muss.

Th3o

2018-08-25, 11:47:05

Jeder Softwareentwickler weiß, dass man durch Tests nur die Anwesenheit von Fehlern feststellen kann, nicht aber deren Abwesenheit. Das gleiche gilt auch für Hardware. Es wäre törricht von AMD zu behaupten, dass deren Produkte 100% Prozent fehlerfrei sein, sie wären sehr angreifbar.

iuno

2018-08-25, 11:51:30

Dann sind wir uns ja einig.

Kriton

2018-08-25, 12:36:07

In der Wissenschaft werden gerne auch Negativergebnisse publiziert.

Reden wir von derselben Wissenschaft? Oder ist das eine Besonderheit in der Informatik?

Lehdro

2018-08-25, 12:36:39

Und ich sehe immer noch kein zurückrudern. Das steht doch direkt in dem Statement was von "near zero risk", was eben kein 100% ausschliessen ist. Somit ist deine Aussage das AMD zurückrudert immernoch faktisch falsch. Und ja, selbst "near zero risk" kann man noch verkleinern, das ist wohl eher ein logisches Problem was du da mit der Aussage hast - das kann aber nicht Gegenstand einer Falschaussage, die bei deiner bisheriger Faktennennung rein auf deinem Gefühl basiert, sein.

fondness

2018-08-25, 12:41:28

Welche Fakten? Fuer die Aussage gibt es doch ueberhaupt keinen Beleg. Hat sich jemand bisher ernsthaft in diesem Zusammenhang Zen angeschaut, abseits von den Trollen die gleich nach Meltdown mit "20 meltdown-like AMD vulnerabilities!!!!!!!!!11111" um die Ecke kamen? In der Wissenschaft werden gerne auch Negativergebnisse publiziert. Natuerlich ist AMD (oder ARM oder IBM, um die auch mal zu nennen) nicht anfaellig fuer hardwarespezifische Intel-Bugs. Aber das heisst doch nicht automatisch, dass sie nicht die selben Probleme bekommen koennten. Core ist jetzt wie viel, 10 Jahre alt? Und nach und nach kommen diese Schwachstellen erst ans Licht. Zen ist gerade mal ein Jahr alt. Dazu ist Intel der Branchenprimus und bietet bei weitem mehr Prestige fuer die Forscher.
Und wenn die Funktionsweise so fundamental anders waere, dass Kategorien dieser Schwachstellen ausgeschlossen werden koennten, koennten diese Hersteller auch mal damit auf den Putz hauen. Das passiert aber nicht. AMD ist damit ja schon auf die Schnauze gefallen, als man verkuendet hat, man sei nicht von Meltdown und Spectre betroffen und dann teilweise zurueckrudern musste.
Es heisst ja nicht, dass AMD automatisch anfaellig ist. Es heisst, dass wir es nicht wissen. Ich waere jetzt schon vorsichtig damit, Intel als Schrotthaufen und AMD/ARM/IBM als super zu bezeichnen und alles umzuziehen. Zumal andere Hersteller auch wieder andere Probleme mitbringen.

Entschuldigung, aber es wurde vor nicht allzu langer Zeit eine völlig neue Art von möglichen Sicherheitslücken aufgedeckt. Diese haben alle dieselbe Vorgangsweise, sie nutzen die spekulative Ausführung von Code moderner CPUs aus. Seitdem haben sich viele Sicherheitsforscher weltweit auf die Suche nach weiteren Lücken gemacht. Dabei wurde auch einiges gefunden, betroffen sind je nach Lücke alle CPU-Hersteller. Praktisch nichts davon sind Intel-spezifische Sicherheitslücken (mit wenigen Ausnahmen, wo allerdings auch bei AMD gesucht wurde und was gefunden wurde, wozu man allerdings root Rechte benötigt AFAIK).

Auffällig ist auf jeden Fall, dass Intel summa summarum am häufigsten betroffen ist, gefolgt von ARM/IBM und am wenigsten betroffen ist ganz eindeutig AMD. Das sind die Fakten, von denen ich gesprochen habe. Heißt das jetzt, dass AMD für alle Zukunft gegen jegliche Sicherheitslücke gefeit ist? Natürlich nicht. Man kann das Vorhandensein einer Sicherheitslücke per se niemals ausschließen. Allerdings muss man deshalb nicht so tun, als wäre alles was man bis heute weiß belanglos. AMD musste im übrigen überhaupt nirgends zurück rudern. Nachdem diese Attacken allerdings kein Intel-Spezifikum sind, sondern wie gesagt allgemeine Vorgangsweisen moderner CPUs versuchen auszunutzen, muss man auch nicht so tun als möchten sich alle Forschen ja nur auf Intel einschießen und den Branchenprimus treffen und es hätte ja so überhaupt nichts mit der HW zu tun.

Denniss

2018-08-25, 12:41:30

AMD hat Spectre V1 immer als zutreffend bezeichnet, Meltdown immer verneint und Spectre V2 als near zero risk bezeichnet. Dies hat sich alles bis heute so gehalten und ist immer noch zutreffend.
AMD hat Gegenmaßnamen for Spectre V2 veröffentlicht um jedes auch noch so kleine Restrisiko auszuschließen.
Ein Zurückrudern gab es nirgends, es gab einige Webseiten die dies verbreitet haben da sie anfangs über AMD falsch berichtet haben (als überhaupt nicht betroffen oder so, Heise hat sich da nicht mit Ruhm bekleckert).

Kriton

2018-08-25, 12:51:35

Zu den neueren Lücken sagt AMD übrigens ein wenig:

"Speculative Store Bypass” Vulnerability Mitigations for AMD Platforms:

5/21/18

Today, Microsoft and Google Project Zero researchers have identified a new category of speculative execution side channel vulnerability (Speculative Store Bypass or SSB) that is closely related to the previously disclosed GPZ/Spectre variant 1 vulnerabilities. Microsoft has released an advisory on the vulnerability and mitigation plans.

AMD recommended mitigations for SSB are being provided by operating system updates back to the Family 15 processors (“Bulldozer” products). For technical details, please see the AMD whitepaper. Microsoft is completing final testing and validation of AMD-specific updates for Windows client and server operating systems, which are expected to be released through their standard update process. Similarly, Linux distributors are developing operating system updates for SSB. AMD recommends checking with your OS provider for specific guidance on schedules.

Based on the difficulty to exploit the vulnerability, AMD and our ecosystem partners currently recommend using the default setting that maintains support for memory disambiguation.

We have not identified any AMD x86 products susceptible to the Variant 3a vulnerability in our analysis to-date.

As a reminder, security best practices of keeping your operating system and BIOS up-to-date, utilizing safe computer practices and running antivirus software are always the first line of defense in maintaining device security.

Foreshadow

8/14/18 – Updated

As in the case with Meltdown, we believe our processors are not susceptible to these new speculative execution attack variants: L1 Terminal Fault – SGX (also known as Foreshadow) CVE 2018-3615, L1 Terminal Fault – OS/SMM (also known as Foreshadow-NG) CVE 2018-3620, and L1 Terminal Fault – VMM (also known as Foreshadow-NG) CVE 2018-3646, due to our hardware paging architecture protections. We are advising customers running AMD EPYC™ processors in their data centers, including in virtualized environments, to not implement Foreshadow-related software mitigations for their AMD platforms.

https://www.amd.com/en/corporate/security-updates

bun

2018-08-25, 15:04:07

Es ist unwahrscheinlich das AMD noch größere Lücken hat, zumindest welche die bekannt sind. Ansonsten gäbe es nämlich weiter fleißig FUD alla CTS-Labs.

TRX

2018-08-25, 21:11:07

Ich schätze mal, dass Intel ne ganze Abteilung damit beschäftigt Exploits lauffähig auf Prozessoren von anderen Herstellern zu erstellen. Bislang war das anscheinend nicht von besonderen Erfolg gekrönt.:biggrin:

Ich denke man kann davon ausgehen, dass die AMD-CPU´s derzeit noch recht sicher sind.:smile:

gravitationsfeld

2018-08-25, 22:57:58

Das wurde mir von einer Person die es wissen muss so mitgeteilt, und ich habe erstmal nicht den geringsten Grund ihr nicht zu glauben.
Es ist immer noch vollstaendiger Schwachsinn. Es gibt keine CPU die nicht spekuliert seit mindestens den ersten Pentiums. Netburst war ein wenig aggressiver, weil sie den Replay-Unsinn hatten, aber das da seither irgend etwas "am Rueckzug" ist, ist absoluter hanebuechener Unsinn.

Ohne Spekulation waere die Performance nicht mal die Haelfte bei modernen CPUs. Und ja, auch jede AMD-CPU seit Jahrzehnten hat Spekulation.

Der P4 hat vor allem auch jede Einheit die nicht ausgelastet war mit Berechnungen zugemüllt, die den potentiellen zukünftigen Stand des Programmflusses entsprechen könnten. Das hat zwar etwas Performance gebracht, aber vorallem viel Strom geschluckt.
Nein. So funktioniert Replay nicht.

Im Uebrigen macht das auch jede andere moderne CPU. Spruenge werden spekuliert und wenn der Sprung dann nicht genommen wurde werden die Ergebnisse verworfen. Seit Ewigkeiten.

Leonidas

2018-08-26, 06:33:22

Irgendein Linux-Entwickler hat das mal mit einer aktuellen Intel-CPU getestet. Der hatte noch 5% Performance damit (ohne Spekulation), ergo ein 20igstel.

Eine ohne Spekulation entwickelte CPU-Architektur könnte schneller sein. Aber richtig Performance ist damit nicht drin. Zudem dürfte das schwer energieeffizient zu bekommen sein - man muß viele Einheiten bauen, lastet aber immer nur wenige davon aus. Letztlich ist die Spungvorhersage eine Vorform von HyperThreading - eine Möglichkeit, bestehende Einheiten besser auszulasten.

fondness

2018-08-26, 08:50:44

Es ist immer noch vollstaendiger Schwachsinn. Es gibt keine CPU die nicht spekuliert seit mindestens den ersten Pentiums. Netburst war ein wenig aggressiver, weil sie den Replay-Unsinn hatten, aber das da seither irgend etwas "am Rueckzug" ist, ist absoluter hanebuechener Unsinn.

Ohne Spekulation waere die Performance nicht mal die Haelfte bei modernen CPUs. Und ja, auch jede AMD-CPU seit Jahrzehnten hat Spekulation.

Ich habe geschrieben, dass speculativ execution seit dem P4 eher am Rückzug ist und nur noch dort eingesetzt wird, wo es sich aus Perf/Watt-Sicht lohnt. Nicht mehr und nicht weniger. Also bitte mir nicht irgendwelche Worte in den Mund legen die nie gesagt wurden. Und nein, dass ist kein Schwachsinn.

aufkrawall

2018-08-26, 20:18:18

Dorn

2018-08-26, 22:25:57

Ich hab den Spectre- & Meltdown-Schutz von Windows im Verdacht, kurzzeitig verzerrten Ton in bestimmten Spielen zu verursachen. Muss aber erst noch Stromsparmodi etc. als Ursache sicherer ausschließen als bislang.
Gleicher CPU und auch Realtek Crap am start, Spectre ist aber nicht installiert und noch nie Sound Bugs gehabt.

aufkrawall

2018-08-26, 22:30:24

Hast du InSpectre gecheckt? Der MC wird via WU verteilt.
Ich hab das auch zu 99% nur in HotS, aber das ist durch seine ständigen Frametime-Spikes auch ein Härtefall.

gravitationsfeld

2018-08-27, 02:00:39

Ich habe geschrieben, dass speculativ execution seit dem P4 eher am Rückzug ist und nur noch dort eingesetzt wird, wo es sich aus Perf/Watt-Sicht lohnt. Nicht mehr und nicht weniger. Also bitte mir nicht irgendwelche Worte in den Mund legen die nie gesagt wurden. Und nein, dass ist kein Schwachsinn.
Das klingt so als wuerdest du meinen, dass es nur "manchmal" passiert. Das ist nicht der Fall. Alle Programmausfuehrung ist spekulativ. Immer. Der Check ob etwas wirklich korrekt war passiert immer erst am Ende in den Reorder-Buffern.

Dorn

2018-08-27, 09:11:53

Hast du InSpectre gecheckt? Der MC wird via WU verteilt.
Gerade geprüft ist nicht installiert. Nach meinem Kenntnisstand muss man den MC für Spectre weiterhin bei Microsoft downloaden. Was ich nicht brauche, da ich am Gamingrechner nur spiele.

Naitsabes

2018-08-27, 12:14:10

Bei den Surfacegeräten wird der MC automatisch heruntergeladen und installiert. Aber die Geräte haben ja auch eine gewisse Sonderstellung.
Bei meinem Rechner mit Kaveri wüsste ich nicht, dass sowas passiert sei (ist da ja auch eher wenig nötig).

aufkrawall

2018-08-27, 12:44:05

Ich hatte die Tage allerdings auch via WU das MC-Update aus Mai fürs AU eingespielt bekommen. Kann allerdings sein, dass ich vorher ein anderes MC-Update manuell installiert hatte.

y33H@

2018-08-30, 09:12:24

Intel hat bestätigt, dass Whiskey Lake U in Hardware gegen Meltdown und gegen L1TF gehärtet ist, bei Amber Lake Y bleibt es bei Microcode-Updates.

unl34shed

2018-08-30, 09:25:14

Wie haben sie das denn so schnell hinbekommen?

eratte

2018-08-30, 09:43:22

Laut heise hat sich am CPU Teil nichts groß getan:

Am CPU-Teil hat sich wenig getan: Abgesehen von minimal anderen Taktraten unterscheidet sich der Prozessor nicht von den fast ein Jahr alten Vierkern-Modellen, die Intel-intern Kaby Lake Refresh heißen und mit vier statt vormals zwei Kernen für einen ordentlichen Performance-Schub sorgten.

Intel's Whiskey Lake Brings In-Silicon Meltdown and Foreshadow Fixes (tom's Hardware) (https://www.tomshardware.com/news/whiskey-lake-mitigations-in-silicon-intel,37723.html)

Whiskey Lake processors will still need a combination of microcode and operating system patches for most variants, but now the Meltdown and L1TF Foreshadow are patched fully in hardware.

Denniss

2018-08-30, 10:57:08

Ob das "patched in hardware" wirklich glaubwürdig ist? Kann ja auch eine schwammige definition sein und bedeutet nur daß der eingebettete Microcode das bereits umgeht.

Ganon

2018-08-30, 11:02:04

Für Meltdown gibt es keinen Microcode-Fix. Das macht das OS komplett alleine. Also entweder ist es ein richtiger Fix oder ein Workaround in Hardware. Ob er "sicher" ist, werden die Forscher vermutlich früh genug rausfinden.

Birdman

2018-08-30, 12:23:00

Wie haben sie das denn so schnell hinbekommen?
Meltdown und damit auch L1TF ist Intel ja schon länger bekannt. (mit Sicherheit seit Mitte 2017, verm. aber schon etwas früher)
Das ist genug Zeit um ein paar Änderungen an einem CPU Design vorzunehmen, das ende 2018 erscheinen soll, zumal ich vermute dass dieser Hardware-Fix noch relativ simplel war.

Complicated

2018-08-30, 12:54:32

Das konnten sie sich ja bei AMD abschauen warum sie für die beiden Lücken nicht anfällig sind. Nun haben sie also hardwareseitig zu AMD aufgeschlossen und bieten den selben Hardware-Schutz wie ein 9 Jahre alter Phenom II.

Lehdro

2018-08-30, 15:48:07

Auch wenn es Phoronix ist:

The Performance Cost Of Spectre / Meltdown / Foreshadow Mitigations On Linux 4.19 (https://www.phoronix.com/scan.php?page=article&item=linux-419-mitigations&num=1)

Intel verliert wenig überraschend teilweise sehr deutlich an Performance, doch auch bei AMD lässt man im Schnitt sicherlich rund 5% liegen.

Complicated

2018-08-30, 16:25:30

Nur sind es bei AMD:
On the AMD EPYC side the default mitigations are just for their relevant vulnerabilities with __user pointer sanitization for Spectre V1, AMD Retpoline IBPB for Spectre V2, and speculative store bypass disable (SSBD) for Spectre V4.
Und bei Intel nicht alle Mitgations aktiv:
On the Intel side the relevant mitigations include page table isolation (PTI/KPTI) for Meltdown and then the various Spectre speculative execution mitigations including __user pointer sanitization, full generic Retpolines via IBPB IBRS_FW, speculative store bypass disable via prctl and seccomp, and for L1TF/Foreshadow is PTE inversion and conditional cache flushes for VMs. By default the Linux kernel doesn't enforce the "full" mitigation of disabling Intel HT/SMT support, so keep that in mind if you are running VMs and whether untrusted code/users have access to the VM that if you opt for the full mitigation where SMT is disabled the performance impact will be a lot more noticeable due to halving the number of threads available.

Achill

2018-08-30, 21:22:45

Ich Forum zu dem Test auf Phoronix wird noch argumentiert, dass der verwendet Microcode noch Einfluss auf die Performance hat.

Der Test zeigt wahrscheinlich nur (kann das nicht prüfen), wie mit den aktuellen Microcode und den Kernel-Switches die Performance variiert, nicht aber, wie die Performance vor Meltdown/Spectre und jetzt ist - dafür müsste ein älterer Microcode verwendet werden. Wäre auch interessant, wie viel ich jetzt unter Linux beim Arbeiten verloren habe... (ist natürlich noch schnell genug für meine paar VM / Docker-Container oder Mini-Kubernetis aka MiniKube)

Eldoran

2018-09-03, 14:01:18

Etwas Off-Topic: Meltdown, Spectre etc. ist nicht der einzige potentielle Angriffsvektor auf die Hardware. Man denke da auch an Rowhammer (https://de.wikipedia.org/wiki/Rowhammer) etc. gerade habe ich da einen weiteren gesehen - EMP auf die ARM Trustzone (https://www.usenix.org/system/files/conference/woot17/woot17-paper-cui.pdf). AMDs ME basiert meines Wissens auf ARM Trustzone. Allerdings realistisch betrachtet, selbst wenn der Aufbau anwendbar sein sollte - das ist nur ein weiterer Angriff der nur mit physischem Zugriff auf de Hardware möglich ist und im Vergleich zu Angriffen über den USB Port bei intel eher komplex.

Complicated

2018-09-03, 14:17:17

Die beste Option bei AMDs Trustzone ist die Deakivierbarkeit, und auch ein Vorteil gegenüber Intel.

aufkrawall

2018-09-03, 14:51:27

Die beste Option bei AMDs Trustzone ist die Deakivierbarkeit, und auch ein Vorteil gegenüber Intel.
Steht das Device dem OS nach Deaktivierung denn wirklich nicht mehr zu Verfügung (z.B. kein Eintrag mehr im Gerätemanager)?

Complicated

2018-09-03, 15:05:59

http://www.pcgameshardware.de/AMD-Zen-Architektur-261795/News/AMD-Platform-Security-Processor-per-BIOS-Update-deaktivierbar-1245467/
Dies ist zum Beispiel bei Asrock-Mainboards wie dem AB350M Pro4 der Fall. Durch Deaktivieren der Setup-Option "BIOS PSP Support" wird laut Beschreibungstext die Ausführung des PSP-Treibers ausgeschaltet.

aufkrawall

2018-09-03, 15:15:06

Toll, und was steht da ein paar Zeilen weiter?
Leider ist die genaue Wirkweise des Platform Security Processors nicht dokumentiert, es ist außerdem nicht klar, ob sämtliche Funktionen des PSPs vollständig deaktiviert werden.

Complicated

2018-09-03, 17:11:40

Und was hindert dich daran auf Basis dieser Info selber weiter zu recherchieren? Für mich war es nicht Interessant bisher, daher ist das der Stand den ich anbieten kann. Nimm es oder lass es, es ist ein Forum. Bisher kanntest du nicht mal die Möglichkeit.

aufkrawall

2018-09-04, 15:57:30

Du hast einfach etwas behauptet und bist einen belastbaren Beweis schuldig gablieben, da brauchts jetzt kein Mimimi zur Ablenkung...

Ganon

2018-09-04, 16:40:55

Der PSP wird damit auch nicht deaktiviert, sondern nur ein paar Schnittstellen zwischen OS und PSP. Aber die Diskussion rund um Lücken aller Art in Firmware findet hier statt (https://www.forum-3dcenter.org/vbulletin/showthread.php?t=580008)

Complicated

2018-09-04, 16:50:01

Du hast einfach etwas behauptet und bist einen belastbaren Beweis schuldig gablieben, da brauchts jetzt kein Mimimi zur Ablenkung...Der Beweis, dass PSP abschaltbar ist geliefert. Der Treiber ist deaktiviert. Ob das deinen persönlichen Ansprüchen genügt weis ich nicht und das musst du selber raus finden. Oder soll ich dir das Ding auch noch zusammenschrauben?

kruemelmonster

2018-09-04, 21:45:42

Der Beweis, dass PSP abschaltbar ist geliefert. Der Treiber ist deaktiviert. Ob das deinen persönlichen Ansprüchen genügt weis ich nicht und das musst du selber raus finden. Oder soll ich dir das Ding auch noch zusammenschrauben?

Wie wärs stattdessen mit anständigem zwischenmenschlichen Verhalten?

[deine mutter]
Benimmst du dich woanders etwa auch so?
[/deine mutter]

Complicated

2018-09-04, 22:10:34

Was meinst du damit? Anderen die Arbeit abnehmen wenn sie unverschämt sind?

Kriton

2018-09-04, 22:31:55

Was vermutlich gut gewesen wäre, das was aufkrawall zitiert hat, bereits in Deinem Zitat mit aufzuführen.

Im Übrigen: Kommt mal alle runter und lasst uns die Metaebene wieder verlassen.

Eldoran

2018-09-15, 19:52:02

Ich glaube Nemesis hatten wir noch nicht - das ist wieder ein anderer Weg um SGX (und vergleichbare Technologien) zu umgehen (Sidechannel: Interrupt timing).
https://people.cs.kuleuven.be/~jo.vanbulck/ccs18.pdf

Das ist für durchschnittlichen Verbraucher eher uninteressant - das gibt es ohnehin nur in den neueren Server Chips. Aber mittlerweile hat sich gezeigt, dass mit spectre etc. mehrere Wege existieren um auf die dort hinterlegten Daten zuzugreifen. Nemesis ist eben ein weiterer Angriffsvektor.

Achill

2018-10-01, 13:32:52

Es gibt ein neues Sicherheitsupdate kb4100347 (https://www.tenforums.com/windows-10-news/110331-kb4100347-intel-microcode-updates-windows-10-v1803-september-13-a.html) von MS inkl. Microcode für die Intel-CPUs:
- Broadwell Server E, EP, EP4S
- Broadwell Server EX
- Skylake Server SP (H0, M0, U0)
- Skylake D (Bakerville)
- Skylake X (Basin Falls)

Soweit eigentlich nicht weiter schlimm, jedoch deaktiviert es bei mir das komplett OC vom 6850k ... das ist mal Performance-Degradation! :freak:

Wenn es auch betrifft, hier der entsprechende Reddit-Thread (https://www.reddit.com/r/overclocking/comments/9i5buy/i76800k_mated_to_asus_x99_a_ii_multiplier_set_to/).

Bei mir fliegt es jetzt runter und wird dann geblockt - wichtige Arbeiten mache ich eh nur unter Linux wo das Microcode-Update schon lange aktiv ist.
1. (als Admin) wusa /uninstall /kb:4100347
2. Mit https://support.microsoft.com/en-us/help/4026726/windows-hide-windows-updates-or-driver-updates Update deaktivieren

--
Edit: Kann den "Fix" jetzt auch bestätigen ...

Rooter

2018-10-03, 14:48:49

Hat CB vor ner Woche auch schon drüber berichtet:
https://www.computerbase.de/2018-09/microcode-broadwell-e-kein-oc/

MfG
Rooter

mironicus

2018-10-03, 19:19:05

Irgendwann bringt Microsoft noch ein Update raus, was das Hyperthreading bei sämtlichen Intel-Prozessoren deaktiviert und Intel sagt dann seinen Kunden das sie bis 2021 warten müssen um fehlerbereinigte Prozessoren erhalten zu können. :D

Th3o

2018-10-03, 22:51:11

Ich habe ein Notebook mit einen i3-3110M mit Windows 7. Seit einiger Zeit kommt mir die Kiste immer langsamer vor, es wird wohl auch an diesen ganzen Meltdown-/Spectre Parches liegen. Das nervt schon. Intel ist für mich erstmal ein No-Go.

Fusion_Power

2018-10-03, 22:59:51

Ich hab zwar auch Microcode Updates erhalten aber ich glaub, mein altes Bios kann damit gar nix anfangen. Merke auch keinen Geschwindigkeitsänderung (Skylake i5 ).

aufkrawall

2018-10-03, 23:07:17

Das Bios spielt wegen des Microcode-Updates via OS dahingehend keine Rolle mehr. ;)
Mit Skylake sind die Performance-Auswirkungen bei typischer Nutzung auch nicht oder fast nicht zu merken. In meinen Spielen war der Unterschied im CPU-Limit bisher faktisch im Rahmen der Messungenauigkeiten (Spectre + Meltdown zusammen).

Fusion_Power

2018-10-04, 15:21:48

Na, dann hab ich ja nochmal Glück gehabt. ^^ Ich blick bei all den Spectre+Meltdown security updates eh nicht durch, außer den Microcode Updates hab ich dahingehend bei mir nichts bemerkt, bzw. nichts extra installiert. Man soll ja auch mal die Management Engine updaten, aber ich weiß nicht mal wie und ob ich die Software dazu überhaupt im System hab.

aufkrawall

2018-10-04, 17:14:54

Es gab letztes Jahr Lücken bei HTT und der ME, die unabhängig von den diesjährigen waren. Die ME konnte man bei ASrock direkt via Tool aktualisieren und für den HTT-Bug gabs ein Bios-Update. Bietet der Board-Hersteller für beides nichts an, hat man Pech gehabt. Anders als bei Spectre, wofür die Microcode-Updates via OS die Hersteller weitestgehend aus der Verantwortung entlassen.

Nochmal ein aktueller Benchmark mit Win 10 1809:
https://abload.de/thumb/sottr_2018_10_04_16_57bdg1.jpg (https://abload.de/image.php?img=sottr_2018_10_04_16_57bdg1.jpg) https://abload.de/thumb/sottr_2018_10_04_17_0vrcj5.jpg (https://abload.de/image.php?img=sottr_2018_10_04_17_0vrcj5.jpg)

Kostet, wie bereits gesagt, quasi gar nichts.

Iscaran

2018-10-04, 19:22:26

111 vs 94 FPS quasi gar nichts ?!? (EDIT: das sind 118% vs 100%) bzw. 100% zu 85%.

aufkrawall

2018-10-04, 19:38:47

Waren ja auch offensichtlich die falschen Bilder, weil noch ein Pfad im Filepicker vom Browser mit ähnlichen Bildern vorausgewählt war. Jetzt stimmt es aber.

Iscaran

2018-10-04, 19:50:51

101.7 / 98.4 sieht schon deutlich besser aus und liegt eher im Rahmen der Erwartungen :-).

=100% / 96.7 %
Also ca 3-4% weniger da Games zum Glück in der Regel nicht sehr I/O lastig sind und viel Datenzugriffe haben.

Achill

2018-10-04, 23:11:34

Die Problematik von kb4100347 war, dass das komplette OC auf Broadwell-E und Skylake-X mit dem Patch deaktiviert wurde.

Unicous

2018-10-05, 01:39:25

Und das er auch auf AMD-Systemen installiert wird.:freak:

Außerdem wird das Update doch immer noch verteilt, oder wurde es schon gefixed?

Dorn

2018-10-17, 19:30:44

Aus dem Urlaub zurück werfe ich mal InSpectre an, was sehen meine Augen mein Skylake ist durch irgendein ein MS Update vor Spectre geschützt. Gleich mal ausschalten! (Gamingrechner!11!1)

sapito

2018-10-17, 21:07:12

habe mal den benchmark mit und ohne meltdown/ spectre mitigation laufen lassen

mitigation ON

https://screenshotscdn.firefoxusercontent.com/images/8e9f40a8-e9db-41a8-9309-479bc86f8195.jpg

mitigation OFF

https://screenshotscdn.firefoxusercontent.com/images/484436b6-cd7c-421d-946e-979989c090b6.jpg

10 FPS weniger bei den Min FPS ist schon ne Hausnummer

aufkrawall

2018-10-17, 21:09:17

Das Spiel soll angeblich Amok laufen bez. IO-Zugriffen fürs Streaming.

Dorn

2018-10-17, 21:39:44

Das Spiel soll angeblich Amok laufen bez. IO-Zugriffen fürs Streaming. Hat aber in erster Linie nichts mit Spectre etc. zu tun.

Glaube nach 15 Jahren Intel (AMD Barton 2500+ war mein letzter AMD CPU) werde ich bei Ryzen 3 wieder zu AMD zurück kehren.

Intel ist bei mir mittlerweile eine Lachnummer, soviel extrem viel Geld und pimmeln immer noch bei quasi 14 nm rum und das mega desaster mit den Sicherheitslücken welche wie ich finde irgendwie bei der Masse schon wieder vergessen sind.

aufkrawall

2018-10-17, 22:11:14

Hat aber in erster Linie nichts mit Spectre etc. zu tun.

Definiere "in erster Linie". Natürlich verursachen die Mitigations keine zusätzlichen IO-Aufrufe, aber sie machen sie eben langsamer.

vanquish

2018-10-22, 22:02:49

In der kommenden Version von Windows 10 will Microsoft Retpoline gegen Spectre einführen.
https://www.golem.de/news/windows-10-retpoline-patch-gegen-spectre-verbessert-cpu-leistung-1810-137253.html

aufkrawall

2018-10-23, 17:49:46

In Linux 4.19 sind alle bekannten Lücken mitigated.

Sephiroth

2018-11-04, 22:44:05

weiter geht es mit CVE-2018-5407 PortSmash
Neue Schwachstelle in Intel-CPUs: Hyper-Threading anfällig für Datenleck

Forscher demonstrieren einen neuen CPU-Bug bei aktuellen Intel-Prozessoren, über den sich Daten aus einem benachbarten Thread auslesen lassen.

Eine Forschergruppe hat in aktuellen Intel-CPUs eine neue Schwachstelle entdeckt, über die Schadcode beliebige Daten eines anderen Prozesses auslesen kann. Der Seitenkanalangriff richtet sich auf simultanes Multi-Threading (SMT), das Intel unter der Bezeichnung Hyper-Threading implementiert, und kann Daten eines zweiten Threads auf demselben CPU-Kern mitschneiden.
https://heise.de/-4210282
https://github.com/bbbrumley/portsmash

Th3o

2018-11-04, 23:08:07

Falsche Übersetzung bei Heise

ZDNET: but Brumley told us via email that he strongly suspects that AMD CPUs are also impacted.
heise: Jedoch sei Billy Brumley, einer der Beteiligten, bereits davon überzeugt, dass AMD-CPUs ebenfalls anfällig sind

suspect bedeutet vermuten nicht überzeugt sein
sogar Google kann das besser übersetzen: Brumley teilte uns per E-Mail mit, dass er den Verdacht hat, dass auch AMD-CPUs betroffen sind.

Heise nur peinlich sowas

Screemer

2018-11-04, 23:16:18

Gaaaanz schlimmer Übersetzungsfehler in dem Zusammenhang...

Ob er das nun sehr stark vermutet oder überzeugt ist, ist doch völlig belanglos. AMD ist in keinem Fall "fein raus".

Mal völlig davon ab, dass im angelsächsischen Sprachgebrauch strongly suspects durchaus überzeugt bedeuten kann. "Ich gehe stark davon aus" kann durchaus die gleiche Notation haben wir "ich bin davon überzeugt"...

Unicous

2018-11-04, 23:18:33

Nein, "strongly suspect" kann man hier schon mit überzeugt übersetzen. Denn was er essentiell sagt, ist dass SMT im Allgemeinen nicht sicher ist und da AMD auch SMT nutzt, ist er sich ziemlich sicher, dass auch AMD betroffen ist, er kann es nur noch nicht beweisen, da sie Ryzen Chips noch nicht untersucht haben.

Es ist natürlich etwas unseriös, AMD zu nennen und andere CPU-Hersteller wie z.B. IBM, die auch SMT nutzen, außen vor zu lassen, aber es sind nun mal die bekanntesten Hersteller.

gravitationsfeld

2018-11-04, 23:40:45

AMD ist definitiv auch betroffen. Da wird sich bei SMT mit grosser Wahrscheinlichkeit auch nie was daran aendern.

Ich wuerde da jetzt aber auch nicht so Panik machen. Um den Bug auszunutzen musst du Zugriff auf die selbe Maschine haben - kann auch eine andere VM sein - und dein Prozess muss auf dem gleichen Core laufen wie der Crypto-Code den du abhoeren willst.

Da sind ganz schoen viele Bedingungen. Fuer Cloud-Anbieter heisst das aber wohl, dass sie keine verschiedenen Kunden mehr auf den gleichen Core legen koennen.

Pirx

2018-11-05, 07:15:04

Screemer

2018-11-05, 07:19:56

Doch, wenn seine ultrastarke Vermutung doch nicht zutreffen sollte.Wie schon mehrfach angemerkt ist das wohl eher ein generelles smt als ein implementierungs Problem. Das er da falsch vermutet ist ziemlich unwahrscheinlich. Aber lasse mich da auch gerne überraschen. Ändert ja auch nix dran, dass es für die Übersetzung irrelevant ist.

Armaq

2018-11-05, 11:28:00

Complicated

2018-11-05, 12:55:17

Bisher war AMDs SMT allerdings nicht betroffen im Gegensatz zu Intels. Daher würde ich doch gerne mal einen PoC sehen bevor jemand davon überzeugt ist.
SMT ist nicht gleich SMT, vor allem nicht da Intels Schwachstelle bei den Sidechannel Attacken oft bei AMD nicht vorhanden ist. Siehe Meltdown und andere veröffentlichte Lücken.

Th3o

2018-11-05, 13:41:44

Anscheinend geht es hier im besonderen um OpenSSL siehe https://www.golem.de/news/portsmash-exploit-fuer-13-jahre-alte-hyperthreading-luecke-1811-137511.html

bun

2018-11-06, 07:09:15

Nein, "strongly suspect" kann man hier schon mit überzeugt übersetzen.

Nein.

Ganon

2018-11-12, 09:25:28

Dürfte zwar die Wenigsten wirklich interessieren, aber der POWER9 Prozessor von IBM wird wohl von Spectre mitigations ziemlich hart in der Performance getroffen. Teils nur ~50% Performance.

https://www.phoronix.com/scan.php?page=article&item=power9-spectre-benchmarks&num=2

An sich kann ein 2x22 Kern Setup aber ziemlich gut mit Intel und AMD mithalten, trotz des Einbruchs. Ist aber natürlich in Sachen Preis (>7000€) und Stromverbrauch (~160W im Idle) jenseits von gut und böse.

https://www.phoronix.com/scan.php?page=article&item=power9-threadripper-core9&num=3

Setsul

2018-11-12, 13:09:10

Man sollte vielleicht anmerken, dass PyBench und PHPBench, wo die -50% auftreten, auch ohne mitigations sehr schlecht laufen.
https://www.phoronix.com/scan.php?page=article&item=power9-threadripper-core9&num=6

Anscheinend hat sich niemand die Mühe gemacht die zu optimieren, das liegt jetzt nicht direkt an Spectre.
Bei Software die vorher gut lief, wo POWER9 mit Intel und AMD mithalten kann, bewegen sich die mitigations auch im gleichem Rahmen wie bei Intel und AMD.

Eldoran

2018-11-15, 02:15:02

Es sind ein paar neue Varianten zu meltdown und spectre aufgetaucht:
https://arstechnica.com/gadgets/2018/11/spectre-meltdown-researchers-unveil-7-more-speculative-execution-attacks/

Benutzername

2018-11-15, 17:37:49

Es sind ein paar neue Varianten zu meltdown und spectre aufgetaucht:
https://arstechnica.com/gadgets/2018/11/spectre-meltdown-researchers-unveil-7-more-speculative-execution-attacks/

Erinnert langsam an einen gewissen Dieselskandal...

https://www.theregister.co.uk/2018/11/14/spectre_meltdown_variants/

Ganon

2018-11-16, 09:26:23

][immy

2018-11-16, 10:50:00

Side-Channel Angriffe auf GPUs ist jetzt wohl auch ein Ding? edit: Hab das Paper jetzt nicht gelesen. GPU Treiber an sich sind ja immer gerne ein nettes Einfalls-Tor. Hier ist es wohl der Performance-Counter.

https://www.phoronix.com/scan.php?page=news_item&px=Uni-GPU-Side-Channel-Flaw

http://www.cs.ucr.edu/~zhiyunq/pub/ccs18_gpu_side_channel.pdf
einer der Gründe warum MS kein OpenGL für Javascript im Browser unterstützen wollte war immer die Sicherheit.

Was können Browser die GPU-Schnittstellen für Javascript eigentlich machen um Angriffe über die GPU zu verhindern? Bisher sind Grafiktreiber ja immer ziemlich löchrig gewesen und enthalten Bugs ohne Ende (abstürze in spielen etc). Kann mir gut vorstellen das sich da einiges Ausnutzen lässt.

Ganon

2018-11-16, 11:08:44

Wenn ich das richtig verstehe ist WebGL hier gar nicht direkt das Einfallstor.

WebGL does not appear to offer extensions to measure
any of the three channels and therefore
cannot be used to implement a spy for our attacks. Although web
browsers and websites which use WebGL (as a JavaScript API to
use GPU for rendering) can be targeted as victims in our attacks
from an OpenGL spy

Also weniger "ich liefere Schadcode per WebGL aus", sondern "ich lausche was der Browser über WebGL macht". Die anderen Szenarien brauchen OpenCL/CUDA.

Achill

2018-11-16, 22:33:26

Cepheus72

2018-11-17, 08:25:12

Hallo!

Habe soeben auf dem
Intel i7-6700K (Win 10 Prof / 64 / Windows Defender) Rechner, als auch auf dem
AMD A12-9720P (Win 10 Home / 64 / Windows Defender) Laptop

Achill

2018-11-18, 10:40:36

Auf phoronix.com gibt es ein neuen Artikel zu Cross-Hyperthread Spectre V2 Mitigation und den Performance-Auswirkungen (https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1) mit den neuen Kernel v4.20

Es gibt jetzt noch ein größeres RoundUp zum Thema STIBP und Performance-Auswirkungen: https://www.phoronix.com/scan.php?page=article&item=linux-420-stibp&num=1

Ganon

2018-11-19, 14:58:32

Und da wird der Kram auch schon wieder im Standard deaktiviert oder vielleicht sogar ganz entfernt:

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Torvalds-STIBP-Comment

Skysnake

2018-11-19, 23:06:43

LOL

Also jetzt mit dem Performancehit zu kommen ist schon irgendwie seltsam. Entweder es ist ein Problem, dann ist es scheis egal wie hoch der Hit ist, oder es ist kein Problem....

Wenn ich das jetzt aber richtig verstehe, dann reduziert STIBP die Leistung auch, wenn SMT disabled ist, und es somit eigentlich gar nicht mehr benötigt würde. Richtig?

Wenn ja, sollte man eine SMT detection einbauen für die Migitation.

Ich hatte heute auch ne Diskussion mit nem Kollegen, was man eigentlich auf großen Clustern jetzt macht. Macht man die ganzen Sachen an, oder lässt man Sie aus, oder macht man einen Teil an und SMT aus?

An sich hat man ja meist nur genau einen Nutzer auf den Nodes, aber der könnte sich ja auch Rootrechte beschaffen....

Das ganze Thema ist echt die absolute Seuche aus der Hölle....

Was habt ihr eigentlich für Erfahrungen aus dem Cluster/Enterprise Segment mit den Betreibern/Nutzern? Ist das ein Thema für euch oder nicht?

Ganon

2018-11-20, 00:12:00

Na wie gesagt wurde: Wer sicher sein will, der macht SMT einfach aus und braucht somit diesen "Fix" nicht und einfach allen Nutzern diesen Performance-Hit aufdrücken, egal ob die Lücke für sie relevant ist oder nicht, ist halt auch nicht sinnvoll. Darum eher im Standard abschalten und ggf. nur für Prozesse aktivieren, die es für sich anfordern.

Das Problem ist aktuell eher, dass der Fix/Workaround nicht viel sinnvoller (sprich: performanter) ist als einfach SMT zu deaktivieren. Dass es auch Non-SMT CPUs ausbremst wäre mir jetzt neu, da es eine reine Hyper-Threading Sache ist. Auch Intel/AMD raten von der Nutzung von STIBP ab.

aufkrawall

2018-11-20, 00:23:39

Ganz schön hässlich, dass das einfach ohne weitere Beanstandung in den Stable-Kernel zurückportiert wurde. :freak:

registrierter Gast

2018-11-20, 00:44:04

Macht man normalerweise Performancetests bevor etwas in den Master Branch gemerged wird?

Ganon

2018-11-20, 00:59:32

Na diese Patchsets waren nun seit August in der Review-Phase und offensichtlich ist der Performance-Hit dort einfach unter all den anderen Spectre-Sachen untergegangen. Ist ja nicht so als wenn das jetzt seit nem Jahr mal wieder ein Spectre-Patch war. Das waren schon ein paar mehr zwischen all den Optimierungen und Änderungen. STIBP ist jetzt auch nichts neues und kam im Zusammenhang mit IBRS Anfang des Jahres in die "Feature-Liste" der CPUs. Was neu ist, dass der Kernel den Kram auch unterstützt.

Ich vermute das "im Standard eingeschaltet" hat man einfach übersehen. Intensive Performance-Tests macht man vor einem Merge natürlich nicht. Für sowas ist die Review-Phase da. Wird auch schwierig etwas auf allen möglichen Konstellationen zu testen. Ist ja nun auch nicht der erste Bug im Kernel der einigen Leuten mal für einen Release mal etwas Performance kostet.

Den neusten Vanilla Upstream Kernel nutzen eh die wenigsten Linux-Nutzer.

Setsul

2018-11-20, 10:56:56

Es wurde nicht übersehen, dass das angeschaltet war, es hat sich einfach keiner Gedanken gemacht, dass das nur was bringt wenn es weniger kostet als SMT auszuschalten.
Alle anderen Mitigations sind standardmäßig an und das ist auch sinnvoll, egal wie viel es kostet. Wenn es mehrere Varianten gibt, wird natürlich die schnellste implementiert, aber darüber hinaus gibt es keine Auswahlmöglichkeit. Das hier ist die Ausnahme.

Die Frage ist was STIBP macht. Er vermute hier stark eine Marketing-Bezeichnung. Der Branch Predictor hat keine Möglichkeit die Vorhersagen nach Threads zu unterscheiden, sonst hätte man das Problem nicht, also nehme ich an dass das einfach die indirekte Sprungvorhersage abschaltet.
Es kann sein, dass der Kernel STIBP nicht aktiviert auf CPUs die kein SMT haben, aber ob das auch funktioniert wenn SMT vorhanden, aber abgeschaltet ist, ist fraglich. Dann würde das tatsächlich Performance kosten, selbst wenn es unnötig ist.

Ganon

2018-11-20, 11:10:13

Alle anderen Mitigations sind standardmäßig an und das ist auch sinnvoll, egal wie viel es kostet.

Das stimmt nicht. Für L1TF/Foreshadow sind diese nicht aktiv bzw. nicht im vollen Umfang. Es wird nur gewarnt, dass man es ggf. aktivieren möchte. Das steht auch im verlinkten Beitrag.

Das sieht dann so aus:
$ dmesg | grep -i l1tf

[ 106.233652] L1TF CPU bug present and SMT on, data leak possible.
See CVE-2018-3646 and https://www.kernel.org/doc/html/latest/admin-guide/l1tf.html for details.

$ cat /proc/cpuinfo | grep -i bugs

bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf

edit:
Und zu dem was STIBP macht:

Single Thread Indirect Branch Predictor (STIBP) exists at MSR 0x48 (SPEC_CTRL) bit 1. When this bit is set in processors that
share branch prediction information, indirect branch predictions from sibling threads cannot influence the predictions of
other sibling threads. Return instructions are always immune to influence by the other thread and do not require this bit to
be set for protection.
AMD is not recommending STIBP currently as a performant mitigation in Windows and Linux for Google Project Zero
Variant 2 (Spectre).

vanquish

2018-11-20, 13:04:21

https://www.phoronix.com/scan.php?page=article&item=linux-420-stibp&num=5

Gerade für Webserver mit PHP, Python & Co. wohl der "ideale" Patch. :D

Ich bin gespannt ob Spectre SMT am Ende den Todesstoß versetzt und man gezwungen sein wird SMT zu deaktivieren.
Mich würde interessieren ob es bereits Ansätze gibt wie dem ganzen in zukünftigen Prozessoren begegnet wird oder ob eine Korrektur so viel Leistung kostet, dass sich SMT möglicherweie kaum mehr lohnt ...

Setsul

2018-11-20, 20:22:12

@Ganon:
Meine Güte, es sollte doch klar sein welche ich gemeint habe, oder?
Meltdown Mitigations sind bei AMD auch nicht standardmäßig aktiv.

Zu STIBP: Nochmal mitdenken bitte.
Ich vermute Marketing-Aussagen. Wenn es keine Predictions gibt, können sich die Threads auch nicht gegenseitig beeinflussen.

Jetzt nochmal andersrum denken: Wenn STIBP tatsächlich nur die Threads voneinander isoliert (und das ohne dass Hardware existiert die die Herkunft der Einträge aufzeichnet, der BP ist z.B. bei Zen explizit nicht bei den Strukturen dabei die tagged sind) und die Predictions weiterlaufen, wo kommen dann die -20% oder sogar -50% bei beiden Threads her?

Lord Wotan

2018-11-20, 21:27:19

Verstehe etwas nicht, habe ein AMD PC da habe ich in der Regedit diese Werte geschrieben:

Enable user-to-kernel protection on AMD and ARM processors together with other protections for CVE 2017-5715:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 64 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
Restart the computer for the changes to take effect.

Enable user-to-kernel protection on AMD processors together with other protections for CVE 2017-5715 and protections for CVE-2018-3639 (Speculative Store Bypass):

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 72 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Restart the computer for the changes to take effect.

Trotzdem zeigt mit das Tool In Spectre System das:
Metdown protected yes
is Spectre protected no
Microcode Update no.
Trotz Windows 10 Fix und Regedit Eintrag.

Ganon

2018-11-21, 01:20:07

@Ganon:
Meine Güte, es sollte doch klar sein welche ich gemeint habe, oder?
Meltdown Mitigations sind bei AMD auch nicht standardmäßig aktiv.

Ja, "alle" war relativ eindeutig und somit falsch... sehe gerade das Problem nicht. Und was das jetzt mit (dem nicht existierenden) Meltdown bei AMD zu tun hat, weiß ich nicht.

Und ja, der Patch selbst hat natürlich vorgesehen, dass STIBP immer aktiv ist. Das steht ja auch im Patch. Aber der grundlegende Patch dazu ist von August, wurde im Oktober noch mal aufgegriffen und dann letztendlich vor kurzem zusammen mit einigen anderen üblichen Meltdown/Spectre-Änderungen mit reingeschoben, sodass der Patch, der STIBP aktiviert, eher eine Randnotiz war.

Deswegen vermute ich hier, dass die Auswirkungen in all dem anderen Rauschen einfach untergegangen ist, weil im Patch selbst steht auch nichts von irgendwelchen größeren Performance-Auswirkungen. Und das ist ja nun nach der Aussage von Linus jetzt auch nicht so weit hergeholt. Ist letztendlich auch egal. STIBP wird vermutlich in der nächsten Version deaktiviert oder entfernt und dann ist die Sache an sich erledigt. Der Rest muss SMT deaktivieren.

Zu STIBP: Nochmal mitdenken bitte.

Ich weiß jetzt ehrlich gesagt nicht, was du in dem Kontext mit "Marketing" meinst.

Was der Flag im Prozessor anrichtet, kann man jetzt lange vermuten, die Hersteller werden es dir vermutlich nicht sagen. Siehe die Aussage vom Intel Mitarbeiter, dass der Flag eher eine Quick&Dirty Holzhammer-Methode war, die man Anfang des Jahres schnell zusammengeschustert hat, soweit es mit Microcode Updates überhaupt möglich war. Von daher irritiert es mich nicht sonderlich, dass der Flag, der vermutlich zum ersten Mal auch wirklich intensiv benutzt wird, doch eher einen ziemlichen Clusterfuck innerhalb der CPU anrichtet, als irgendwie fein granular "perfekt" zu arbeiten.

Es ist ja nicht gerade so, dass Intel (und AMD) STIBP als wunderschöne Lösung für das Problem "verkaufen". Sie raten beide von der Nutzung ab.

Und ja, wenn man sich die Patches anschaut: Wenn die CPU kein SMT meldet, dann ist auch der Flag nicht aktiv. Also egal ob SMT deaktiviert wurde, oder die CPU kein SMT hat.

Setsul

2018-11-21, 11:15:49

Ja, "alle" war relativ eindeutig und somit falsch... sehe gerade das Problem nicht. Und was das jetzt mit (dem nicht existierenden) Meltdown bei AMD zu tun hat, weiß ich nicht.

Stimmt, mit "alle" meine ich offensichtlich auch SGXPectre und Meltdown.
Für Meltdown existieren offensichtlich auch Mitigations und die sind offensichtlich nicht standardmäßig auf allen CPUs aktiv.
Es geht um Mitigations für Spectre 1 und 2 und ret2spec/SpectreRSB.

Und ja, der Patch selbst hat natürlich vorgesehen, dass STIBP immer aktiv ist.
Ich weiß nicht ob du das jetzt absichtlich missverstehst oder einfach nicht liest.

Retpoline und ähnliche sind immer aktiv weil man keine Wahl hat. STIBP ist in der gleichen Kategorie weil es auf die gleiche Schwachstelle abzielt. Es hat sich nur keiner Gedanken gemacht, dass das so viel mehr Leistung kostet (vielleicht wegen des schönen Namens, wenn das flag "indirect BP off" hieße wäre es wohl aufgefallen) und es sich nicht lohnt wenn SMT off schneller ist.

STIBP wird vermutlich in der nächsten Version deaktiviert oder entfernt und dann ist die Sache an sich erledigt. Der Rest muss SMT deaktivieren.

STIBP wird sicher nicht entfernt.
Man kann es immernoch aktivieren, also muss der Rest nicht SMT deaktivieren.
Die Diskussion ist doch momentan dabei es sogar für non-dumpable taks aktiv zu lassen, wie soll das gehen wenn es entfernt wird?
https://lkml.org/lkml/2018/11/21/367

Was der Flag im Prozessor anrichtet, kann man jetzt lange vermuten, die Hersteller werden es dir vermutlich nicht sagen.
Was du nicht sagst.
Aber erst das posten

Und zu dem was STIBP macht:
https://developer.amd.com/wp-content/resources/Architecture_Guidelines_Update_Indirect_Branch_Control.pdf
Single Thread Indirect Branch Predictor (STIBP) exists at MSR 0x48 (SPEC_CTRL) bit 1. When this bit is set in processors that
share branch prediction information, indirect branch predictions from sibling threads cannot influence the predictions of
other sibling threads. Return instructions are always immune to influence by the other thread and do not require this bit to
be set for protection.
AMD is not recommending STIBP currently as a performant mitigation in Windows and Linux for Google Project Zero
Variant 2 (Spectre).
und vorgeben dass du meine Frage nicht verstehst.

Ich weiß jetzt ehrlich gesagt nicht, was du in dem Kontext mit "Marketing" meinst.
Man nennt das Ding "Single Thread Indirect Branch Predictor (STIBP)" und behauptet es macht Threads gegen Beeinflussung durch SMT Threads immun.
Das hört sich einfach viel besser an als "Disable Indirect Branch Predictor for this sibling Thread", was es wohl macht.

Das ist genauso wie "Indirect Branch Restricted Speculation (IBRS)". Intel bastelt schonmal an Patches für zukünftige CPUs, bei denen das tatsächlich nur "restricted", aber was es momentan wirklich macht ist, dass es Indirect Branch Prediction komplett abschaltet.

Natürlich ist das die Holzhammer-Methode, aber etwas anderes kann man ohne entsprechende Tags in Hardware nicht implementieren. Die Mitarbeiter müssen das schönreden, "alles nur Quick&Dirty", wissen aber genau dass das nie besser werden wird und raten natürlich von der Nutzung ab wenn es nicht unumgänglich ist.

Wenn man einen Ingenieur gefragt hätte, dann hätte er das Kind beim Namen genannt und gesagt "das schaltet Indirect Branch Prediction ab". Hört sich aber schlecht an, das kann man nicht als "Fix" verkaufen. Als wirft Marketing diese Methode und künftige, elegantere, in einen Topf und benennt den Topf nach dem zukünftigen Verhalten also "single thread IBP" und "restricted IBP" anstatt "turn off IBP for one thread" und "turn off IBP for all threads".

Und ja, wenn man sich die Patches anschaut: Wenn die CPU kein SMT meldet, dann ist auch der Flag nicht aktiv. Also egal ob SMT deaktiviert wurde, oder die CPU kein SMT hat.
Es wäre nett wenn du mir die Stelle zeigen könntest, dann muss ich nicht auch noch suchen.

Ganon

2018-11-21, 11:42:35

STIBP wird sicher nicht entfernt.
Man kann es immernoch aktivieren, also muss der Rest nicht SMT deaktivieren.
Die Diskussion ist doch momentan dabei es sogar für non-dumpable taks aktiv zu lassen, wie soll das gehen wenn es entfernt wird?
https://lkml.org/lkml/2018/11/21/367

Ja... darum hab ich "oder" geschrieben. Ich hab auch in einem Beitrag hier erwähnt, dass man es für spezielle Prozesse vielleicht aktiviert lässt. Es ist müßig über eine Blackbox zu diskutieren bei Messwerten von einer einzigen CPU, wo ein Flag gesetzt wird, der >irgendwas< innerhalb einer CPU macht.

Was du nicht sagst.
Aber erst das posten

Ja was soll ich sonst posten? Du hast gefragt, ich hab dir den Link gegeben. Wenn du jetzt auf dem Namen so rumreiten willst, oder meinst er tut nicht das was er soll, dann ist das jetzt kein großes Geheimnis was gelüftet werden müsste.

Es wäre nett wenn du mir die Stelle zeigen könntest, dann muss ich nicht auch noch suchen.

Aber auch nur, weil du so ein angenehmer Diskussionspartner bist...

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86-pti-for-linus&id=53c613fe6349994f023245519265999eed75957f

Wenn die CPU STIBP Support hat und als für Spectre V2 anfällig gilt, dann wird STIBP aktiviert, außer SMT ist deaktiviert. Das wird dir auch im Kernel-Log gesagt:

pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
cpu_smt_control == CPU_SMT_ENABLED ?
"Enabling" : "Disabling");

Setsul

2018-11-21, 15:35:33

Ja... darum hab ich "oder" geschrieben.
Ja und ich habe geschrieben, dass eine der Möglichkeiten nach dem jetzigen Stand der Dinge nicht eintreten kann. Mit der anderen habe ich kein Problem.

Ich hab auch in einem Beitrag hier erwähnt, dass man es für spezielle Prozesse vielleicht aktiviert lässt.
Finde ich gerade nicht, anderer Thread oder lange her?
Es ist müßig über eine Blackbox zu diskutieren bei Messwerten von einer einzigen CPU, wo ein Flag gesetzt wird, der >irgendwas< innerhalb einer CPU macht.

Woher kommt das jetzt? Der Linux Kernel ist keine Blackbox, also ob das deaktiviert oder komplett entfernt wird ist relativ klar.

Und es lässt sich auch ziemlich klar eingrenzen was STIBP innerhalb der CPU macht, das ist sicher nicht völlig willkürlich. Was genau war eben meine Frage vorhin.

Ja was soll ich sonst posten? Du hast gefragt, ich hab dir den Link gegeben.

Du musst eine Frage nicht beantworten, wenn du die Antwort nicht kennst.
War es wirklich nicht zu erkennen, dass ich über das interne Verhalten geschrieben habe, oder gehst du einfach pauschal davon aus, dass ich keine Ahnung habe was STIBP überhaupt macht und postest deshalb die offizielle Definition?

Wenn du jetzt auf dem Namen so rumreiten willst, oder meinst er tut nicht das was er soll, dann ist das jetzt kein großes Geheimnis was gelüftet werden müsste.

Natürlich tut es das was es soll, aber es ist ein Holzhammer, nicht das was der "elegante" Name vielleicht vermuten lässt und was dann auch in zukünftigen CPUs gemacht wird.

Was ich meine ist, dass noch irgendein Kürzel keinem auffällt, weil es sich nicht schlimm anhört. "We'll enable IBRS, IBPB and STIBP as Spectre v2 mitigations by default" winkt man durch. "We'll flush the branch predictor on context switch" bringt man wahrscheinlich durch weils notwendig ist aber wenn jemand versucht "disable indirect branch prediction when SMT is enabled" zu mergen wäre das wohl kaum problemlos durchgegangen. Da ist vielen sofort klar, dass das massiv Performance kostet.

Aber auch nur, weil du so ein angenehmer Diskussionspartner bist...

https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git/commit/?h=x86-pti-for-linus&id=53c613fe6349994f023245519265999eed75957f

Wenn die CPU STIBP Support hat und als für Spectre V2 anfällig gilt, dann wird STIBP aktiviert, außer SMT ist deaktiviert. Das wird dir auch im Kernel-Log gesagt:

pr_info("Spectre v2 cross-process SMT mitigation: %s STIBP\n",
cpu_smt_control == CPU_SMT_ENABLED ?
"Enabling" : "Disabling");

Danke, da sieht man auch gleich das Problem.
STIBP gehört zu Spectre v2 Mitigations (richtig), Spectre v2 Mitigations sind standardmäßig an (sinnvoll) also ist auch STIBP standardmäßig an (nicht völlig abwegig).

STIBP ist zwar ein Holzhammer, aber SMT off ist ein noch größerer Holzhammer.
Ich nehme an, dass in den nächsten Patches da noch viel rumgebastelt wird um STIBP nur dann anzuschalten, wenn es wirklich gebraucht wird und sobald das dann deutlich schneller ist als SMT off wird das wieder default.
Bis dahin warnt man die, die Performance wollen, dass es nicht sicher ist, und die die Sicherheit wollen sind sowieso schon mit SMT off unterwegs gewesen und wenn nicht dann ab jetzt.

aufkrawall

2018-11-21, 15:37:17

Kann man sich jetzt ohne Patches irgendwie STIBP entledigen?

Ganon

2018-11-21, 18:54:14

Finde ich gerade nicht, anderer Thread oder lange her?

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11857057&postcount=2348

Woher kommt das jetzt? Der Linux Kernel ist keine Blackbox, also ob das deaktiviert oder komplett entfernt wird ist relativ klar.

Der Linux Kernel setzt einfach beim Boot ein Flag im Prozessor, mehr nicht. Das war's. Da gibt's nicht viel zu analysieren. Der Rest ist CPU-Intern und somit eine Blackbox. Davon rede ich. Ich bin jetzt nun davon ausgegangen, dass du bereits weißt, was der Kernel da gemacht hat... ich mein, ist ja Open Source.

Und es lässt sich auch ziemlich klar eingrenzen was STIBP innerhalb der CPU macht, das ist sicher nicht völlig willkürlich. Was genau war eben meine Frage vorhin.

Wie die CPU es intern macht kann sich auch von CPU zu CPU und Hersteller zu Hersteller unterscheiden. AMD wird den Flag sicherlich anders implementiert haben als Intel.

War es wirklich nicht zu erkennen, dass ich über das interne Verhalten geschrieben habe, oder gehst du einfach pauschal davon aus, dass ich keine Ahnung habe was STIBP überhaupt macht und postest deshalb die offizielle Definition?

Es tut mir leid, dass ich offizielle Dokumentationen verlinkt habe? :ugly: Woher soll ich wissen, dass du weißt was STIBP ist, aber dann wiederum nicht weißt in welche Kategorie es eigentlich fällt und wie der Patch ausgesehen hat...

Anyways, wir reden hier die ganze Zeit aneinander vorbei. Der Patch kam übrigens auch nicht von Intel, sondern von SUSE, die es einfach aktivieren wollten, weil es da ist. Von daher wollte hier auch keiner irgendwas verheimlichen. Die ganze Geschichte ist einfach nur unglücklich abgelaufen. Lies einfach die Kernel-Mailing-Liste dazu.

Kann man sich jetzt ohne Patches irgendwie STIBP entledigen?

Nein, es wird nur abgeschaltet, wenn du _alle_ Spectre V2 Mitigations abschaltest. An einer separaten Abschaltung (bzw. eher Aktivierung) wird gerade gearbeitet.

Setsul

2018-11-21, 20:06:53

https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11857057&postcount=2348

Der Linux Kernel setzt einfach beim Boot ein Flag im Prozessor, mehr nicht. Das war's. Da gibt's nicht viel zu analysieren. Der Rest ist CPU-Intern und somit eine Blackbox. Davon rede ich. Ich bin jetzt nun davon ausgegangen, dass du bereits weißt, was der Kernel da gemacht hat... ich mein, ist ja Open Source.

Ja aber wie zum Teufel kommst du von der Diskussion ob STIBP aus den Kernel Patches entfernt wird zu "das ist eine Blackbox, darüber kann man nicht diskutieren"?

Nochmal den Kontext:

STIBP wird vermutlich in der nächsten Version deaktiviert oder entfernt und dann ist die Sache an sich erledigt. Der Rest muss SMT deaktivieren.

STIBP wird sicher nicht entfernt.
Man kann es immernoch aktivieren, also muss der Rest nicht SMT deaktivieren.
Die Diskussion ist doch momentan dabei es sogar für non-dumpable taks aktiv zu lassen, wie soll das gehen wenn es entfernt wird?
https://lkml.org/lkml/2018/11/21/367

Ja... darum hab ich "oder" geschrieben. Ich hab auch in einem Beitrag hier erwähnt, dass man es für spezielle Prozesse vielleicht aktiviert lässt. Es ist müßig über eine Blackbox zu diskutieren bei Messwerten von einer einzigen CPU, wo ein Flag gesetzt wird, der >irgendwas< innerhalb einer CPU macht.

Auf einmal springst du zu "Blackbox, Ende der Diskussion". Ob STIBP eine Blackbox ist oder nicht hat rein gar nichts damit zu tun ob es im Kernel verwendet wird oder sämtlicher Code der damit zu tun hat wieder entfernt wird.

Wie die CPU es intern macht kann sich auch von CPU zu CPU und Hersteller zu Hersteller unterscheiden. AMD wird den Flag sicherlich anders implementiert haben als Intel.

AMD kann auch keine magischen Tags aus dem Nichts herzaubern.
Das Problem ist ja das nichts dafür implementiert ist. Die einzige Möglichkeit ist abschalten. Aus ist aus, ich sehe da wenig Variationen.

Tatsächliche Fixes in neuen CPUs werden sich unterscheiden.

Es tut mir leid, dass ich offizielle Dokumentationen verlinkt habe? :ugly: Woher soll ich wissen, dass du weißt was STIBP ist, aber dann wiederum nicht weißt in welche Kategorie es eigentlich fällt und wie der Patch ausgesehen hat...

Auch hier ein bisschen Kontext.

Die Frage ist was STIBP macht. Er vermute hier stark eine Marketing-Bezeichnung. Der Branch Predictor hat keine Möglichkeit die Vorhersagen nach Threads zu unterscheiden, sonst hätte man das Problem nicht, also nehme ich an dass das einfach die indirekte Sprungvorhersage abschaltet.

Ja was soll ich sonst posten? Du hast gefragt, ich hab dir den Link gegeben.

Du musst eine Frage nicht beantworten, wenn du die Antwort nicht kennst.
War es wirklich nicht zu erkennen, dass ich über das interne Verhalten geschrieben habe, oder gehst du einfach pauschal davon aus, dass ich keine Ahnung habe was STIBP überhaupt macht und postest deshalb die offizielle Definition?

Sind meine Fragen wirklich so unverständlich?

Anyways, wir reden hier die ganze Zeit aneinander vorbei. Der Patch kam übrigens auch nicht von Intel, sondern von SUSE, die es einfach aktivieren wollten, weil es da ist. Von daher wollte hier auch keiner irgendwas verheimlichen. Die ganze Geschichte ist einfach nur unglücklich abgelaufen.

Woher kommt das jetzt wieder?
Was habe ich denn anderes gesagt?
STIBP ist bei den Spectre v2 Patches die standardmäßig an sind.
Klingt genauso "harmlos" wie die anderen, ist es aber nicht.

Aber ja, wir reden aneinander vorbei. Du gehst anscheinend jedesmal wieder davon aus, dass ich der DAU bin, und ich bin immer wieder davon ausgegangen, dass du zumindest versuchst hast zu verstehen was ich meine. Anscheinend liegen wir beide falsch.

Ganon

2018-11-21, 20:41:42

[...]
Aber ja, wir reden aneinander vorbei. Du gehst anscheinend jedesmal wieder davon aus, dass ich der DAU bin, und ich bin immer wieder davon ausgegangen, dass du zumindest versuchst hast zu verstehen was ich meine. Anscheinend liegen wir beide falsch.

Wenn du noch mal genau liest, bin ich auf deine "STIBP ist Marketing" eigentlich nie eingegangen, sondern nur auf deine Aussage, dass "alle Mitigations sind an, egal was es kostet" und hab auf deine Frage hin verlinkt was STIBP eigentlich ist bzw. sein soll. Und dass du darauf hin immer wieder diese "STIBP ist Marketing" Argumentation mit mir anfängst, hab ich gesagt, dass ich diese Diskussion müßig finde, weil man hier über irgendwelchen Blackbox Kram redet. Darum verstehe ich weiterhin nicht warum du diesen Kram unbedingt mit mir besprechen willst. Darum bin ich der, der hier das Gefühl hat, dass du mich unbedingt falsch verstehen willst. Etwaige Verschwurbelungen um das Thema "STIBP ist Marketing", so wie du es mir dann auf Nachfrage erklärt hast, sind für mich nicht sonderlich interessant, weil es dazu eben keine Fakten gibt, sondern nur irgendwelche Spekulationen die man sich selbst zusammenreimen muss.

Ich hab dir nur erklärt was der Kernel Patch macht, was er nicht macht und wie die Zukunft von STIBP im Linux-Kernel aussieht und du erzählst mir halt dauernd was mit irgendwelchen Begrifflichkeiten, weil du scheinbar nicht von einem Versehen in der ganzen Kette der ganzen Patches ausgehen willst!? Keine Ahnung... Und nur weil ich dir irgend einen Link schicke, dann heißt das nicht, dass ich dich für dumm halte, sondern dient das einfach dazu, der Diskussion auch ein paar Fakten zu liefern. Woher soll ich denn wissen was du weißt und was du nicht weißt. Ich bin auch davon ausgegeangen, dass du dir die Patches bereits angesehen hattest... siehst... war also ein Link im Vorfeld zu wenig.

Der Patch, so wie er war, war ein Fehler, der leider nicht rechtzeitig erkannt wurde. Er hat selbst auch "Fehler", weil er z.B. STIBP aktiviert, auch wenn IBRS aktiv ist, obwohl diese beiden Flags zusammen unnötig sind. Die neuen Patches sind bereits in der Review-Phase und auch wesentlich komplexer als "if spectre_v2 && smt then stibp = on".

Setsul

2018-11-21, 20:52:43

Jep, Diskussion beendet, über Blackboxen kann man nicht reden.

Ganon

2018-11-21, 21:15:23

Jep, Diskussion beendet, über Blackboxen kann man nicht reden.

Aber nur, damit wieder nicht noch mehr Missverständnisse auftreten: _Ich_ will darüber nicht diskutieren. Wenn du jemand anderen dazu findest, nur zu ;)

---

Ansonsten steht nur für mich die Frage im Raum was das im Zusammenhang mit AMD ist. Spectre V2 ist ja bei AMD mehr so eine theoretische Sache, jedoch hat der Patch auch STIBP bei AMD CPUs aktiviert, denn die haben auch SMT und "wegen der eher theoretischen Sache" ist der Spectre V2 Flag im Kernel afaik auch gesetzt (man siehe unter "bugs" bei /proc/cpuinfo), auch wenn er intern anders handelt als bei Intel CPUs.

Ist AMD über SMT bei Spectre V2 auch tatsächlich "im gleichen Maße" anfällig oder ist hier STIBP auch so ziemlich komplett unnötig und einfach nur eine Handbremse für theoretische Konstrukte?

Achill

2018-11-21, 23:26:10

[..]

Ansonsten steht nur für mich die Frage im Raum was das im Zusammenhang mit AMD ist. Spectre V2 ist ja bei AMD mehr so eine theoretische Sache, jedoch hat der Patch auch STIBP bei AMD CPUs aktiviert, denn die haben auch SMT und "wegen der eher theoretischen Sache" ist der Spectre V2 Flag im Kernel afaik auch gesetzt (man siehe unter "bugs" bei /proc/cpuinfo), auch wenn er intern anders handelt als bei Intel CPUs.

Ist AMD über SMT bei Spectre V2 auch tatsächlich "im gleichen Maße" anfällig oder ist hier STIBP auch so ziemlich komplett unnötig und einfach nur eine Handbremse für theoretische Konstrukte?

Sry Ganon, aber ich hoffe du meinst mit "Ist AMD über SMT bei Spectre V2 auch tatsächlich "im gleichen Maße" anfällig?" die Anfälligkeit gegenüber STIBP und machst nicht den ganzen Spectre V2 Sack auf, weil dann die Annahme/Argument fehlt, warum das so sein sollte.

Und "Ist hier STIBP auch so ziemlich komplett unnötig und einfach nur eine Handbremse für theoretische Konstrukte?" ist dann eine allgemeine Frage im Context von ARM, AMD, Intel, ...? Weil es gibt keine genannte Annahme / Argument zwischen den zwei Teilen und warum dies jetzt sein sollte.

--

Zum ersten Teil: Ich weiß es nicht und bisher habe ich nur von Angriffen auf SMT bei Intel gelesen. Es könnte sein, dass:
- AMD dies vorsorglich einbaut? Wenn es so wäre, dann wäre dies ein vorbildliche Maßnahme um später erfolgreich eintretende Angriffe sehr kurzfristig abwähren zu können (als reine Möglichkeit ohne Garantie). Eine Möglichkeit wäre dies zumindest.
- SMT bei AMD auch betroffen ist - ich habe dazu aber noch nichts gelesen

Zum Zusatz vom ersten Teil: Ob AMD "im gleichen Maßen" betroffen sein kann, dass wird die Zeit zeigen, es kann auch viel schwächer oder stärker sein.

Wir sollten jedoch nochmal festhalten:
- Die Performance bei AMD und Intel wird reduziert, dies jedoch unterschiedlich stark. AMD kaum, Intel sehr. Siehe den ersten Test zur Performance von Kernel 4.20 auf phoronix.com (https://www.phoronix.com/scan.php?page=article&item=linux-420-bisect&num=1)
- Der Angriff kann nur in bestimmte Szenarien passieren (VM- / Cloud-Provider, Ausführung von untrusted Code in Container/Sandbox) und damit sehen einige Kernel-Entwickler die obligatorische Absicherung in keinen guten Verhältnis zum eingetretenen Leistungseinbruch
=> Das beide Hersteller empfehlen, dies nicht zu nutzen sollte damit auf der Hand liegen - nicht mehr, nicht weniger.

Damit fällt dann auch meine Einschätzung zum zweiten Teil entsprechend aus:
- Kein theoretische Konstrukt, da Schwachstelle und Bedrohungsszenario existieren.
- Es kann damit auch keine Handbremse sein, da Bedrohung existent und (zumindest wir) keine bessere Lösung kennen.
- Es wirkt als Bremse wenn das System/User sich nicht Angriffsvektor des Bedrohungsszenario bewegt.

Ganon

2018-11-22, 00:07:40

:ugly: Ich hab eine simple Frage gestellt, und schon wird wieder sonst was vermutet, was ich damit "eigentlich" fragen wollte...

Aber noch mal in Stichpunkten und ausführlicher:

- Der STIBP Flag ist eine Mitigation im Kontext von Spectre V2
- Der STIBP Flag wird nur gesetzt wenn die CPU überhaupt als anfällig für Spectre V2 gilt (und SMT hat)
- Im Linux Kernel gilt, soweit ich das in Erfahrung bringen kann, AMD (Ryzen und Co.) auch als anfällig gegen Spectre V2
- Die Spectre V2 Anfälligkeit bei AMD ist, wie hier ja nun auch schon zig mal durchgekaut, eine "near zero risk" und auch der Linux Kernel fährt eher minimale Mitigations auf AMD CPUs
- Der aktuelle Zustand im Kernel ist also so, dass auch auf AMD Hardware das STIBP Flag dauerhaft aktiv ist
- Der zukünftige Zustand wird wohl auch so sein, dass auch bei AMD im gleichen Maße wie bei Intel STIBP gesetzt wird

Meine Frage: Hat das auf AMD Hardware irgend einen Sinn? Also einen praktischen Sinn und nicht nur "es verhindert die letzten 0,001% Wahrscheinlichkeit eines erfolgreichen Angriffs". Und nochmals: Die Flags sind nicht neu. Die kamen alle Anfang des Jahres.

Ganon

2018-11-22, 12:31:05

Benutzername

2018-11-22, 13:44:29

Auch wenn es jetzt nichts mit den CPUs zu tun hat, man hat jetzt wohl Rowhammer bei ECC RAM durchführen können. https://www.golem.de/news/eccploit-rowhammer-angriff-funktioniert-auch-mit-ecc-1811-137863.html

Es wurde zwar mit DDR3 RAM gemacht, aber sie glauben unter DDR4 geht das auch. Grundlage ist hier übrigens wohl auch wieder ein Seitenkanal-Angriff, um verwundbare Bits zu finden.

Und was ist mit ECC-DDR5? DDR4 und 3 wird sich ja nichts mehr ändern lassen, aber 5 ist ja noch nicht so wirklich auf dem Markt, da könnte man noch was nachsteuern.

Iscaran

2018-11-22, 14:15:41

Bzgl STIBP und IBPB:
http://lkml.iu.edu/hypermail/linux/kernel/1811.2/05632.html
"The mitigation guide documents how STIPB works:

Setting bit 1 (STIBP) of the IA32_SPEC_CTRL MSR on a logical processor
prevents the predicted targets of indirect branches on any logical
processor of that core from being controlled by software that executes
(or executed previously) on another logical processor of the same core.

Ergo setting STIBP protects the task itself from being attacked from a task
running on a different hyper-thread and protects the tasks running on
different hyper-threads from being attacked.

IBPB is issued when the task switches out, so malicious sandbox code cannot
mistrain the branch predictor for the next user space task on the same
logical processor."

STIBP schützt also sowohl den Prozess selbst vor Zugriffen von ungeschützten Prozessen von außen als auch andere äußere Prozesse vor versuchten Spectre-Zugriffen aus dem STIBP geschützten Prozess selbst. Allerdings nur bei Hyper-Thread (alias SMT-Ablaufenden Prozessen).

Es funktioniert also in BEIDE Richtungen !

IBPB schützt hingegen vor Spectre-Attacken aus einem User-Space hinaus in einen beliebigen anderen User-Space. Es blockiert das Mistraining des BTBs beim Prozess-Wechsel.

Die Verwendung von IBRS macht STIBP übrigens unnötig.

http://lkml.iu.edu/hypermail/linux/kernel/1811.2/05641.html
"If enhanced IBRS is active, STIBP is redundant for mitigating Spectre v2
user space exploits from hyperthread sibling.

Disable STIBP when enhanced IBRS is used."

Evtl. ein Grund warum AMD CPUs hier im Phoronix-Test so glimpflich davonkommen ?
https://www.phoronix.com/scan.php?page=article&item=linux-420-stibp&num=1

Die Ryzens/Epyc können alle "enhanced" IBRS (soweit mir bekannt) und leiden auch nicht an der Buffer-Overflow Problematik bei IBRS auf Skylake und den davon abgeleiteten Derivaten (der Grund für "enhanced" IBRS das Intel erst in den neuesten Arch nachgerüstet hat).

Ganon

2018-11-22, 14:23:13

Evtl. ein Grund warum AMD CPUs hier im Phoronix-Test so glimpflich davonkommen ?

So wie es aktuell im Kernel funktioniert, wird STIBP immer aktiviert, vollkommen unabhängig was sonst noch gesetzt ist. Das wird erst im kommenden Patch geändert. Von daher sind die Benchmarks soweit ich das sehe schon mit aktiviertem STIBP.

Der von dir verlinkte Patch ist genau der, der noch in Arbeit ist.

Iscaran

2018-11-22, 15:17:28

So wie es aktuell im Kernel funktioniert, wird STIBP immer aktiviert, vollkommen unabhängig was sonst noch gesetzt ist.

Im Benchmark sieht man aber dass die EPYCs hier kaum einbrechen. Michael hat aber bestätigt dass er definitiv ALLE Mitigations aktiviert hatte (und zwar für beide CPU Sorten).

=> Verschiedene Erklärungsmöglichkeiten:
1.) Entweder wurde STIBP auf den EPYCs nicht korrekt aktiviert.
=> Resultierend in zu hoher Epyc-Performance
2.) STIBP wurde auf EPYC nicht durch den Patch aktiviert da er bereits IBRS kann (anders als die Skylakes (auch enhanced IBRS) weshalb bei den Xeons zusätzlich STIBP dazu kam
=> beobachtetes Perfomance-Bild Intel bricht um 20-30% ein, Epyc nicht.
3.) STIPB wird nur auf Intel aktiviert und nicht auf AMD ? (Weil Situation unklar ?)
4.) STIPB wirkt bei AMD nicht derart bremsend
=> unwahrscheinlich da AMD selbst von STIBP abrät wenn nicht zwingend erforderlich.

Aber mal sehen - schon morgen soll ja der Performance-Patch für STIBP raus sein - dann gibts sicher upgedatete Benchmarks.

Birdman

2018-11-22, 18:17:45

Evtl. ein Grund warum AMD CPUs hier im Phoronix-Test so glimpflich davonkommen ?
https://www.phoronix.com/scan.php?page=article&item=linux-420-stibp&num=1
Gut möglich
Ich habe mich bei den Benchmarks nämlich auch schon gefragt wieso die Zen CPU mehrheitlich unbeeindruckt war von STIBP, obwohl AMD selbst von dessen Nutzung auf eines zu hohen Performanceimpacts abgeraten hat.

Ganon

2018-11-22, 23:12:39

Der STIBP Patch wird mit den Kerneln 4.19.4 und 4.14.83 erst mal komplett entfernt. Kommt dann irgendwann in einer ordentlichen Fassung dann wieder.

https://www.phoronix.com/scan.php?page=news_item&px=Linux-Stable-Dropping-STIBP

Lord Wotan

2018-11-24, 13:30:43

Ich frage noch mal.

Ich habe folgende AMD CPU amd phenom 925 ii x4 prozessor auf einen GA-MA785GT-UD3H Mainboard. Da gibt es keine Bios Updates mehr die das fixen. Nun habe ich folgendes gelesen.

Wenn man diese Werte in die Regedit einträgt, wird Spectre bei AMD gefixt

Enable user-to-kernel protection on AMD and ARM processors together with other protections for CVE 2017-5715:

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 64 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f
Restart the computer for the changes to take effect.

Enable user-to-kernel protection on AMD processors together with other protections for CVE 2017-5715 and protections for CVE-2018-3639 (Speculative Store Bypass):

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverride /t REG_DWORD /d 72 /f

reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management" /v FeatureSettingsOverrideMask /t REG_DWORD /d 3 /f

Restart the computer for the changes to take effect.

Trotzdem zeigt mit das Tool In Spectre System das:
Metdown protected yes
is Spectre protected no
Microcode Update no.
Trotz Windows 10 v.1809 Bild 134 plus Microsoft Firmware Patch und Regedit Eintrag.

Warum zeigt mir das Tool in Spectre weiterhin am das das der PC gegen Spectre nicht geschützt ist. Oder Funktioniert dsas Tool nur bei Intel CPU´s?

Complicated

2018-11-24, 15:58:12

Weil du kein Microupdate für das BIOS hast. Beides muss installiert sein um den Schutz zu aktivieren.

Lord Wotan

2018-11-25, 11:35:34

Weil du kein Microupdate für das BIOS hast. Beides muss installiert sein um den Schutz zu aktivieren.
Das macht doch Microsoft über das Patch, wie bei Intel wo es auch für ältere Mainboards kein Bios Fix gibt. Oder nicht?

Dorn

2018-11-25, 16:44:46

Das macht doch Microsoft über das Patch, wie bei Intel wo es auch für ältere Mainboards kein Bios Fix gibt.Richtig

looking glass

2018-11-25, 17:00:20

Mal die Frage, ist ein 9700k mit 8 Kernen ohne HT dahingehend dann sicherer was Meltdown und Spectre angeht, immerhin ist einiges davon ja nur mit HT möglich.

Ach ja, soweit mitbekommen hiess es ja 9000er CPUs würden nur auf 390iger Chipsatz laufen, dann kam die Meldung der Mainboardhersteller, die liefen auch auf 370iger, wenn man die per BIOS dafür klar macht - bezieht sich das auch auf H370iger und nicht nur auf Z370iger Chipsätze? Gibt es da irgendwie eine Übersicht welche Hersteller welche Mainboards einem BIOS Update zukommen lassen haben, damit 9000er CPUs drauf laufen?

Sinn ist der, das ich dann gern ein 9700k auf einem H370 laufen lassen würde, weil ich nicht OCen will, aber dafür ein niedrigen Verbrauch beim idle hätte, was irgendwie nur klappt, wenn die Hersteller sich an die TDP Specs der CPU halten würden, was viele der OC Mainboards so nicht unbedingt tun, wie es scheint.

Lord Wotan

2018-11-25, 17:59:51

Richtig
OK und warum zeigt das Tool Inspectre das mein AMD System nicht vor Spectre geschützt ist? Wie gesagt Microsoft Mikrocode Update für Windows 10 v. 1809 ist drauf und die Einstellungen in der Regedit für AMD CPU´s stehen.

Complicated

2018-11-25, 22:15:22

Das macht doch Microsoft über das Patch, wie bei Intel wo es auch für ältere Mainboards kein Bios Fix gibt. Oder nicht?
Mictosoft kann nur Microcodes updaten die AMD veröffentlicht. Bitte zeige mir wo die für Phenom II CPUs zu finden sind.

Lord Wotan

2018-11-25, 22:27:03

Mictosoft kann nur Microcodes updaten die AMD veröffentlicht. Bitte zeige mir wo die für Phenom II CPUs zu finden sind.
Sind die nicht in letzten Update bei gewesen?

Complicated

2018-11-26, 07:09:59

Mir sind bisher nur Microcodes bis Bulldozer Version 1 bekannt. Daher meine Frage nach Quellen für PII.

Eldoran

2018-12-05, 12:33:08

Split-Spectre... eine Optimierung zu Spectre V1 https://heise.de/-4241478

Eldoran

2019-02-12, 20:50:51

SGX wird langsam ein echtes anti-security Feature. Es gibt jetzt Proof of Concept für eine Malware in der SGX.
https://www.heise.de/security/meldung/Prozessor-Sicherheit-Intels-sichere-Software-Enklave-SGX-wurde-geknackt-4306965.html

Complicated

2019-02-13, 12:30:38

Naja... so einige bezeichnen das schon als FUD.
Aus dem Heiseforum:
https://www.heise.de/forum/heise-Security/News-Kommentare/Prozessor-Sicherheit-Intels-sichere-Software-Enklave-SGX-wurde-geknackt/Re-kann-ein-sogenannter-Remote-Attestation-Server-jederzeit-aus-dem-Netz-verifi/posting-33941122/show/

Keine Sorge, der Artikel sowie das eigentliche paper strotzen nur so vor Ungenauigkeiten und Effekthascherei.

Ein remote attestation server kann verifizieren was fuer ein code in der enclave ausgefuehrt wird. Dazu schickt er eine challenge, die vom Netzwerkstack empfangen und an die enclave durchgereicht werden muss. Wenn du das nicht machst, kann die enclave auch nicht antworten.

Die Kommunikation laeuft auch nicht durch den Kernel sondern eine enclave ist immer an einen userspace Prozess gebunden. Der Kerneltreiber wird nur benoetigt weil das OS die verschluesselten enclave pages nicht mehr so einfach umalloziieren kann wie bei normalen tasks. Ausserdem muss man irgendwie den Zugriff auf SGX managen, es soll ja nicht jeder user beliebig enclaves laden koennen, und access control macht in Linux/Windows halt das OS.

Das bedeutet aber andersrum dass die SGX enclave erstmal immer nur ihren entsprechenden user-prozess exploiten kann, aus dem heraus sie geladen wurde. Wie im paper richtig gesagt kann das zB bei DRM bedeuten dass jemand enclaves laedt die man eigentlich nicht will. Aber das Problem hast du auch jetzt schon, das DRM SW eventuell Treiber/kmod laedt die eigentlich ein Sicherheitsrisiko sind. Wer solche tasks laedt sollte sich nicht wundern wenn sie unerwuenschte Dinge tun.

Soweit ich sehe kann der Angriff nicht aus dem user-prozess ausbrechen sondern benoetigt dafuer weitere exploits oder side-channels. Das Problem hast du aber auch so schon, dass ein potentiell nicht vertrauenswuerdiger Task dir mit Hilfe weiterer exploits oder side-channels deine security untergraben kann.

Und natuerlich kann das OS die enclave sowie den task einfach abschiessen und die memory pages ueberschreiben. Und es kann auch nicht irgendwas geladen oder gepatcht werden sondern es ist immer genau das, was im enclave manifest signiert wurde.

Das paper sagt dazu, dass die stealthy SGX malware ja im Hintergrund scannen und warten kann. Das kann eine malware oder DRM application natuerlich ebenso. Mit SGX kann man solche Anwendungen nun wirklich stark verschluesselt ausliefern statt nur obfuscation zu machen, aber gerade deswegen sind sie ja auf usermode limitiert und werden nur mit Zustimmung des OS ausgefuehrt..

Alles in allem sehe ich nur jede Menge FUD. Das Paper spricht von read/write primitives die sie bei Angriffen einsetzen und lassen geflissentlich unter den Tisch fallen dass sie damit lediglich die Anwendung angreifen, die ueberhaupt erst die Enclave geladen hat. Jede beliebige malware kann per se erstmal ohne Schadcode kommen und dann aber verschluesselte payloads nachladen..

lumines

2019-02-17, 11:01:03

The tower of abstractions has allowed us to gain confidence in our designs through separate reasoning and verification, separating hardware from software, and introducing security boundaries. But we see again that our abstractions leak, side-channels exist outside of our models, and now, down deep in the hardware where we were not supposed to see, there are vulnerabilities in the very chips we deployed the world over.

https://arxiv.org/abs/1902.05178?fbclid=IwAR2Pw6Zy0d3CTAmSTQgv5iRxpcIn1tWItSKEMMmPiEJpRbH95pxBRVpDAxE

Eine Analyse zu Spectre und ähnlichen Sicherheitslücken.

Benutzername

2019-02-19, 15:36:59

https://www.heise.de/security/meldung/Software-Schutz-vor-Spectre-Angriffen-ist-weitestgehend-nutzlos-4311666.html

Software-Schutz vor Spectre-Angriffen ist weitestgehend nutzlos

Also jetzt Millionen CPUs umtauschen? (wird nicht passieren)

edit: Ich sehe lumines hat das relevante paper verlinkt

Lurtz

2019-02-19, 15:46:55

Ihre Erkenntnisse sind allerdings kein Grund zur Panik, da von den Angriffen praktisch nur Programme betroffen sind, die Code aus nicht vertrauenswürdigen Quellen ausführen – die meisten Programme, die wir im Alltag nutzen, gehören nicht zu dieser Kategorie. Die wichtigste Gruppe solcher gefährdeter Programme sind Web-Browser.
:ugly:

aufkrawall

2019-02-19, 15:58:03

Das ist in der Introduction des Papers allerdings nicht so dümmlich formuliert. Heise sowieso CB sind leider stilistisch und semantisch notorische Durchfall-Produzenten.

Gut, dass ich in Firefox schon lange mit 99 Content-Prozessen unterwegs bin. Die OS-Mitigations hab ich nun schon seit Längerem aus, da Multi-Prozess und Quellcode-Hardening mir gegen das ohnehin hypothetische Angriffsszenario für Consumer hinreichend erscheinen.

Lurtz

2019-02-19, 21:45:13

Kannst es auch auf -1 stellen, dann nimmt er unbegrenzte Content-Prozesse. Bringt nur nicht soo viel, da Site Isolation in Firefox noch nicht umgesetzt ist und zB iFrames im gleichen Prozess verbleiben.

Wobei es auch Stimmen gibt, die Site Isolation nicht die große Bedeutung beimessen:
https://twitter.com/pcwalton/status/1096540124509159425

Naitsabes

2019-03-01, 22:53:13

Mit KB4482887 von heute nutzt Windows 10 auch retpoline (jedenfalls bis Broadwell, ob auch bei skylake und neuer weiß ich nicht).

https://www.deskmodder.de/blog/2019/03/01/kb4482887-windows-10-1809-17763-346-manueller-download-steht-im-rp-ring-bereit/

Ganon

2019-03-02, 20:32:41

Ist eigentlich in dem Zusammenhang bekannt, ob Windows auf Coffee Lake R CPUs die Meltdown-Mitigations deaktiviert? Mich würde in dem Zusammenhang mal ein Benchmark interessieren, wo man mal vergleicht wie viel Performance die Hardware-Lösung kostet im Vergleich zu älteren CPUs.

y33H@

2019-03-02, 21:56:08

Ian hat sich mal dran versucht: https://www.anandtech.com/show/13659/analyzing-core-i9-9900k-performance-with-spectre-and-meltdown-hardware-mitigations

Ganon

2019-03-02, 22:18:59

Danke für den Link. Beantwortet auch gleich die Frage ob Windows die Meltdown-Fixes deaktiviert (Ja, tut es).

Dass die Performance sich im Vergleich kaum bewegt (und es teilweise sogar noch langsamer wird) ist dann aber schon irgendwie seltsam. Der Test hat leider auch Hyper-Threading deaktiviert und in den Kommentaren hat der Autor wohl daraufhin einen Nachtest angekündigt, der aber wohl nicht nicht erschienen ist!? Weil L1TF-Mitigations deaktivieren ja mehr oder weniger HT in bestimmten Situationen. Wenn das nicht mehr nötig ist, sollte es ja wieder mehr Performance bringen. Zumindest in der Theorie. Ein breiteres Spektrum an CPUs mit deaktivierten Fixes vs Hardware-Fix wäre auch noch mal interessant.

Tarkin

2019-03-05, 12:37:30

https://www.theregister.co.uk/2019/03/05/spoiler_intel_flaw/

neue Sicherheitslücke entdeckt - "SPOILER"

Pirx

2019-03-05, 12:54:01

https://www.theregister.co.uk/2019/03/05/spoiler_intel_flaw/

neue Sicherheitslücke entdeckt - "SPOILER"
WOW, sieht erstmal heftig aus und nutzt genau Intels Masche aus.

Aktuelle Linux-Benchmarks zu den Auswirkungen der Mitigations. https://www.phoronix.com/scan.php?page=article&item=linux50-spectre-meltdown&num=1

BigKid

2019-03-05, 13:20:10

Bin mal gespannt ob ein 1700X demnächst bei der pro Core Leistung mit dem 8700K gleichziehen kann... 20% Leistungsverlust sind nicht ohne und es ist ja irgendwie kein Ende in Sicht.

Iscaran

2019-03-05, 16:53:31

Further, we showed the impact of SPOILER by performing
a highly targeted Rowhammer attack in a native user-level
environment. We further demonstrated the applicability of
SPOILER in sandboxed environments by constructing efficient
eviction sets from JavaScript, an extremely restrictive
environment that usually does not grant any access to physical
addresses. Gaining even partial knowledge of the physical
address will make new attack targets feasible in browsers even
though JavaScript-enabled attacks are known to be difficult to
realize in practice due to the limited nature of the JavaScript
environment. Broadly put, the leakage described in this paper
will enable attackers to perform existing attacks more efficiently,...

Damit wird es nun also möglich Spectre etc. "effizient" auf Intel CPUs durchzuführen auch wenn der Angreifer im JavaScript Sandbox im Browser sitzt.

Also wird ein echtes PATCHEN gegen Spectre und Co nun zunehmend wichtig bzw. Pflicht werden.

Complicated

2019-03-06, 14:41:54

Die Lücke hat nichts mit Spectre zu tun. Es vereinfacht Rowhammer, wie ja schon zitiert.
The issue is separate from the Spectre vulnerabilities, and is not addressed by existing mitigations. It can be exploited from user space without elevated privileges.

Iscaran

2019-03-06, 15:38:50

Ja - aber mit dem vereinfachten Rowhammer kann ich viel genauer und schneller relevante Adressbereiche definieren die ich dann an ein Spectre Skript übergeben kann ?

Zumindest kam mir dieser Kontext in den Kopf als ich das Paper las.

BTB

2019-03-11, 10:59:52

Habe noch einen alten Core2Duo als Arbeits-PC, da sind die Performance Einbussen schon heftig, hab zwar nichts gebencht, mich aber die letzte Zeit immer über die schlechte (vor allem I/O) Performance geärgert. In dem Teilchen ist eine SSD und eine fette HDD verbaut.

Da mich das so genervt hat, hab ich die Patche jetzt deaktiviert. Bricht ja sicher nicht gleich die Hölle über einen rein, Windows hat auch so genug Probleme denke ich und ausser bekannte Seiten, surfe ich eh nichts an. Und wenn was passiert sterbe ich davon sicher auch nicht.

Gefühlt jetzt alles wieder fluffiger.

Achill

2019-03-18, 07:28:23

https://www.theregister.co.uk/2019/03/05/spoiler_intel_flaw/

neue Sicherheitslücke entdeckt - "SPOILER"

Kleines Update, AMD ist nicht davon betroffen: https://www.amd.com/en/support/kb/faq/pa-240

Denniss

2019-03-18, 09:16:29

Also das übliche, Intel prüft nicht die ganze Adresse damit die Verabeitung schneller geht.
It's not a Bug, it's a Feature !

Pirx

2019-04-12, 14:41:44

Intel äußert sich zu SPOILER

https://www.zdnet.com/article/intel-finally-issues-spoiler-attack-alert-now-non-spectre-exploit-gets-cve-but-no-patch/

https://bit-tech.net/news/tech/intel-warns-of-four-security-vulnerabilities/1/

Rampage 2

2019-04-19, 23:52:52

Ich habe ein paar Fragen zur Intel Management Engine:

Auch wenn diese bereits in der CPU integriert ist und schon beim Starten des Rechners aktiv wird, bietet Intel zusätzlich noch Treiber und/oder Firmware dafür an - meist unter den Bezeichnungen "Intel Management Engine Interface", "Intel Management Engine Driver" oder "Intel Management Engine Firmware" und ähnlichen Namen.

Da man die ME im BIOS eh nicht deaktivieren kann, würde ich gerne wissen, ob es einen Unterschied macht, wenn man die zuständigen Treiber installiert oder nicht installiert. Insbesondere in folgenden Punkten:

1.) Da nicht deaktivierbar, ist die ME eh ein ziemlich offenes Scheunentor - egal mit oder ohne dafür installierten Treibern. Aber würde die Installation von ME-Treibern das Ganze noch zusätzlich verschlimmern? (z.B. das Scheunentor noch weiter öffnen, zusätzliche Angriffs-, Kontroll- oder Überwachungsvektoren einbauen?)

2.) Würde - abseits vom Sicherheitsaspekt - das Installieren von ME-Treibern irgendwelche Vorteile bringen? (bessere Performance, mehr Funktionalität und/oder Zuverlässigkeit/Systemstabilität, höhere Kompatibilität)

3.) Umgekehrt, hätte das Nicht-Installieren von ME-Treibern irgendwelche Nachteile (schlechtere/keine vollständige Systemperformance, weniger zuverlässiger oder stabiler Systembetrieb, weniger Funktionen oder sogar kein einwandfrei lauffähiger Rechner) ? Ich hatte mal irgendwo gelesen, dass ohne eine einwandfrei funktionierende ME ein Intel-Rechner gar nicht erst lauffähig ist bzw. der Rechner gar nicht erst startet.

Wenn ich an "Motherboard" bzw. "Chipsatz"-Treiber denke, dann fallen mir als Allererstes die MEI-Treiber und der normale Intel Chipsatz-Treiber ein - diese sind sozusagen die wichtigsten Treiber für das Motherboard und/oder den Chipsatz (auch wenn es noch andere wichtige Treiber gibt - z.B. Intel RST-Treiber, Intel USB3.0-Treiber oder Intel LAN-Treiber). Diese Aussage ist natürlich nur auf Intel-Systeme bezogen;)

Normalerweise installiere ich immer die Treiber für alle verfügbaren Geräte, aber zumindest bei der Intel ME tue ich mir damit möglicherweise nichts Gutes, sondern Böses an. Deswegen ja auch die Fragen in diesem Posting...

R2

aufkrawall

2019-04-20, 00:01:04

Dass sich die Angriffsfläche mit einem weiteren Treiber, der die Kommunikationsfunktionalität zwischen OS und ME ausbaut, erhöht, ist ziemlich plausibel. Trotzdem war es all die Jahre kein für Enduser relevantes Einfallstor für Malware.

Rampage 2

2019-04-20, 20:32:57

Tarkin

2019-05-14, 20:13:43

https://www.heise.de/newsticker/meldung/Neue-Sicherheitsluecken-in-Intel-Prozessoren-ZombieLoad-4421217.html

ZombieLoad: Neue Sicherheitslücken in Intel-Prozessoren

Betroffene Prozessoren
Die ZombieLoad-Attacke (CVE-2018-12130) trifft fast alle Core-i- und Xeon-Prozessoren seit etwa 2011 außer den jüngsten Versionen: Core i-8000U (Whiskey Lake-U) für Notebooks, Core i-9000 (Coffee Lake Refresh) ab Stepping 13 (R0) für Desktop-PCs und Xeon-SP der zweiten Generation (Cascade Lake). Die Unterscheidung ist aber schwierig, denn den Core i9-9900K gibt es beispielsweise im älteren Stepping 12 (Intel64 Family 6 Model 158 Stepping 12) und auch im jüngeren Stepping 13 (Intel64 Family 6 Model 158 Stepping 13).

Nie wieder Intel - sorry, aber die CPUs sind so löchrig wie Schweizer Käse!!!

Benutzername

2019-05-15, 01:16:58

Nie wieder Intel - sorry, aber die CPUs sind so löchrig wie Schweizer Käse!!!

aber aber aber 5 Gigahertz! :wink:

Erinnert mich immer mehr an die Abgasschummelei der Autohersteller. Mit den ganzen Gegenmaßnahmen verpufft dann auch wieder die Mehrleistung der intel CPUs. OpenBSD hat schon vor längerem Hyperthreading bei intel deaktiviert aus sicherheitsgründen. Die haben das als Quelle von noch mehr Lücken gesehen wegen der unterschiedlichen Rechte:

SMT (Simultanious Multi Threading) implementations typically share
TLBs and L1 caches between threads. This can make cache timing
attacks a lot easier and we strongly suspect that this will make
several spectre-class bugs exploitable. Especially on Intel's SMT
implementation which is better known as Hypter-threading. We really
should not run different security domains on different processor
threads of the same core. Unfortunately changing our scheduler to
take this into account is far from trivial. Since many modern
machines no longer provide the ability to disable Hyper-threading in
the BIOS setup, provide a way to disable the use of additional
processor threads in our scheduler. And since we suspect there are
serious risks, we disable them by default. This can be controlled
through a new hw.smt sysctl. For now this only works on Intel CPUs
when running OpenBSD/amd64. But we're planning to extend this feature
to CPUs from other vendors and other hardware architectures.

Note that SMT doesn't necessarily have a posive effect on performance;
it highly depends on the workload. In all likelyhood it will actually
slow down most workloads if you have a CPU with more than two cores.

https://www.mail-archive.com/source-changes@openbsd.org/msg99141.html

Wenn Ich das so lese war Bulldozer vielleicht doch nicht so verkehrt gedacht. Kein HT, kein Problem. zumindest sollte man unterschiedliche sicherheitslevel Threads nicht auf demselben Kern laufen lassen. :uponder:

--------------------

https://venturebeat.com/2019/05/14/intel-zombieload-flaw-forces-os-patches-with-up-to-40-performance-hits/

Autsch bis zu 40% Leistung weg.

Google schaltet es in Chromebooks ab:

https://www.aboutchromebooks.com/news/chrome-os-74-disables-cpu-hyperthreading-intel-mds-vulnerabilities-security/

Unicous

2019-05-15, 01:43:32

Wie es scheint kehrt Intel zum alten Geschäftsgebahren zurück.

Ich hoffe das wird entsprechend von den Medien aufgearbeitet:

Original-Quelle auf Niederländisch
https://www.nrc.nl/nieuws/2019/05/14/hackers-mikken-op-het-intel-hart-a3960208

Google Translate

https://translate.google.com/translate?sl=nl&tl=de&u=https%3A%2F%2Fwww.nrc.nl%2Fnieuws%2F2019%2F05%2F14%2Fhackers-mikken-op-het-intel-hart-a3960208

Obwohl Teile des Lecks von mehreren Forschern verschiedener Universitäten und Unternehmen gefunden wurden, hat die FE die Mehrheit entdeckt. Die Universität Amsterdam ist auch die einzige Partei, die eine Belohnung erhält: $ 100.000 (89.000 Euro), Intels maximale Belohnung für Entdecker kritischer Lecks.

Die Prämie hat einen kleinen Geschmack. Laut der VU versuchte Intel, den Schweregrad des Lecks herunterzuspielen, indem er offiziell 40.000 US-Dollar an Belohnungen und zusätzlich "80.000 US-Dollar" auszahlte. Dieses Angebot wurde höflich abgelehnt.

Wer eine Belohnung annimmt, muss sich auch an die Regeln halten. In diesem Fall bedeutete das: keine Rücksprache zwischen Forschern und Unsicherheit darüber, welche Softwarehersteller im Vorfeld gewarnt wurden. Technologiefirmen argumentieren nach Ansicht der Forscher nicht im Interesse des Anwenders, sondern des Aktionärs.

Intel versäumte es zunächst, Google und Mozilla, zwei große Browserhersteller, zu benachrichtigen.

Die FE versuchte den Hersteller zu zwingen, schneller herauszukommen. Schließlich zwang die VU Intel, im Mai herauszukommen - sonst würde die Universität die Details selbst veröffentlichen. "Wenn es nach Intel ginge, hätten sie noch ein halbes Jahr warten wollen", sagt Bos.

Intel hatte versprochen, dass die nächste Generation von Chips nicht für RIDL anfällig sein würde, aber das ist nicht der Fall.

:freak::freak::freak:

edit:

Die Website/jump page (samt URL) von der Uni Graz sind auch Zucker.

https://cpu.fail/

:freak:

https://cpu.fail/public/images/zombieload_logo.png

Leonidas

2019-05-15, 07:21:02

Da man die ME im BIOS eh nicht deaktivieren kann, würde ich gerne wissen, ob es einen Unterschied macht, wenn man die zuständigen Treiber installiert oder nicht installiert. Insbesondere in folgenden Punkten:

1.) Da nicht deaktivierbar, ist die ME eh ein ziemlich offenes Scheunentor - egal mit oder ohne dafür installierten Treibern. Aber würde die Installation von ME-Treibern das Ganze noch zusätzlich verschlimmern? (z.B. das Scheunentor noch weiter öffnen, zusätzliche Angriffs-, Kontroll- oder Überwachungsvektoren einbauen?)

Man kann das HW-Gerät deaktivieren. Dann dürfte es seinen Dienst generell nicht tun. Die Treiber könnten in der Tat aber nur für die Windows-Integration (Kommunikation mit anderer Windows-Software) da sein, regulär sollte die ME auch so laufen.

Aber da Intel in die ME inzwischen auch HW-Kontrollfunktionen einbaut (Lüftersteuerung), ist die leider sowieso unumgänglich. Wenn nicht schon jetzt, dann zukünftig.

Mangel76

2019-05-15, 07:54:28

Zumindest wird jetzt noch klarer, warum Intel neuerdings viele CPUs unterhalb des Spitzenmodells ohne HT verkauft. Da scheint noch einiges zu lauern.

Isen

2019-05-15, 08:57:36

Ich hoffe das wird entsprechend von den Medien aufgearbeitet:

Wovon träumst du Nachts? (;))
Die Currywurstbuden berichten nur das, was für alle offensichtlich ist, die Gebaren dahinter existieren nicht.

Lowkey

2019-05-15, 09:36:19

Zumindest wird jetzt noch klarer, warum Intel neuerdings viele CPUs unterhalb des Spitzenmodells ohne HT verkauft. Da scheint noch einiges zu lauern.

Vorher: i5 4 Kerne, i7 4+4
Heute: i7 8 Kerne, i9 8+8

Geändert hat sich nichts, aber Verschwörungstheoretiker gibt es immer ;)

Mangel76

2019-05-15, 10:25:53

Vorher: i5 4 Kerne, i7 4+4
Heute: i7 8 Kerne, i9 8+8

Geändert hat sich nichts, aber Verschwörungstheoretiker gibt es immer ;)

Ähm...
i7-8700k 6(12) i7-9700k 8(8)

Bis zur 7. Generation hatte lediglich i5 kein HT um sie vom i7 abzugrenzen. In der 9000er Reihe hat nur noch der i9 HT, darunter keiner mehr.

y33H@

2019-05-15, 11:02:54

Intel hat mal eben für alle 9th Gen Desktop Chips das R0-Stepping aufgelegt, hui.

M4xw0lf

2019-05-15, 11:29:08

Intel hat mal eben für alle 9th Gen Desktop Chips das R0-Stepping aufgelegt, hui.
Und das bringt neue Maßnahmen gegen die Sicherheitslücken?

y33H@

2019-05-15, 11:43:23

Nur das neue Stepping für Desktop, für Notebooks und für Ultrabooks geht in Hardware gegen Microarchitectural Data Sampling vor. Finde ich krass, weil Intel wenigstens drei oder vier Dies dafür überarbeitet hat.

Achill

2019-05-15, 11:58:53

Das ist ja faktisch ein Eingeständnis der Schwere der Lücke.

Tesseract

2019-05-15, 12:41:13

Zumindest wird jetzt noch klarer, warum Intel neuerdings viele CPUs unterhalb des Spitzenmodells ohne HT verkauft. Da scheint noch einiges zu lauern.

warum intel das macht ist offensichtlich: weil sie zum dritten mal skylake aufwärmen und ein paar MHz mehr takt inzwischen nicht mehr reichen um das ganze als "neue generation" zu verkaufen. mehr cores dafür ohne HT ist die "halbe" upgradestufe die sie brauchen für den generationssprung ohne sich den markt für die teureren modelle kaputt zu machen.

y33H@

2019-05-15, 13:24:28

Das ist ja faktisch ein Eingeständnis der Schwere der Lücke.Ich hatte mich schon gewundert warum die vPro-Modelle von Whiskey Lake U nicht auch zur IFA im August 2018 kamen, sondern erst im April 2019 - die Antwort ist, dass Intel den Chip erst noch gefixt hat, damit er in Buiness-Geräte kann :freak:

fondness

2019-05-15, 15:57:28

Schön langsam wird es wirklich lächerlich. Immer wieder droppen neue Sicherheitslücken herein und die einzige konstante scheint zu sein, dass Intel betroffen ist.

Unicous

2019-05-15, 16:14:53

Sicherheitslücken (in Hardware) sind heutzutage so gut wie unvermeidbar. (AMD, ARM und Co. können sich glücklich schätzen, vorerst glimpflich davon gekommen zu sein.)

Viel verwerflicher sind die Versuche seitens Intel, das zu vertuschen bzw. zumindest die Offenlegung zu beeinflussen/zu verzögern. Und sie kommen damit durch. Niemand, absolut niemand geht Intel dafür an den Kragen, das war schon bei MD&Spectre der Fall. Wirkliche Konsequenzen hat Intel bislang nicht zu spüren bekommen. Das ist der eigentliche Skandal.

Benutzername

2019-05-15, 16:27:30

Schön langsam wird es wirklich lächerlich. Immer wieder droppen neue Sicherheitslücken herein und die einzige konstante scheint zu sein, dass Intel betroffen ist.

Naja, intel wird jetzt besonders beäugt, dann findet man auch mehr Fehler natürlich. AMD hat auch spekulative Ausführung und HT, das kann schief gehen. Das wurde sogar schon damals bei DEC Alfas bemerkt, daß das passieren kann. Aber intel scheint besonders Leitstung vor allem anderen gesetzt zu haben und jetzt haben wir den Salat bei intel CPUs der letzten zehn Jahre.

In other news, gerade eben hat debian den intel microcode ausgeliefert bei mir, als Ich meinem Phenom angemacht habe. fefe (https://blog.fefe.de/?ts=a22536c6) meint der microcode patch sei von Januar:

microcode: microcode updated early to revision 0x2e, date = 2019-01-02

Mangels "aktuellem" intel kann Ich das hier nicht prüfen. Januar? :O

---------------------------------------------------------------

Hatten wir schon RIDL & Fallout?
https://mdsattacks.com/

sind auch auf https://cpu.fail/ aufgelistet.

AMD sagt die letzten zwei treffen nicht auf sie zu.

Fallout and Rogue In-Flight Data Load (RIDL)
5/14/19

At AMD we develop our products and services with security in mind. Based on our analysis and discussions with the researchers, we believe our products are not susceptible to ‘Fallout’ or ‘RIDL’ because of the hardware protection checks in our architecture. We have not been able to demonstrate these exploits on AMD products and are unaware of others having done so.

For more information, see our new whitepaper, titled “Speculation Behavior in AMD Micro-Architectures.”

https://www.amd.com/en/corporate/product-security

--------------------------------------------------------

In nochmal anderen Neuigkeiten will intel von UEFI weg (https://www.phoronix.com/scan.php?page=news_item&px=Intel-modernFW-Rust-VMM). Aber dafür mache Ich besser eienn neuen auf, glaube Ich.

Benutzername

2019-05-15, 16:36:25

Sicherheitslücken (in Hardware) sind heutzutage so gut wie unvermeidbar. (AMD, ARM und Co. können sich glücklich schätzen, vorerst glimpflich davon gekommen zu sein.)

Man hat es nur noch nicht gefunden, aber spekulative Ausführung scheint grundsätzlich anfällig für sowas.

Viel verwerflicher sind die Versuche seitens Intel, das zu vertuschen bzw. zumindest die Offenlegung zu beeinflussen/zu verzögern. Und sie kommen damit durch. Niemand, absolut niemand geht Intel dafür an den Kragen, das war schon bei MD&Spectre der Fall. Wirkliche Konsequenzen hat Intel bislang nicht zu spüren bekommen. Das ist der eigentliche Skandal.

intel hat immernoch die dicke Werbekohle. Also besser nicht zu laut kritisieren in den Zeitschriften und Websites. Auf blogs und Foren wird ja schon fleißig gewettert. Im endkundenbreich hat AMd ja so etwa 25% Marktanteil letztes Jahr gehabt, also ein umdenken gibt es, aber die längerfristigen Lieferverträge mit integratoren sind ja auch nicht so ohne weiteres zu ersetzen, weil niemand sonst diese Stückzahlen liefern kann. AMD könnte da auch in die Bredoullle geraten, wenn sie noch mehr Ryzen verkaufen wollen aber nicht können, weil die Herstelung nicht mithalten kann.

Google hat ja gerade Ht auf Chromebooks abgeschaltet, was merklich weh tut. Also es tut sich was, aber mit der breiten installierten Basis an intel CPUs gibt es natürlich auch genug Schönredner sonst müsste man ja teuer neu kaufen. Und für saubere Geschäftspraktiken wie zB Knebelverträge ist intel ja schon lange bekannt, wie auch für Vertuschung. Wie war das damals eigentlich mit dem FDIV bug? Hat intel da auch vrtuscht?

y33H@

2019-05-15, 18:17:01

Schaltet denn Intel überhaupt Werbung bei Heise, Golem, Computerbase, PCGH usw?

Menace

2019-05-15, 18:21:31

Schaltet denn Intel überhaupt Werbung bei Heise, Golem, Computerbase, PCGH usw?

Das ist eine Frage. Ich hoffe ja, dass keine vergünstigten oder geschenkten Hardware-Teile geliefert bzw. akzeptiert werden (unabhängig vom Hersteller).

kruemelmonster

2019-05-15, 18:48:43

fefe (https://blog.fefe.de/?ts=a22536c6) meint der microcode patch sei von Januar:

microcode: microcode updated early to revision 0x2e, date = 2019-01-02

Mangels "aktuellem" intel kann Ich das hier nicht prüfen. Januar? :O

fefe ist kein goldenes Kalb sondern blubbert auch mal ungeprüft Unfug (*) heraus: der vorige Microcode war 2E, das ZombieLoad Update hat die Version 2F und wurde am 17. Februar kompiliert. Quelle (https://www.intel.com/content/dam/www/public/us/en/documents/corporate-information/SA00233-microcode-update-guidance_05132019.pdf)
Wahrscheinlich hat seine Distro das Update noch nicht rausgegeben, so dass er noch mit der alten Version anhängt. Kann man sich ggf aber auch selber bauen, ich hab mir das Bios vom Zweitrechner (Asus P8Z68-V Pro) bereits mittels UBU (https://www.win-raid.com/t154f16-Tool-Guide-News-quot-UEFI-BIOS-Updater-quot-UBU.html) mit den aktuellen Microcodes (https://github.com/platomav/CPUMicrocodes) gepatched.

* aktuelles Beispiel (https://blog.fefe.de/?ts=a227a6c6): nicht nur dass es keine besonders erwähnenswerte News ist da es schon zig Security Bulletins von NV gab, auch Intel hat schon so einige Sicherheitslücken in ihren Grafikkartentreibern gehabt und auf ihrer Security Seite gelistet. Nothing to write home about, aber er macht daraus BILD-mäßige Meinungsmache und framed das Ganze als Drama.

=Floi=

2019-05-15, 19:38:42

Google hat ja gerade Ht auf Chromebooks abgeschaltet,

gibt es dazu eine news? warum sollten CB kompromittiert werden? :confused:
Kann man es dann wieder einschalten? Hat eher den anschein das alte langsamer zu machen...

Schaltet denn Intel überhaupt Werbung bei Heise, Golem, Computerbase, PCGH usw?

ihr werdet doch direkt von intel bezahlt :ugly:

Lehdro

2019-05-15, 19:48:08

gibt es dazu eine news? warum sollten CB kompromittiert werden? :confused:
Kann man es dann wieder einschalten? Hat eher den anschein das alte langsamer zu machen...

Er hat es doch verlinkt, dort findet man direkt die Quelle bei google selber:

https://support.google.com/faqs/answer/9330250

Google Chrome OS (Chromebooks, etc.)

Google has disabled Hyper-Threading by default on Chrome OS 74 and later. Chrome OS 75 will include additional mitigations.

No additional user or customer action is needed. Users wishing to control Hyper-Threading directly should refer to these instructions (https://www.chromium.org/chromium-os/mds-on-chromeos).

][immy

2019-05-16, 08:57:27

Naja, intel wird jetzt besonders beäugt, dann findet man auch mehr Fehler natürlich. AMD hat auch spekulative Ausführung und HT, das kann schief gehen. Das wurde sogar schon damals bei DEC Alfas bemerkt, daß das passieren kann. Aber intel scheint besonders Leitstung vor allem anderen gesetzt zu haben und jetzt haben wir den Salat bei intel CPUs der letzten zehn Jahre.

Ja, intel hat an z.B. Adresslängen gespart wodurch die letzten Sicherheitslücken auf Intel CPUs sehr viel wahrscheinlicher waren, während es auf AMD CPUs sehr unwahrscheinlich war. Zudem sind intel CPUs aggressiver bei der Sprung-vorhersage, wo man einiges an Vorsprung vor der Konkurrenz hat. Gut möglich das man dadurch gleichzeitig mehr Unsicherheit in kauf genommen hat.
Das man intel auch ein wenig genauer unter die Lupe nimmt, dürfte aber auch an deren quasi-Monopolstellung im Server-Markt liegen. Für entsprechende Märkte sind Sicherheitslücken auf intel-CPUs halt auch attraktiver als auf AMD CPUs, schon weil diese stärker verbreitet sind.

Setsul

2019-05-16, 11:55:19

Nicht unbedingt gespart, das ist einfach ein anderes Design. Weniger bits für die Adresse, was dadurch an Logik/Verbrauch frei wird kann man anderweitig einsetzen und dort nützt es vielleicht mehr als die zufälligen falschen Zuordnungen loszuwerden.
Inwiefern ist Intel agressiver bei der Sprungvorhersage? Jede CPU sagt alle Sprünge vorher (oder gar keine), egal ob Intel, AMD, IBM oder ARM. Ich wüsste auch nicht dass Intel dort einen großen Vorsprung hat.

Bei Intel wurde einfach die Entscheidung getroffen ist dass es besser ist alle Überprüfungen von Berechtigungen usw. erst am Ende beim Retirement zu machen und erstmal davon auszugehen dass alles funktioniert. Das wurde dann konsequent durchgezogen bei allem in der Annahme dass niemand an den speculative state rankommt und deshalb ist jetzt alles unsicher.
AMD hat in den letzten 10 Jahren 3 sehr verschiedene Architekturen gehabt während Intel immer auf der letzten aufgebaut hat und mehr oder weniger große Teile verbessert/ausgetauscht hat. Es ist nicht verwunderlich dass bei Intel deshalb alles die gleichen Lücken hat während K7-K10, Bulldozer und Zen sich deutlich unterscheiden. IBM ist ähnlich, aber nicht ganz so extrem.

Die einzig interessante Frage ist wieso AMD/ARM/IBM seltener betroffen sind und selbst das ist eher akademisch. Eine Möglichkeit ist dass sie einfach nicht dazugekommen sind die Optimierungen früher einzuführen, AMD wegen den "häufigen" Architekturwechseln, IBM wegen weniger Architekturen insgesamt und ARM wegen jährlichen Wechseln. Dafür spricht dass ARM beim A75 und IBM ab POWER7 auch Meltdown haben. Eine andere Möglichkeit wäre dass ein früher Abbruch Energie spart und deshalb AMD sich bewusst gegen die Optimierung entschieden hat während IBM da wenig Hemmungen hat und ARM entschieden hat, dass sie sich das auf 10nm leisten können.

tl;dr
Intel hat die Entscheidung einmal getroffen und sie konsequent durchgezogen weil es funktioniert hat, nicht weil sie der Konkurrenz um Jahrzehnte bei der Sprungvorhersage vorraus sind.

Opprobrium

2019-05-16, 17:31:59

AMD dürfte (theoretisch) nochmal etwas sicherer werden mit der neuen Chipsatzgeneration. Die vorherigen waren ja an ASMedia outgesourced und soweit ich das richtig im Kopf habe waren die der Stein des Anstoßes für die berüchtigte "RyzenFall"geschichte.

Zumindest kann ich mir nicht vorstellen, daß die mit Meltdown, Spectre und Ryzenfall im Hinterkopf bei der Entwicklung des neuen Chipsatzes und überhaupt bei der Finalisierung des Chipletansatzes nicht verstärkt auf solche Exploits geachtet haben.

Armaq

2019-05-16, 20:46:08

Die Forscher sagten bereits, dass Intel die Sicherheitsaspekte billigend in Kauf nahm, weil der Konsument Performance will.

Dino-Fossil

2019-05-17, 13:24:56

Phoronix hat einen kurzen Test zu den Performance-Auswirkungen der Sicherheitspatches auf Linux (noch mit SMT!).
https://www.phoronix.com/scan.php?page=news_item&px=MDS-Zombieload-Initial-Impact

Nicht ganz ohne...

Wobei man bedenken sollte, dass auch die Meltdown/Spectre Patches anfangs stärkere Auswirkungen hatten, die dann teilweise "wegoptimiert" wurden.

Unicous

2019-05-17, 16:02:48

Es haben bislang nur sehr wenige Medien über die Bestechungsversuche seitens Intel berichtet und so wie ich das sehe kein einziges deutsches Medium.

Wie erwartet.

Fusion_Power

2019-05-17, 16:19:45

Will Intel nicht eh bald sicherere CPUs raus bringen oder war das nur gequassel? :uponder: AMD hat jedenfalls wieder mal gut Lachen, hoffe deren Aktie steigt gerade.

][immy

2019-05-17, 16:48:29

Will Intel nicht eh bald sicherere CPUs raus bringen oder war das nur gequassel? :uponder: AMD hat jedenfalls wieder mal gut Lachen, hoffe deren Aktie steigt gerade.
naja, nicht wirklich. Allerdings fällt die Intel Aktie seit dem 23.4 ziemlich heftig. War aber wohl eher nur der Absturz zur Normalität und nicht das es wirklich bergab ging. Ging vorher einfach zu steil nach oben.

Interessant ist ja, das Intel das Problem in einer neuen Revision behoben hat. D.h. es dürfte dann bald Performance-Unterschiede geben, je nachdem ob man einen Core i9/7/5/3 der alten oder neuen Revision hat.
Hätte intel vielleicht noch warten sollen mit coffee lake, dann hätte man das als performance-gewinne gegenüber der 8er gen verkaufen können. :freak:
Aber das könnte man natürlich später auch in Benchermarks der Gen 10 verwenden, diese gegen die alte Gen 9 Revision zu testen. Bis die raus sind, achtet doch eh keiner mehr drauf, das es 2 Revisionen gab.

Fusion_Power

2019-05-17, 17:08:47

Na hoffentlich bekommen die dann auch ihre neuen CPUs sicher und trotzdem performant. Noch mehr Sicherheitslücken wären schlecht. Nicht dass sich ein Intel Prozessor zum Hardware Acrobat Reader entwickelt.

Achill

2019-05-17, 20:01:00

[immy;11997025']naja, nicht wirklich. Allerdings fällt die Intel Aktie seit dem 23.4 ziemlich heftig. War aber wohl eher nur der Absturz zur Normalität und nicht das es wirklich bergab ging. Ging vorher einfach zu steil nach oben.

Interessant ist ja, das Intel das Problem in einer neuen Revision behoben hat. D.h. es dürfte dann bald Performance-Unterschiede geben, je nachdem ob man einen Core i9/7/5/3 der alten oder neuen Revision hat.
Hätte intel vielleicht noch warten sollen mit coffee lake, dann hätte man das als performance-gewinne gegenüber der 8er gen verkaufen können. :freak:
Aber das könnte man natürlich später auch in Benchermarks der Gen 10 verwenden, diese gegen die alte Gen 9 Revision zu testen. Bis die raus sind, achtet doch eh keiner mehr drauf, das es 2 Revisionen gab.

Wie sieht es den mit der Vergabe von Revisionen aus? Wäre das reine verpassen eines aktuellen Microcode-Stands "ab Werk" evtl. schon eine neue Revision?

Es sind ja für das Marketing bzw. für Aktionärsversammlungen / -Mitteilungen ganz unterschiedlich Aussagen, ob man nur sagen kann: "Es gibt ein Microcode-Fix, den die Hersteller von MB/OS übernehmen / einspielen müssen." oder ob man sagen kann: "Es gibt eine neue Revision (mit den Microcode ab Werk) wo die Lücke behoben wurde." ... neue, fest installiere Firmware ist evtl. auch neue Hardware !?!? :freak: :devil:

Rooter

2019-05-18, 18:51:11

y33H@

2019-05-18, 22:04:07

Linux- oder (später vll) Windows-Update.

BlackArchon

2019-05-18, 23:14:17

Für mein olles Z68 Bord gibt es kein BIOS-Update:
https://www.asrock.com/mb/Intel/Z68%20Pro3%20Gen3/index.de.asp#BIOS

Gibt es einen anderen sicheren Weg den Mikrocode da rein zu bekommen?

MfG
Rooter
Ich habe hiermit schon viele BIOSe erfolgreich gemoddet und auch geflasht: https://www.win-raid.com/t154f16-Tool-Guide-News-quot-UEFI-BIOS-Updater-quot-UBU.html

Iscaran

2019-05-20, 11:46:49

War das schon gepostet (habe die letzten paar Seiten nicht gelesen) ?
https://www.phoronix.com/scan.php?page=article&item=mds-zombieload-mit&num=10

Wenn also alle Mitigations aktiv sind (inkl. HT) verliert ein 8700K also grob 33% Leistung (271 vs 204 punkte im global mean)

Bei AMD ergibt sich z.B. bei einem 2700X nur ein Einbruch von 3% (219 vs 213).

Im voll gepatchten Fall ist die Performance eins 2700X und 8700K als mittlerweile ziemlich gleich auf :-).

EDIT: Ich weiss Linux Benchmarks. Aber dürfte unter Windows nur leicht besser ausfallen im Endeffekt.

kruemelmonster

2019-05-20, 13:41:21

Für mein olles Z68 Bord gibt es kein BIOS-Update:
https://www.asrock.com/mb/Intel/Z68%20Pro3%20Gen3/index.de.asp#BIOS

Gibt es einen anderen sicheren Weg den Mikrocode da rein zu bekommen?

MfG
Rooter

Schreib doch ASRock direkt an, die sind da sehr hilfsbereit.
Es gibt bereits ein Bios Update für das non-Gen3 Model: https://www.asrock.com/support/index.de.asp?cat=bBIOS , dann sollten sie dir auch ein Bios für dein Board erstellen können. Dauert erfahrungsgemäß nur 2-3 Tage bis du eine Antwort bekommst.

Ansonsten mittels UBU wie BlackArchon sagte, das Tool hab ich hier auch schon einige Male empfohlen.

Birdman

2019-05-20, 15:05:52

EDIT: Ich weiss Linux Benchmarks. Aber dürfte unter Windows nur leicht besser ausfallen im Endeffekt.
Ich wüsste nicht wieso es unter Windows besser sein sollte.
Schlussendlich ist das ganze vor allem eine Frage was man misst - bei den üblichen Spieleparcours unter Windows wird der Unterschied sehr gering sein, bei Speicher und I/O intensiven Anwendungen dafür umso mehr.

Iscaran

2019-05-20, 15:07:33

Ich wüsste nicht wieso es unter Windows besser sein sollte.

Unter Windows ist es derzeit vor allem besser, weil insgesamt noch weniger Mitigations umgesetzt sind bzw. aktiv sind ;).

Pirx

2019-05-22, 07:11:27

Intel hat versucht, die UNI Amsterdam zu bestechen, um das Wissen über MDS-Sicherheitslücken zu unterdrücken:hammer:

https://www.techpowerup.com/255563/intel-tried-to-bribe-dutch-university-to-suppress-knowledge-of-mds-vulnerability

basix

2019-05-22, 07:36:45

Unterdrücken nicht, aber die Veröffentlichung um weitere 6 Monate bis November hinauszuzögern (wegen Release 10er CPU Serie?) und die Lücke milder darzustellen (um den Schaden für Intel abzuschwächen). Es wirft definitiv kein gutes Licht auf Intel.

Schnoesel

2019-05-22, 09:20:24

Das Intel das machen würde wundert mich nicht. Ein klassischer Intel dickmove eben. Dass sich die Presse in so einem Fall aber so fein zurückhält ärgert mich schon etwas. Solches Verhalten gehört angeprangert, ansonsten ändert sich bei denen nie etwas.

dildo4u

2019-05-22, 09:39:05

CB hat Haswell,Ryzen und Coffeelake mit Win 10 1903 gebencht.

https://www.computerbase.de/2019-05/windows-10-mai-2019-update-download/

unl34shed

2019-05-22, 09:47:20

Sind ja nur spiele Benchmarks, war doch abzusehen, das hier die Auswirkungen gering sind. Anwendungen wären interessanter gewesen.

N0Thing

2019-05-22, 14:06:26

Ich hätte Messungen der Ladezeiten auch interessanter gefunden, als FPS-Vergleiche.

Birdman

2019-05-22, 18:02:45

Ich hätte Messungen der Ladezeiten auch interessanter gefunden, als FPS-Vergleiche.
Da ändert sich auch nix entscheidendes, sieht man bereits anhand von Vergleichen zwischen SATA-SSD, NVMe-SSD, RAM-Disk und Konsorten.

Scorpius

2019-05-22, 18:33:19

Einerseits nervt das Verhalten von Intel aber andererseits auch diverse Seiten und Forenuser.
Nach dem Motto vonwegen die Patches und Workarounds würden einen extremen Performancehit für alle haben. Richtig spürbar ist es eher im Firmenumfeld denn bei Otto Normal User.

Achill

2019-05-22, 20:38:34

CB hat Haswell,Ryzen und Coffeelake mit Win 10 1903 gebencht.

https://www.computerbase.de/2019-05/windows-10-mai-2019-update-download/

Der Link ist hier eigentlich Falsch, weil es im Artikel nicht die Auswirkungen der Microcode-Updates geht. Dafür hätte man ein älteres Windows 10 gebraucht und sicherstellen müssen, dass einmal das Bios Microcode-Update hat und einmal nicht ...

Tarkin

2019-05-22, 21:18:49

Pirx

2019-05-22, 22:06:04

Wieso testet Intelbase sowas nicht?

Isen

2019-05-22, 23:59:05

Weil man es mit Game-Benches halt nicht zeigen kann. Ist halt eher mehr ne Gamer-Base als Computer/Anwendungen.

Complicated

2019-05-23, 05:29:55

Sie betonen doch immer Sie machen Spiele-Tests und keine CPU-Tests. Daher muss man solche Untersuchungen der CPU auch nicht erwarten bei CB. Dafür gibt es ja Hardware-Testseiten.

Razor

2019-05-23, 07:15:36

Windows 10 Security Patch Slowed Intel Core i9 9900K in Pix4D, Metashape, & RealityCapture (https://www.pugetsystems.com/labs/articles/Windows-10-Security-Patch-Slowed-Intel-Core-i9-9900K-in-Pix4D-Metashape-RealityCapture-1461/)
einfach mal so bis zu 28% Performance gekostet die letzten Patches
Wo steht denn da was von 28%?
:confused::confused::confused:

Da steht was von: zwischen 1% und 14% increase (beim Bild berechnen), was natürlich immer noch "doof" ist.

Das liegt aber nicht am Switch auf Retpoline mit diesem Update?
https://www.pcgameshardware.de/Windows-10-Software-259581/News/Update-aktiviert-Retpoline-Schutz-gegen-Spectre-V2-standardmaessig-1282370/

Habe ich selber getestet... die "Overrides" raus genommen und Retpoline ist noch immer aktiviert.
Funktioniert ja seit KB4482887, musste dort aber per RegHack aktiviert werden - schlummerte also inaktiv im System.
Nun ist es "wach" :)

Razor

Tarkin

2019-05-23, 08:06:06

hier... und weiter unten sogar 29%- hatte ich übersehen

y33H@

2019-05-23, 09:25:48

Was macht Metashape so anfällig?

dildo4u

2019-05-23, 09:33:56

Eine Sammlung an Fotos wird zu einem 3D Modell zusammen gestickt,also erzeugt das Programm vermutlich viele kleine SSD Zugriffe.

https://youtu.be/E1rirH0m1gw?t=142

Lehdro

2019-05-24, 18:39:36

Hier noch ein schöner I/O Test zur Diskperformance von Intel & AMD mit den Mitigations unter Windoof:

https://www.tomshardware.com/reviews/intel-amd-storage-test-mds-zombieload-ridl-fallout,6146.html

Intel verliert stellenweise heftig, so dass overall auf einmal AMD die Nase vorne hat.

Unicous

2019-05-24, 18:54:02

Hat inzwischen eigentlich mal ein deutsches Medium zumindest erwähnt, dass Intel versucht hat die Forscher zu bestechen?

Ich verstehe nicht warum das so schwer ist dazu einen Artikel zu schreiben und fast schon unter den Teppich gekehrt wird.:confused:

Razor

2019-05-24, 22:24:09

Weil das hier in D langsam "Normal" wird... siehe FakeNews und deren "Kontrolle" *grmpf*
Wir kuscheln halt mit America und da heißt es eben Intel: :up:, gell?

Razor

BigKid

2019-05-25, 07:21:45

Ich hab ja damals kontroverse Reaktionen ausgelöst als
ich MSI bzw. den Händler für ein Werbeversprechen in die Pflicht nehmen wollte (und es auch getan habe).
Aber was ich überhaupt noch nicht gesehen habe ist eine Diskussion der Frage ob das nun einen Sachmangel im Rahmen der Gewährleistung ist und entsprechende Rechte auf Rückabwicklung und Wandel bestehen.
Da es aus meiner Sicht ein verdeckter Mangel sein könnte eventuell sogar bei älteren Geräten/Prozessoren. Das würde vermutlich nicht einfach da zu klären wäre ab wann Intel davon wusste und somit Vorsatz bestehen könnte.
Aber wer noch innerhalb der 2 Jahre liegt sollte sich überlegen ob er reagiert...
Bis Zombieload habe ich das mehr oder minder stoisch hingenommen aber jetzt Frag ich mich ob man das als Verbraucher wirklich einfach so hinnehmen muss.

Tarkin

2019-05-25, 09:47:24

Benchmarking AMD FX vs. Intel Sandy/Ivy Bridge CPUs Following Spectre, Meltdown, L1TF, Zombieload (https://www.phoronix.com/scan.php?page=article&item=sandy-fx-zombieload)

The Intel Core i5/i7 CPUs remained ahead but the Core i5 2500K saw a 14% hit to the performance in the benchmarks ran with the default mitigations. The Core i7 2700K and i7 3770K each saw around a 14% hit to the default mitigated performance as well but that extended to 18~19% if disabling Hyper Threading in the name of security. The AMD FX CPUs saw minimal change to performance with their relevant Spectre mitigations.

Intel gehört eigentlich mit Klagen überzogen! Das ist doch bitte ein Witz!

Gibt noch mehr....

Spectre/Meltdown/L1TF/MDS Mitigation Costs On An Intel Dual Core + HT Laptop (https://www.phoronix.com/scan.php?page=news_item&px=Spec-Melt-L1TF-MDS-Laptop-Run)

If looking at the geometric mean across dozens of benchmarks ran, the default/out-of-the-box mitigations dropped the performance by 18% or 25% when disabling Hyper Threading

diese Laptops kann man dann grad in die Tonne treten

ZombieLoad Mitigation Costs For Intel Haswell Xeon, Plus Overall Mitigation Impact (https://www.phoronix.com/scan.php?page=news_item&px=Haswell-Xeon-Zombie-Load-Ref)

When looking at the current costs of all mitigations to date combined, that's a 13% hit using the same set of benchmarks carried out for the recent Xeon/EPYC comparison a few days back. If also disabling Hyper Threading, it equates to about a 19% hit.

...

Also im Schnitt so um die 15% Performance-Hit und mit HT disabled noch schlimmer logischerweise. Ja, schönen Dank auch Intel. Kommt mir schlimmer vor als Spectre/Meltdown. Mit der nächsten Lücke (die bestimmt kommt), ist dann Bulldozer vermutlich endgültig schneller als Sandy/Ivy Bridge - würde mich nicht wundern.

Einfach nur krass!! Und wo ist die deutsche Qualitätspresse!??

Für Intel wird Zen 2 zum Super Gau habe ich das Gefühl -alle Reviews jetzt natürlich mit gepatchten Systemen (und den Intel CPUs HOFFENTLICH neu getestet - und nicht einfach nur Copy-Paste von alten Reviews ohne Mitigations)

Isen

2019-05-25, 10:10:00

Da bekommt das Reifen bei AMD mit dem CMT-Konzept und das "Reifen" =verfaulen beim Kunden (Intel) eine ganz neue Bedeutung...;D;D

Razor

2019-05-25, 10:17:42

Einfach nur krass!! Und wo ist die deutsche Qualitätspresse!??
Vor allem aber... wo sind die Tests unter Windows?
Deine drei Tests wurden alle unter Linux getätigt und ich meine, in den ersten beiden sogar mit dem gleichen Notebook... abgeschrieben?
Ehrlich Leutz, wo sind die Tests auf unterschiedlichsten Plattformen und gerade unter dem meist verbreitetsten Betriebssystem auf diesem Erdesrund?

Razor

nagus

2019-05-25, 10:29:57

Möchte wissen wieviel Kohle Intel den Tech-Jorunalisten in dan Anus bläst damit die Windows Tests schön brav unterlassen.

Und dann liest man auf 3Dcenter, dass das Linux-Workstation Umgebungen sind und man das nicht auf Windows ummünzen kann. Gibts leicht keine Workstations auf Windows, oder wie? Und verschiedene Windows Versionen sind dazwischen... als ob Windows Versionen schon jemals großartige Performance-Veränderungen gebracht hätten... *lol*. Und selbst wenn.. warum nicht mit einem pre-Meltdown/Spectre Windows testen und dann die Patches aufspielen? Muss man wirklich zur letzten Windows Version greifen um alle Security-Patches zu bekommen?! Kann ich mir nicht vorstellen....

r-or

2019-05-25, 10:30:09

Warum sollte es unter Windows anders/besser sein? Zumindest mit ähnlichen Tasks? Ungeachtet dessen, dass niemand Windows für Server workloads benutzt.

Diese Resultate sind eher für professionals interessant. Die FPS von counter strike bleiben dieselben, weshalb man auf pcgh nichts davon liest.

Lehdro

2019-05-25, 11:17:47

Diese Resultate sind eher für professionals interessant. Die FPS von counter strike bleiben dieselben, weshalb man auf pcgh nichts davon liest.
Ich glaube für den durschnittlichen Gamer ist es schon interessant wenn sich die Ladezeit auf Intel im Gegensatz zu AMD messbar verschlechtert:

https://img.purch.com/image011-png/o/aHR0cDovL21lZGlhLmJlc3RvZm1pY3JvLmNvbS84L1cvODM4ODMyL29yaWdpbmFsL2ltYWdlMDExLnBu Zw==

Damit wird auch die eigene Investition in eine SSD noch entwertet, etwas was sonst als Garant für schnelle Ladezeiten galt. Möchte nicht wissen was passiert wenn man ein Spiel wählt was für nochmals deutlich längere Ladezeiten bekannt ist (lategame 4X Spiel zum Beispiel).

aufkrawall

2019-05-25, 12:52:05

y33H@

2019-05-25, 13:16:21

Alle Reviews jetzt natürlich mit gepatchten Systemen (und den Intel CPUs HOFFENTLICH neu getestet - und nicht einfach nur Copy-Paste von alten Reviews ohne Mitigations)Generell sollte man immer den aktuellen Firmware/Software-Stand berücksichtigen, finde ich. Werde für Matisse daher auch mit Windows v1905 und allen Patches testen und hoffe, ich schaffe es, neben dem 9900K mit P0-Stepping auch einen im neuen R0-Stepping mit in den Benches zu haben.

Ich glaube für den durchschnittlichen Gamer ist es schon interessant wenn sich die Ladezeit auf Intel im Gegensatz zu AMD messbar verschlechtert.Das müsste man sich im Detail anschauen, wie lange welches Spiel auf welcher CPU (und mit welcher SSD) lädt ... andererseits macht man das idR nur 1x, denn ingame ein Savegame zu laden, geht viel flotter weil halt schon alles im RAM ist.

BigKid

2019-05-25, 13:18:53

Nur weil ständig neue Lücken auftauchen, hat sich dadurch noch nicht etwas am Bedrohungsszenario geändert. Gibt es nach 1,5 Jahren irgendeinen Bericht von Malware-Attacken in the wild, die Enduser geschadet hätten?
Wenn nein, warum soll ich für den Quatsch auch nur 1% Leistung opfern, wenn ich es auch einfach ausschalten kann?
Oehm... Google?
zB
https://www.msspalert.com/cybersecurity-news/meltdown-spectre-vulnerability-malware-fortinet-report/
Abgesehen davon: Wo beginnt bei dir der Schaden? Offensichtlich noch nicht bei „nur“ ausgespähten Passwörtern... Diese Lücken eignen sich halt vermutlich mehr für Spyware als für Erpressungstrojaner...

aufkrawall

2019-05-25, 13:27:20

Ich seh da keinen Nachweis für geglückte Angriffe.

Lehdro

2019-05-25, 13:31:31

Das müsste man sich im Detail anschauen, wie lange welches Spiel auf welcher CPU (und mit welcher SSD) lädt ... andererseits macht man das idR nur 1x, denn ingame ein Savegame zu laden, geht viel flotter weil halt schon alles im RAM ist.
Ich spiele derzeit viel TW:WH2, dort muss man für jedes Battle innerhalb des Spieles laden (von global map -> battle map), das sind im lategame locker mal 2-3 Battles pro Zug, da stellt sich nun die Frage: Beeinflussen die Mitigations das Laden in dem Spiel stark? Keine Ahnung, habe AMD und keine Vergleichswerte. Aber wirklich flott ist das Laden der Gefechte sowieso nicht, jedes bisschen extra ist dann schon nervig. Könnte man sich mal anschauen...

DrMabuse1963

2019-05-25, 13:51:18

Sind denn nur Ladezeiten betroffen?Ich spiele seit ein paar Wochen The Witcher 3,meine CPU ist auf 8x4,5 GHz getaktet,bisher hatte ich InGame max 90% Load auf einem Kern(kurzzeitig),neuerdings sehe ich des öfteren kurz die 100 %.Könnte aber auch daran liegen das ich die letzte zeit Blod and Whine in der Goty zocke,habe kein Plan ob im DLC die Anforderungen gestiegen sind.Ne Möglichkeit die Patches zu deaktivieren gibt es nicht ? MfG

Edit:Ruckler habe ich jetzt auch bei 60FPS manchmal,schaue dann schnell auf den LCD der Tasta wobei ich da seltsamer Weise nicht die 100%Load sehe...
Hatte aber auch vor ~5 Tagen nen Bios Update gemacht das mit den Einstellungen wie ich sie vorher hatte nicht stabil war,hatte dann CPU und Memory V minimal erhöht.

aufkrawall

2019-05-25, 14:08:23

Witcher 3 kompiliert Shader erst während des Spielens, verursacht Ruckler und 100% Auslastung auf einem Thread.

DrMabuse1963

2019-05-25, 14:20:14

Habs vorher aber nie gesehen das 100% Load war,Ruckler hatte ich keine,kann aber auch wie geschrieben am DLC liegen.MfG

y33H@

2019-05-25, 14:27:44

Möchte wissen wieviel Kohle Intel den Tech-Jorunalisten in den Anus bläst damit die Windows Tests schön brav unterlassen.was sollen so beleidigende dumme Kommentare bewirken? ist das deine Art von Motivation? danke, hilft bestimmt.

Ich spiele derzeit viel TW:WH2, dort muss man für jedes Battle innerhalb des Spieles laden (von global map -> battle map), das sind im lategame locker mal 2-3 Battles pro Zug, da stellt sich nun die Frage: Beeinflussen die Mitigations das Laden in dem Spiel stark? Cooles Beispiel, ich hab eh TWTK in den Benches drin, vll komme ich dazu zumindest AMD vs Intel zu testen.

aufkrawall

2019-05-25, 14:29:01

Habs vorher aber nie gesehen das 100% Load war,Ruckler hatte ich keine,kann aber auch wie geschrieben am DLC liegen.MfG
Das Spiel hatte schon immer geruckelt, so lange der Shader Cache nicht gefüllt war. Nach jedem Treiber-Update muss es sich erst wieder "einlaufen".
Dass OS/Treiber/Mitigations allgemein noch weiteres Ruckeln verursachen können, ist natürlich nicht ausgeschlossen. Spiele mit so einem technischen Makel wie oben beschrieben eignen sich aber halt schlecht dafür, das zuzuordnen.

BigKid

2019-05-25, 15:53:27

Ich seh da keinen Nachweis für geglückte Angriffe.
Welche Form von Selbstbetrug ist es denn bei dir?
Es gibt funktionierende POCs für die Exploits - es gibt nachweislich Malware da draussen die die Prinzipien nutzt... Kopf in den Sand hilft nicht... nicht mehr surfen auf der Daddelkiste - das wäre das einzige.. Wartest du jetzt auf etwas Wannacry bevor dus glaubst?
Lass mal raten - du verteidigst auch VW - und hältst alle Regressforderungen für Unsinn - oder ?

Birdman

2019-05-25, 16:01:01

Welche Form von Selbstbetrug ist es denn bei dir?
Es gibt funktionierende POCs für die Exploits - es gibt nachweislich Malware da draussen die die Prinzipien nutzt... Kopf in den Sand hilft nicht... nicht mehr surfen auf der Daddelkiste - das wäre das einzige.. Wartest du jetzt auf etwas Wannacry bevor dus glaubst?
Du hast offensichtlich recht wenig Ahung davon wie die ganzen Spectre "Sicherheitslücken" funktionieren und was die Bedrohungsszenarien sind.
Ich vermute dass dein Rechner mit aktiver Mitigation einem grösseres Risiko für irgendwelchen Malware Befalll ausgesetzt ist, als derjenige von Aufkrawall mit deaktiviertem Meltdown/Spectre Schutz.

BigKid

2019-05-25, 16:13:06

Du hast offensichtlich recht wenig Ahung davon wie die ganzen Spectre "Sicherheitslücken" funktionieren und was die Bedrohungsszenarien sind.
Ich vermute dass dein Rechner mit aktiver Mitigation einem grösseres Risiko für irgendwelchen Malware Befalll ausgesetzt ist, als derjenige von Aufkrawall mit deaktiviertem Meltdown/Spectre Schutz.
Jede Katastrophe beruht auf einer Vermutung...
Diese Sicherheitslücken ermöglichen es Daten eines fremden Tasks auszuspähen... und das selbst aus einer Sandbox oder VM heraus.
Das ist für Cloud Anbieter eine Katastrophe und für jeden Endverbraucher ein Risiko... Ich wundere mich immer wieder wie hier Leute ankommen und Hersteller verteidigen als würde ihr Leben davon abhängen und lieber Anfangen andere User anzugehen...
Wer hier nicht zumindest ein Risiko sieht oder glaubt nur weil es anscheinend(!) nur POCs gibt würde das noch nicht ausgenutzt sieht glaubt auch an den Weihnachstmann... Es ist meines Erachtens nach nur eine Frage der Zeit bis das Zeug im Baukasten für ambitionierte Script-Kiddies auftaucht...
Ja Brain 1.0 ist immernoch der beste Schutz - aber manchmal ist man Müde, Abgelenkt und der „Angriff“ raffiniert - und dann fehlt halt „nur noch“ eine ungepatchte Lücke - so einfach ist das...
Nach deiner Argumentation bräuchte es auch kein ABS - muss ja jeder nur vernünftig fahren...
Und VW ist auch von jeder Schuld freizusprechen denn die Abschaltvorrichtung selbst ist noch nicht direkt in freier Wildbahn beim verursachen eines echten Schadens gesehen worden ;)
Aber hey - Danke für die Sorge um meinen Rechner...
Hinweis: Ich habe schon viele Jahre mehrere Rechner im Einsatz und hatte bisher noch keine Probleme mit Malware/Viren.

aufkrawall

2019-05-25, 16:28:35

Diese Sicherheitslücken ermöglichen es Daten eines fremden Tasks auszuspähen... und das selbst aus einer Sandbox oder VM heraus.

Unter bestimmten Umständen. Deswegen wär es anstatt des Schwalls an Polemik interessanter, von dir mal eine Erörterung zu bekommen, wie der Angriff denn konkret ablaufen würde, und wie wahrscheinlich es ist, dass dies eine reale Gefahr wäre...

BigKid

2019-05-25, 16:36:49

Unter bestimmten Umständen. Deswegen wär es anstatt des Schwalls an Polemik interessanter, von dir mal eine Erörterung zu bekommen, wie der Angriff denn konkret ablaufen würde, und wie wahrscheinlich es ist, dass dies eine reale Gefahr wäre...
Ich werd dir nicht den Erklärbär machen nur damit du mich dann wegen Vereinfachungen oder Formulierungen angehen kannst... Drehen wir den Spiess doch mal um: Finde jemanden der das Risiko eines Exploits für nicht existent hält... Nichtmal Intel tut das - sonst würden sie ganz anders agieren.
Ich halte es Aufgrund von dem was ich gelesen habe und auch Aufgrund der Reaktionen von Intel und anderen für ein reales Risiko - du hältst es für sehr Unwahrscheinlich und das Risiko für Überschaubar... Ist es bei Atomkraftwerken auch - trotzdem sind schon 2 hochgegangen...
Aber am Ende: Es gibt Lücken, Intel und Softwarehersteller zusammem können diese nur unter Leistungsverlusten schliessen. Und die neuste wohl gar nicht mehr. Das ist für mich ein Mangel! Also rate ich jedem der noch in der 2 Jahres Frist für Gewährleistung sich zu überlegen ob er nicht mal seinen Händler anschreibt und die Verhandlungen aufnimmt... das hat aufschiebende Wirkung...
Und selbst an deiner Stelle: Allein der Ärger die Patches runter zu bekommen um wieder die gekaufte Leistung zu belommen wäre für mich schon ein Grund...

Razor

2019-05-25, 16:42:06

Damit wird auch die eigene Investition in eine SSD noch entwertet, etwas was sonst als Garant für schnelle Ladezeiten galt. Möchte nicht wissen was passiert wenn man ein Spiel wählt was für nochmals deutlich längere Ladezeiten bekannt ist (lategame 4X Spiel zum Beispiel).
Öhm... und Du glaubst wirklich, dass Du den Unterschied überhaupt merkst?
Klar, für die "Benchies" unter uns mag das ein Problem darstellen, aber ich z.Bsp. merke keinen Unterschied zwischen 39,7 und 37,4 Sekunden.
Selbst prozentual gesehen beläuft sich der Unterschied auf gerade mal 5,8%... wovon ein Großteil auf die ohnehin vorhandenen Patches entfällt.

Möchte wissen wieviel Kohle Intel den Tech-Jorunalisten in dan Anus bläst damit die Windows Tests schön brav unterlassen.
Na ja... hoffen wir mal, dass da nichts Wahres dran ist.

Es gibt funktionierende POCs für die Exploits - es gibt nachweislich Malware da draussen die die Prinzipien nutzt... Kopf in den Sand hilft nicht... nicht mehr surfen auf der Daddelkiste - das wäre das einzige.. Wartest du jetzt auf etwas Wannacry bevor dus glaubst?
Ich vermute, dass Du nicht ganz aufgepasst hast, was damit eigentlich möglich ist.
Mitlesen ja, verändern nein - that's it.

Und "ausspioniert" werden wir an allen Ecken und Enden, also was solls?
Aber klar, ich bin auch der Meinung, dass man das tun sollte, was möglich oder ggf. auch nötig ist... nichts zu tun, ist einfach nur dumm.

Das ist für Cloud Anbieter eine Katastrophe und für jeden Endverbraucher ein Risiko...
Und das ist der Punkt... für Rechenzentren-Betreiber ein echtes Problem, weil hier schon 3% Performance-Verlust ein wirtschaftlicher Schaden ist.
Aber ein Rechner zuhause? Der sowieso ganz anderen "Bedrohungen" ausgesetzt ist und zudem dem - meist dummen - Nutzer.

Office-Anwendungen sind kein Problem... Performance statt.
Spiele schon eher, nur sehe ich "Ladezeiten" in diesem Umfang nun nicht wirklich als großes Problem.

Got it?

Razor

aufkrawall

2019-05-25, 16:42:36

@BigKid: Und, schon HTT abgeschaltet? :rolleyes:

Lehdro

2019-05-25, 17:33:39

Öhm... und Du glaubst wirklich, dass Du den Unterschied überhaupt merkst?
"Merken" ist das falsche Wort. Es "merkt" ja auch keiner zb 5,8% "mehr" FPS, trotzdem ist dieses dann objektiv das bessere Produkt (sofern keine anderen Unterschiede auftreten).

Klar, für die "Benchies" unter uns mag das ein Problem darstellen, aber ich z.Bsp. merke keinen Unterschied zwischen 39,7 und 37,4 Sekunden.
Trotzdem, bei meinem skizzierten Szenario wird dich das real treffen, ob du das nun merkst oder nicht. Jedes mal 2 Sekunden, lass es mehr sein in anderen Spielen oder weniger. Kleinvieh macht auch Mist.
Das ist deine reale Zeit die dir dann flöten geht, was dann eventuell mit anderen Anbietern nicht passiert. Ich meine ich kann mir viel kaufen aber eins nicht: Zeit. Vorallem wenn ich vorher diese Zeit nicht aufwenden musste ist das doppelt ärgerlich. Das hört ja nicht beim Gaming auf, bei Anwendungen kann das durchaus auch reinhauen.

Selbst prozentual gesehen beläuft sich der Unterschied auf gerade mal 5,8%...

So vergleicht man nunmal unterschiedliche Anbieter, anhand von Unterschieden. Wenn bisher aufgrund geringer Unterschiede Kaufempfehlungen ausgesprochen wurden, die jetzt wegfallen würden, so ist das doch relevant? Verstehe nicht warum dem jetzt die Validität abgesprochen wird von dir.

BigKid

2019-05-25, 17:50:15

@razor: Ich habe nix von verändern gesagt... im Gegenteil ich sagte dass sich die Lücken eher zum Spionieren als für Malware nutzen lassen... Egal... haut nur weiter auf mich anstatt auf Intel... Wenns euch dann besser geht... Ich halte das in Zeiten von Internetbanking, Shopping und im Rahmen von Identitätsdiebstahl für ein gross genuges Risko... Wer das Passwort zu deinem Mail Account und deine Haupt eMail Adresse hat, hat dich ganz schön bei den Eiern...

@aufkrawall: Nein - aber heute um Wandlung in 2 Fällen im Rahmen der Gewährleistung / Mängelhafting gebeten... Schon länger AMD Aktien gekauft - mich über mehr als 50%+ gefreut und werde wohl beim nächsten Kauf auf AMD setzen... Abgesehen davon hat mich als altem Intel Käufer das Ryzen System von der Restrampe (gebrauchte Teile aus dem Forum + Soda Teile von mir) bisher nur positiv überrascht... Steht am „Wochendwohnsitz“ (nein ich habs nichz zu dick sondern ne Wochenendbeziehung...)

DrMabuse1963

2019-05-25, 18:33:02

Das Spiel hatte schon immer geruckelt, so lange der Shader Cache nicht gefüllt war. Nach jedem Treiber-Update muss es sich erst wieder "einlaufen".
Dass OS/Treiber/Mitigations allgemein noch weiteres Ruckeln verursachen können, ist natürlich nicht ausgeschlossen. Spiele mit so einem technischen Makel wie oben beschrieben eignen sich aber halt schlecht dafür, das zuzuordnen.
Seit ich das Game hab zocke ich nichts anderes,werde mal CoD WW2 testen da ich da die "alte" CPU Load noch einigermaßen weiß.Allerdings wenn es wirklich nur um ladezeiten geht kann ich mich halbwegs damit abfinden,wobei ich trotzdem hoffe das da was besseres gefunden wird,dafür hab ich nu die 970 Evo nicht angeschaft damit se gleich wieder kastriert wird...MfG und Danke

Razor

2019-05-26, 07:22:30

BigKid

2019-05-26, 07:28:51

@Lehdro: sorry, aber dermaßen viel Unsinn musste ich selten lesen... Du willst wirklich über die Zeit philosophieren? :confused:
Und was hast Du mit "Anbietern"? Worauf willst Du hinaus?

@BigKid: Du hast den Vergleich mit WannaCry gezogen... und das ist eben ein ganz anderes Kaliber und hat mit dieser Geschichte nichts zu tun.
Und klar, Identitätsdiebstahl ist doof - kann aber auf sehr viel einfachere Wege geschehen, als jetzt CPU-Fehler auszunutzen.

Razor
WannaCry nannte ich wegen des Ausmasses und das es das wohl braucht bis manche hier das Risiko als Real ansehen... Unabhängig davon hat man selbst dann Scherereien wenn man das Risiko nicht sieht und einfach nur wieder 100% Performance haben will... Die Frage ist nämlich berechtigt ob man das so einfach hinbekommt...
EDIT: Übrigens die hier von Manchen immer wieder ins Feld geführte Existenz von alternativen Möglichkeiten zum Ausspähen sind reiner WhatAboutism und irrelevant. Natürlich gibt es immer wieder Menschen die aus Dummheit, Gier oder schlicht in einem schwachen Moment auf einen falschen Link klicken oder eine Exe starten, die sie lieber nicht gestartet hätten. Das hat aber null und garnix mit den hardwaremässigen Sicherheitslücken zu tun um die es hier geht. Wie ich bereits sagte: Mit der Argumentation kann man sich alle Anstrengungen gleich sparen... Das ist einfach falsch und ne reine Nebelkerze... Sorry...
EDIT2: Im Prinzip bist du sogar davon betroffen, wenn du gar keine Intel CPU hast nur weil du Systeme nutzt, die eine haben... Angrifsszenario: Rausbekommen welchen Cloud-Dienstleister ein bestimmer Dienst nutzt, dort auch (Virtuelle) Server mieten, auf diese Schadsoftware drauf und mit etwas Geduld (und Glück ?) dann deine eMail, Login und PW ausspähen... Und wieviele Menschen nutzen ihre Passwörter öfter und man hat damit dann zugriff auf Ihre eMail Accounts ? Ja klar - die haben auch einen Fehler gemacht indem sie das PW öfter nutzen... Trotzdem bleibt das Szenario...
Der Mangel ist die Existenz der Sicherheitslücken, das zerrüttete Vertrauen in das eigene System weil über einen langen Zeitraum immer wieder neue Auftauchen und die letzte sich nur unter Abschalten eines zugesicherten Features (HT) beheben lässt - mit den Performance-Einbussen solltest du nicht argumentieren wenn du um Wandel bittest...

Lehdro

2019-05-26, 10:12:10

@Lehdro: sorry, aber dermaßen viel Unsinn musste ich selten lesen... Du willst wirklich über die Zeit philosophieren? :confused:

Bei dir scheint es ja dann gewaltig am Leseverständnis zu hapern. Alle Fragen sich immer was der ganze Mitigationskram denn eigentlich für Auswirkungen hat und wenn dann mal eine präsentiert wird die jeden trifft, wenn auch zugegebenermaßen nur minimal, so ist dies gleich wieder komplett irrelevant - was soll das? Das kann doch dann jeder für sich entscheiden - du bist nicht die Größe an der die Relevanz gemessen wird. Sieh es so: Es ist zumindest objektiv ein klarer Nachteil der gemessen werden kann, was dem schon eine Relevanz zuordnet. Vorallem wenn man einen Leistungsverlust feststellt, was niemals im Sinne des Kunden sein kann - "Intel" nimmt dir durch ihr Eigenversagen etwas weg für dass du bezahlt hast und das du ggf. jahrelang nutzen konntest. Sowas sollte immer relevant sein auf einem Markt in dem dieser Fakt hauptsächlich auf einen Anbieter zutrifft.

Und was hast Du mit "Anbietern"? Worauf willst Du hinaus?

Ist das so schwer? AMD hat derzeit keinen Leistungsverlust in dieser Höhe in diesem Szenario zu beklagen - Intel schon. Reicht dir das oder muss ich es noch weiter runterbrechen?