Meltdown & Spectre: Sicherheitsrisiken durch Spekulation bei aktuellen Prozessoren

[Loeschzwerg]

Zhaoxin Prozessoren sind laut Hersteller nicht von ZombieLoad betroffen: http://www.zhaoxin.com/InCenterContent.aspx?id=233
Security researchers show real-time monitoring of web pages viewed by users with ZombieLoad vulnerabilities

In response to this vulnerability, Zhaoxin carried out an architectural principle analysis and considered that our processor was not affected by the current vulnerability, and at the same time conducted a simulated attack test, and this problem was not found yet.

Zhaoxin will continue to analyze and pay attention to whether there are new types of vulnerability variants. (Google Übersetzer)

[Tarkin]

Intel verarscht die User wirklich nach STRICH UND FADEN - anders kann man das nicht mehr bezeichnen:

"The Core i5 9400 series is part of the line-up now featuring silicon-level mitigations for Meltdown and hardware/software improvements around Spectre and L1TF"


JEDOCH:

If taking a look at the geometric mean across the dozens of benchmarks carried out, both the Core i5 8400 and i5 9400F basically have around 18% lower performance from these default/out-of-the-box mitigations on Linux systems for Meltdown, Spectre, L1TF/Foreshadow, and MDS/Zombieload. Those wanting to dig more into these numbers and some additional data points can do so via this OpenBenchmarking.org result file.

von hier: https://www.phoronix.com/scan.php?page=article&item=intel-9400f-mitigations&num=1

Und wann verdammt gibts zu diesem Thema endlich mal anständige Artikel und Tests in DEUTSCHEN Publikationen??? Ich kann gar nicht soviel Whisky saufen wie ich kotzen möchte. Die 18% IPC von Ice Lake kann man garantiert in die TONNE treten - alles erstunken und erlogen... sowas von 100% fix genau so hingebogen, dass es passt.

Sorry... aber wer sich von denen noch länger verarschen lässt, dem ist nicht zu helfen. Intel gehört (ich wiederhole mich) mit Sammelklagen überzogen!

[Birdman]

@Tarkin
Kommentare lesen hilft, denn so wie es aussieht hatte die getestete 9400F CPU gar keine zusätzliche/neue Hardware Mitigation, da noch auf altem Stepping basierend.

[Ganon]

Eigentlich lässt sich sowas recht simpel feststellen unter Linux:

$ grep bugs /proc/cpuinfo
cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds

Wenn da cpu_meltdown und l1tf gelistet wird, dann hat die CPU keinen HW fix. Ansonsten meldet die CPU über einen MSR-Eintrag, dass sie einen Fix in-Hardware hat. Darum braucht die HW-Fix auch Software-Support, weil der Kern im MSR nachschauen muss, ob die Mitigations nötig sind oder nicht.

[Denniss]

der einzige "fix in hardware" wird die Einspielung der damals aktuellen microcodes ab Werk sein

[Ganon]

der einzige "fix in hardware" wird die Einspielung der damals aktuellen microcodes ab Werk sein

Dann würde der Linux Kernel aber weiterhin "cpu_meltdown" melden, da der Microcode alleine den Bug auch nicht behebt. Afaik wurde in den neusten 9xxx Revisionen der Kram wirklich in Hardware gefixt. Im Linux Kernel wurde entsprechend der Gegencheck im MSR eingebaut.

https://www.digitaltrends.com/computing/intel-9-series-cpu-spectre/
https://www.digitaltrends.com/computing/intel-whiskey-lake-has-meldown-fix-amber-lake-does-not/

[Birdman]

der einzige "fix in hardware" wird die Einspielung der damals aktuellen microcodes ab Werk sein
Nein, da wurde durchaus was an der Hardware gedreht, siehe auch https://www.phoronix.com/scan.php?page=article&item=intel-mds-xeon&num=5
2nd gen "Xeon Scalable" Plattform verliert im Gegensatz zur 1st gen kaum mehr was bei aktiver Mitigation.

[gmb]

Nein, da wurde durchaus was an der Hardware gedreht, siehe auch https://www.phoronix.com/scan.php?page=article&item=intel-mds-xeon&num=5
2nd gen "Xeon Scalable" Plattform verliert im Gegensatz zur 1st gen kaum mehr was bei aktiver Mitigation.


Ja eben, siehe Übersicht hier: https://www.intel.com/content/www/us/en/architecture-and-technology/engineering-new-protections-into-hardware.html

Cascade Lake sieht gut aus, der hat am meisten in Hardware geschützt. Interessant ist für Consumer das Stepping 13 (R0), der kommende i9-9900KS ist ein Kandidat dafür. Die restliche 9000er Serie soll nach und nach mit R0 ersetzt werden, aber das dauert. Gegenüber dem aktuellen Stepping 12 vom i9-9900K bringt der Hardware Schutz mit für Spectre V2, Spectre V4, MSBDS/Fallout, MLPDS und MDSUM. Der einzige Unterschied zu Cascade Lake ist nur noch der fehlende Hardware Schutz für Spectre V3a, und beiden fehlt Spectre V1.

[Ganon]

und beiden fehlt Spectre V1.

Das bekommst du afaik auch nicht in Hardware gefixt, außer du deaktivierst die Out-of-Order Ausführung.

[BigKid]

Sehe ich das eigentlich richtig und mittlerweile kann man per Lücke eben doch nicht mehr nur lesend sondern nun doch auch schreibend auf Speicher zugreifen der einen eigentlich nix angeht (Meltdown-RW) ?
Jetzt mal unabhängig davon wie aufwändig/warscheinlich ?

[Birdman]

Sehe ich das eigentlich richtig und mittlerweile kann man per Lücke eben doch nicht mehr nur lesend sondern nun doch auch schreibend auf Speicher zugreifen der einen eigentlich nix angeht (Meltdown-RW) ?
Jetzt mal unabhängig davon wie aufwändig/warscheinlich ?
Nein

[BigKid]

Nein
Na vielen Dank für die vielen Infos ;)


Die Forscher klassifizieren auch einige CPU-Lücken neu. So nennen sie den ursprünglich als Spectre V1.2 (Read-only Protection Bypass) vorgestellten Bug nun Meltdown-RW, weil er im Kern einen Mechanismus vom Meltdown-Typ nutzt, nämlich das Page-Fault-Signal #PF durch schreibenden Zugriff auf einen Read-only markierten Adressbereich, den der Prozess nur lesen dürfte.
Bedeutet also, dass der Angriff "einfach" nur den Schreibzugriff auf einen Read-Only Adressbereich nutzt - nicht aber diesen erfolgreich durchbekommt - Somit beschreibt das RW nur den Angriffsvektor aber nicht das Ergebis ? Hab ich es jetzt richtig verstanden ?

[BigKid]

Frage: Gibt es neben den Tests von Poronix noch weitere AKTUELLERE Tests die die Auswirkung der Mitigations einschliesslich Zombieload unter Windows 10 messen ? Hat jemand eventuell Links ?

[Complicated]

Am 7.7. Gibt es die sicherlich ganz aktuell.

[kruemelmonster]

Frage: Gibt es neben den Tests von Poronix noch weitere AKTUELLERE Tests die die Auswirkung der Mitigations einschliesslich Zombieload unter Windows 10 messen ? Hat jemand eventuell Links ?

Kannst du doch selbst benchen, die Schutzfunktionen lassen sich einzeln per Registry aus- und wieder anknipsen. Siehe hier (https://support.microsoft.com/de-de/help/4073119/protect-against-speculative-execution-side-channel-vulnerabilities-in).

Ich erstelle zZ solche Benchmarkreihen auf 7800X sowie 2600K, kann aber noch dauern, insofern wären deine Benchmarks hier gern gesehen.

[BigKid]

Danke für den Link...

Dann schauen wir erstmal wie es aktuell aussieht...
Die Reihe "mit Default Mitigations" also mit diesen Settings...

Get-SpeculationControlSettings
For more information about the output below, please refer to https://support.microsoft.com/help/4074629

Speculation control settings for CVE-2017-5715 [branch target injection]

Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: True [not required for security]

Speculation control settings for CVE-2018-3639 [speculative store bypass]

Hardware is vulnerable to speculative store bypass: True
Hardware support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is enabled system-wide: False

Speculation control settings for CVE-2018-3620 [L1 terminal fault]

Hardware is vulnerable to L1 terminal fault: True
Windows OS support for L1 terminal fault mitigation is present: True
Windows OS support for L1 terminal fault mitigation is enabled: True

Speculation control settings for MDS [microarchitectural data sampling]

Windows OS support for MDS mitigation is present: True
Hardware is vulnerable to MDS: True
Windows OS support for MDS mitigation is enabled: True


BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : True
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
BTIKernelRetpolineEnabled : False
BTIKernelImportOptimizationEnabled : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True
SSBDWindowsSupportPresent : True
SSBDHardwareVulnerable : True
SSBDHardwarePresent : True
SSBDWindowsSupportEnabledSystemWide : False
L1TFHardwareVulnerable : True
L1TFWindowsSupportPresent : True
L1TFWindowsSupportEnabled : True
L1TFInvalidPteBit : 45
L1DFlushSupported : True
MDSWindowsSupportPresent : True
MDSHardwareVulnerable : True
MDSWindowsSupportEnabled : True


Halten wir mal fest - um MDS Absicherung zu bekommen war bei mir ein erneutes Bios Update Notwendig - und zwar eines bei dem der Hersteller sagte "tus nicht wenn dein System stabil läuft..." - nun ja...

Die Reihe ohne Mitigations mit diesen Settings:

Get-SpeculationControlSettings
For more information about the output below, please refer to https://support.microsoft.com/help/4074629

Speculation control settings for CVE-2017-5715 [branch target injection]

Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: True
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: False

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: False

Speculation control settings for CVE-2018-3639 [speculative store bypass]

Hardware is vulnerable to speculative store bypass: True
Hardware support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is enabled system-wide: False

Speculation control settings for CVE-2018-3620 [L1 terminal fault]

Hardware is vulnerable to L1 terminal fault: True
Windows OS support for L1 terminal fault mitigation is present: True
Windows OS support for L1 terminal fault mitigation is enabled: False

Speculation control settings for MDS [microarchitectural data sampling]

Windows OS support for MDS mitigation is present: True
Hardware is vulnerable to MDS: True
Windows OS support for MDS mitigation is enabled: False

Suggested actions

* Follow the guidance for enabling Windows Client support for speculation control mitigations described in https://support.microsoft.com/help/4073119


BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : True
BTIDisabledByNoHardwareSupport : False
BTIKernelRetpolineEnabled : False
BTIKernelImportOptimizationEnabled : False
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : False
KVAShadowPcidEnabled : False
SSBDWindowsSupportPresent : True
SSBDHardwareVulnerable : True
SSBDHardwarePresent : True
SSBDWindowsSupportEnabledSystemWide : False
L1TFHardwareVulnerable : True
L1TFWindowsSupportPresent : True
L1TFWindowsSupportEnabled : False
L1TFInvalidPteBit : 45
L1DFlushSupported : True
MDSWindowsSupportPresent : True
MDSHardwareVulnerable : True
MDSWindowsSupportEnabled : False


3DMark Firestrike (ohne Mitigations -> mit Default):
22359 -> 22114 (Besonders gelitten hat der Phsysics Score mit c.a. -5 %)

3DMark TimeSpy (ohne Mitigations -> mit Default):
10347 -> 10088 (Besonders gelitten hat hier Graphics Test 1 mit c.a. -6,4 %)

PCMark 10 (wie gehabt)
6461 -> 6198 (Besonders gelitten hat hier der Productivity Score (Spreadsheet) 11389->9549)
[Und das ganze OHNE Verwendung einer NVME SSD ... ich denke MIT würde es beim AppStart deutlicher zur Sache gehen...]

Generelle System Infos:
Windows 10 (1903)
Intel i7-8700k auf ASRock Z370 Gaming K6 mit 32GB (4x8 GB) Ram @ 3400Mhz (lief bisher eigentlich mit 3600, war aber mit dem neusten Bios Upate nicht mehr Stabil und ich musste runter).
Gigabyte RTX2080 Gaming OC mit 120% Powertarget und Templimiz bei 88°C sowie Custom Kurve 1890Mhz bei 0,975V (ab da Gerade).
System-Platten: SATA SSDs CT1000MX500, Samsung 850 EVO 1TB
Kühlung CPU: Noctua NHD15-S, 6x 120mm Gehäuselüftern (3 Blasen rein (2 im Boden, 1x Front Unten), 3 Raus (einer oben hinter der CPU, 2 an der Decke)) - da sollte nix Überhitzen...

Zwischen den Tests wurde nix ausser den Mitigations verändert.
Raumtemp durchgehend bei unerträglichen 35 Grad (gefühlt - nicht gemessen) ...

Wenn jemand noch Tipps und Anregungen hat bezüglich der Settings für die Mitigations oder der "Testmethodik" hat - immer her damit - solange sie nett und höflich rüber kommen... Ich lerne gerne dazu...

Ich hatte Probleme mit der Systemstabilität nach dem Bios Update... Am Ende musste ich mit dem Speicher von 3600 auf 3400Mhz runter...
Keine Ahnung ob das am Bios Update, der Hitze, oder der Monoblock Klimanlage (Stromnetz ? - auch wenn ichs mal nicht glaube...) lag...
Am Ende halt Speicher auf 3400(bei ALLEN Tests) und Klima aus um mal vorwärts zu kommen...

1 Fazit: Es gibt auch unter Windows messbare Verluste, in einzelnen Szenarien um die 5 %

Die nun folgenden Ergebnisse zu den Spielen sind nicht ganz Plausibel. Ich geh darauf im einzelnen Nochmal ein - habe aber die nächsten Tage keine Möglichkeit die Läufe nochmal zu wiederholen...

AC Odyssey (ohne Mitigations -> mit Default Mitigations)
FullHD, Preset niedrig, kein AA, kein VSync

FPS Min 21 -> 55
FPS max 188->186
FPS avg 131->124

CPU (ms) max 47 -> 8
CPU (ms) min 5->5
CPU (ms) avg 8->8

GPU (ms) max 16->15
GPU (ms) min 8->8
GPU (ms) avg 8->8


AC Odyssey (ohne Mitigations -> mit Default Mitigations)
WQHD, Preset Ultra Hoch, kein AA, kein VSync

FPS Min 32 -> 39
FPS max 126->116
FPS avg 65->66

CPU (ms) max 31 -> 26
CPU (ms) min 8->9
CPU (ms) avg 16->15

GPU (ms) max 19->18
GPU (ms) min 11->11
GPU (ms) avg 15->15

Die min FPS sind nicht brauchbar - vermutlich reicht es schon wenn auf dem System irgendwas auch nur ne ns gezuckt hat. Da es mir drumm ging die Auswirkung im Alltag zu messen habe ich auch nicht extra ne Jungfrau aufgsetzt... Die restlichen Werte zeigen im CPU Limit (FullHD) leichte Auswirkungen (AvgFPS von 131->124) in meinem normal Setting (WQHD) merkt man vermutlich eher nix auch wenn die MaxFPS leicht gesunken sind...


Tombraider (Shadow of)
FullHD, niedrig (nicht niedrigstes), kein AA, kein VSync

CPU-Spiel min: 113->107
CPU-Spiel max: 210->201
CPU-Spiel avg: 161->154
CPU-Spiel 95%: 117->114

CPU-Rend min: 176->158
CPU-Rend max: 471->411
CPU-Rend avg: 250->237
CPU-Rend 95%: 192->175

GPU min: 173->176
GPU max: 369->362
GPU avg: 221->222
GPU 95%: 187->190


Fazit habe ich erstmal keines. Es scheint dass AC O. eher unbeieindruckt ist. Die avg. fps sind leicht gesunken unter FullHD (niedrig) aber unter WQHD merkt man da schon nix mehr - da limitiert wohl die GPU schon wieder. Das selbe scheint für Tombraider zu gelten, denn wärend die Werte für CPU-Spiel und CPU-Rend durchaus reagieren, reagiert die GPU eigentlich gar nicht...

[Razor]

Klasse Vergleich!

Habe nun auch mal die Microcodes im Bios für meine Haswell-CPU (306C3) i7-4770s aktualisiert (v25 auf v27) und werde nun mal schauen...
PS C:\WINDOWS\system32> Get-SpeculationControlSettings
For more information about the output below, please refer to https://support.microsoft.com/help/4074629

Speculation control settings for CVE-2017-5715

Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: True [not required for security]

Speculation control settings for CVE-2018-3639 [speculative store bypass]

Hardware is vulnerable to speculative store bypass: True
Hardware support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is enabled system-wide: False

Speculation control settings for CVE-2018-3620 [L1 terminal fault]

Hardware is vulnerable to L1 terminal fault: True
Windows OS support for L1 terminal fault mitigation is present: True
Windows OS support for L1 terminal fault mitigation is enabled: True

Speculation control settings for MDS [microarchitectural data sampling]

Windows OS support for MDS mitigation is present: True
Hardware is vulnerable to MDS: True
Windows OS support for MDS mitigation is enabled: True


BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : True
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
[B]BTIKernelRetpolineEnabled : True
BTIKernelImportOptimizationEnabled : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True
SSBDWindowsSupportPresent : True
SSBDHardwareVulnerable : True
SSBDHardwarePresent : True
SSBDWindowsSupportEnabledSystemWide : False
L1TFHardwareVulnerable : True
L1TFWindowsSupportPresent : True
L1TFWindowsSupportEnabled : True
L1TFInvalidPteBit : 45
L1DFlushSupported : True
MDSWindowsSupportPresent : True
MDSHardwareVulnerable : True
MDSWindowsSupportEnabled : True
Mir ist allerdings aufgefallen, dass bei Dir Retpoline nicht aktiviert ist.
Dürfte allerdings "normal" sein, da ja alle CPU's ab Skylake nicht kompatibel sein sollen.

Hyperthreading werde ich allerdings vorerst nicht aktivieren, weil ich mir aktuell nicht sicher bin, ob das Gefahrenpotential diese Maßnahme rechtfertigt.
https://www.pcworld.com/article/3395439/intel-hyper-threading-zombieload-cpu-exploit.html

Die einen sagen:

“As ZombieLoad leaks loaded values across logical cores, a straightforward mitigation is disabling the use of Hyper-Threading. Hyper-Threading improves performance for certain workloads by 30 percent to 40 percent.”

Intel sagt:

“Because these factors will vary considerably by customer, Intel is not recommending that Intel HT be disabled, and it’s important to understand that doing so does not alone provide protection against MDS,” Intel said in a statement.”

Ergo: Deaktivieren von HT "heilt" das Problem vs. Nö, tut es nicht.
Kann hierzu vielleicht noch jemand Konkreteres beisteuern?

Bei mir sind nun alle "FeatureOverrides" deaktiviert, bzw. existieren die Reg-Keys nicht mehr, was zu o.g. Ergebnis führt.
OK, das Bios habe ich selber per UBU gepatched, weil mein "lieber" Board-Hersteller (ASUS Z87-A) der Meinung ist, hier nichts mehr tun zu müssen :)

Razor

P.S.: meine nächste CPU wird wohl von AMD kommen... Zen2, ich komme! :D
P.P.S.: und mein nächstes Mainboard wohl nicht von ASUS ;D

[Armaq]

Klasse Vergleich!

Habe nun auch mal die Microcodes im Bios für meine Haswell-CPU (306C3) i7-4770s aktualisiert (v25 auf v27) und werde nun mal schauen...
PS C:\WINDOWS\system32> Get-SpeculationControlSettings
For more information about the output below, please refer to https://support.microsoft.com/help/4074629

Speculation control settings for CVE-2017-5715

Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: True

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID performance optimization is enabled: True [not required for security]

Speculation control settings for CVE-2018-3639 [speculative store bypass]

Hardware is vulnerable to speculative store bypass: True
Hardware support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is present: True
Windows OS support for speculative store bypass disable is enabled system-wide: False

Speculation control settings for CVE-2018-3620 [L1 terminal fault]

Hardware is vulnerable to L1 terminal fault: True
Windows OS support for L1 terminal fault mitigation is present: True
Windows OS support for L1 terminal fault mitigation is enabled: True

Speculation control settings for MDS [microarchitectural data sampling]

Windows OS support for MDS mitigation is present: True
Hardware is vulnerable to MDS: True
Windows OS support for MDS mitigation is enabled: True


BTIHardwarePresent : True
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : True
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : False
[B]BTIKernelRetpolineEnabled : True
BTIKernelImportOptimizationEnabled : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True
SSBDWindowsSupportPresent : True
SSBDHardwareVulnerable : True
SSBDHardwarePresent : True
SSBDWindowsSupportEnabledSystemWide : False
L1TFHardwareVulnerable : True
L1TFWindowsSupportPresent : True
L1TFWindowsSupportEnabled : True
L1TFInvalidPteBit : 45
L1DFlushSupported : True
MDSWindowsSupportPresent : True
MDSHardwareVulnerable : True
MDSWindowsSupportEnabled : True
Mir ist allerdings aufgefallen, dass bei Dir Retpoline nicht aktiviert ist.
Dürfte allerdings "normal" sein, da ja alle CPU's ab Skylake nicht kompatibel sein sollen.

Hyperthreading werde ich allerdings vorerst nicht aktivieren, weil ich mir aktuell nicht sicher bin, ob das Gefahrenpotential diese Maßnahme rechtfertigt.
https://www.pcworld.com/article/3395439/intel-hyper-threading-zombieload-cpu-exploit.html

Die einen sagen:

“As ZombieLoad leaks loaded values across logical cores, a straightforward mitigation is disabling the use of Hyper-Threading. Hyper-Threading improves performance for certain workloads by 30 percent to 40 percent.”

Intel sagt:

“Because these factors will vary considerably by customer, Intel is not recommending that Intel HT be disabled, and it’s important to understand that doing so does not alone provide protection against MDS,” Intel said in a statement.”

Ergo: Deaktivieren von HT "heilt" das Problem vs. Nö, tut es nicht.
Kann hierzu vielleicht noch jemand Konkreteres beisteuern?

Bei mir sind nun alle "FeatureOverrides" deaktiviert, bzw. existieren die Reg-Keys nicht mehr, was zu o.g. Ergebnis führt.
OK, das Bios habe ich selber per UBU gepatched, weil mein "lieber" Board-Hersteller (ASUS Z87-A) der Meinung ist, hier nichts mehr tun zu müssen :)

Razor

P.S.: meine nächste CPU wird wohl von AMD kommen... Zen2, ich komme! :D
P.P.S.: und mein nächstes Mainboard wohl nicht von ASUS ;D
Cloud Provider haben in vielen Serien HT disabled, denn es mitigiert das Problem. Für Provider bedeutet das übrigens massive Einschnitte in der Profitabilität einer CPU, daher macht man es nur, wenn man muss. Intels Statement sind eine Frechheit und wurden zurecht von z.B. Linus Torvalds massiv kritisiert.

[Razor]

Cloud Provider haben in vielen Serien HT disabled, denn es mitigiert das Problem. Für Provider bedeutet das übrigens massive Einschnitte in der Profitabilität einer CPU, daher macht man es nur, wenn man muss. Intels Statement sind eine Frechheit und wurden zurecht von z.B. Linus Torvalds massiv kritisiert.
Gibt es denn Nachweise, dass dem tatsächlich so ist?
Oder macht man dies nur "vorsichtshalber"?

Ernsthaft... ich konnte noch nichts wirklich spezifisches darüber lesen!
Hast Du etwas derartiges zur Hand?

Razor

[BigKid]

Gibt es denn Nachweise, dass dem tatsächlich so ist?
Oder macht man dies nur "vorsichtshalber"?

Ernsthaft... ich konnte noch nichts wirklich spezifisches darüber lesen!
Hast Du etwas derartiges zur Hand?

Razor
Wenn Firmen wie Apple sagen: Absolute Sicherheit nur mit Abschalten dann kann sich keiner der mit Serververmietung Geld verdient es leisten es nicht zu tun... Bei den Klagen falls irgendwo mal Daten ausgespäht und es war nicht aus wird Intel nämlich nicht helfen können...

[Complicated]

Oder macht man dies nur "vorsichtshalber"?


Man schließt jede Sicherheitslücke "vorsichtshalber". Was gibt es sonst noch für Gründe?

[Achill]

Cloud Provider haben in vielen Serien HT disabled, denn es mitigiert das Problem. Für Provider bedeutet das übrigens massive Einschnitte in der Profitabilität einer CPU, daher macht man es nur, wenn man muss. Intels Statement sind eine Frechheit und wurden zurecht von z.B. Linus Torvalds massiv kritisiert.


Gibt es denn Nachweise, dass dem tatsächlich so ist?
Oder macht man dies nur "vorsichtshalber"?

Ernsthaft... ich konnte noch nichts wirklich spezifisches darüber lesen!
Hast Du etwas derartiges zur Hand?

Razor

Jain, man muss wohl unterscheiden, ob man eine ganze Instanzen mietet (AWS, Google Cloud, Azure) oder nur Container in einer Umgebung laufen lässt (z.B. Google App Engine).

Für den letzteren Teil gehe ich davon aus, dass dies Migration durch die Provider passiert ist - das Risiko des Daten abfließen und man dies verschuldet, ohne das der Kunde etwas unternehmen konnte, wird man nicht eingehen.

Für den ersten Teil gibt es Dokumentation die explizit die Risiken benennt, man überlässt es aber den Kunden, ob er HT deaktiviert. Es ist z.B. nicht notwenig, wenn man kein untrusted Code/Programm ausführt. Doku für z.B. Azure: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/mitigate-se

[Razor]

Wenn Firmen wie Apple sagen: Absolute Sicherheit nur mit Abschalten dann kann sich keiner der mit Serververmietung Geld verdient es leisten es nicht zu tun... Bei den Klagen falls irgendwo mal Daten ausgespäht und es war nicht aus wird Intel nämlich nicht helfen können...
Oh ha... na ja, wenn gerade Apple so etwas "sagt" :ucrazy3:
Regelrecht grotesk finde ich die Formulierung "absolute Sicherheit"... klingt mir doch sehr nach Panik.
(zumal das Abschalten von HT nach Intel eben genau das nicht zur Folge hat)

Jain, man muss wohl unterscheiden...
Hmmm... das war jetzt nicht unbedingt das, was ich meinte.
Gibt es irgendeinen Hinweis, dass es gelungen wäre, ohne Admin-Rechte (!) ein System zu infizieren?
Oder noch viel konkreter: ist dies überhaupt schon mal irgendwo passiert?

Selbst Microsoft sagt dazu: "customers may wish to"
Die Vorgehensweise wird zwar empfohlen, aber...

Klingt für mich alles zu schwammig und wenn Microsoft darin wirklich ein Problem sehen würde, gäbe es einen Patch, der dies schlicht erzwingt.
(wie es beispielsweise bei Google geschah)

Razor

P.S.: hab't Ihr denn HT abschaltet?

[Birdman]

(zumal das Abschalten von HT nach Intel eben genau das nicht zur Folge hat)
Die Aussage ist so gemeint, dass HT deaktivieren ohne dass man auch zusätzlich noch die Software Patches einspielt, keine vollständige Sicherheit bietet. HT off sowie alle OS/Software patches drauf, ist sicher*.

* Ihm Rahmen dessen was man heutzutage allgemein bzgl. der Spectre Problematik als "sicher" anschaut.

[Freestaler]

Ich glaube nicht, das es deaktiviert wurde. Weder bei Google, Amazon noch Microsoft. Zu viel Geld im Spiel. Unter uns, es ist nur eine Bedrohungen von vielen und Riskmanagment gehört zum Geschäft. Ein paar neue dedection Rules und generell Honeypots anpassung. Evtl. Noch nen suchfilter mehr im darknet. Mehr ist da nicht. Da sind z.B. Mitarbeiter das grössere Risiko.

[BigKid]

Oh ha... na ja, wenn gerade Apple so etwas "sagt" :ucrazy3:
Regelrecht grotesk finde ich die Formulierung "absolute Sicherheit"... klingt mir doch sehr nach Panik.
(zumal das Abschalten von HT nach Intel eben genau das nicht zur Folge hat)

Als ob Intel jetzt besser wäre oder was ?
Fakt ist doch der EINZIGE der sagt es ist nicht schlimm IST Intel... Da unterstelle ich mal schon eine gewisse Tendenz zur Schadensbegrnezung in der Argumentation...
Apple und andere Leute die da vermutlich mehr Ahnung haben also du oder ich (also zB der Vater von Linux) sagen was anderes und haben Intel für ihr "runterspielen" schon ziemlich kritisiert...



Hmmm... das war jetzt nicht unbedingt das, was ich meinte.
Gibt es irgendeinen Hinweis, dass es gelungen wäre, ohne Admin-Rechte (!) ein System zu infizieren?
Oder noch viel konkreter: ist dies überhaupt schon mal irgendwo passiert?

Selbst Microsoft sagt dazu: "customers may wish to"
Die Vorgehensweise wird zwar empfohlen, aber...

Klingt für mich alles zu schwammig und wenn Microsoft darin wirklich ein Problem sehen würde, gäbe es einen Patch, der dies schlicht erzwingt.
(wie es beispielsweise bei Google geschah)

Razor

P.S.: hab't Ihr denn HT abschaltet?
Ich glaube du hast das Problem für Rechenzentren nicht verstanden.
Es MUSS niemand DEINE Maschine infizieren...
Es reicht ganz legal einen virtuellen Server zu mieten und dann unter Verwendung des entsprechenden Codes Daten von ANDEREN virtuellen Maschinen auf der selben CPU in diesem Rechenzentrum auszuspähen...
Und dieser Angriff lässt sich auf der ANDEREN Maschine auch nicht bemerken oder nachweisen...
Genauso muss (bzw. musste wenn dein System gepatcht ist) auch niemand DEINEN Rechner infizieren sondern es reichte den Code auf ner Webseite laufen zu lassen und es konnte sein dass jemand Daten von anderen Programmen ausspäht die du grade laufen hattest...
Das Problem bei den Schwachstellen ist nur, dass sich nicht gut "zielen" lässt und es daher lange dauert bis man was brauchbares abgreift... Hast du aber alle Zeit der Welt wie bei einem gemieteten Server... ... ...
Ich hatte es oben schon gesagt: Es reicht doch dass du von dem Risiko gewusst und nicht alles getan hast was dir möglich war - na - siehst du die Abmahnungen/Klagen schon kommen ?

[Ganon]

Weiter geht's: SWAPGSAttack

Bisher "nur" unter Windows x64 erfolgreich durchgeführt worden. Patches für Windows und Linux stehen aber wohl bereit.

https://www.computerbase.de/2019-08/swapgsattack-schwachstelle-intel-prozessoren-cpu/
https://access.redhat.com/articles/4329821

[Armaq]

Jain, man muss wohl unterscheiden, ob man eine ganze Instanzen mietet (AWS, Google Cloud, Azure) oder nur Container in einer Umgebung laufen lässt (z.B. Google App Engine).

Für den letzteren Teil gehe ich davon aus, dass dies Migration durch die Provider passiert ist - das Risiko des Daten abfließen und man dies verschuldet, ohne das der Kunde etwas unternehmen konnte, wird man nicht eingehen.

Für den ersten Teil gibt es Dokumentation die explizit die Risiken benennt, man überlässt es aber den Kunden, ob er HT deaktiviert. Es ist z.B. nicht notwenig, wenn man kein untrusted Code/Programm ausführt. Doku für z.B. Azure: https://docs.microsoft.com/en-us/azure/virtual-machines/windows/mitigate-se
Ich arbeite in dem Umfeld und du kannst HT nicht aktivieren. Wenn du das machst, kannst du dem Kunden keine Zusage geben, denn es kommen immer mehr Fehler auf. In den in-house IT Abteilungen gehen viele ähnlich vor.

Anders gesagt, unsere Kunden sind mit der Lösung einverstanden.

Das Aws und Azure ht abschalten auf User Ebene sehen, macht Ihnen null Aufwand.

Edit: Siehe Post über mir, als ob ich das vorbereitet hätte.

[Schnoesel]

New NetCAT Vulnerability Exploits DDIO on Intel Xeon Processors to Steal Data

https://www.techpowerup.com/259096/new-netcat-vulnerability-exploits-ddio-on-intel-xeon-processors-to-steal-data

QXut1XBymAk

[Complicated]

Hmmm ist nicht mal eine Sidechannel Attacke oder die spekulative Ausführung involviert. Wie ist hier der Zusammenhang zu Meltdown oder Spectre?

[Schnoesel]

Stimmt ist was anderes, aber brauchts für jede Sicherheitslücke einen neuen Thread?

[Complicated]

Nein. Doch die Meltdown/Spectre sind recht breit gefächert an sich und wäre schön wenn man andere etwa in einem allgemeinen Thread für Sicherheitslücken sammeln kann. Lediglich als Vorschlag gedacht.

[Skysnake]

Sign

[nagus]

da kommt noch was auf intel zu

[Unicous]

Ist das dein Ernst?:confused:

Wo hast du das überhaupt her? Aus irgendeiner Kommentarspalte? Ein anonymer Account der mit "for the non political idiots" einsteigt und fortfährt mit 'Ich arbeite bei einer Top 100 Firma also ist das was ich sage wahr' soll für dich eine solide Quelle sein?:freak:

[Zossel]

Wo hast du das überhaupt her? Aus irgendeiner Kommentarspalte? Ein anonymer Account der mit "for the non political idiots" einsteigt und fortfährt mit 'Ich arbeite bei einer Top 100 Firma also ist das was ich sage wahr' soll für dich eine solide Quelle sein?:freak:

Das klingt erstmal nicht nach Sicherheit: https://www.phoronix.com/scan.php?page=news_item&px=Chrome-Geminilake-Bug

From the bug reports, they determined a pattern for the crashes and that it involves reading incorrect instruction bytes when crossing select 16-byte boundaries.

IMHO hatte schon der 6502 diese Art von Bug.

[Unicous]

Die "Atom"-Chips haben seit jeher eine Serie von Bugs in Hardware, Intel scheint nicht wirklich daran interessiert, diese auszumerzen.

Das hat aber augenscheinlich nichts mit dem kolportierten "security flaw" zu tun denn es wird auf Folgendes hingewiesen:

From that bug report the issue appears to have been introduced by a CPU microcode update.

Das eine hat also mit dem anderen (augenscheinlich) nichts zu tun, worauf willst du also hinaus?:confused:

edit:

Ein Post im Phoronix-Forum behauptet:

If you read through the Firefox bugzilla, it was already closed three months ago as bug reports had stopped; it only affected version 67 of Firefox; and it did not seem to be related to microcode as the "microcode versions associated with the crashes we're seeing are all over the place".

Sounds like Google is introducing a bug fix and trying to blame it on Intel, when it's probably Google's own code that's to blame.

Also doch nicht die CPU, sondern Chrome selbst? ¯\_(ツ)_/¯

[Zossel]

Und weiter gehts: https://cyberus-technology.de/posts/2019-11-12-taa.html

Diesmal via TSX.

https://www.youtube.com/watch?v=zaTxBZXE9pQ

https://github.com/IAIK/ZombieLoad/

[Skysnake]

Nice....

NOT

[Loeschzwerg]

Habe mich nicht genauer damit befasst, aber es sind scheinbar schon Fixes u.a. von MS raus: https://support.microsoft.com/en-us/help/4524570/windows-10-update-kb4524570

Ob es hilft und was es macht, keine Ahnung.

[Birdman]

Ob es hilft und was es macht, keine Ahnung.
Hat sich nicht so gelesen. Software Patches machen es wohl nur schwieriger.
Hier wäre es aber wohl weniger intrusiv wenn man TSX deaktiviert (wenn das überhaupt möglich ist) anstelle von HT, wobei man in entsprechend gefährdeten Umgebungen wohl eh schon HT deaktiviert hat.
Ausser natürlich die Käufer von Xeon Scalable Gen2 Plattformen - die sind nun neu halt auch gefikt.

[Tarkin]

“67 of the 77 vulnerabilities we are addressing were internally found by Intel”

WOW herzlichen Glückwunsch intel.... ein Wahnsinn.

https://blogs.intel.com/technology/2019/11/ipas-november-2019-intel-platform-update-ipu/#gs.fmz1yb

[Th3o]

Trotzdem ist der Aktienkurs nah am 52-Wochen-Hoch. Die Menschheit will verarscht werden.

[y33H@]

Vor allem Intel wusste, dass die TSX-Variante auch bei Cascade Lake funktioniert, beworben wurden die CPUs aber damit, dass sie gegen MDS wie Zombie Losd geschützt seien ... uff.

[Lehdro]

Vor allem Intel wusste, dass die TSX-Variante auch bei Cascade Lake funktioniert, beworben wurden die CPUs aber damit, dass sie gegen MDS wie Zombie Losd geschützt seien ... uff.
Klingt nach einem Fall für ein paar windige Anwälte....

[nagus]

da kommt noch was auf intel zu

I told you so ;)

[Tarkin]

https://www.phoronix.com/scan.php?page=article&item=intel-jcc-gaming&num=2

und wieder mal werden Intel CPUs im Gaming etwas langsamer ....

[y33H@]

Gibt halt Kontext, es liegt am Microcode für JCC, eine neue Lücke.

[Slashman]

Ich verstehe die Leute nicht... Ganz besonders die Intel Fanboys. Intel verschleiert um jeden Preis diese vielen gefährlichen Sicherheitslücken... Ihre Architektur ist voller Lücken nur um 5-10% mehr IPC zu haben... 77 neue Lücken gefunden auch in komplett neuen CPUs.

https://www.computerbase.de/2019-11/taa-mds-ridl-ng-intel-cpu-sicherheitsluecken/

Überschrifft:
"TAA/MDS/RIDL_NG: Intel bestätigt 77 neue Sicherheitslücken und Fehler"

Ich meine da geht einem Intel User ja richtig einer ab wenn er sagt wow meine i7 9900K ist 5% schneller pro MHz als eine Ryzen 3700X oder 15-20% schneller als eine 2700X. Das dieser IPC Vorteil durch mehr als 70 kritische Lücken bei der Sicherheit erkauft wurde... das sehen die nicht^^.

Hey schaltet die Firewall ab und das Anti Virus Programm liebe Intel Fanboys, dann habt ihr sicher noch weitere 5% mehr Leistung... auf diese 5% kommt es ja an.
Würde Intel alles Patchen und die kommende Architektur wirklich Sicher genug machen wäre sie nicht so schnell wie ein Zen2. Ich denke Speed um jeden Preis ist ein Fehler. Wer denkt Lücken im System ist nicht so wichtig, der sollte bedenken, das gerade Kriminelle Menschen sich hier freuen. Ich bleibe bei AMD bis Intel wieder das ist was es sein sollte. Marktführer in der Technologie...

Info am Rande:
Ich hatte bis August nur Intel CPUs in meinen Gamingsystemen. Eigentlich immer Nvidia und Intel... Bin jetzt wegen der vielen Negativen Presse zu AMD/ATI gewechselt. Ich finde es echt traurig das Intel noch weiterhin CPUs absetzt obwohl sie nur 14nm Aufguss mit vielen (70-80) Lücken in der Sicherheit verkaufen.

[Iscaran]

https://futurezone.at/produkte/intel-prozessoren-erneut-gefaehrdet/400672775
"„Eine Variante von ZombieLoad geht auch auf den neueren Cascade Lake Prozessoren“, erzählt Gruss im Gespräch mit der futurezone. „Die neuen CPUs waren zum Zeitpunkt unserer Tests noch schwierig zu bekommen und für Privatkunden noch nicht erhältlich. Wir konnten sie aber über Cloud-Provider ausprobieren und haben getestet, ob der Angriff dort auch funktioniert - und das tut er.“ Das war im April - einen Monat, bevor ZombieLoad der Öffentlichkeit präsentiert wurde. Und einen Monat bevor Intel in einem offiziellen Statement verkündet hatte, dass „neue Prozessoren von dem Problem nicht betroffen“ seien."

Ja Intel hat von den Forschern also erfahren daß die neuen Cascade Lakes NICHT sicher sind.
Hat dann die Forscher um ein 6 Monate Embargo der Info "gebeten" (sonst kein Geld).

Dann die neuen Cascade Lakes als "sicher" beworben und massenhaft verkauft OBWOHL sie schon wußten daß dies nicht stimmt.

Diesel-Skandal anyone ?

[SKYNET]

kurz: die komplette core architektur ist absoluter schrott und muss eigentlich eingestampft werden... HT: nicht nutzbar, dutzende sicherheitslücken: performance geht in keller... für mehr als nen bissl besseren taschenrechner, sind die teile also nicht zu gebrauchen. :ulol:

[Slashman]

https://futurezone.at/produkte/intel-prozessoren-erneut-gefaehrdet/400672775
"„Eine Variante von ZombieLoad geht auch auf den neueren Cascade Lake Prozessoren“, erzählt Gruss im Gespräch mit der futurezone. „Die neuen CPUs waren zum Zeitpunkt unserer Tests noch schwierig zu bekommen und für Privatkunden noch nicht erhältlich. Wir konnten sie aber über Cloud-Provider ausprobieren und haben getestet, ob der Angriff dort auch funktioniert - und das tut er.“ Das war im April - einen Monat, bevor ZombieLoad der Öffentlichkeit präsentiert wurde. Und einen Monat bevor Intel in einem offiziellen Statement verkündet hatte, dass „neue Prozessoren von dem Problem nicht betroffen“ seien."

Ja Intel hat von den Forschern also erfahren daß die neuen Cascade Lakes NICHT sicher sind.
Hat dann die Forscher um ein 6 Monate Embargo der Info "gebeten" (sonst kein Geld).

Dann die neuen Cascade Lakes als "sicher" beworben und massenhaft verkauft OBWOHL sie schon wußten daß dies nicht stimmt.

Diesel-Skandal anyone ?

Der nervige Punkt ist das die Intel Fanboys ehrlich sich um 5% mehr ipc (erkauft durch die über 70 Sicherheitslücken) als sich über die Sicherheit Gedanken zu machen.

Eigentlich müsste man eine Intel CPU Rückruf Aktion starten... Bei Dieselautos wurde das ja auch gemacht... Jeder gibt die neuen CPUs zurück und sagt zu Intel "versprechen halten und sichere CPU geben"...

Aber die Intel Lemminge kaufen weiter von Intel... Kritisieren AMD wegen des etwas niedrigeren Boosttakts... Wow das ist so wichtig.
Wenn mal das System des Fanboys gekapert ist wegen Viren, dann denkt er sich bestimmt... Ist nicht inteö schuld.

[aufkrawall]

Wenn mal das System des Fanboys gekapert ist wegen Viren, dann denkt er sich bestimmt... Ist nicht inteö schuld.
Hast du mal einen Nachweis dafür, dass durch die neuen Sicherheitslücken ohne Mitigations Code ausgeführt oder realistisch Daten im Browser abgegriffen werden können?
Wenn nicht, solltest du vielleicht nicht Panik schüren, wenn dir der Sachverhalt gar nicht wirklich geläufig ist. Ich kann mir auch irren, aber ich hab noch nichts in diese Richtung aus den Medien vernommen.

Ich komm dir aber entgegen, indem ich dir sage, dass CFL auch ohne Mitigations keine höhere IPC als Zen 2 hat. ;)

Habs btw, mal in SotTR Vulkan 6700k unter Linux getestet. Das sind keine exakten Werte (Kameraperspektive weicht wegen Auslotung der niedrigsten fps ab), die Relationen stimmen aber:
mitigations=off:
https://abload.de/thumb/screenshot_20191113_1fmjc5.png (https://abload.de/image.php?img=screenshot_20191113_1fmjc5.png)

Standard-Mitigations mit altem µcode:
https://abload.de/thumb/screenshot_20191113_1psjew.png (https://abload.de/image.php?img=screenshot_20191113_1psjew.png)


Standard-Mitigations mit neuem µcode:
https://abload.de/thumb/screenshot_20191113_1ovkpm.png (https://abload.de/image.php?img=screenshot_20191113_1ovkpm.png)

Ist schon übel, kann man nicht anders sagen.

[JVC]

@aufkrawall :up:
Und komplett ohne HT und ohne Patches als Abschluss wäre noch nice :)

Ist SMT eigentlich sicher ?
Egal, bei AMD bekomm ich auch in AM4 16Kerne,
da scheiss ich auf SMT :wink:

M.f.G. JVC

[aufkrawall]

Das hört sich ziemlich irrational an.

[Birdman]

Wenn mal das System des Fanboys gekapert ist wegen Viren, dann denkt er sich bestimmt... Ist nicht inteö schuld.

Für solchen Stuss sollte man Leute melden können....
Informiert euch doch bitte wie die Spectre Sicherheitslücken funktionieren, bevor Ihr Threads wie diesen mit solchem unqualifizierten Blödsinn zumüllt.

[Schnoesel]

Scheint ganz einfach über Javascript im Browser auszuführen zu sein:

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1138596-new-zombieload-side-channel-attack-variant-tsx-asynchronous-abort

[Slashman]

Hast du mal einen Nachweis dafür, dass durch die neuen Sicherheitslücken ohne Mitigations Code ausgeführt oder realistisch Daten im Browser abgegriffen werden können?
Wenn nicht, solltest du vielleicht nicht Panik schüren, wenn dir der Sachverhalt gar nicht wirklich geläufig ist. Ich kann mir auch irren, aber ich hab noch nichts in diese Richtung aus den Medien vernommen.

Ich komm dir aber entgegen, indem ich dir sage, dass CFL auch ohne Mitigations keine höhere IPC als Zen 2 hat. ;)

Habs btw, mal in SotTR Vulkan 6700k unter Linux getestet. Das sind keine exakten Werte (Kameraperspektive weicht wegen Auslotung der niedrigsten fps ab), die Relationen stimmen aber:
mitigations=off:
https://abload.de/thumb/screenshot_20191113_1fmjc5.png (https://abload.de/image.php?img=screenshot_20191113_1fmjc5.png)

Standard-Mitigations mit altem µcode:
https://abload.de/thumb/screenshot_20191113_1psjew.png (https://abload.de/image.php?img=screenshot_20191113_1psjew.png)


Standard-Mitigations mit neuem µcode:
https://abload.de/thumb/screenshot_20191113_1ovkpm.png (https://abload.de/image.php?img=screenshot_20191113_1ovkpm.png)

Ist schon übel, kann man nicht anders sagen.

Ähm... 77 neue Sicherheitslücken und Fehler... Nicht gesamt 77... Die alten Bekannten sind nicht in den 77. Für mich das Signal die Finger von den CPUs zu lassen. Aber du kannst dir ja einreden Lücken in der Sicherheit einer CPU kann man nicht ausnutzen.

Und nein Panikmache ist es nicht... Aber ignorant sein ist der falsche Weg. Ich frage dich was wäre wenn du ein Auto kaufst und die Funkverbindung kann dank 77 Lücken im System angegriffen werden... Bedeutet dein Auto ist nicht sicher... Was passiert dann? Genau es wird eine Rückruf Aktion geben.

Intel hat wissentlich fehlerhafte CPUs als sicher verkauft und Kumden getäuscht... Statt Intel vor Gericht zu zerren danken Intel Jünger für weitere 5% ipc mit dem Kauf einer 14nm ausgelutschten CPU Architektur voller Lücken. Ich verstehe echt nicht wie informierte Intel Kunden noch immer Intel vertrauen können... Würde AMD das machen gäbe es einen Aufschrei... Oh gab es wegen dem Boosttakts...

[aufkrawall]

Scheint ganz einfach über Javascript im Browser auszuführen zu sein:

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1138596-new-zombieload-side-channel-attack-variant-tsx-asynchronous-abort
Muss ich mir jetzt alle Comments dort durchlesen? Kann man nicht einfach quoten, worauf man sich bezieht? :rolleyes:

Ähm... 77 neue Sicherheitslücken und Fehler... Nicht gesamt 77... Die alten Bekannten sind nicht in den 77. Für mich das Signal die Finger von den CPUs zu lassen. Aber du kannst dir ja einreden Lücken in der Sicherheit einer CPU kann man nicht ausnutzen.

Du hast also inhaltlich rein gar nichts vorzuweisen.


Intel hat wissentlich fehlerhafte CPUs als sicher verkauft und Kumden getäuscht... Statt Intel vor Gericht zu zerren danken Intel Jünger für weitere 5% ipc mit dem Kauf einer 14nm ausgelutschten CPU Architektur voller Lücken. Ich verstehe echt nicht wie informierte Intel Kunden noch immer Intel vertrauen können... Würde AMD das machen gäbe es einen Aufschrei... Oh gab es wegen dem Boosttakts...
Du wiederholst dich.

[Slashman]

Muss ich mir jetzt alle Comments dort durchlesen? Kann man nicht einfach quoten, worauf man sich bezieht? :rolleyes:


Du hast also inhaltlich rein gar nichts vorzuweisen.


Du wiederholst dich.

Du bist "der Beweis" (South park witz). Sorry der musste sein... Wofür werden Lücken in der Software oder Hardware genutzt... Wie schaffen es Häcker das? Nur weil es noch keine großen Schäden gab ist es also ok.

Du bist der Beweis, da du hier das klein redest was Experten kritisieren. Ach was rede ich mit Fanboys... War schon immer sinnlos.

Heil Intel mein Kollege.
Darf Forscher bestechen für ein Info embargo.
Darf wissentlich lügen in der PR.
Darf ihren alten Aufguss als neu verkaufen, darf OEM bestechen.
Darf betrügen...
Immerhin bist du hinter ihnen.
👍🏽👍🏽👍🏽

[Schnoesel]

Dachte es wäre schon direkt auf den Comment verlinkt:

https://www.phoronix.com/forums/forum/phoronix/latest-phoronix-articles/1138596-new-zombieload-side-channel-attack-variant-tsx-asynchronous-abort?p=1138602#post1138602

[JVC]

Das hört sich ziemlich irrational an.
Wenn man es sich leisten kann und will, anstelle von nem 8Kerner gleich nen 16Kerner zu holen...
Ich denke ein 16Kerner ohne SMT ist trotzdem schneller als ein 8Kerner mit SMT.
Und im "Notfall" kann man es noch immer aktivieren ;)

Mir stößt nur das "schlechtere" Chiplet beim 3900X(3950X?) sauer auf :mad:
(das alleine könnte mich noch zum 3800X + SMT greifen lassen)
Aber es gibt auch 3900X die 4,6Ghz AC schaffen...
Mal die genaueren Tests zum 3950X abwarten...

Solange Intel nur "bunte Pflaster" auf die "Wehwehs" klebt, sind Sie bei mir raus.

M.f.G. JVC

[Birdman]

Kommentare sind Kommentare und wer diese als irgendeinen "Beweis" anschaut, der sollte ähhhm, na ja, wie auch immer.

Das mit dem Browser und JS ist Blödsinn - dies ist schon seit zwei Jahren nicht mehr relevant.
Klar, wer noch einen alten Browser einsetzt, der ist tendenziell nun angreifbar, das wäre er aber auch auf einem AMD System. (dort dann halt für Spectre v1)

[aufkrawall]

Das ist doch keine Quelle. :freak:
Im CVE steht:

An attacker cannot use this vulnerability to target specific data. An
attack would likely require sampling over a period of time and the
application of statistical methods to reconstruct interesting data.
https://seclists.org/oss-sec/2019/q4/67
Klingt nicht sonderlich interessant für Angriffe auf normale Nutzer im Browser.

Zu JCC Erratum gibts btw. keinen CVE, weil es gar keine Sicherheitslücke ist. ;)

Die 77 Lücken beziehen sich btw. auf Intels komplettes Angebot, wovon ein Großteil auf diesen Müllhaufen ME entfällt (zwar immer wieder schockierend, aber auch nichts wirklich neues), bis hin zu Grafik- und Wifi-Treiber etc. Man muss schon echt hartes Zeug genommen haben, anzunehmen, dass das alles CPU-Lücken wären. :freak:

[Pirx]

Wieso sollen Kommentare keine Quellen sein? Sie haben manchmal wesentlich mehr Wert, als die Artikel. Dieser Kommetar verweist auf ein youtube-Video mit dieser Quelle: https://mdsattacks.com/

[aufkrawall]

In dem Video wird ein PoC demonstriert, ohne irgendeinen Bezug zu einem Browser. Man sollte schon einordnen können, worauf man sich bezieht...

[Iscaran]

@Aufkrawall:
CVE-2019-11135 ist Zombieload V2 bzw. TAA-MDS und daß ist genau die Lücke auf die sich das JCC Erratum bezieht.

Der JCC Patch war für die Zombieload v1 Attacken und mußte nun "überraschend" nachgeschärft werden weil es v2 gibt (bekannt seit April auch bei Intel). Man hatte dennoch die ganze Zeit über Cascade Lakes verkauft mit dem Hinweis "sicher gegen Zombieload"...was schon damals klar war, daß es gelogen ist.

Zombieload v1 als auch v2 lassen sich via JS im Browser ausführen.

Was das ausmachen kann beschreibt das Video das von "User" Birdie gelinkt wurde.
Birdie ist übrigens Member des RHEL Dev teams...

EDIT: In deinem Seclist: https://seclists.org/oss-sec/2019/q4/67
"An attacker, which could include a malicious untrusted user process on a
trusted guest, or an untrusted guest, can sample the content of
recently-used memory operands and IO Port writes.

This can include data from:

* A previously executing context (process, or guest, or
hypervisor/toolstack) at the same privilege level.
* A higher privilege context (kernel, hypervisor, SMM) which
interrupted the attacker's execution."

Das beschreibt die Anwendung des Exploits aus einem Browser fenster heraus. "Executing context at teh same prilege level"...= JS im Browser.

EDIT2: Aus dem Zombieload Whitepaper:
https://zombieloadattack.com/zombieload.pdf
"Furthermore, we show that ZombieLoad even works onMDS- and Meltdown-resistant processors,i.e., even on the newestCascade Lake microarchitecture. We demonstrated the immense attack potential by monitoring browser behaviour, extracting AESkeys, establishing cross-VM covert channels or recovering SGXsealing keys."

[Pirx]

In dem Video wird ein PoC demonstriert, ohne irgendeinen Bezug zu einem Browser. Man sollte schon einordnen können, worauf man sich bezieht...
Der Kommentator schreibt dazu:"...AMD CPUs are not affected.

Again, if you're not running untrusted code on your system (a web browser with enabled JS does run it), there's nothing to worry about.

In short: this new vulnerability again mostly affects cloud providers and users who run untrusted random code off the net."

Ist das falsch?

[aufkrawall]

Das beschreibt die Anwendung des Exploits aus einem Browser fenster heraus. "Executing context at teh same prilege level"...= JS im Browser.

For attacks inside of a single process (e.g., JavaScript sandbox), the sandbox implementation must make sure that the requirements for mounting ZombieLoad are not met. One example is to prevent generation and execution of the clflush instructions, which so far is a crucial part of the attack.
https://zombieloadattack.com/zombieload.pdf
clflush ist aber schon seit rowhammer in der Chrome-Sandbox ungenutzt:
https://bugs.chromium.org/p/nativeclient/issues/detail?id=3944

Wieso gibt es denn offenbar keinen PoC explizit für den Browser?

[Iscaran]

@aufkrawall:

Whatabout: ?

clflush ist aber schon seit rowhammer in der Chrome-Sandbox ungenutzt:
https://bugs.chromium.org/p/nativecl...detail?id=3944

Wieso gibt es denn offenbar keinen PoC explizit für den Browser?

Wieso erzeugen wir immer noch Strom in Kohlekraftwerken ?

Sind Äpfel was anderes als Birnen ?

[aufkrawall]

Das hat nichts mit "Whaboutism" zu tun, sondern ist wichtig für die Fragestellung, ob man als Consumer davon wirklich bedroht ist.
Bitte mal die Schadens-Geilheit abstellen, nur weil es um Intel geht...

[Iscaran]

Achja und:

Die Chromium Aussage bezieht sich auf Zombieload Variant 1.

Variant 2 umgeht das Problem und ist NUR durch abschalten von TSX fixbar. Auch die Microcode updates sind NICHT ausreichend.
Siehe Zombieload Whitepaper und die Differenzierung in die 5 Zombieload varianten.
V2 MDS-TAA ist nicht gefixed und kann umgangen werden. (und ist nebenbei auch noch die "performanteste" der Zombieload-Lücken.

[Iscaran]

Ich weiss nicht ob es schon jemand gesehen hat - aber es gibt ein nettes "Tool" von den MDS / Zombieload PoC-Findern.

Nennt sich MDS-Tool.
https://mdsattacks.com/files/mdstool-win-20190519.zip

Es zeigt auf sehr überschaubare Weise den "Patch"Status des Systems.
Finde ich jedenfalls "userfreundlicher" als die PowerShell-Skripts von MS.

[aufkrawall]

Immerhin wird SotTR mit Linux 5.3.11 nicht noch langsamer.

[Complicated]

Wer hier noch die Frage stellt ob Consumer davon betroffen sind, der begreift wohl das Ausmaß was hier vorgeht nicht so ganz. Alleine die schiere Anzahl und die Art und Weise wie Intel diese Lücken abarbeitet ist eine Bankrotterklärung.

In particular, at the request of Intel, we withheld the following details on the original RIDL/MDS disclosure date:


TSX Asynchronous Abort (TAA). Intel's TSX hardware feature can be used to efficiently mount a RIDL attack even on allegedly non-vulnerable CPUs (with hardware mitigations).
Alignment faults. These can be used to trigger an exception, giving an attacker yet another way of leaking data. This attack vector seems to be fixed in the latest generation of Intel CPUs.
Flawed MDS mitigation. The initial mitigations against MDS clear the buffers by writing stale, potentially sensitive, data into these buffers, allowing an attacker to leak information despite mitigations being enabled.
The RIDL test suite. We can now release the RIDL test suite at https://github.com/vusec/ridl.


Damit kann Intel seine Server-Kunden mal auf lange Sicht vergessen. Nun weiss man auch warum Google auf AMD umsteigt. Dass wird kein Versuchsballon, sondern ist ein kompletter Vertrauensverlust in Intel.

Es gibt eine RIDL-Testsuite , die seit Mai 2019 von den Forschern zur Verfügung gestellt wurde und was Intel daraus macht ist reines Marketing mit rechtlichen Mitteln. Und jede neue Intel CPU ist immer noch verwundbar - kein Hardwarefix der wirklich hilft, ebenso wenig wie die ganzen microcode Updates. TSX ist kaputt.

Und das wird nun lediglich der Anfang sein, wenn Forscher nach den Erlebnissen nun keine Embargos mehr unterschreiben, da Intel während dem Embargo auch überhaupt keine Informationen geteilt hat. Man muss sich nur mal die Timeline ansehen.

[aufkrawall]

Wer hier noch die Frage stellt ob Consumer davon betroffen sind, der begreift wohl das Ausmaß was hier vorgeht nicht so ganz.
Na zum Glück gibts ja dich, der es sicherlich erklären kann. Oder?

[Complicated]

Na zum Glück gibts ja dich, der es sicherlich erklären kann. Oder?Neidisch?:biggrin:

[Zossel]

Hier (https://blog.fefe.de/?ts=a332c070) wird es wirklich abstrus:

Intel hat Patches an binutils geschickt, damit die NOPs einbauen (der Nichtstun-Befehl, 1 Byte lang), um die conditional jumps zu verschieben.

Mal eben alles neu compilieren, echt super Intel.

[r-or]

Ja, das heißt dass jede x86 binary jetzt größer wird und diese 'fixes' für jegliche CPU enthält? Also auch CPUs, die nicht betroffen sind? Denn man kann ja nicht erwarten dass in Zukunft überall 2 Downloads angeboten werden: ein langsamerer, größerer mit mitigations für Intel und der andere ohne. Muss man in Zukunft seinen Kernel selbst neu kompilieren? Wie werden die distros das handlen?

Sollte eigentlich direkt abgelehnt werden für mainline.

[Birdman]

Es wird nur ein Compilat geben, das eine Byte interessiert schlussendlich niemanden. Wir schleppen ja noch für ganz viele andere CPUs und Bugs irgendwelchen Zusatzcode mit, von dem man i.d.R. nix braucht.

[r-or]

Dafür gibt es μcode Updates. Natürlich mit Performance Impact, aber nur für die betroffenen CPUs. Könnte ja jeder kommen..

[Birdman]

hmm? Alleine für die bisherigen Specte Sicherheitslücken gibts im Kernel ganz viel neuer Code den alle bekommen. Ist dann natürlich nicht alles für alle aktiv aber ein paar zusätzliche if-else Abfragen muss trotzdem jedes System stemmen.

[Badesalz]

hmm? Alleine für die bisherigen Specte Sicherheitslücken gibts im Kernel ganz viel neuer Code den alle bekommen. Ist dann natürlich nicht alles für alle aktiv aber ein paar zusätzliche if-else Abfragen muss trotzdem jedes System stemmen.if ist grad eine schlechte Lösung ;)

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

edit:
Wegen https://blog.fefe.de/?ts=a335e6a6

[Tarkin]

https://www.phoronix.com/scan.php?page=article&item=jcc-firefox-chrome&num=3

4.2% im Schnitt Performance Verlust bei Browser-Benchmarks.

und aus einem 9900KS wird plötzlich wieder ein 9900K

Ich hoffe inständig, jemand hat die Eier und verklagt diese Bande

[Zossel]

Es wird nur ein Compilat geben, das eine Byte interessiert schlussendlich niemanden. Wir schleppen ja noch für ganz viele andere CPUs und Bugs irgendwelchen Zusatzcode mit, von dem man i.d.R. nix braucht.

Der Schwenk auf 64 Bit dürfte einige Altlasten entsorgt haben.

[AnnoDADDY]

Glaube ich auf Hardware Seite weniger. Da wird doch alles aus legacy Gründen mitgenommen und beibehalten. Es braucht eigentlich komplett neue Architekturen für OS und Hardware, aber das traut sich leider keiner...

[BigKid]

https://www.phoronix.com/scan.php?page=article&item=jcc-firefox-chrome&num=3

4.2% im Schnitt Performance Verlust bei Browser-Benchmarks.

und aus einem 9900KS wird plötzlich wieder ein 9900K

Ich hoffe inständig, jemand hat die Eier und verklagt diese Bande

Wäre das nicht ein Fall für ne Musterfeststellungsklage?
Gegen einzelne lässt es Intel wohl echt drauf ankommen - ich hab versucht bei meinem Händler auf Gewährleistung zu gehen - mit Anwalt - ich hätte wirklich klagen müssen...

[Ganon]

Es braucht eigentlich komplett neue Architekturen für OS und Hardware, aber das traut sich leider keiner...

Und das stellst du dir wie vor? Wenn du eine garantiert fehlerfreie CPU haben willst, musst du halt eine klassische In-Order RISC CPU bauen. Dann bist du bei der Performance aber in den frühen 90ern.

Das ist der schlichte Grund, warum sich das "niemand traut".

[Opprobrium]

Glaube ich auf Hardware Seite weniger. Da wird doch alles aus legacy Gründen mitgenommen und beibehalten. Es braucht eigentlich komplett neue Architekturen für OS und Hardware, aber das traut sich leider keiner...
Itanium ;)

[#44]

if ist grad eine schlechte Lösung ;)

https://blog.fefe.de/?ts=a332c070
Nur, damit es nicht unerwähnt bleibt: Auch Fefe hat da nochmal editiert.

[Zossel]

Glaube ich auf Hardware Seite weniger. Da wird doch alles aus legacy Gründen mitgenommen und beibehalten. Es braucht eigentlich komplett neue Architekturen für OS und Hardware, aber das traut sich leider keiner...

RISC-V, läuft allerdings kein Windows drauf.

[Ganon]

RISC-V, läuft allerdings kein Windows drauf.

RISC-V ist "nur" ein Instruction Set, kein fertiger Prozessor (zum Vergleich armv8 vs. ARM Cortex-A72). Je nachdem wie du den RISC-V Prozessor baust, kann der auch von Meltdown, Spectre und Co. betroffen sein.

[iuno]

Ja, dasselbe gilt aber fuer ARMvX oder x86, die koennte man auch ohne speculative execution bauen.

Da das so mit der groesste Performance Faktor der letzten Jahre ist und jetzt erstmal eher kleinere "Klitschen" (in Relation zu Intel) RISC-V CPUs bauen, ist die Wahrscheinlichkeit eher hoeher, dass die dafuer gar keine Ressourcen haben. Das sind ja eher einfache Designs zum Start.

Gibt es eigentlich irgendeine Prognose/Schaetzung wie schnell/lahm eine "moderne" (sofern man das dann uberhaupt noch so nennen kann) CPU so ganz ohne speculative execution und HT waere?

[Ganon]

Gibt es eigentlich irgendeine Prognose/Schaetzung wie schnell/lahm eine "moderne" (sofern man das dann uberhaupt noch so nennen kann) CPU so ganz ohne speculative execution und HT waere?

Vergleiche doch mit einem Cortex-A53. Der ist zwar auch nicht sauber zum Thema "bugfrei" aber er ist immun beim Thema Meltdown und Spectre.

[Zossel]

RISC-V ist "nur" ein Instruction Set, kein fertiger Prozessor (zum Vergleich armv8 vs. ARM Cortex-A72). Je nachdem wie du den RISC-V Prozessor baust, kann der auch von Meltdown, Spectre und Co. betroffen sein.

Ging es nicht um Altlasten?

[Zossel]

Vergleiche doch mit einem Cortex-A53. Der ist zwar auch nicht sauber zum Thema "bugfrei" aber er ist immun beim Thema Meltdown und Spectre.


The lack of speculation in the ARM1176, Cortex-A7, and Cortex-A53 cores used in Raspberry Pi render us immune to attacks of the sort.

https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

[Ganon]

Ging es nicht um Altlasten?

Ändert aber am Thema Sicherheit nichts. Ob Altlasten da sind oder nicht, ändert nichts daran, dass man mit RISC-V auch einen extrem kaputten Prozessor bauen kann.

Man könnte vermutlich auch einen komplett altlastenfreien x86_64 Prozessor bauen. Der ist dann zwar nicht mehr 100% kompatibel, aber ich denke etwaige Anpassungen würden sich im Rahmen halten. Gerade im Vergleich zu einem kompletten Architekturwechsel.

edit:
https://www.raspberrypi.org/blog/why-raspberry-pi-isnt-vulnerable-to-spectre-or-meltdown/

Ja, gilt halt aber nur beim Pi <= Pi3. Der Pi4 hat einen A72, der auch von fast der ganzen Spectre-Kategorie betroffen ist.

[aufkrawall]

Es ist ja schon bezeichnend, als wie sicher Zen bez. des Themas nach der langen Zeit immer noch gilt. Und die Mitigations, die man für Zen in Betracht ziehen kann, wenn man denn unbedingt will, kosten afair quasi keine Performance.

[Zossel]

Man könnte vermutlich auch einen komplett altlastenfreien x86_64 Prozessor bauen. Der ist dann zwar nicht mehr 100% kompatibel, aber ich denke etwaige Anpassungen würden sich im Rahmen halten. Gerade im Vergleich zu einem kompletten Architekturwechsel.

Neulich gab es doch wieder einen Aufschrei weil irgendein uraltes Gammel-Spiel wg. Bugs nicht richtig auf den neuen Zens lief. Was soll das erst werden wenn überhaupt kein 32-Bit Zeug mehr unter Windows läuft.

Mittlerweile kommen die neuen Löcher jeden Tag: https://www.heise.de/security/meldung/Angriffe-auf-Trusted-Platform-Modules-von-Intel-und-STMicroelectronics-4585573.html

[Zossel]

Ja, gilt halt aber nur beim Pi <= Pi3. Der Pi4 hat einen A72, der auch von fast der ganzen Spectre-Kategorie betroffen ist.

Irgendwann kommt auch wieder so ein Ding: https://de.wikipedia.org/wiki/Carrington-Ereignis

[Ganon]

Neulich gab es doch wieder einen Aufschrei weil irgendein uraltes Gammel-Spiel wg. Bugs nicht richtig auf den neuen Zens lief. Was soll das erst werden wenn überhaupt kein 32-Bit Zeug mehr unter Windows läuft.

Und wenn du die Architektur wechselst, läuft gar nichts mehr (ohne Emulation). Wähle das kleinere Übel.

[Ganon]

Phoronix Benchmarks immer mit Vorsicht genießen, aber scheinbar ist es zumindest bei Cascade Lake wohl besser TSX einfach abzuschalten, statt die Mitigations zu fahren. In fast allen Benchmarks ist der Performanceunterschied ohne TSX wesentlich geringer als wenn man TSX mit Mitigations fährt.

https://www.phoronix.com/scan.php?page=article&item=zombieload-v2-taa&num=2

Hab auf Twitter auch schon irgendwo gelesen, dass im Standard Linux wohl TSX einfach abschalten wird und die Mitigations nur fährt, wenn man TSX explizit einschaltet.

[Galaxie]

Ich finde beides sehr bedenklich, aber bei Intel ME weis man wengistens was diese genau macht,
Amd gibt sich hierzu sehr verschlossen.

Deswegen nutze ich immer noch einen FX 9370.

Mir ist Amd zu Suspekt und Intel mit einer wissentlichen Backdoor, verwende ich 100% nicht als Heim PC,
sicher wenn man en neuesten Schei** auf dem PC spielen muss kommt man dabei wohl nicht rum.

Aber ich bin Sei Dank in der Lage das mir das vollkommen egal sein kann.
Keine Grafikhure bin und deshalb zwischen Pro und PC wechseln kann wie mir je nach Genre beliebt.

Als auch der neueste Schei** an Hrdware sonst wo vorbei gehen kann, macht das Leben einfacher und spart auch Geld (wobei FX 9370 naja)

[Tarkin]

https://twitter.com/damageboy/status/1194751035136450560

Intel JCC microcode fixes: 20% performance loss on some code

hmmm... alles klar und intel sagt der fix kostet 0-4%

das ist einfach unfassbar! Die müssen endlich einmal richtig eine euf den DECKEL bekommen. Was ist da los?? Lug und Betrug sind hier wohl an der Tagesordnung bei Intel

[woodsdog]

https://twitter.com/damageboy/status/1194751035136450560

Intel JCC microcode fixes: 20% performance loss on some code

hmmm... alles klar und intel sagt der fix kostet 0-4%

das ist einfach unfassbar! Die müssen endlich einmal richtig eine euf den DECKEL bekommen. Was ist da los?? Lug und Betrug sind hier wohl an der Tagesordnung bei Intel

Jetzt komm mal runter... ich sehe die Aussage von Intel in keiner weise als Lug und Betrug an weil die eben von "Im schnitt über verschiedene Benchmarks" sprechen.
Der Typ auf Twitter hat halt Code gefunden der besonders schlecht mit den Fixes performt - so what. War doch bisher immer so das spezielle Codebeispiele besonders gelitten haben. Das jetzt aber zu verallgemeinern ist genau so unehrlich weil keine Software, Spiele etc nur aus Array.Sort bestehen :rolleyes:

[Armaq]

Ich denke, wenn Intel wirklich die Performance aufgibt und Sicherheit priorisiert, dann haben wir sofort mehr als 20% Rückstand auf AMD. Ihr Verhalten lässt keinen anderen Schluss zu.

[Brillus]

Bzgl. des Compilerpatches. AMD CPUs scheint der egal zu sein: https://www.phoronix.com/scan.php?page=news_item&px=AMD-With-Intel-JCC-Assembler

[Iscaran]

Strenggenommen stimmt das nicht.
Er kostet 0.3% Performance...für etwas das es eigentlich nicht bräuchte @AMD.
Der Compilerpatch wird ja "nur" gemacht damit man die negative Performanceeinbuße die der Microcode Patch bringt @Intel von ~4% runterbringen kann auf <1%.

Finde ich ehrlich gesagt aber dennoch unter aller SAU hier alle anderen (und sei es auch noch so gering) zu bestrafen, nur weil die eigene CPU verbugged ist. Aber klar mit 90% Marktmacht kann man das schon durchdrücken.

[mboeller]

Strenggenommen stimmt das nicht.
Er kostet 0.3% Performance...für etwas das es eigentlich nicht bräuchte @AMD.


0,3% x 5GHz = 15MHz ...

[Iscaran]

@mboeller

Ja aber die 15 MHz "mehr" OC sind ein unnötiger Verlust den @ALLE CPUhersteller "einbüßen" nur weil Intel keinen performantere Microcode Patch hinbekommt.

Ferrari möchte gern das alle anderen Autos 1km/h runtergebremst werden, weil sonst die Motorsteuerung ihrer Ferraris das bei den Drehzahlen nicht hinbekommt (und sie deswegen 10 km/h langsamer fahren müsste als ursprünglich gedacht).

[Birdman]

Aber klar mit 90% Marktmacht kann man das schon durchdrücken.
Blablabla, was für ein dummes Geschwätz....diese Marktmacht Tränendrüse Pille ist so abgedroschen wie falsch.
Dir ist wohl nicht klar dass ein Grossteil der Programmierer für Firmen arbeiten welche zu 95%+ mit Intel Systemen ausgerüstet sind.
Dementsprechend schreibt man solche Patches einfach auch mal ganz egoistisch für sich selber, oder eben für diese 95% der "Opfer" von Intel Systemen.

[Opprobrium]

Blablabla, was für ein dummes Geschwätz....diese Marktmacht Tränendrüse Pille ist so abgedroschen wie falsch.
Dir ist wohl nicht klar dass ein Grossteil der Programmierer für Firmen arbeiten welche zu 95%+ mit Intel Systemen ausgerüstet sind.
Dementsprechend schreibt man solche Patches einfach auch mal ganz egoistisch für sich selber, oder eben für diese 95% der "Opfer" von Intel Systemen.
Sehe da jetzt keinen Widerspruch ;)

[aufkrawall]

Intel schmeißt munter mit µcode-Updates um sich:
https://github.com/intel/Intel-Linux-Processor-Microcode-Data-Files/releases
Wirkt ziemlich chaotisch.

[Benutzername]

Strenggenommen stimmt das nicht.
Er kostet 0.3% Performance...für etwas das es eigentlich nicht bräuchte @AMD.
Der Compilerpatch wird ja "nur" gemacht damit man die negative Performanceeinbuße die der Microcode Patch bringt @Intel von ~4% runterbringen kann auf <1%.

Finde ich ehrlich gesagt aber dennoch unter aller SAU hier alle anderen (und sei es auch noch so gering) zu bestrafen, nur weil die eigene CPU verbugged ist. Aber klar mit 90% Marktmacht kann man das schon durchdrücken.

Ähm der compiler ist von intel. Natürlich optimiert der für intel CPUs. Den muss man ja nicht benutzen um x86 code zu erstellen.

[Iscaran]

Hast du die Kommentare beim Phoronix gelesen...

90% der Programmierer nehmen natürlich den "Generic" Codepath - der ist natürlich dann "intel gepatched für alle".

Genau das ist ja die Schweinerei...und das betrifft nicht nur den Compiler von Intel. Das war von Intel die ernsthaft propagierte Lösung für alle Compiler.

[Benutzername]

Hast du die Kommentare beim Phoronix gelesen...

90% der Programmierer nehmen natürlich den "Generic" Codepath - der ist natürlich dann "intel gepatched für alle".

Genau das ist ja die Schweinerei...und das betrifft nicht nur den Compiler von Intel. Das war von Intel die ernsthaft propagierte Lösung für alle Compiler.

Ach so, die wollen das überall haben. Im GCC hat das natürlich nix zu suchen als default. Was andere C-compiler Hersteller machen ist deren Sache.


intel muss ja richtig die Muffe gehen, wenn sie schon die Konkurrenz so untergraben müssen.

[Badesalz]

Das jetzt aber zu verallgemeinern ist genau so unehrlich weil keine Software, Spiele etc nur aus Array.Sort bestehen :rolleyes:Wenn ich array sort google, bekomme ich 85.5 Mio. Treffer. Memcpy bringt es auf 67.8 Mio.
Hmm...

[woodsdog]

Wenn ich array sort google, bekomme ich 85.5 Mio. Treffer. Memcpy bringt es auf 67.8 Mio.
Hmm...

Was die Anzahl von Suchergebnissen mit dem Thema zu tun hat, darfst du dann gerne als Erklärung mit dazu schreiben.
Alternativ gerne eine Anwedung/Spiel benennen, welche analog zu den kleinen Code-Schleifen 20ish% Leistung durch den Patch verliert.

Disclaimer: Natürlich ist das alles Scheisse von Intel... Trodzdem ist es nicht zielführend, irgendwelche extrem-Werte als allgemeingültig hinzustellen.

[Badesalz]

:rolleyes:
Diese Funktion wird viel öfters im Netz besprochen (noch bevor eine Welle mit sort array wegen Intelpatches losgehen konnte), als memcpy. Und memcpy ist jetzt nicht grad was seltenes...

Es ging darum - ok, mit einem Augenzwinker - daß man 2x nachschauen sollte bevor man Thesen aufstellt welche Operatonen den Leute mehr und welche weniger wichtig sind.

Von der Quali der Verallgemeinerung (Google) find ich das jetzt nicht wirklich schlechter als wenn man sagt, Programme bestehen doch nicht nur aus sort array ;)

WIRKLICH INTERESSANT wäre so langsam jemand der ehrlich genug ist paar reale Benches - Anwendungen und Spiele im CPU-Limit - mit einem komplett CPU-ungepatchten Intelsys und mit einem aktuellst gepatchten, zu machen.
Ergo nicht schauen wieviel der aktuelle Patch real kostet, sondern wieviel Leistung die Leute in den letzten 2 Jahren verloren haben.

[aufkrawall]

Hier nochmal mit linux 5.4-rc8 ohne TSX kompiliert, intel-ucode 20191115:
mitigations=off
https://abload.de/thumb/screenshot_20191118_1m7jut.png (https://abload.de/image.php?img=screenshot_20191118_1m7jut.png)

Standard-Mitigations:
https://abload.de/thumb/screenshot_20191118_1qhj6w.png (https://abload.de/image.php?img=screenshot_20191118_1qhj6w.png)

~9%

[Badesalz]

Das ist schon recht ordentlich. Ordentlich weniger :ulol:

[aufkrawall]

Tja, ist auch vorstellbar, dass es bei I/O-Vorgängen noch teurer wäre. Recht unschön, da in Bewegung die fps im CPU-Limit eh noch niedriger sind. Und da das OS durch Caching I/O-zugriffe verringert, müsste man eigentlich vor jedem Run auch noch den Cache flushen.

[woodsdog]

Tja, ist auch vorstellbar, dass es bei I/O-Vorgängen noch teurer wäre. Recht unschön, da in Bewegung die fps im CPU-Limit eh noch niedriger sind. Und da das OS durch Caching I/O-zugriffe verringert, müsste man eigentlich vor jedem Run auch noch den Cache flushen.

Danke für die Bilder.
Das bestätigt ja nur genau das was ich gesagt habe....
Man sieht ganz toll, das am ende real 9-10% raus kommen wenn ALLE fixes zusammen aktiv sind. (und ja, i/O leidet erheblich mehr, dass ist aber wie breit festgestellt für privat user fast immer paktisch egal)

von den "Intel JCC microcode fixes: 20% performance loss on some code" bleiben halt in der Praxis glaubhafte 4ish% hängen. Aufschrei Ende.

Dieses Geschwurbel, das die Anzahl der Google-Suchergebnisse mit dem Thema zu tun hat war super kreativ.

[Badesalz]

@woodsdog
Ja, war schon kreativ. Aber, sozusagen, "analog". Wie du mathematisch 10% und 4% nahezu gleichsetzt, find ich wesentlich kreativer.

Wenn ALLE aktuellen Patches, alle Microcodes drauf sind, ist man je nach CPU zwischen 9% und 12%. Im Schnitt. Wenige Programme liegen drunter, einige liegen bei nah 14%.

Wo steht das? Wirst das mit der Zeit noch mitbekommen...

Nein, sind keine 20%. Und nein, auch keine 4%.

[Iscaran]

4% ist das neue 9% ;)...

Die letzte Intel CPU hat man sich ja gekauft weil man sich krampfhaft daran geklammert hat daß diese immernoch im Schnitt 3 % schneller ist SingleCore als der Ryzen...

[Opprobrium]

@woodsdog & @badesalz: Euch ist schon klar, daß ihr im Grunde dasselbe schreibt :confused: (Stichwort: ALLE)

[Badesalz]

@Opprobrium
Mir ist das schon klar. Wenn zwei über das gleiche reden bedeutet das aber nicht, daß beide der Sache mit gleich viel Grips betrachten...

[Birdman]

4% ist das neue 9% ;)...

Die letzte Intel CPU hat man sich ja gekauft weil man sich krampfhaft daran geklammert hat daß diese immernoch im Schnitt 3 % schneller ist SingleCore als der Ryzen...

die 4% hat Intel nur für den JCC Workaround genannt und nicht alle Mitigationen seit Anbeginn der (Spectre) Zeit

[Armaq]

Nimm doch mal ne ungepatchte Intel Kiste und eine gepatchte, mach dann nochmal die Softwarepatches raus und dann wieder rein. Da sind meine 20 Prozent konservativ geschätzt. :)

[aufkrawall]

Wird das hier jetzt ein Wettbewerb, wer die dümmsten BS-Zahlen feil bietet?

[Badesalz]

die 4% hat Intel nur für den JCC Workaround genannt und nicht alle Mitigationen seit Anbeginn der (Spectre) ZeitIch finde da aber nichts charmantes dran, als Endbenutzer, das immer einzeln "durchzublättern".
Man macht immer jeweils alles drauf, und schaut was gegenüber ZPSS (zero patches since Spectre) übrig bleibt.

Und die "Programme" dafür auch kleinwenig bunter wählt und nicht bei 3 Spielen die FPS kurz betrachtet Sind wir alle knapp 16 oder was?

[aufkrawall]

Wieso seit Spectre und nicht alle sinnvollen Mitigations on vs. off?
Davon ab könnte die Ruhe zum Teil auch einfach dem Sachverhalt geschuldet sein, dass Consumer-Software eher im niedrig einstelligen Bereich ausgebremst wird...

[Benutzername]

Wieso seit Spectre und nicht alle sinnvollen Mitigations on vs. off?
Davon ab könnte die Ruhe zum Teil auch einfach dem Sachverhalt geschuldet sein, dass Consumer-Software eher im niedrig einstelligen Bereich ausgebremst wird...

Eben. Otto Normalbüromensch merkt es eh nicht. Und auch die meisten Daddler fahren ihre Spiele mit suboptimalen Einstellungen. Siehe zum beipiel das Rumgeheule einiger bei RDR2, daß eine 2080Ti nicht auf max ultra locker läuft. Oder was Ich sonst so bei weniger versierten Freunden gesehen habe. Die waren alle imme rüberrascht, wenn Ich erheblich mehr FPS rausgekitzelt habe durch zB Reduktion weniger sichtbarer Details etc. Also viele merken es eigentlich nicht bis kaum, daß ihr Win10 ihnen die neueste Firmware für ihre intel CPU eingespielt hat.


uind ansonsten dürfte sich auch shcon ein gewisser Fatalismus breit gemacht haben. Bei jeder neuen Lücke in einer intel CPU zuckt man nur noch mit den Schultern. Neuanschaffung ist aber noch nicht im Plan.

[Birdman]

Ich finde da aber nichts charmantes dran, als Endbenutzer, das immer einzeln "durchzublättern".
Das ginge auch nicht, niemand kann so genau sagen was die einzelnen Mitigationen ausmachen und je nach CPU Model kosten diese ja auch unterschiedlich viel.
Es gibt auch nicht DEN Mitigationspatch für jede Lücke, in vielen Fällen wurden diese weiterentwickelt, adaptiert oder geändert (prominentes Beispiel ist hier SpectreV2 unter Windows, wo Microsoft die Mitigation nach einem Jahr auf die Retpoline Methode umgeschrieben hat und somit weniger Performanceverlust erzeugt)

Wenn Du wissen willst was es - stand Heute - kostet, muss Du einen aktuellen Test suchen/machen, der genau dein CPU Model mit und ohne aktiver Mitigation vergleicht.
(und das bitte ohne diese ominösen "4%/JCC" Patch, denn der gehört hier eigentlich nicht hin/rein)


Man macht immer jeweils alles drauf, und schaut was gegenüber ZPSS (zero patches since Spectre) übrig bleibt.
Das wäre hahnebüchen und sinnlos - da haben ja alle andern/allgemeinen Änderungen von BIOS, Betriebssystem und Programmen (die in der Zeit gekommen sind) mehr Einfluss als die Spectre Patches...
Der einzige sinnvolle und realistische Vergleich ist aktuellstes Patchstand von OS und Bios und dann per Konfiguration deaktivierte/aktivierte Mitigation.

[Cubitus]

Hab mich heute mit der Thematik etwas mehr beschäftigt..

Eigl überleg ich mir ernsthaft nach so einem Chaos meine Intel CPU raus zu werfen und mir eine adäquate AMD-CPU zu holen.

1. Intels Marketing, meh
2. Systemsicherheit, meh
3. Leistung durch diverse Updates, meh
4. immer neue Bios Version flashen, falls überhaupt verfügbar, meh

Intel Beschiss siehe Matlab z.b.. was soll sowas !?

Intel CPUs waren damals noBrainer heutzutage bereiten sie einem wirklich Kopfzerbrechen..

Danke für die Bilder.
Das bestätigt ja nur genau das was ich gesagt habe....
Man sieht ganz toll, das am ende real 9-10% raus kommen wenn ALLE fixes zusammen aktiv sind. (und ja, i/O leidet erheblich mehr, dass ist aber wie breit festgestellt für privat user fast immer paktisch egal)

Das sind 10 Prozent zu viel, außerdem wer weiß was noch kommt?

[Complicated]

Vor allem 10% ohne dass die CPU sicher ist.

[aufkrawall]

4. immer neue Bios Version flashen, falls überhaupt verfügbar, meh

Microcode via OS ist real nicht unsicherer, aber bei Windows ist man dafür natürlich von Microsoft abhängig. Unter Arch Linux gibts jeden neuen Microcode quasi instant via Repository.


Intel CPUs waren damals noBrainer heutzutage bereiten sie einem wirklich Kopfzerbrechen..

Seit Zen 2 ist AMD für 99% der User eh vernünftiger, selbst ohne Intels miesem Gehabe.


Das sind 10 Prozent zu viel, außerdem wer weiß was noch kommt?
Ist bisher aber auch der Härtefall hier, Spiele mit deutlich weniger ausgelasteten Threads liefen bislang irgendwo im Rahmen der Messungenauigkeit langsamer.

[Badesalz]

Wieso seit Spectre und nicht alle sinnvollen Mitigations on vs. off?Was sind sinnvolle Mitigations? Gibts da auch unsinnige?

Ist das nicht sowieso ein Witz, daß die Patches "Mitigations" heissen? Die lösen die (Sicherheits)Probleme ja nicht.
https://dict.leo.org/german-english/mitigation
Sie "entschärfen" und "lindern" nur diese Sicherheitsrisiken. Die restlichen Vorschläge auf LEO gelten wohl der anschliessenden Leistung der CPU :ulol:

Mitigations... Geile Nummer :uup:

Seit Zen 2 ist AMD für 99% der User eh vernünftiger, selbst ohne Intels miesem Gehabe.Boards. Mit der Leistung pro € kann man sich schon länger arrangieren, wenn man das kühl überschaut was man wirklich braucht und was es kosten soll. Es geht immer (noch) um die Boards, was die Leute davon ggf. abhält.
Der alten Zeit wegen. Weil? Weil irgendwie immer alles einen kleinen Tacken gemählicher gewesen (USB, SATA, Ethernet, Speicherdurchsatz) als bei Intel und nicht ganz so fehlerfrei.

Das sind die Schwerpunkte auf die man setzen soll. Jetzt. Von den CPUs sind nun alle ÜBerzeugt. Wer zögert ohne Fanboy zu sein (in Blau), tut das diesmal nicht mehr wegen der CPU.

Speicher bleibt aber noch ein Thema. Das Timingsmassaker kann man eigentlich keinem zumuten. Der Checker zeigt aber, daß nicht immer alles brauchbar zündet. Das muß weg sowas (mit den Fehlzündungen)

[Iscaran]

@Badesalz:

Zieh dich doch nicht an der Semantik des Wortes "mitigation" hoch. Für viele Lücken sind diese "echte" Patches...zumindest solange bis keiner wieder einen neuen Workaround hat den Patch zu durchbrechen.

Stichwort KASLR, KAISER, KPTI, in Kontext von Meltdown.

KPTI vs Meltdown ist demnach ein "echter Patch" - ebenso wie KASLR für AMD-Systeme notwendig ist da sonst diese Lücke unabhängig von der CPU ausgenutzt werden kann (hat mit Meltdown aber nix zu tun)

[Badesalz]

Zieh dich doch nicht an der Semantik des Wortes "mitigation" hoch.Wer hat den Begriff für diese Patches seinerzeit überhaupt lanciert?

Früher nannte man Patches beiläufig Fixes. Heute sind das Mitigations und die Leute quatschen das auch noch fröhlich-unreflektiert nach als wenn sie stolz drauf wären einen vermeindlichen Fachbegriff mehr zu kennen :ulol:

[aufkrawall]

Was sind sinnvolle Mitigations? Gibts da auch unsinnige?

Kann man so sehen, Linux stellt standardmäßig Hyperthreading nicht ab.

[aufkrawall]

Was zum Fick?
Scores im Octane 2.0 JS-Benchmark FF 70 Linux 6700k:

mitigations on: ~32300
mitigations off: ~38300

Ohne ~18,5% schneller bzw. höherer Score. :freak: :freak:

https://chromium.github.io/octane/

[Armaq]

Voll unrealistisch die 20%...

[Birdman]

Scores im Octane 2.0 JS-Benchmark FF 70 Linux 6700k:
Da es sieht hier um einen Browserbenchmark handelt- war die Mitigation von Spectre1 auch aktiv/inaktiv bei deiner Messung?

[aufkrawall]

Ganz einfach mitigations=off vs. Standard. Aber es kommt noch besser: Mit mitigations=off + ungeladenem intel-ucode beträgt der Benchmark-Score ca. 40300.
25% ;D

[Iscaran]

Wundert mich nicht. Hier der ausführliche JCC-fuck up nachtest von Phoronix.

Schade daß er nicht auch eine AMD CPU mitgeschleppt hat um den Compiler Fuck-Up mitzubenchen der aus den -9% die sage und schreibe 2-3% macht die am Ende hängen bleiben.
https://www.phoronix.com/scan.php?page=article&item=cascadelake-jcc-taa&num=7

[dildo4u]

i9 10980XE büßt laut diesem Test durch die Hardware Fixes ordentlich ein.

https://youtu.be/vuaiqcjf0bs

SSD Tests wäre auch Interessant.

[Birdman]

Ganz einfach mitigations=off vs. Standard. Aber es kommt noch besser: Mit mitigations=off + ungeladenem intel-ucode beträgt der Benchmark-Score ca. 40300.
25% ;D
Spectre1 hat ja nix mit Microcode und OS zu tun, sondern wird/wurde in der jeweiligen Software gefixt, namentlich eben Webbrowser.
Um hier die Mitigation zu deaktivieren, hilft es daher imho nicht im OS ein paar flags zu setzen, sondern wenn dann müsste das beim Webbrowser gemacht werden. (sofern der überhaupt eine solche Einstellung kennt)

[Ganon]

Spectre1 hat ja nix mit Microcode und OS zu tun, sondern wird/wurde in der jeweiligen Software gefixt, namentlich eben Webbrowser.

Auch der Kern fährt Spectre V1 Mitigations. Also ganz frei vom OS ist es nicht. Aber Spectre V1 Mitigations kommen hauptsächlich vom Compiler, die man soweit ich weiß manuell per Flag beim Compilieren deaktivieren muss. Die manuellen Änderungen im Browser sind hauptsächlich Site Isolation und geringere Timer-Genauigkeit. Beides Sachen die der Peformance an sich nicht schaden sollten. Zumindest nicht auf dem Level.

Du müsstest also letztendlich dein ganzes OS neu durchkompileren. Ich glaube nicht, dass der Aufwand lohnt, weil so gut wie jede halbwegs schnelle CPU von Spectre V1 betroffen ist. Aber wer es testen mag, nur zu.

[aufkrawall]

Mit Windows gibts keinen Unterschied beim Score zwischen on/off. Da müsste man jetzt mal einzeln schauen, was unter Linux dabei so teuer ist, und ob es unter Windows überhaupt diese Mitigations gibt. JCC Erratum µcode-Update scheint es für Windows ja auch noch nicht zu geben? Wenn man da durchsteigen will, muss man sich wohl die ganzen scheiß Docs von Microsoft in jeder Einzelheit reinziehen...

[r-or]

Convenient Zeitpunkt von Intel, der Fehler wird 2 Wochen vor Release des 10980 disclosed. Die meisten Mainstream Medien (anandtech etc) testen ausschließlich mit Windows, welches sicherlich noch keinen fix hat

:)

[Ganon]

https://cacheoutattack.com/

We present CacheOut, a new speculative execution attack that is capable of leaking data from Intel CPUs across many security boundaries. We show that despite Intel's attempts to address previous generations of speculative execution attacks, CPUs are still vulnerable, allowing attackers to exploit these vulnerabilities to leak sensitive data.

Moreover, unlike previous MDS issues, we show in our work how an attacker can exploit the CPU's caching mechanisms to select what data to leak, as opposed to waiting for the data to be available. Finally, we empirically demonstrate that CacheOut can violate nearly every hardware-based security domain, leaking data from the OS kernel, co-resident virtual machines, and even SGX enclaves.

Ein Workaround ist TSX abschalten bzw. Microcode Updates.

[robbitop]

Frage: wenn man mit einem Haswell @Windows10 das uCode Update vom BIOS nicht installiert und via Inspectre die Windows Meltdown + Spectre Patches deaktiviert - ist man dann von allen Performancenachteilen befreit? (Privat PC zum Spielen -> Security -> wayne ^^)

Oder werden Nachteile durch moderne Spiele die mit modernen Compilern erstellt worden sind entstehen, da gleich Mitigations in die Spiele integriert werden?

Ich habe von dem Thema keine Ahnung. Also sorry für die vielleicht dumme Frage. :)

[Ganon]

ist man dann von allen Performancenachteilen befreit?

Nicht allen. Zum Einen spielt dir Windows die Microcode Updates ein (d.h. du müsstest die relevanten Updates entfernen), zum Anderen gibt es softwareseitige Mitigations die du nicht immer abschalten kannst.

Ansonsten wird dir das Abschalten via Insprectre trotzdem etwas Mehrleistung bringen. Bei mir waren es bei einer sehr CPU/Threadlastigen Anwendung etwa 8%.

[y33H@]

In Spielen macht das bisher ja eh quasi nichts aus ... erschreckend ist, dass schon wieder selbst Cascade Lake betroffen ist.

[Lurtz]

In Spielen macht das bisher ja eh quasi nichts aus ... erschreckend ist, dass schon wieder selbst Cascade Lake betroffen ist.
Der Grund wurde ja genannt:
If Intel isn’t looking and is making no effort, who knows how many vulnerabilities are left?

[Iscaran]

Auch neu ist Vector Register Sampling (VRS):
https://software.intel.com/security-software-guidance/software-guidance/vector-register-sampling

Allerdings hat es kaum Impact.

Als Mitigation müsste wohl der bisherige MDS-Patch angepasst werden. Oder eben TSX-abgeschaltet werden.

[Rampage 2]

Ein Workaround ist TSX abschalten bzw. Microcode Updates.


Wird TSX eigentlich mittlerweile genutzt? Diesen Befehlssatz gibt es ja schon seit Haswell (allerdings mit einem HW-Bug; wurde erst mit Broadwell oder Skylake gefixt). Mittlerweile sollte der Anteil an CPUs mit Skylake- oder neuerem Unterbau doch ausreichend hoch sein, da Intel-CPUs insbesodere bei Gamern weiterhin sehr gefragt sind. Dasselbe gilt für AVX2. (seit Excavator und Zen auch bei AMD-CPUs eingebaut!)

Soweit ich es verstanden habe, sollte TSX das Multi-Threading von Anwendungen verbessern oder dessen Implementierung vereinfachen. Damals gab es auch kein DX12.

Hat Intel oder AMD selber das Interesse, diesen Befehlssatz auch AMD zur Verfügung zur stellen/von Intel anzunehmen? AMD wollte ja anfangs einen ähnlichen (eigenen) Befehlssatz für seine CPUs implementieren, aber daraus ist leider nichts geworden - so bleibt nur TSX als Möglichkeit...

R2

[Complicated]

AMD hat seit 2010 eine Technik die keine Datenlecks hat und wird sicher TSX (2012) nicht implementieren.
https://de.wikipedia.org/wiki/Transactional_Synchronization_Extensions
https://llvm.org/pubs/2010-04-EUROSYS-DresdenTM.pdf

Transactional Memory Operationen basieren auf spekulativer Ausführung.

[Tesseract]

Wird TSX eigentlich mittlerweile genutzt?
sicher nicht. dazu müsste intel mal damit anfangen es auf ALLEN eigenen CPUs freizuschalten, AMD dazu bringen es auch zu nuzten und dann könnte man jahre später vielleicht mal überlegen es zu nutzen.

[Ganon]

sicher nicht.

Die Verbreitung ist nicht hoch. In meinem Hobby-Bereich ist es z.B. der Playstation 3 Emulator RPCS3. Dieser hat(te) teils deutlich (+40%) von Intels TSX profitiert. Seit dem Microcode Update für MDS war es zwar weiterhin profitabel, aber nicht mehr so stark: https://rpcs3.net/blog/2019/07/31/progress-report-june-2019

Java kann auch mittels Command Line Parameter TSX nutzen (-XX:+UseRTMLocking).

[gravitationsfeld]

AMD hat seit 2010 eine Technik die keine Datenlecks hat und wird sicher TSX (2012) nicht implementieren.
https://de.wikipedia.org/wiki/Transactional_Synchronization_Extensions
https://llvm.org/pubs/2010-04-EUROSYS-DresdenTM.pdf

Transactional Memory Operationen basieren auf spekulativer Ausführung.
ASF wurde nie implementiert und die Datenlenks von TSX haben nichts mit der Spezifikation zu tun sondern spezifischen Hardware-Bugs.

Das AMD ASF ohne Bugs implementieren koennte ist reine Mutmassung deinerseits.

[Lehdro]

Passt gerade so schön: (https://www.heise.de/security/meldung/Intels-CSME-Tool-zur-Erkennung-von-Sicherheitsluecken-ist-selbst-verwundbar-4658767.html)
Intel hat wichtige Sicherheitsupdates veröffentlicht, die Lücken in unterschiedlicher Software schließen. [...]
Alleinig die Lücke in CSME hat Intel mit dem Bedrohungsgrad "hoch" eingestuft. Dabei handelt es sich um ein Erkennungstool, mit dem sich auf einem Computer Sicherheitslücken in Intel-Software aufspüren lassen.

https://i.redd.it/pzf5ab0feyh01.png

[JVC]

"Dabei handelt es sich um ein Erkennungstool,
mit dem sich auf einem Computer Sicherheitslücken in Intel-Software aufspüren lassen."
Ja das passt zu Intel ^^
Wenn man den "der mit dem Finger drauf zeigt" weck macht,
sind doch alle Probleme gelöst ... :ulol:

Aber was anderes wie "Vogel-Strauß-Taktik" ist man von Intel
im Bezug auf Sicherheitslücken ja gar nicht mehr gewohnt.

Ich kaufe erst wieder nen Intel, wenn das Produkt weitgehend frei von schweren Fehlern ist.
(ich finde das noch weit schlimmer als VWs Schummel-Software)
Warum Intel dies bezüglich noch keine Klagen am Hals hat ist mir sowieso ein Rätsel.

Naja, bei meinen Eltern deren Apples ist HT schon längst deaktiviert.
(die machen auch Banksachen und so)
Und mein 3570K hat ja kein HT. (hab dem spekulativem Teil nie getraut)

M.f.G. JVC

[Naitsabes]

HT hat nichts mit spekulativem Zeug zu tun.

[aufkrawall]

Lass ihn sich doch besser fühlen, wenn er schon keine CPUs mit UTZ-Zertifikat kaufen kann...

[Unicous]

Geht fröhlich weiter bei Intel. CSME ist noch löchriger als vorher angenommen:

https://arstechnica.com/information-technology/2020/03/5-years-of-intel-cpus-and-chipsets-have-a-concerning-flaw-thats-unfixable/

[Simon Moon]

https://www.golem.de/news/load-value-injection-reverse-meltdown-attacke-gegen-intel-cpus-2003-147160.html
Anders als bei bisherigen Meltdown-Attacken reicht es als Gegenmaßnahme nicht, "vergiftete" Zwischenspeicher wie den Inline-Fill-Buffer zu leeren. Stattdessen muss nach jedem Ladevorgang einer Instruktion eine Speicherbarriere (LFENCE) ausgelöst werden. Vorläufige und nicht optimierte Gegenmaßnahmen der Forscher zeigen, dass das die Performance um das bis zu 19-Fache reduziert. Selbst aktuelle, vermeintlich Meltdown-sichere CPUs sind ohne entsprechende Mitigation nicht ausreichend gesichert.

Oh Wow, Intel verkackt wieder mal hart.

[Wake]

Webauftritt dazu: https://lviattack.eu

Edit: Kann gelöscht werden, war nicht vom Golem-Artikel sondern Reddit aber kam ja auch in ersterem als Quelle vor.

[M4xw0lf]

https://www.golem.de/news/load-value-injection-reverse-meltdown-attacke-gegen-intel-cpus-2003-147160.html


Oh Wow, Intel verkackt wieder mal hart.
Grml. Wenn die Performance "um das 19-fache reduziert" wird, hätte man hinterher "-18" Performance :ulol:
In sinnvoll sollte es heißen, dass nur ca 5% Performance übrig bleiben.
Ok, Golem ist hierbei entschuldigt, da die das auf der offiziellen Website so formulieren. Um so schlimmer.

[Ganon]

Hmm, der Golem Artikel ist imo etwas schwammig. Von der Webseite:

which may slow down Intel SGX enclave computations 2 up to 19 times

Hab jetzt aber auch keine Ahnung wie verbreitet Anwendungen sind, die Intels SGX Enklaven benutzen. Geht vermutlich beim Endanwender gegen 0. Außerdem braucht es Admin-Rechte auf dem OS.

[iuno]

Grml. Wenn die Performance "um das 19-fache reduziert" wird, hätte man hinterher "-18" Performance :ulol:
In sinnvoll sollte es heißen, dass nur ca 5% Performance übrig bleiben.
X dauert halt 19x so lange im Vergleich zu vorher.

Der Fehler ist insbesondere im Englischen so verbreitet (oft auch im Positiven; "200% performance increase", wenn es am Ende 200%, also 100% Steigerung sind), dass ich mich oft frage, ob das dort ueberhaupt als Fehler gilt. Und rege mich trotzdem jedes Mal darueber auf :freak:

[Benutzername]

X dauert halt 19x so lange im Vergleich zu vorher.

Der Fehler ist insbesondere im Englischen so verbreitet (oft auch im Positiven; "200% performance increase", wenn es am Ende 200%, also 100% Steigerung sind), dass ich mich oft frage, ob das dort ueberhaupt als Fehler gilt. Und rege mich trotzdem jedes Mal darueber auf :freak:


Journalisten sind dort genauso doof wie hier. Und weil die das dauernd falsch schreiben färbt das leider auf die Allgemeinheit ab.

[y33H@]

Stimmt, alle nicht-Journalisten sind super clever =)

[Zossel]

Grml. Wenn die Performance "um das 19-fache reduziert" wird, hätte man hinterher "-18" Performance :ulol:
In sinnvoll sollte es heißen, dass nur ca 5% Performance übrig bleiben.
Ok, Golem ist hierbei entschuldigt, da die das auf der offiziellen Website so formulieren. Um so schlimmer.

Also ich lese daraus den folgenden Fakor (https://de.wikipedia.org/wiki/Multiplikation#Namensgebung): 1/19.

Aber bei dem Thema ist sowieso jeder mit seinen eigenen Definitionen unterwegs und jeder andere der nicht zufällig die eigene Definition teilt ist dann doof.

[iuno]

Also ich lese daraus den folgenden Fakor (https://de.wikipedia.org/wiki/Multiplikation#Namensgebung): 1/19
Dann hast du kein Leseverständnis.
19-fach ist ganz klar Faktor 19 und nicht 1/19.

Aber bei dem Thema ist sowieso jeder mit seinen eigenen Definitionen unterwegs

Nein. Die Dinge sind nicht ohne Grund klar geregelt und objektiv als richtig oder falsch einzustufen. Dass der mitdenkende Leser in manchen Fällen von sich aus drauf kommt dass es falsch ist ändert nichts daran und es bleibt halt dennoch falsch.

Stimmt, alle nicht-Journalisten sind super clever =)

Das behauptet keiner. Es ist aber offenbar, dass viele Journalisten sich noch nicht entschieden haben, ob sie ihre Verantwortung eher in der Information oder der Verblödung der Gesellschaft sehen. Das schließt auch die ein, die sich überhaupt noch nie Gedanken über ihre Verantwortung gemacht haben und dann implizit letzteres wahrnehmen. Aber dafür gibt es eigene threads.

[M4xw0lf]

Also ich lese daraus den folgenden Fakor (https://de.wikipedia.org/wiki/Multiplikation#Namensgebung): 1/19.

Aber bei dem Thema ist sowieso jeder mit seinen eigenen Definitionen unterwegs und jeder andere der nicht zufällig die eigene Definition teilt ist dann doof.
1/19 sind die "ca 5%" von denen ich schrieb, ne. Und natürlich ist das gemeint, aber geschrieben wurde was anderes.

[Achill]

Es gibt schon seit ein paar Tagen ein Test von phoronix.com (https://www.phoronix.com/scan.php?page=article&item=lvi-attack-perf) zu dem Auswirkung der Load Value Injection mitigations.

Leider wird nicht klar, welche der verschieden Mitigations für welche CPU-Generation von Intel benötig wird - da es jedoch nur SGX betrifft (nach meinem Verständnis) muss es ggf. nur eingeschränkt eingesetzt werden.

[Iscaran]

@Achill:

Doch, steht sogar da. Grundsätzlich braucht es LFENCE zwischen jedem Befehl und vor allem NACH jedem Load Befehl.

Also wäre die eigentlich "notwendige" Mitigation die Worst-Case Mitigation.

Die Frage die sich Phoronix aber stellt ist - ob es nicht "ausreichend" wäre (jedoch im Sinne einer nicht vollständigen Mitigierung) nur die wenig Performance kostenden LFENCE Befehle zu implementieren. Evtl. kann man damit den Angriff schon schwer genug machen um ihn unpraktikabel zu machen. GGf. kann man das noch kombinieren mit einer Änderung im Process Scheduling und Sachen wit HT=OFF um hier auf fast vollständige Mitigation zu kommen und dabei "nur" 10% Leistung zu verlieren.

LFENCE nach jedem Load als Mitigation dürfte aber ausgeschlossen sein. Dazu ist der Einbruch einfach zu groß.

[Zossel]

19-fach ist ganz klar Faktor 19 und nicht 1/19.

"um das 19-fache reduziert"

Also der Kehrwert.

[iuno]

Nein! :facepalm:

"Reduziert" gibt das Vorzeichen an, sonst gar nichts.
vorher: 1
Veraenderung: -19
nachher: -18

Das steht da, und nichts anderes. Ich weiss nicht warum, man darueber so lange diskutieren muessen soll. Hast du keine Schule besucht?

[Setsul]

Was soll die Diskussion?
Ist vielleicht nicht die eleganteste Übersetzung aber glaubt hier wirklich irgendjemand, dass zu viel LFENCE die Zeit rückwärts laufen lässt mit 18-facher Geschwindigkeit?
Mit auch nur einem bisschen Hirn versteht man, dass das 19-fache Rechenzeit bzw. 1/19 Geschwindigkeit bedeutet.
Ist schon klar dass "auf das 3-fache erhöht" 3x bedeutet und "um das 3-fache erhöht" 1+3=4x aber "auf das 19-fache reduziert" wäre völlig bescheuert.

Ohne 1/19 zu schreiben, was nicht schön zu lesen ist, lässt sich das nicht wirklich besser formulieren. Wenn man sich beschweren will, dann darüber dass alles mit möglichst großen Zahlen daherkommen muss. "Performance auf 5% bzw. 1/19 reduziert" macht nicht so viel her weil dann könnte ja jemand "um" lesen und um 1-5% kennen wir ja schon von genügend Mitigations, das ist langweilig. Deshalb nimmt die Webseite ja auch "19", damit auch alle sehen "langsamer" + große Zahl = sehr schlecht.

[iuno]

Was soll die Diskussion?

Das frage ich mich auch.


Ist vielleicht nicht die eleganteste Übersetzung aber glaubt hier wirklich irgendjemand, dass zu viel LFENCE die Zeit rückwärts laufen lässt mit 18-facher Geschwindigkeit?

Das glaubt hoffentlich niemand. Es steht aber halt trotzdem genau so im Artikel.

Ohne 1/19 zu schreiben, was nicht schön zu lesen ist, lässt sich das nicht wirklich besser formulieren. Wenn man sich beschweren will, dann darüber dass alles mit möglichst großen Zahlen daherkommen muss. "Performance auf 5% bzw. 1/19 reduziert" macht nicht so viel her weil dann könnte ja jemand "um" lesen
Ja. Weil die richtige Info jemand ohne Leseverstaendnis missverstehen koennte, schreiben wir lieber gleich was komplett falsches auf :up:
Wirklich grandiose Idee.

[Setsul]

Also die Leute ohne Leseverständnis verstehen was gemeint ist und die Leute mit Leseverständnis meinen die Zeit läuft rückwärts?

Hast du verstanden was gemeint war?
Haben alle anderen verstanden was gemeint war?
Wo ist jetzt das Problem, außer dass du dich an der Formulierung störst?

[Benutzername]

Stimmt, alle nicht-Journalisten sind super clever =)

Ausnahmen, Regel und so. ;)


Aber es ging eben um das Falsche Verwenden von Vielfachen und Prozenten. Und das ist wirklich so oft falsch, daß es schon fast zur Regel geworden ist. :freak:

Wieviele saarländische Badewannen sind das dann auf wievielen Fußballfeldern?

[aufkrawall]

Es kommt halt alle x Monate irgendwas neues mit gewisser Relevanz für Cloud-Anbieter raus. Möglichst reißerische Headlines helfen bei der öffentlichen Resonanz...

[y33H@]

Grml. Wenn die Performance "um das 19-fache reduziert" wird, hätte man hinterher "-18" Performance :ulol: In sinnvoll sollte es heißen, dass nur ca 5% Performance übrig bleiben. Ok, Golem ist hierbei entschuldigt, da die das auf der offiziellen Website so formulieren. Um so schlimmer.Ich habe es übrigens mittlerweile auf 1/19 geändert :redface:

[M4xw0lf]

Ich habe es übrigens mittlerweile auf 1/19 geändert :redface:
:ulove4:

[y33H@]

Ich bin ja kein Unmensch!

[Iscaran]

Neuester LVI-Patch für LLVM hat es immerhin geschafft den Performance impact für die Mitigation von -93% (also runter der Leistung auf 7% der ursprünglichen Leistung) auf immerhin grob 30-50% Verlust "worst case" zu "optimieren". Mit im Mittel ca. 10% Verlust - das ganze halt stark Fall spezifisch, daher ist der Mittelwert eher nichtssagend.

Die Option ist aktuell nicht DEFAULT im LLVM.

https://www.phoronix.com/scan.php?page=article&item=llvm-intel-lvi&num=2

[Iscaran]

Mehr benches für LVI-Compiler Patch auf Phoronix:
https://www.phoronix.com/scan.php?page=article&item=intel-cxlr-lvi&num=5

Im Mittel 20% Verlust @CascadeLake.

Allerdings, und das finde ich bedenklich, wäre ein derartiger Compilerpatch AUCH für alle anderen, z.T. einfach nicht betroffenen Systeme ebenfalls Aktiv und würde ähnlich hohe Performanceverluste bedeuten.

Hoffentlich benutzt man diesen Flag also eben nur für Software die EXPLIZIT dafür vorgehesen ist auf Intel-Systemen zu laufen, die von LVI betroffen sind. Und nicht allgemein.

[Denniss]

Da sollte eine Vendor-ID abfrage rein in die ausführbare Datei damit das nur bei Intel aktiviert wird.
Sollte eigentlich machbar sein da Intel mit so einer Abfrage andere Prozessoren in ihrer MKL-Bibliothek benachteiligt.

[Birdman]

Das ist nicht so einfach, der Compiler kann nicht einfach zwei unterschiedliche Pfade machen.
Zudem, auf die Vendor-ID zu gehen ist ganz schlecht.

[Iscaran]

Siehe Intel MKL :-D.

Aber grundsätzlich KÖNNTE man das schon machen mit mehreren Pfaden. Aber dann würde halt jedes Programm auf mind. 2 Codepfade kompiliert sein. Im Worst case also jede Exe, dll etc. doppelt so groß wie bisher

[Birdman]

Siehe Intel MKL :-D

Da wirds im Code gemacht und nicht vom Compiler

[Achill]

Gerade gesehen aber noch nicht gelesen. Die nächsten Lücken bei Intel-CPUs (Zusammenfassung z.B. bei Heise (https://www.heise.de/news/Neue-CPU-Sicherheitsluecken-in-Intel-Prozessoren-umgehen-Kern-Grenzen-4780215.html))
- CROSSTalk (https://www.vusec.net/projects/crosstalk/)
- CacheOut (https://cacheoutattack.com/)

--
Performance wird für bestimmte aber wichtige Fälle (Zufallszahlen) um ~97% reduziert: https://www.phoronix.com/scan.php?page=news_item&px=RdRand-3-Percent

[Opprobrium]

Aua. Aus dem Phoronix Forum:

I wonder if only the threads using rdrand are affected or other threads will slow down because of rdrand being called. If it Is the latter, this would be a potential DoS attack. :/

Probably yes, as this locks the memory bus .. Could imagine the having a big impact on games/game servers, where the instruction is used to generate randomness in high frequency.

The really bad thing about this specular execution vulnerability is, that it leaks information between physical cores!! So a mitigation for VMs where you pin a VM on one core and the other on another for example, won´t work. This sets it appart from all the other currently known speculative execution bugs.
As Intel has often a homogenous chip design, this won´t even effect just a "cluster" but probably all cores on one die / processor.

[Birdman]

Das mit der Performance von rdrand ist lächerlich.
Wird zum einen nur selten genutzt und ähm, bis und mit Sandy Bridge hatte das keine CPU und denkt ihr dass eine Sandy Bridge CPU in heutigen Spielen/Anwendungen 97% langsamer ist als ein CoffeeLake?

CrossTalk ist da schon lustiger, denn dass bisher bei allen Lücken der Attack und Victim Thread auf dem gleichen Core laufen mussten, machten diese Angriffe in virtualisierten Umgebungen sehr schwierig überhaupt auszunutzen. (ausser man hätte sich via weiteren/anderen Exploits die Möglichkeit eingeräumt, die Core/Thread Nutzung gezielt zu steuern)

[Eldoran]

Was mich bei den Test interessieren würde, was der Vergleich zum deaktivieren des Hardware Zufallsgenerators ist (die Software sollte ja in der Regel auch ohne funktionieren). Es wäre nicht die einzige Lücke der letzten Zeit, bei der Fix mehr Leistung kostet, als das Feature einfach zu deaktivieren.

[unl34shed]

Massive 20GB Intel IP Data Breach Floods the Internet, Mentions Backdoors (Intel Responds)

https://www.tomshardware.com/news/massive-20gb-intel-data-breach-floods-the-internet-mentions-backdoors

"We are investigating this situation. The information appears to come from the Intel Resource and Design Center, which hosts information for use by our customers, partners and other external parties who have registered for access. We believe an individual with access downloaded and shared this data."

The folder appears to have been originally posted by an anonymous source that claims more is coming soon, and while we don't know the exact specifics of the folder's contents, we have verified that it does exist. In fact, the title of many of the documents do correlate to the list of purported information posted by the leaker:


Intel ME Bringup guides + (flash) tooling + samples for various platforms
Kabylake (Purley Platform) BIOS Reference Code and Sample Code + Initialization code (some of it as exported git repos with full history)
Intel CEFDK (Consumer Electronics Firmware Development Kit (Bootloader stuff)) SOURCES
Silicon / FSP source code packages for various platforms
Various Intel Development and Debugging Tools
Simics Simulation for Rocket Lake S and potentially other platforms
Various roadmaps and other documents
Binaries for Camera drivers Intel made for SpaceX
Schematics, Docs, Tools + Firmware for the unreleased Tiger Lake platform
(very horrible) Kabylake FDK training videos
Intel Trace Hub + decoder files for various Intel ME versions
Elkhart Lake Silicon Reference and Platform Sample Code
Some Verilog stuff for various Xeon Platforms, unsure what it is exactly.
Debug BIOS/TXE builds for various Platforms
Bootguard SDK (encrypted zip)
Intel Snowridge / Snowfish Process Simulator ADK
Various schematics
Intel Marketing Material Templates (InDesign)
Lots of other things

[Opprobrium]

Massive 20GB Intel IP Data Breach Floods the Internet, Mentions Backdoors (Intel Responds)
Oops...

Peinlich sowas.

Und ein weiteres Argument gegen Dinge wie Closed Source Management Engines :rolleyes:

[Complicated]

Interestingly, Kottman also notes "If you find password protected zips in the release the password is probably either "Intel123" or "intel123". This was not set by me or my source, this is how it was acquired from Intel."
Vertrauensfördernd der Umgang mit vertraulichen Daten :freak:

[Opprobrium]

Ich finde ja Fefes Kommentar (http://blog.fefe.de/?ts=a1d0ab50) zu einer weiteren Schreckensmeldung (https://www.theregister.com/2020/08/07/foreshadow_strikes_back_boffins_find/) ganz treffend:

Die spekulativen Seitenkanäle in CPUs sind schlimmer als bisher angenommen. Gut, das überrascht jetzt niemanden mehr. Aber darüber sollten wir mal reden, finde ich. Wir setzen hier eine Basistechnologie ein, deren Funktionsweise vom Hersteller geheimgehalten wird. Das alleine ist schonmal ein Problem finde ich.
Dann, wenn ein Sicherheitsproblem auftritt, nutzt der Hersteller die Geheimhaltung, um das Ausmaß des Problems zu verschleiern.

Und Drittens ist diese Technologie so komplex und so schwierig von außen zu verstehen, dass es Jahre dauert, bis die Forschung diese Details herausgefunden hat.

Wir reden hier von einer menschengeschaffenen Sache, nicht von einem Aspekt der Natur! Stellt euch mal vor, Brücken würden so gebaut! Ja gut, die ist jetzt eingestürzt, aber vielleicht stürzen die anderen ja nicht von alleine ein! Wir reduzieren mal den Verkehr, vielleicht hilft das ja!1!! Wir reduzieren uns hier selbst auf vorsintflutliche phänomenologische Aberglauben-Level Reaktionen auf Verhalten, das wir verstehen könnten, aber wo wir absichtlich im Dunkeln gehalten werden. Ich finde das einen Riesenskandal.

Ich sage ja schon länger, daß der ganze Umgang mit KI, Digitalisierung etc. sowas wie der Wiedereingang des Menschen in die selbstverschuldete Unmündigkeit ist...

[aufkrawall]

Taten diese Lücken bisher irgendwem anders weh als Cloud-Anbietern? Wenn nein: Dein großer Bogen zur Aufklärung könnte an dieser Stelle melodramatischer nicht sein. ;D

[Opprobrium]

Taten diese Lücken bisher irgendwem anders weh als Cloud-Anbietern? Wenn nein: Dein großer Bogen zur Aufklärung könnte an dieser Stelle melodramatischer nicht sein. ;D
Tjoa, wenn halt alles in die Cloud geschoben wird, von den Urlaubsfotos bis zu unseren Gesundheitsdaten, dann sollte man das schon diskutieren ;) Es tut ja nicht nur den Cloudanbietern weh, wenn dann mal wieder riesige Datensätze leaken, bzw. tut das denen vielleicht finanziell ein bißchen weh, den eigentlichen Schaden haben aber die Kunden...

Und es geht ja nicht nur um die Sicherheitslücken in Server CPUs, es geht generell darum, daß derzeit viel zu viel Aufwand geübt wird, um möglichst viele Entscheidungen irgendwelchen KIs zu überlassen. Und wenn dann irgendwas schiefgeht, dann war es ein Softwarefehler, für den natürlich niemand verantwortlich ist.

Ich find den Bogen zur Aufklärung nicht so weit hergeholt, resultierte diese doch mehr oder weniger aus der Erfindung der Druckerpresse. Und was sind moderne Informations- und Kommunikationstechnologien anderes als Gutenberg 2.0 (um mal in der Sprache unserer Zeit zu bleiben ;))?

[Skysnake]

Taten diese Lücken bisher irgendwem anders weh als Cloud-Anbietern? Wenn nein: Dein großer Bogen zur Aufklärung könnte an dieser Stelle melodramatischer nicht sein. ;D
JA und zwar massiv.

Meine Kollegen und ich hatten ziemlich viel Mehraufwand, die zugesagten Performancewerte von Clustern zu erreichen, weil ständig irgendwo was an Migitations dazukommt und mal und mal da was gedreht wird...

Also das ist teilweise echt nicht mehr lustig, wieviel Performance bei Intel CPUs von einer Firmware Version zur nächsten einfach mal flöten geht...

Mal ganz davon abgesehen, das man sich einfach mit diesem elendigen Thema beschäftigen MUSS um zu entscheiden wo es relevant ist und wo nicht. Das kostet alles Zeit und Geld. Wobei natürlich die normale Arbeit nicht weniger wird, ist also einfach immer noch was oben drauf... :down::motz:

[lumines]

Tjoa, wenn halt alles in die Cloud geschoben wird, von den Urlaubsfotos bis zu unseren Gesundheitsdaten, dann sollte man das schon diskutieren ;) Es tut ja nicht nur den Cloudanbietern weh, wenn dann mal wieder riesige Datensätze leaken, bzw. tut das denen vielleicht finanziell ein bißchen weh, den eigentlichen Schaden haben aber die Kunden...

Ironischerweise werden hier nicht die großen Cloud-Anbieter wie Google, Amazon und Microsoft bluten, sondern kleinere Anbieter von Cloud-Diensten (oder allgemein selbstgehosteter IT-Infrastruktur), welche nicht das Know How haben, um eine vollständige Risikoanalyse durchzuführen, die solche Lücken miteinbezieht, sondern nur auf Gut Glück die Mitigations einspielen können und damit ganz real Leistung verlieren. Google, Amazon und Microsoft können sehr viel feiner granuliert entscheiden, wie und auf welche Art sie ihre Infrastruktur absichern müssen.

Man kann daher genau so gut behaupten, dass diese Lücken zu einer stärkeren Zentralisierung hin zu einigen wenigen Anbietern führen werden.

Also das ist teilweise echt nicht mehr lustig, wieviel Performance bei Intel CPUs von einer Firmware Version zur nächsten einfach mal flöten geht...

Mal ganz davon abgesehen, das man sich einfach mit diesem elendigen Thema beschäftigen MUSS um zu entscheiden wo es relevant ist und wo nicht. Das kostet alles Zeit und Geld. Wobei natürlich die normale Arbeit nicht weniger wird, ist also einfach immer noch was oben drauf... :down::motz:

Ja, alleine der organisatorische Mehraufwand ist enorm. Wenn solche Probleme nicht irgendwann auf Architekturebene stark abgemildert werden, wird das noch zu spannenden Entwicklungen führen, einfach weil sie ganz fundamentale Annahmen über Kosten und Sicherheit der Infrastruktur durcheinanderbringen und die Planung massiv erschwert wird.

[Zossel]

Taten diese Lücken bisher irgendwem anders weh als Cloud-Anbietern? Wenn nein: Dein großer Bogen zur Aufklärung könnte an dieser Stelle melodramatischer nicht sein. ;D

Nutzt du keine IT-Leistungen?

[Opprobrium]

Ironischerweise werden hier nicht die großen Cloud-Anbieter wie Google, Amazon und Microsoft bluten, sondern kleinere Anbieter von Cloud-Diensten (oder allgemein selbstgehosteter IT-Infrastruktur), welche nicht das Know How haben, um eine vollständige Risikoanalyse durchzuführen, die solche Lücken miteinbezieht, sondern nur auf Gut Glück die Mitigations einspielen können und damit ganz real Leistung verlieren. Google, Amazon und Microsoft können sehr viel feiner granuliert entscheiden, wie und auf welche Art sie ihre Infrastruktur absichern müssen.

Man kann daher genau so gut behaupten, dass diese Lücken zu einer stärkeren Zentralisierung hin zu einigen wenigen Anbietern führen werden.
Eben, und genau von diesen Zentralisierten Lösungen machen wir uns sehenden Auges abhängig --> Unmündigkeit...

Ich finde das ungut, und sehe da durchaus Probleme historischen Ausmaßes auf uns zukommen, zumal ja die wenigsten Länder eine gescheite Grundausbildung in den ITKs anbieten. Frei nach Arthur C. Clarke ist dann diese technologie für viele eben eine Art Magie, weil das Grundverständnis fehlt.

[Benutzername]

von lumines: Man kann daher genau so gut behaupten, dass diese Lücken zu einer stärkeren Zentralisierung hin zu einigen wenigen Anbietern führen werden.


Das eine schliest ja das andere nicht aus. richtig große Firmen haben genug Geld um so etwas abzufedern oder Gerichtsprozesse so lange auszudehnen bis der Kläger aufgibt. Zur Erreichung und Festigung eines Mono- oder Oligopols wäre das alles durchaus hilfreich um lästige Konkurrenz loszuwerden. Ob das eine technisch gute Lösung oder gut für die Kunden ist, ist dabei egal und stört eigentlich.

Von daher sind Projekte wie RISC-V und andere open source Prozessoren so wichtig als offene vertrauenswürdigere Alternative. Die derzeitigen CPUs sind magische Kisten in die man auf der einen Seite seine Rechenaufgaben einwirft, als Benutzer nicht weiss was darin passiert, und auf der anderen Seite kommt ein Ergebnis heraus. Deswegen tun die CPUs dann auch Dinge, die man nciht erwartet hat wie eben Spectre, Meltdown, oder eben jetzt Foreshadow. Die Informatiker der Uni Graz stochern da auch nur im Dunklen und gucken wie die CPUs darauf reagieren, wenn sie dieses oder jenes den CPUs als Anweisung geben.


Tja der sachstand ist jetzt wohl, daß durch Sprungvorhersage und ähnliche Mechanismen in modernen CPUs in den derzeitigen Implementierungen die alle angreifar sind. Egal ob intel oder AMD, POWER, ARM. tja also müssen wir zurück in die Zeit ohne Sprungvorhersagen? Kann man das bauen ohne Lücken aufzureißen?


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

Eben, und genau von diesen Zentralisierten Lösungen machen wir uns sehenden Auges abhängig. Ich finde das ungut, und sehe da durchaus Probleme historischen Ausmaßes auf uns zukommen.


Digitalisierung First! Bedenken Second!


Und das von einer angeblich freiheitlichen Partei direkt in die Zeit der von Mönchen bewachten Bibliotheken. Was ziemlich ironisch ist angesichts der immer einfacheren Verbreitung von Information.

[aufkrawall]

Nutzt du keine IT-Leistungen?
Habe noch keine Einschränkungen bemerkt. Und auch sonst niemand, den ich kenne.

[lumines]

Habe noch keine Einschränkungen bemerkt. Und auch sonst niemand, den ich kenne.

Die Einschränkungen bekommst auch nicht du zu spüren, sondern diejenigen Unternehmen, die selber IT-Infrastruktur vermieten.

[Skysnake]

Oder betreiben.

Nach dem großen Hack von Clustern aus der Wissenschaft, drehen die aktuell ziemlich am Rad. Da werden auch zweistellige Performanceverluste jetzt akzeptiert.

Das war bis vor kurzem eigentlich nicht denkbar. Jetzt heißt es aber security First.

Ich bin mir nicht sicher aber ich meine wir hätten schon Verluste um Bereich von 20-30% gesehen und das ist echt heftig.

Stell dir das mal bei tausend Knoten vor.... das ist echt Asche die da verbrannt wird.

[aufkrawall]

Ich hoffe dann mal stark, dass auch in diesem Umfeld nun vermehrt AMD nachgefragt wird. Wenn man sich weiterhin von Intel willentlich für dumm verkaufen ließe, wär das dann ein hausgemachtes Problem...

[Skysnake]

Naja, wird man sehen müssen. So Kunden bestehensvhon länger auf dem neuesten Bios/Firmware aber wenn dann doch nen Verlust dabei war würde das meist doch nicht gemacht.

Die Frage ist halt wer haftet? Wenn dich nen BIOS Update 10% Memorybandbreite in stream kostet, dann wird es unlustig.

Das ist halt echt die Frage wie darauf reagiert wird. Man bewegt sich in dem Bereich ja oft am Limit weil die Konkurrenz groß ist. Ich glaub die Käufer werden aber daraus lernen und das Risiko abfedern in Zukunft. Nur als Anbieter ist man da ja total machtlos. Das könnte also noch so machen netten Rechtsstreit ergeben.

Sowas wird aber sicherlich auch mal dem einen oder anderen Anbieter das Genick brechen.

Ich denke das wird durch die steigenden security anforderungen eh passieren.

[unl34shed]

https://www.phoronix.com/scan.php?page=news_item&px=BlindSide

BlindSide is self-described as being able to "mount BROP-style attacks in the speculative execution domain to repeatedly probe and derandomize the kernel address space, craft arbitrary memory read gadgets, and enable reliable exploitation. This works even in face of strong randomization schemes, e.g., the recent FGKASLR or fine-grained schemes based on execute-only memory, and state-of-the-art mitigations against Spectre and other transient execution attacks."

Basiert wohl auf einem Buffer Overflow.

[davidzo]

Gute Nachrichten!


Ihr könnt jetzt eure Goldmont CPU und möglicherweise kommende Alderlake Mont Corecluster unlocken und übertakten, ganz ohne Z-series Chipsatz.

Offener multiplier, Bus Übertaktung, etc. alles ist jetzt möglich dank Intel Ingenieuren die uns einen leicht zu überwindenen weg dafür eingebaut haben eigene Microcode updates auszuliefern :freak:

Ich freue mich schon auf die neuen OC-tools, ein serial programmer mit USB: "Übertaktung per Microcode" ;D

https://arstechnica.com/gadgets/2020/10/in-a-first-researchers-extract-secret-key-used-to-encrypt-intel-cpu-code/

[Complicated]

Heftig - keine Ende in Sicht für Intel.

[dildo4u]

Linux Benchmark mit und ohne Migrations Haswell bis Comet Lake und Zen 1 bis Zen 3.

9900k ist mal richtig am Arsch Comet Lake verträgts deutlich besser.

https://www.phoronix.com/scan.php?page=article&item=3-years-specmelt&num=1

[aufkrawall]

Sähe noch übler aus, wäre bei mitigations = off auch intel-ucode nicht geladen.
Aber wie man sieht, wird durch den Quatsch (zumindest für Consumer) auch AMD mitunter ordentlich in Mitleidenschaft gezogen. :freak:

[Badesalz]

Ich hab auf dem E5-1630 v3 Rechner (Haswell) das letzte Bios, bevor sie angefangen dran rumzupatchen...
Nur läuft da noch kein Win10 drauf. Soll aber. Kann man das irgedwie vermeiden, daß MS die eigenen slowdown Patches einspielt/aktiviert?

Oder ist man den Mist automatisch los, wenn das Bios nicht mitmacht?

[Birdman]

AMD lässt bei Zen3 nun doch diese eine Mitigation (hab vergessen welche und bin zu faul zum nachschauen) aktiv mitlaufen, welche bei allen andern CPUs (Intel und AMD) optional und per default auf Off ist.

Das könnte ein Grund sein, wieso der 5950x so zu beissen hat.

[aufkrawall]

Ich hab auf dem E5-1630 v3 Rechner (Haswell) das letzte Bios, bevor sie angefangen dran rumzupatchen...
Nur läuft da noch kein Win10 drauf. Soll aber. Kann man das irgedwie vermeiden, daß MS die eigenen slowdown Patches einspielt/aktiviert?

Oder ist man den Mist automatisch los, wenn das Bios nicht mitmacht?
Ist dir ein Nachweis dafür bekannt, dass es unter Windows mit im OS deaktivierten Mitigations tatsächlich irgendeine Leistungsbeeinträchtigung gibt (ob nun mit altem oder neuem Bios)? Mir jedenfalls nicht, ich finde dafür keinen Beleg. Daher gehe ich davon aus, dass dem nicht so ist.

[Iscaran]

AMD lässt bei Zen3 nun doch diese eine Mitigation (hab vergessen welche und bin zu faul zum nachschauen) aktiv mitlaufen, welche bei allen andern CPUs (Intel und AMD) optional und per default auf Off ist.
Das könnte ein Grund sein, wieso der 5950x so zu beissen hat.

Nicht nur könnte. Michael bestätigt es auch im Forum und hat es bei früheren Tests bemerkt.

AMD hat bei Zen3 nun STIBP default = ON, statt sich auf die Software zu verlassen und STIBP "conditional" ausführen zu lassen.

Allein, diese eine Änderung macht afaik ca 60% der "Verluste" bei Zen3 aus.

Und ist gut so. Die Zen3 sind trotz dieser zusätzlichen Bremse immer noch schneller als dier Intel-Schweizer Käse CPUs.

Leider hat er zu dem "Comet Lake" Spezialfall nichts neues geschrieben, oder ich habs überlesen. Dass Comet Lake nämlich MIT Mitigations SCHNELLER ist als OHNE (in manchen Tests).

[Iscaran]

Es ist soweit - erste Spectre-Exploits "in the wild".
https://dustri.org/b/spectre-exploits-in-the-wild.html
https://www.bleepingcomputer.com/news/security/working-windows-and-linux-spectre-exploits-found-on-virustotal/
Erläuterung auf Deutsch: https://www.planet3dnow.de/cms/61492-erste-exploits-fuer-cpu-sicherheitsluecke-spectre-verfuegbar/

[Benutzername]

Wundert mich, daß die Exploits jetzt erst auftauchen.


Wie sieht es eigentlich mit den neuen nicht mehr Skylake+++ CPUs von intel aus mit Meltdown, Spectre usw.?

[Zossel]

Nächste Runde: https://arxiv.org/pdf/2103.03443.pdf

We introduce the first microarchitectural side channel at-tacks that leverage contention on the CPU ring interconnect.There are two challenges that make it uniquely difficult toexploit this channel. First, little is known about the ring inter-connect’s functioning and architecture. Second, informationthat can be learned by an attacker through ring contention isnoisy by nature and has coarse spatial granularity. To addressthe first challenge, we perform a thorough reverse engineeringof the sophisticated protocols that handle communication onthe ring interconnect. With this knowledge, we build a cross-core covert channel over the ring interconnect with a capacityof over 4 Mbps from a single thread, the largest to date for across-core channel not relying on shared memory. To addressthe second challenge, we leverage the fine-grained temporalpatterns of ring contention to infer a victim program’s secrets.We demonstrate our attack by extracting key bits from vulner-able EdDSA and RSA implementations, as well as inferringthe precise timing of keystrokes typed by a victim user.

[aufkrawall]

Fucking KB4589212, das via WU ausgerollt wird, reduziert trotz deaktiverter Spectre & Meltdown-Mitigations via Inspectre die Performance in SotTR um mindestens 4% im CPU-Limit auf dem 6700k :mad: :
https://abload.de/thumb/sottr_2021_03_12_12_5upkog.png (https://abload.de/image.php?img=sottr_2021_03_12_12_5upkog.png) https://abload.de/thumb/sottr_2021_03_12_12_4k3kl5.png (https://abload.de/image.php?img=sottr_2021_03_12_12_4k3kl5.png)

Das ist Diebstahl, wen kann ich verklagen? :freak:

[Benutzername]

]

Das ist Diebstahl, wen kann ich verklagen? :freak:


Intel. Die haben die CPUs wissentlich so ausgeliefert, daß sie die Mitigations brauchen.

[aufkrawall]

Ich brauche keine Mitigations (außer solche, die Programme wie Browser extra eingebaut haben, um ohne Ausbremsungen via Kernel/MC auskommen zu können). Ich frage mich, ob man den schadhaften Microcode mit zukünftigen Windows 10-Versionen überhaupt noch irgendwie wird loswerden können...

[aufkrawall]

Summiert sich mit den anderen Mitigations, klaut ~10%:
https://forums.guru3d.com/threads/windows-update-ships-new-mitigations-via-microcode-hurts-intel-cpu-performance.437150/#post-5896193

[Dorn]

Summiert sich mit den anderen Mitigations, klaut ~10%:
https://forums.guru3d.com/threads/windows-update-ships-new-mitigations-via-microcode-hurts-intel-cpu-performance.437150/#post-5896193
Na dann wird es aber mal Zeit für einen neuen CPU aufkrawall.:smile:

[aufkrawall]

Käme mir angesichts der Spiele-Flaute unklug vor, vor Alder Lake so viel Geld (denn >=10C müssten es schon sein) auszugeben.
Außerdem kann ich die alte CPU nicht für mehr verkaufen als die neue kosten würde. Das fühlt sich nach meinem letzten GPU-Upgrade unbefriedigend an. :D

[crux2005]

Wie sehen die Mitigation Einstellungen mit euren AMD Zen 3 CPUs aus?

https://i.imgur.com/jIxxMID.jpg

Sieht IMHO gut aus, aber will sicher sein. :)

[nagus]

wieder einmal eine neue Sicherheitslücke bei Intel? https://twitter.com/_markel___/status/1373059797155778562

[x-dragon]

Laut fefe muss man sich da erstmal keine Sorgen machen, so lange keine weiteren Details bekannt sind ...

https://blog.fefe.de/?ts=9ea9cfa5

[Achill]

wieder einmal eine neue Sicherheitslücke bei Intel? https://twitter.com/_markel___/status/1373059797155778562

Kann es nur begrenz Einschätzen, aber mit Kontrolle über den Microcode in der CPU - und dies aus dem User-Mode heraus - klingt das doch schon fast wie ein Backdoor ... :confused:

[Unicous]

Keine Sorge, fefe sagt es klingt nicht gut, aber er hat zu wenig Informationen um es beurteilen zu können und deswegen ist alles in Ordnung.:uup:

Ich verstehe weiterhin nicht, warum so viele Leute diesem konstant unterinformierten Bewusstseinsstrom so viel Bedeutung beimessen.
fefe hier, fefe da. Zu fast jedem Thema gibt es einen Link zum HTML-Blog für Unbedarfte indem fefe einem die Welt auf Stammtisch-Niveau erklärt.:rolleyes:

[x-dragon]

Ja, sorry :), hatte seinen Beitrag zu dem Thema nur kurz vor der Frage hier gelesen und er versteht zumindest deutlich mehr davon als ich ... Meistens hat er ja wenigstens weiterführende Links, wo es mehr Informationen gibt, oder erklärt wenigstens warum er der Meinung ist. Aber klar ist denke ich, das man da wohl mehr Informationen braucht.

[aufkrawall]

Mit Rocket Lake sind mit Windows 20H2 inkls. KB4589212 offenbar keinerlei OS/Microcode-Mitigations standardmäßig aktiv, entsprechend kann ich keine Gewinne/Verluste in SotTR feststellen.

[fezie]

https://www.phoronix.com/scan.php?page=news_item&px=AMD-PSF-Security-Analysis

Zen3 hat wohl mit dem Predictive Store Forwarding eine Lücke eingeführt die wohl ähnliche Auswirkungen wie Spectre V4 haben könnte.

[crux2005]

War nur eine Frage der Zeit wann mehr Lücken in Zen gefunden werden. War sicher nicht die letzte.

[fezie]

Jupp.
Es geht weiter mit den Spectre Lücken:

https://www.phoronix.com/scan.php?page=news_item&px=Spectre-Micro-Op-Cache-Exploits

[][immy]

Jupp.
Es geht weiter mit den Spectre Lücken:

https://www.phoronix.com/scan.php?page=news_item&px=Spectre-Micro-Op-Cache-Exploits
Etwas früh veröffentlicht. Da haben die Hersteller ja nicht mal die Zeit gehabt das zu validieren.

Solcherart Angriffsszenarien wird man aber wohl nie ausschließen können, sobald du anfängst etwas zu cachen. Und ohne Cache wollen wir erst gar nicht anfangen irgendwas auf Computern heutzutage zu machen.
Wird vielleicht Zeit das Browser wirklich nur noch simples HTML zu lesen anbieten, damit man keine Sicherheitslücken mehr Ausnutzen kann die sich mit dem Ausführen von Fremdcode auf der eigenen Maschine einschleichen können ^^

Will aber wohl auch keiner.

[Badesalz]

Bald werden die M1 4x so schnell pro Mhz als Intels x86...
https://travisdowns.github.io/blog/2021/06/17/rip-zero-opt.html

Oder anders gesagt, der Vorsprung zu Sandy wird bald kaum messbar sein...

[Iscaran]

Intel deaktiviert TSX komplett bei allen älteren CPUs wegen der Spectre/Meltdown Attacken:

https://cdrdv2.intel.com/v1/dl/getContent/604224

https://www.computerbase.de/2021-06/anhaltende-probleme-intel-deaktiviert-tsx-bei-skylake-bis-coffee-lake/

Performance drops je nach Anwendung um bis zu 50%...Intel FTW.

[ryan]

The Current Intel Coffee Lake Mitigation Performance Impact With Linux 5.9 (https://www.phoronix.com/scan.php?page=article&item=linux-59-9900k&num=1)

Spectre Mitigation Performance Impact For Intel's Rocket Lake (https://www.phoronix.com/scan.php?page=article&item=spectre-rocket-lake&num=1)

Is It Worthwhile Running Intel Alder Lake With mitigations=off? (https://www.phoronix.com/scan.php?page=article&item=alder-lake-mitigations&num=1)


speedup vs mitigations=off

Coffee Lake= 12.5%
Rocket Lake= 2.0%
Alder Lake= 0.4%


Bei Rocket Lake gab es bei den Browser Benchmark noch einen deutlichen performance Rückgang, das ist bei Alder Lake jetzt nicht mehr der Rede wert.

[Pirx]

wieder mal leichte Sicherheitsproblemchen bei den Intel-CPUs der letzten Jahre?

https://www.techradar.com/news/latest-intel-cpus-have-impossible-to-fix-security-flaw

[Denniss]

Och nö, noch ein Loch im schweizer Käse?

[aufkrawall]

Ein weiteres Problem exklusiv für Paranoiker.