Test Meltdown & Spectre: Benchmarks mit AMD und Intel unter Windows 7 und 10

[Anon-525334]

Naja er winiger grundsätzlich klar nix ist hundertprozentig sicher dass muss klar sein ich weiß es sehr gut.

Ich verstehe nur Bahnhof

 

[vander]

Ich finde man sollte ARMA III - bei aller Liebe zum Spiel- nicht als Benchmark benutzten, da das Spiel durch seine schlecht optimierte Engine oftmals nicht aussagekräftig bzgl. Leistungsunterschieden ist.
Die Hardware wird bei mir meist nicht mehr als 45-65 % bei der Ausführung belastet, die meisten CPU Kerne dümpeln vor sich hin.

Ich war immer der Meinung das die Arma Reihe ein CPU Fresser ist und gerade deshalb auf AMD nicht besonders gut läuft.

Die benutzen die gleichen CPUs, also haben auch die gleichen Probleme.

Naja, da diverse Einfallsvektoren auf isolierten Systemen wegfallen hält sich das ganze in Grenzen.
Da ist die Whatsapp/Facebook Familie mit nicht administrierten Email Account deutlich größeren Risiken ausgesetzt.

jetzt wollen die wohl den Microcode per Windows-update verteilen, kann man das dann verhindern?

Ja, wenn es den sein muss. Oder nach der Installation die Dlls umbenennen, soll auch funktionieren.
Risiko liegt bei dir.

Entscheidend ist wo sich die aktuellere Version befindet.

D.h. nach einem Update (z.B. BIOS) kann das OS direkt das nächste drüber bügeln? Wundert mich eigentlich das es dafür keine Sperrmöglichkeit gibt. So wie bei der 'ATA Passwort setzen/verriegeln' Funktion.

 

[yummycandy]

Naja, da diverse Einfallsvektoren auf isolierten Systemen wegfallen hält sich das ganze in Grenzen.
Da ist die Whatsapp/Facebook Familie mit nicht administrierten Email Account deutlich größeren Risiken ausgesetzt.
Funktion.

Das eine besondere Sicherheit in diesem Bereich herrscht, ist mir klar. Ich denke aber, die Frage zielte auf die eingesetzte Hardware ab. Und die ist natürlich die gleiche, wie im zivilen Bereich.

 

[aldaric]

Ich war immer der Meinung das die Arma Reihe ein CPU Fresser ist und gerade deshalb auf AMD nicht besonders gut läuft.

Arma 3 läuft auf Ryzen nicht merklich schlechter als auf Intel. Bohemia wollte eigentlich die Engine nach dem Ryzen Release noch anpassen für Ryzen. (ist das bisher geschehen?)

Aber ein CPU Fresser ist das nur bedingt, da Arma mit seiner URALT Engine nur einen Kern wirklich "fressen" kann. Und bei Arma3 spielen soviele andere Faktoren in die Performance mit rein...als Benchmark einfach ungeeignet.

 

[Iscaran]

Hier gibt es eine schöne Übersicht welche Exploits bislang auf welchen CPUS "erfolgreich" gestestet worden sind:
https://github.com/marcan/speculation-bugs/blob/master/README.md

PoCs

[Mispredict] = Spectre1 (hiervon gibt es effektiv unzählige denkbare Varianten
[BTI] = Spectre2
[PRIV-LOAD] = Meltdown


[MISPREDICT] Google Project Zero: basic same-process PoC
Platforms:
Intel Haswell Xeon
AMD FX CPU
AMD PRO CPU
ARM Cortex A57

[MISPREDICT] Google Project Zero: arbitrary kernel reads with eBPF JIT
Platforms:
Intel Haswell Xeon CPU
AMD PRO CPU

A process running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range in kernel virtual memory.
This is an interpreter/JIT attack in the kernel. On Haswell, it works in both JIT and interpreter mode, as the speculation seems to be deep enough to reach even in interpreter mode. On AMD, JIT is required.

Mitigation: AMD: disable eBPF JIT (net.core.bpf_jit_enable sysctl). Intel: disable BPF entirely?

[BTI] Google Project Zero: HV guest root process can read host physical memory

Platforms:
Intel Haswell Xeon CPU

A process running with root privileges inside a KVM guest created using virt-manager, with a specific (now outdated) version of Debian's distro kernel running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization.

Mitigation: None yet. Kernel/compiler patches in the works.
---------------------------------
=> Hier setzen die Benchmarks von Phoronix weiter unten an !
---------------------------------
[PRIV-LOAD] Google Project Zero: Partial kernel memory read from userspace

Platforms:
Intel Haswell Xeon CPU

A process running with normal user privileges can read kernel memory under some precondition, presumed to be that the targeted kernel memory is present in the L1D cache.

Mitigation: KPTI

Performance impact von KPTI:
https://lwn.net/Articles/742702/

The answer here is kernel page-table isolation, making the kernel-space data completely invisible to user space so that it cannot be used in speculative execution. This is the only one of the three issues that is addressed by page-table isolation; it alone imposes a performance cost of 5-30% or so. Intel and ARM processors seem to be vulnerable to this issue; AMD processors evidently are not.

----------------------------------------------------------------------------------------------
So oder so wird es interessant werden die vermutlich teils sehr unterschiedlich ausfallende Performance Impacts der Spectre Mitigations zu betrachten.

Erste Hinweise auf "optimierte" Spectre 2 Patches und deren Performance Auswirkungen:
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Retpoline-Linux-4.15-FX-Zen

Hier tut sich nicht allzuviel scheinbar mit verschiedenen AMD-Setups. Einzig der Threadripper hat hier ein starken Impact. Ich vermute mal dass hier irgendetwas am Patch noch nicht richtig ist...denn Ryzen und Epyc sehen komplett anders aus und Threadripper ist "fast" baugleich mit Epyc (bis auf die 2 deaktiverten/Dummy CPUs im Sockel).

Mehr infos über die Details wie diese optimierten Mitigations arbeiten gibt es hier:
https://medium.com/@mattklein123/meltdown-spectre-explained-6bc8634cc0c2
aber auch hier (Stichwort Retpoline):
https://github.com/marcan/speculation-bugs/blob/master/README.md#pocs

Requires recompiling all affected software (not just the kernel, but all of userspace) for full mitigation. This is microarchitecture-specific and thus not necessarily applicable to all CPUs. Kernel implementation will likely enable it only when a vulnerable CPU is detected. In fact, it's insufficient on Skylake and newer CPUs, where even ret may predict from the indirect branch predictor as a fallback; those need IBRS.

Dummerweise siehts für die neuere CPUs ab Skylake hier schlecht aus - da sie offenbar eine Architekturielle Änderung haben die die Retpolines umgehen kann so das man zusätzlich IBRS-Mitigation aktivieren muss. Was relative viel Performance kosten dürfte.
Siehe hier auch ein bisschen weiter unterhalb: https://github.com/marcan/speculation-bugs/blob/master/README.md

IBRS patches
Support for Intel's architectural mitigation in lieu of retpolines. Required on Skylake and newer, where even retpolines may be vulnerable. Requires microcode update on current CPUs. Perf hit vs. retpolines on older CPUs.

Möglicher Performance Hit wegen der Verwendung der IBRS Mitigation laut https://medium.com/@mattklein123/meltdown-spectre-explained-6bc8634cc0c2

The cost of IBRS also appears to vary extremely widely between CPU architectures with newer Intel Skylake processors being relatively cheap compared to older processors. At Lyft, we saw an approximately 20% slowdown on certain system call heavy workloads on AWS C4 instances when the mitigations were rolled out.

Und als Nebenaspekt hat Matt Klein auch noch ein paar Gedanken zu Meltdown:

Now, you might be wondering: “You said that page tables have permission bits. How can it be that user mode code was able to speculatively access kernel memory?” The reason is this is a bug in Intel processors. In my opinion, there is no good reason, performance or otherwise, for this to be possible. Recall that all virtual memory access must occur through the TLB. It is easily possible during speculative execution to check that a cached mapping has permissions compatible with the current running privilege level.

Das Windows Update KB4056892 besteht aus 2 Teilen einem KPTI analogen Patch und dem IBRS Spectre Patch (letzterer Teil sorgte für die Probleme bei manchen AMD/Intel CPUs:

[PRIV-LOAD + BTI] Windows: KB4056892 (OS Build 16299.192)
Presumably does roughly the same thing as KPTI. Also contains IBRS support.

Bin also wirklich gespannt auf die weiteren Benchmarks in der Sache - das kann ja nochmal lustig werden wenn die Auswirkungen so derart CPU-Typ abhängig ausfallen !

 

[Siegfriedphirit]

Müsste Intel nicht für die nun entstandenen Schäden haften? Hoffentlich finden sich genügend Leute die klagen. Ein Autohersteller muss doch auch für Schäden haften auch wenn dafür Zulieferer verantwortlich sind und kostenfrei nachbessern bzw durch neue und fehlerfreie Teile nachbessern.

 

[Iscaran]

Dieser Poster hier beschreibt eine Interessante Idee die sich meines erachtens nach mit dem Ars-Technica Artikel zur "Resistenz" der AMD Architekturen vs. Spectre 2 deckt:
https://lwn.net/Articles/742904/
"To be vulnerable to branch predictor abuse, you need to be able to train the predictor. If you (correctly) index your predictor using all of the bits of the VA, as opposed to the low order bits, you remove the most obvious route of attack."

Wenn ich das richtig übersetzte sagt er dass man den predictor nicht (effektiv) trainieren kann wenn man vollständige Adresspräzision verwendet ?

Weiter schreibt er dann:https://lwn.net/Articles/743093/
"Nah, it's VA+ASID/PCID. It's actually very simple to have a branch predictor that is safe against variant 2. You just need to have your index completely disambiguate against other live contexts. The only problem with this is it's more bits to compare, but as compared to not having any branch prediction within one of the contexts, or flushing the predictor."

Und weiter https://lwn.net/Articles/742968/
"Indeed, but as I said elsewhere in the thread, you can mitigate branch predictor abuse if you correctly index your predictor based upon the full address space (including ASID/PCID/etc.). The hardware fix for variant 2 isn't actually as bad as people claim."

Übrigens seine Qualifikation beschreibt er so: https://lwn.net/Articles/743094/
"I co-lead the mitigation team within Red Hat for some time on this issue."

Bezugnehmend auf den Ars-Technica Artikel: https://arstechnica.com/gadgets/201...e-and-meltdown-patches-will-hurt-performance/
"Zen's branch predictor, however, is a bit different. AMD says that its predictor always uses the full address of the branch; there's no flattening of multiple branch addresses onto one entry in the BTB. This means that the branch predictor can only be trained by using the victim's real branch address."

Haben wir also schon 2 Quellen (+ AMD selbst) die technisch versierter sind und erklären warum AMD sich hier "relativ" sicher fühlt bzw. fühlen kann.
Man kann auf AMD-Systemen den Branch Predictor eben nur sehr eingeschränkt bzw. gar nicht trainieren - weshalb ein Spectre 2 Exploit viel schwerer umzusetzen ist.
Möglich - wahrscheinlich - aber bei Intel ist es eben so "leicht" den Predictor zu trainen weil die Sprungvorhersagen jeweils riesige Adressbereiche zulassen (wegen der unvollständigen Adresslokalisation (dem sogenannten "flattening") bei Intel (aus dem Ars-Technica Artikel):

"Instead, just like the processor's cache, they have some mapping from memory addresses to slots in the BTB. Intel's Ivy Bridge and Haswell chips, for example, are measured at storing information about 4,096 branches, with each branch address mapping to one of four possible locations in the BTB."

Bei AMD wird immer 1:1 gemapped (siehe lwn.net) - da der Exploit genau darauf basiert diese Mapping imprecision auszunutzen um eine misprediction zu mappen um dort dann einen branch zu injizieren ist es halt auf AMD wohl schwierig mispredictions für die injektion zu erhalten.Dazu kommt vermutlich noch der Privilege Check für Spekulative Befehle den AMD CPUs machen, der gegen Meltdown schützt. AMD CPUs führen spekulativ deshalb keine Befehle aus die nicht den Privilegien des Prozessess der gerade ausgeführt wird entsprechen. Dieser Check wird bei AMD vor bzw. während dem Adresssprung ausgeführt. Hat die Zieladresse ein anderes Privileg wird die Speculative Execution nicht ausgeführt und die ganze Branch wird angehalten.

Daher kann es auch gut sein dass der Performance-Impact mit Spectre 2 Mitigation @AMD niedriger ausfällt.
Mal sehen was die Benches zeigen...

 

[Benji18]

@Iscaran

AMDs Aussage dazu war doch das Sie ein Microcode Update rausbringen das keine Messbaren Performance verlust bringen wird, ich denke einmal das man die Hürde die man für Spectre 2 ee schon hat einfach noch etwas anhebt.

 

[Iscaran]

@Benji:

Ja. AMD hat angekündigt ebenfalls microcode updates rauzubringen (gegen Spectre 2). Auf Linux Basis laufen dazu auch schon tests und Benchmarks auf Phoronix.

Nichts genaues über die Änderungen hab ich aber noch nirgends lesen können. Ich vermute dass man mit kleinen Änderungen am Branch Predictor bzw.an der Privileg-Prüfung für Spekulative Ausführung ansetzt und da noch ein paar kleinere Hürden ein bauen kann (Stichwort IBRS und Co.)
Diese "Features" bewirken ja dass man bestimmte Prüfungen vornimmt bzw. bestimmte Befehlsmuster von Speculativer Ausführung ausnimmt) und dann ggf. Speculative Execution verwirft bevor sie ausgeführt wird.

So oder so in den Phoronix-Tests sind die bisherigen Leistungsverluste @Spectre 2 eher überschaubar (für AMD):
https://www.phoronix.com/scan.php?page=news_item&px=AMD-Retpoline-Linux-4.15-FX-Zen
"With the latest Linux 4.15 kernel there is not only the original Retpoline code but also an AMD-specific minimal thunk that is optimized for AMD's processor and should perform better for this Sepctre Variant Two mitigation."

Nur auf Threadripper scheint hier noch ein Bug vorzuliegen....da es eigentlich keinen Grund gibt warum TR so deutlich in einem der Benchmarks von Epyc bzw. Ryzen abweichen sollte.
Witzigerweise gewinnt Ryzen hier beim IO Test sogar Performance mit dem Patch - da sieht man mal was so ein wenig optimierung im Compiler manchmal für sonst eher vernachlässigte Architekturen bringen kann.
Redis ist evtl. das markanteste da "real-world" benchmark.
Sieht so ca nach ~0% Verlust aus@Zen. -10% @TR und -5%@Epyc. Wobei unklar ist wie groß hier evtl. Benchmarkschwankungen sind.

Für Intel gibt es hier auch schon erste Tests und zwar betreffs des Problems dass die einfache IBRS-Lösung bei den neueren Architekturen ab Skylake nicht mehr ausreichen schützt, weshalb man den Retpoline_Underflow noch nachschiebt:
https://www.phoronix.com/scan.php?page=news_item&px=Retpoline-Underflow-Benchmarks
"Beyond the Retpoline support already found in the mainline Linux kernel, developers are working on Retpoline Underflow support that would be used for Intel Skylake and Kabylake CPUs. RETPOLINE_UNDERFLOW protects against falling back to a potentially poisoned indirect branch predictor when a return buffer underflows and this additional protection is needed for Intel Skylake/Kabylake processors."
sieht so nach 1-20% Einbruch aus (in Redis).

 

[Bolko]

Durch das Update KB4056897 ist die GPU-3D-DX10-Leistung deutlich gestiegen (die DX9-Leistung ist unverändert).
i5-750, GTX 950, Win7



Passmark PerformanceTest 7.0 build 1024:
http://www.guru3d.com/files-get/passmark-performancetest-7-build-1024,1.html

ohne Patch:
GPU 2D DX10: 443,4
GPU 3D DX10: 2143,3

mit Patch:
GPU 2D DX10: 504,6 (+ 13,8 %)
GPU 3D DX10: 4688,8 (+ 118,76 %)



"PC UserBenchmark":
http://www.userbenchmark.com/Software

ohne Patch:
MRender DX10: 62.4
Gravity DX10: 68.8
Splatting DX10: 52.7
fps DX10: 61.3

mit Patch:
MRender DX10: 77.5 (+ 24,19 %)
Gravity DX10: 94 (+ 36,6 %)
Splatting DX10: 75 (+ 42,3 %)
fps DX10: 82.2 (+ 66,77 %)



Wie ist denn dieser krasse Anstieg der GPU-DX10-Leistung zu erklären?
Warum wirkt sich das bei DX9 nicht aus?
Benchmark wurde jeweils 2 mal durchgeführt.

Die SSD-Leistung ist unverändert (SATA2, Crystal DiskMark v5.1.0).

Edit:
Nach einem Neustart und erneutem Test mit Patch sind die Werte leider wieder auf den niedrigeren Wert gesunken. Wie kann es denn da solche Unterschiede bei den DX10-Messungen geben?
Taugt der Benchmark (Passmark PerformanceTest) evtl. nichts?

 

[Mcr-King]

Ja die sind nicht wirklich brauchbar wie die meisten Benchmarks oder zockst du Benchmarks.

 

[Iscaran]

Wie hast du denn das mit Patch und ohne Patch getestet ?

Eine Deaktivieren/Aktivieren des Patches erfordert in JEDEM fall einen Computer neustart. Wenn du das nicht gemacht hast - kannst die Zahlen eh komplett vergessen.

 

[Bolko]

Klar habe ich den Rechner neu gestartet.

2 mal gebencht mit Patch. Hohe 3D DX10 Werte gemessen.
Danach Patch deinstalliert und neu gestartet.
2 mal gebencht. Niedrige 3D DX10 Werte gemessen.
Patch installiert und neu gestartet.
Gebencht und niedrige Werte gemessen.

Ist offenbar nicht reproduzierbar.
Vielleicht schummelt auch einfach nur der NVidia Grafik-Treiber, wenn er das Benchmarkprogramm erkennt?

 

[Mcr-King]

Ja kann auch sein und wäre ja nicht neu 😁

 

[Mr.Blade]

Gibt's diese eklatanten Leistungseinbrüche bei SSDs auch bei AMD?

 

[Iscaran]

Die Meltdown-Patch relevanten I/O Einbrüche gibt es NICHT auf AMD.
(EDIT: siehe https://www.computerbase.de/2018-01...-benchmarks/#abschnitt_ryzen_unter_windows_10

Die Spectre-Patch(es) verursachten aber je nachdem mehr oder meist weniger auch auf AMD.
Auf CB noch nicht getestet.

Aber z.B. @Linux:
Intel: https://www.phoronix.com/scan.php?page=news_item&px=Retpoline-Underflow-Benchmarks
AMD: https://www.phoronix.com/scan.php?page=news_item&px=AMD-Retpoline-Linux-4.15-FX-Zen

Man erwartet aber dass die Performance @Intel noch "etwas" besser wird evtl.:
https://www.phoronix.com/scan.php?page=news_item&px=RETPOLINE_UNDERFLOW

 

[Banned]

Gibt's diese eklatanten Leistungseinbrüche bei SSDs auch bei AMD?

Nein. Aber AMD war da vorher auf so einem schlechten Stand bzw. Intel auf so einem guten, dass sie jetzt in etwa gleich sind.

 

[etoo]

Gibts schon berichre über den amd spectre fix und der Performance?

 

[Iscaran]

Gibts schon berichre über den amd spectre fix und der Performance?

In der Tat gibt es nun langsam erste Hinweise unter Linux wie der Performance Hit mit Spectre V1/V2 und ohne ausfällt auf AMD:
https://www.phoronix.com/scan.php?page=article&item=linux-416-epyc&num=1

Es wurden auf Phoronix insgesamt mehrere Linux-Varianten mit mehreren Mitigation-Level Varianten getestet:

"Linux 4.14.0 stable that doesn't contain any Spectre V1 or V2 mitigation for the EPYC system. - Linux 4.14.24 as the latest 4.14 stable point release at the time of testing that includes both __user pointer sanitization for Spectre Variant One and backported full AMD Retpoline protection for Spectre Variant Two."
Linux 4.15.0 stable that contained full AMD Retpoline protection but that release hadn't offered any Spectre V1 protection.
- Linux 4.16 Git from this week offering both user pointer sanitization and full AMD Retpoline protection.
- Linux 4.16 Git from the same build but disabling the Retpoline support via the "spectre_v2=off" kernel command-line option. This though still leaves Spectre V1 protection in place."

Also 1x 4.16 mit Mitigation gegen Spectre V1 UND V2 und 1x 4.16 mit NUR Spectre V1 Schutz aktiv !
Das Linux 4.15. enthält also KEINEN Spectre V1 Schutz, wohl aber den Retpoline V2 Schutz

Für den I/O Tester ist der Performancehit meist sehr klein und wesentlich kleiner als alleine der KPTI-Fix für Meltdown auf Intel-Systemen.

"The impact of fending off Spectre remains relatively small and much less noticeable than the impact on Intel hardware with needing kernel page-table isolation (KPTI) for also addressing the Meltdown vulnerability that affects their chips to date."

Im Allgemeinen ist die I/O Performance auf AMD nahezu unverändert. Allerdings hat gerade Linux v4.16 hier noch luft nach oben da es generell noch etwas schlechter performed als Linux v4.14.

"Overall, the performance of Linux 4.14 to 4.16 for most I/O workloads is a relatively small drop."

Auch AMD Compilerperformance ist quasi gleich.

"The AMD compiler performance isn't degraded with their Spectre mitigation techniques."

Und in PostGreSQL (auf 1 Thread) ist der Einbruch ebenfalls eher unsichtbar.

"At least when running PostgreSQL with one thread, the performance hit is small."

Deutlicher im Vorteil ist AMD wohl bei GIMP...das auf Intels wohl schon messbar langsamer läuft. AMD quasi unverändert.

"The GIMP image manipulation program saw some measurable performance slowdowns on Intel with the Spectre/Meltdown mitigation, but on the AMD side there isn't much of a difference."

Und bei Redis sieht man auch nichts@Epyc

"The Redis performance also doesn't appear affected for EPYC."

Stress-NG fällt auch nur auf weil 4.16 schlechter als .15, bzw .14 läuft...Spectre ist egal.

"The Stress-NG synthetic kernel benchmark does indicate slower performance in general with the Linux 4.16-based kernel than 4.14/4.15."

Einzig mit Apache sieht man dass Spectre-Patch via Retpoline etwas Leistung frisst. Aber auch ist anzumerken dass selbst 4.15 (und wohl auch 4.16) noch nicht voll optimiert sind da 4.14 immer noch schneller. Aber auch 4.14 mit Spectre-Schutz zeigt einen kleinen Performance Hit @4.14 von ca. 600 Punkten ca. 3% bei +-1.2% statistischer Unsicherheit. Also gerade mal leicht über dem kleinsten Signifikanzniveau (2-Sigma) der Messung.

"The Apache web server performance was affected by Linux 4.15+ with its Spectre mitigation but disabling Retpolines does boost the performance albeit not to the 4.14.0 performance level."

Also der Retpoline Schutz würde wirklich sau-gut funktionieren...mal abwarten was die Geschichte unter RS5 und dem vermeintlichen SpectreSchutz @Ryzen ist.

 

[vander]

@Iscaran
Danke für deine Mühe, aber ich glaube der Leistungsverlust unter Windows ist (entsprechend der Nutzerzahl) von weitaus größerem Interesse. Insbesondere, da es von AMD keine Meldungen zu µCode Updates für ältere CPUs (FX) gibt.
Ich glaube immer noch sie werden es, mit fortwährendem Verweis auf das 'near Zero risk', einfach aussitzen und dabei fleißig weiter neue CPUs mit der gleichen Argumentation verkaufen.