News Downfall & Inception: Neue CPU-Schwachstellen gefährden Intel- und AMD-Systeme

Muntermacher schrieb:
Vielleicht eine blöde Frage:
wenn nur 39 Bytes je Sekunde ausgelesen werden können, wie kann der Angreifsr,si herstellen, daß das PW in diesen ist, oder ist es eher Zufall?

Ja, das gehoert auch noch zu einem Exploit dazu, und um das schwerer zu machen, gibt es Abwehrmechanismen wie ASLR (address space layout randomization), aber trotzdem wuerde ich mich nicht darauf verlassen, dass der Angreifer das nicht herausfindet, oder kein Glueck hat.
 
  • Gefällt mir
Reaktionen: Muntermacher
Discovery_1 schrieb:
Sorry, ich verstehe deine Frage nicht.
Auch im BIOS/UEFI können kritische Sicherheitslücken drin sein, die von Außen angreifbar sind. Gerade die ganze Bloatware-Geschichte, die über APIs Software auf dein OS ziehen lässt, kann von Bad Actors ausgenutzt werden.
 
tomgit schrieb:

Was Phoronix da gemessen hat, ist (soweit ich es verstehe), was passiert, wenn im Linux-Kernel verschiedene Spectre-v2-Mitigations aktiviert werden. Da ist der User-Code noch gar nicht dagegen gesichert.

Ein extremes Beispiel, wieviel die Spectre-v2-Mitigations kosten koennen, ist Gforth bzw. allgemein Programmierspracheninterpreter; selbst mit den Resultaten fuer thunk-inline, die bei Gforth-fast deutlich besser sind (aber bei einem Interpreter mit weniger Optimierung nicht besser waeren, siehe die --no-dynamic-Resultate), sieht man einen Slowdown von mindestens einem Faktor 2 bis hin zu einem Faktor 9 (fft auf dem Pentium G4560).
 
  • Gefällt mir
Reaktionen: frankx82
Also wenn man die "Schwachstellen" der letzten Jahre zusammen nimmt.
Dann die Steigerungen der IPC nimmt.
Kann man fast sagen die letzten 10 Jahre sind wir dann bei 5%?
Die gefakten Benchmarks vor dem Patch und danach lassen wir mal weg.

Dann kommt noch dazu, wem so eine Schwachstelle nutzt.
Es werden mehr CPUs oder Hardware verkauft, es werden Softwarefirmen mit der Entwicklung von Patches und anderen Sicherheitsprogrammen beauftragt.

Also wie immer, mit Angst kann man Geld machen.

Es wäre schön wenn man selber entscheiden könnte ob man den Patch haben möchte.
Denn alte Hardware ist nicht schlecht, aber mit solchen zwangs Updates (oft im Betriebssystem schon enthalten) wird sie dann immer langsamer.

Es bleibt spannend, wie stark es real Leistung kostet.
Aber bitte keine Benchmarks von Herstellern vertrauen. :p
Für kleine CPUs kann dies schon das Ende bedeuten. :mad:



Update:
@mae
Über mir.
Genau das meinte ich.
Vielen Dank
Der Atom 330 ist sogar Faktor 20 langsamer.
Wenn ich das richtig lese.
 
Those are the initial benchmarks I've been able to carry out of workloads I've found to be impacted in less than 24 hours since the Intel Downfall vulnerability was made public. As Phoronix is a one-man-band I am still battling away with exploring more workloads to be impacted by the mitigation but at least AVX2/AVX-512 workloads without using the VGATHER* instructions (or not within any hot code paths) are not impaired and showing the same level of performance as with prior microcode revisions. However, there still are certainly some workloads like various AI software and some Intel oneAPI open-source components that do indeed carry very measurable overhead now as a result of the Downfall mitigations. Stay tuned to Phoronix for more testing as I explore more workloads, especially on the client side with Intel Core CPUs and the more diverse workloads on that side of the computing spectrum.

Hat erstmal nicht viel zu sagen.
SSD I/Os sind spannend und andere Apps.
Aber er zeigt erstmal einen Anfang.

Was auch wichtig ist für mich:
For those on Skylake to Ice Lake / Tigerlake and running workloads affected by the GDS/Downfall mitigation but feel you are not prone to being exploited by Downfall, the Linux kernel with yesterday's patches does add the gather_data_sampling=off kernel option for disabling the mitigation even if using the newest microcode. The mitigations=off route will also disable the mitigation.

Gibt es das für alle Patches auch Meltdown usw?
 
Was ich hierbei interessant finde, ist das Alder Lake und neuer nicht betroffen sind, was für mich heißt, das Intel mindestens seit 2019 von dem Sicherheitsproblem wusste, und daher Golden Cove und Gracemont entsprechend angepasst hat wärend der Entwicklung.

Und trotzdem wurden die entsprechenden CPUs mit diesem Fehler zwischen 2019 und 2021 auf den Markt gebracht.
Ergänzung ()

frankx82 schrieb:
Hat erstmal nicht viel zu sagen.
SSD I/Os sind spannend und andere Apps.
Aber er zeigt erstmal einen Anfang.

Was auch wichtig ist für mich:


Gibt es das für alle Patches auch Meltdown usw?
Ja gibt es, allerdings führt das Abschalten der mitigations bei modernen CPUs zu Performance Einbußen. Kannst du auch bei Phoronix nachlesen. Mit modern meine ich alle CPUs die entsprechende Anpassungen dafür in Hardware haben.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: Engaged und frankx82
frankx82 schrieb:
Der Atom 330 ist sogar Faktor 20 langsamer.
Wenn ich das richtig lese.

Der Atom 330 (Bonnell-Mikroarchitektur) ist insoweit interessant, als er den Spectre-Bug nicht hat, und einige Leute meinen, man sollte Prozessoren so bauen, um sicher zu sein. Aber er ist auch ohne die Mitigations sehr viel langsamer als die out-of-order Mikroarchitekturen der anderen gemessenen Prozessoren ohne Mitigations. Und mit der thunk-inline-Mitigation is Gforth-fast auf Ryzen 3900X und Pentium G4560 noch immer etwas schneller als auf dem Atom 330 ohne Mitigations.
Ergänzung ()

cha0shacker schrieb:
Was ich hierbei interessant finde, ist das Alder Lake und neuer nicht betroffen sind, was für mich heißt, das Intel mindestens seit 2019 von dem Sicherheitsproblem wusste, und daher Golden Cove und Gracemont entsprechend angepasst hat wärend der Entwicklung.

Nicht unbedingt. Haswell und Broadwell sind laut Intel auch nicht betroffen. Es kann sein, dass die das einfach so neu entworfen haben, um bessere Performance zu erzielen, und es dabei richtig gemacht haben, ohne sich gross damit zu beschaeftigen, ob die Loesung von Skylake-Tiger Lake falsch ist.
 
  • Gefällt mir
Reaktionen: frankx82
mae schrieb:
gibt es Abwehrmechanismen wie ASLR (address space layout randomization)
Ergänzung ()

andi_sco schrieb:
Und du glaubst, das die IBM und ARM CPUs fehlerfrei sind?
Ich hab nicht von öffentlich zugänglichen Massenprodukte gesprochen sondern natürlich von Eigenbauten bzw custom CPUs. Dann könnte man zb schon mal den branch predictor weglassen in kritischen Systemen.
 
Da in Unternehmen zu 99% Intel Systeme laufen ist man als AMD User eigentlich ziemlich sicher, da gibt es das meisste Geld zu holen.
Ich würde meine Angriffe eher auf solche Ziele konzentrieren, die paar AMD nutzer lohnen sich da kaum.
 
  • Gefällt mir
Reaktionen: Pleasedontkill
Dann hoffen wir mal, dass zukünftige CPUs, sowohl von AMB als auch Intel, jeweils das in HW behoben haben ohne Performance Einbußen.
 
Pixelkiller schrieb:
Da in Unternehmen zu 99% Intel Systeme laufen ist man als AMD User eigentlich ziemlich sicher
Ist ja nicht so, als würden nicht nur vier der zehn schnellsten TOP500 Systemen auf AMD laufen: https://www.top500.org/lists/top500/2023/06/
Oder sowohl AWS: https://www.amd.com/de/processors/amd-epyc-aws
GCP: https://www.amd.com/de/processors/epyc-google-cloud
Oder Azure: https://www.amd.com/de/processors/epyc-microsoft-azure
Epyc-basierte Instanzen liefern.

Pixelkiller schrieb:
Ich würde meine Angriffe eher auf solche Ziele konzentrieren, die paar AMD nutzer lohnen sich da kaum.
Jap, die paar tausend Server :freak:
 

JEDER
Enthusiast oder Besitzer will gerne wissen ob sein 10700K aktuell so schnell ist wie ein 13700 weil im neueren zu viele Patches bremsen, und wie schnell sein 10700 im Vergleich zu Releasedatum war....

Traut sich doch eh niemand es sich mit AMD oder Inrtel zu verscherzen indem man mal einen Artikel bringt wo man genau aufzeigt wie schnell CPUs zum Release waren und dann noch paar Jahren noch sind wegen dieser Patches, am besten die Patches einzeln durchtesten und dann gemeinsam.
 
  • Gefällt mir
Reaktionen: Engaged, STangs, Corpus Delicti und 3 andere
aber Intel (und AMD) wollen offenbar nicht.
...den dritten Beteiligten nicht vergessen, die Geheimdienste!
Es gab mal ne interessante Doku über die Geheimdienste, ist aber schon eine Weile her.

Die hat das System bei Intel & Microsoft einmal angeschaut und auch erklärt, dass Intel selbst, Mitarbeiter der US-Geheimdienste stellen und bezahlen muss, die nichts anderes machen, als Lücken in das Betriebssystem zu schießen für einen gewissen Zeitraum bzw. auch schon bei neuen Systemen um einen globalen Zugriff auf die Systeme zu ermöglichen.
Genau oder mit Beispielen wollte man das natürlich nicht unterlegen, aber es zeigt woher der Wind weht.
Ich vermute mal stark, dass viele Lücken absichtlich geschaffen werden und, wenn es auffällt, mit Patches gestopft, und gleichzeitig neue geschaffen werden.

Dann gibt es ja auch noch den komplett abstrusen Handel mit Sicherheitslücken (Exploit-Handel) der teilweise ja sogar legal ist. Auch hier kann man vermuten, dass die ein oder andere Lücke freundschaftlich absichtlich eingebaut wird, damit man für sich selbst oder andere, einen Schein unter dem Tisch gereicht bekommt.
 
  • Gefällt mir
Reaktionen: drago-museweni und dernettehans
Hito360 schrieb:
JEDER Enthusiast oder Besitzer will gerne wissen ob sein 10700K aktuell so schnell ist wie ein 13700 weil im neueren zu viele Patches bremsen, und wie schnell sein 10700 im Vergleich zu Releasedatum war....
Nein, will nicht jeder. Weil der Vergleich auch hanebüchen ist. Soll man dann einen 13700K aus dem Hut zaubern, bei dem eventuelle Mitigationen nicht berücksichtigt wurden, aber trotzdem im Microcode eingepflegt wurden?
Zumal das beim 10700K im Vergleich zu (manchen) Vorgängern exakt zutrifft: Spectre-Mitigationen wurden in der 8. oder 9. Generation bereits im Microcode integriert.

Hito360 schrieb:
Traut sich doch eh niemand es sich mit AMD oder Inrtel zu verscherzen
Und darum bringt Phoronix solche Tests - und arbeitet weiterhin fleißig mit AMD und Intel zusammen.

Aber wem Sicherheit egal ist und lieber ein paar Random Prozentpunkte in irgendwelchen abstrusen und für den Normal-Nutzer, wahrscheinlich selbst für die allermeisten Enthusiasten, absolut irrelevanten Szenarien sehen können möchte, der hat mMn ohnehin die falschen Prioritäten.
... oder dürfe sich im Zweifel auch nicht darüber wundern, falls die Credentials irgendwo geleaket werden, weil man sei ja sicher.
 
  • Gefällt mir
Reaktionen: amorosa
Zurück
Oben