News Massive Sicherheitslücke in Intel-CPUs der letzten Jahre

@Complicated: ja, ich kenne die Aussagen und Links. Und ich erneuere meine Aussage: Solange das so bleibt und die Entwickler streng unterscheiden zwischen den Plattformen, ist das für AMD gut. Sollte aber irgendwann einmal ein Entscheidungsträger vorgeben, dass irgendwelche Fixes nicht mehr selektiv, sondern grundsätzlich aktiviert werden, dann sähe es für AMD nicht mehr so rosig aus.
 
Ich wüsste nicht warum man das ändern sollte nachdem die Entscheidung ja jetzt getroffen wurde. Wenn neue Sicherheitslücken auftauchen muss ja sowieso alles neu überprüft werden. Nur Meltdown ist ja nun gerade sehr deutlich von AMD für Windows und Linux als nicht betroffen kommuniziert worden und auch gehört worden, was es ja zu betätigen galt, nach diesem ersten Tweet den du ja gepostet hast.

War sowieso seltsam, dass zuallererst ein AMD System mit dem Penalty öffentlich gemacht wurde durch Grsecurity, wo AMD ja gar nicht betroffen ist vom PTI-Patch. Macht mich etwas misstrauisch dem Laden gegenüber.
Sowieso nachdem ich das gelesen habe was Linus Torvalds über die schon geäußert hat:
https://www.golem.de/news/linux-ker...eichnet-grsecurity-als-muell-1706-128636.html
"Ihre Patches sind reiner Müll", antwortete Torvalds auf einen Vorschlag, sich im Zuge der Stack-Clash-Sicherheitslücke doch mal die Patches von Grsecurity anzusehen. "Diese Sache ist ein Witz und sie sind Clowns", schrieb der Linux-Erfinder weiter.
Zum Vergrößern anklicken....
;D
Der weitere Schlagabtausch ist auch lesenswert ;)
 
Wie ein Choleriker muss man sich aber auch nicht aufführen. :)
 
Zuletzt bearbeitet:
Spectre und Meltdown
90 Prozent der aktuellen Intel-CPUs werden gepatcht
(...)
Intel gibt sich mit Blick auf die Sicherheitslücken Spectre und Meltdown zuversichtlich: Bis zur nächsten Woche sollen etwa 90 Prozent der Prozessoren mit Patches ausgestattet werden, die in den vergangenen fünf Jahren auf den Markt gekommen sind. Die älteste Generation scheint demnach Haswell zu sein, die durch die Bezeichnung 4xxx erkennbar ist. In einem Informationspost spricht das Unternehmen davon, betroffene Systeme gegen beide Angriffe immun zu machen.
Zum Vergrößern anklicken....
https://www.golem.de/news/spectre-u...n-intel-cpus-werden-gepatcht-1801-131981.html

Hmm, heißt das jetzt, dass mein Notebook mit i7-3630QM niemals ein Update sehen wird, oder dass es nur irgendwann später kommt?

In Firmen dürften ja auch noch Millionen von älteren Rechnern stehen.
 
Man kann jetzt auch nur Vermutungen anstellen warum Intel nicht reagiert hat. Ich denke mal das wenn sie den Cache dicht machen die Leistungsfähigkeit der Architektur quasi zusammenbricht. Was dann dazu führt das ein Coffeelake vll noch die Leistung eines Ryzen 1600 hat. Skylake würde mehr heizen als rechnen.

Das Cenario wäre dann noch übler für Intel.
 
https://twitter.com/PCzanik/status/949275491617464320
The fix for the #Intel CPU vulnerabilities has a #brutal effect on compile times.
Compiling the #syslog_ng package on #Fedora changed drastically: from 4 minutes to 21!
As far as I can see compiling #Java is affected most.
Zum Vergrößern anklicken....
Kompilieren unter Java scheint stark betroffen zu sein. Liegt Nahe mit vielen kleinen Files und syscalls sowie I/O-Lastig.

Ein guter Joke im Tweet sagt, dass wohl alte Zeiten zurück kehren ;D

compiling.png
 
Das schmälert nicht die Brisanz der aufgedeckten Lücken, aber ich finde es bemerkenswert wie langwierig ein solcher Angriff doch ist. Nehmen wir Spectre; selbst wenn man die richtigen Vorzeichen durch die Aktivierung des JIT Compilers für ePBF Instruktionen schafft, würde bei einem Epyc-System mit Speichervollausbau viele Stunden oder Tage vergehen bis man auf den gesuchten Inhalt stößt. Bei der Haswell Architektur wurde vom Google Zero Projekt eine Leserate von 1,5kB/s erzielt; bei Zen wird jene trotz leistungsstärkerem Memory Controllers nicht deutlich höher liegen.

An dieser Stelle wäre eine empirische Erfassung aufschlußreich bei wievielen VM-Lösungen überhaupt der JIT Compiler für ePBF Instruktionen aktiv ist. AMD kann sich jedenfalls entspannt zurück lehnen, die Deaktivierung des JIT Compilers für ePBF Instruktionen ist eine einfach umzusetzende Lösung, die bei kaum einem Kunden für Unverständnis sorgen dürfte. Der zum Linux Kernel gehörige JIT Compiler für ePBF Instruktionen sollte ohnehin per default disabled sein, wie bereits mehrfach erwähnt wurde. Für Intel sieht es mit der Anfälligkeit für Meltdown wesentlich düsterer aus. Ich bin schon auf eine Analyse der von Intel in Aussicht gestellten Microcode Updates gespannt. Diese dürfte Microsoft in Kürze ebenfalls außerplanmäßig über Windows Update verteilen.
 
Peet007 schrieb:
Man kann jetzt auch nur Vermutungen anstellen warum Intel nicht reagiert hat. Ich denke mal das wenn sie den Cache dicht machen die Leistungsfähigkeit der Architektur quasi zusammenbricht. Was dann dazu führt das ein Coffeelake vll noch die Leistung eines Ryzen 1600 hat. Skylake würde mehr heizen als rechnen.
Zum Vergrößern anklicken....
Halte ich für unwahrscheinlich, die OS-Patches sollten eigentlich mehr Leistung verbraten als ein Fix per Neuauflage der gleichen Hardware. Weil Transistoren schalten geht schneller als Bits im Speicher lesen/schreiben.

Was nicht heißt, dass die Veröffentlichung neuer CPUs mit diesem Fehler nach Kenntnisnahme ok wäre. Zumindest für diese wäre ein Umtausch oder halt Bußgelder angebracht. Lustig: für Autos, Medizingeräte usw. muss zertifiziert und gehaftet werden aber bei den Mikrochips innen drin geht die Post ab.


@Firmware-Update
Jetzt bin ich verwundert, dachte innerhalb der Hardware (inkl. Firmware) ist nichts zu machen? Zumindest gegen Meltdown hieß es doch.

@Security
Imho stellen sich aktuell 2 Konzepte als dumme Idee raus:
- mit Intel ME und jetzt (siehe Vorposter) AMD PSP als komplexe Betriebssysteme (in C) in der Firmware in der CPU
- untrusted remote Code per Javascript, Flash etc. aus dem Internet per JIT nativ compilieren
 
Zuletzt bearbeitet:
Die Schwachstelle im AMD PSP klingt nach einem alten Hut, der im Zuge von Meltdown wieder aufgewärmt wird. Zumindest hat einen ähnliche Meldung schon vor einigen Monaten die Runde gemacht. Bei einigen Socket AM4 Mainboards von ASRock soll man den AMD PSP in Teilen im UEFI lahmlegen können. Die entsprechenden Firmware Updates wurden zwar damals alsbald zurückgezogen, aber das muss nicht wegen diesem Feature geschehen sein. Ich kann man mir nicht vorstellen, dass AMD mit rechtlichen Schritten gedroht hat. Solch ein Geschäftsgebahren gab es in der Vergangenheit nur bei der blauen Fraktion.

Quelle: https://heise.de/-3913635
 
Was weiß ich was heutzutage so alles auf einer x86 CPU alles platz gefunden hat. was dort nichts zu suchen hat. Klare Aussage von der MIlitärseite ist "alles was ans Internet angesteckt werden kann auf das wollen wir Zugriff" Am besten mit Bild und Ton vom Gerät..........*buck*

Durch die Jahre ist da ein Haufen "Bullshit" entstanden den man nicht mehr händeln kann. GNU mit "Stallman" war eben die Gegenbewegung, die dann Linux mit ins Boot bekamen.

Microsoft bekommt nichts mehr auf die Reihe, Software Müll in Gigabyt größe. Das kann keiner mehr üperblicken. (Creators FALL, wie fallen)

Nur mal die Augen auf machen.

Open Source soll es jetzt richten.

Das schreib ich jetzt auf einer aktuellen Hardware die mit open source lauft. Aber unter dem ein clost source UEFI Sys läuft. Wahrscheinlich mit der Möglichkeit die Hardware auf Knopfdurck zu killen.
 
Zuletzt bearbeitet:
SPINA schrieb:
Das schmälert nicht die Brisanz der aufgedeckten Lücken, aber ich finde es bemerkenswert wie langwierig ein solcher Angriff doch ist. Nehmen wir Spectre; selbst wenn man die richtigen Vorzeichen durch die Aktivierung des JIT Compilers für ePBF Instruktionen schafft, würde bei einem Epyc-System mit Speichervollausbau viele Stunden oder Tage vergehen bis man auf den gesuchten Inhalt stößt. Bei der Haswell Architektur wurde vom Google Zero Projekt eine Leserate von 1,5kB/s erzielt; bei Zen wird jene trotz leistungsstärkerem Memory Controllers nicht deutlich höher liegen.
Zum Vergrößern anklicken....

Das ist nur bei diesen Forschern so lahm. Benutzt man z.B. TSX ist der Angriff um ein vielfaches schneller, da er die OS Exception Handler umgeht. Da werden aus 4000 Zyklen plötzlich nur noch 220 Zyklen. Und der Exploit funktioniert dann auch OS Unabhängig. Siehe das verlinkte PDF von der Blackhat 2016.

Auswirkungen des Patch auf den Fortnight Server bei Epic Games:
https://www.epicgames.com/fortnite/forums/news/announcements/132642-epic-services-stability-update

MwzsHRXQLVbmJ3pusNuGwn0ZQVjo9h8nRJHJhIo4d3XFqbvUYCj8EPq5jV7zeVEEcHAkraNBesbbNDW_UAlIjvw-hZBd80rKt7ZYl35nBIcfCCVyRvW5V7M7KVejv9tvVBHfgSKr
 
Zuletzt bearbeitet:
Was passieren kann oder schon im laufen ist, das die open source Entwickler zu ARM abwandern. Alles was mit Verwaltung und Sicherheitsrelavanten Servern zu tun hat auf ARM umgestellt wird. Gaming und Konzerninteressen interessieren da nicht. Sollen sie mit ihren ....... zurechtkommen. Für AMD sieht es da auch nicht besser aus weil auch Epyc offen steht wie ein Scheunentor, mit dem ganzen was sie mit an Board haben.

End of an Era.
 
Peet007 schrieb:
Für AMD sieht es da auch nicht besser aus weil auch Epyc offen steht wie ein Scheunentor, mit dem ganzen was sie mit an Board haben.
Zum Vergrößern anklicken....
Das ist erstens hier nicht relevant und zweitens ohne Belege. Ich will jetzt hier keine Quellen sehen, da Offtopic. Doch ich fordere dich auf einen Thread auf zu machen wo die Scheunentore von Epyc diskutiert werden können, die du dort aufzeigst. Oder lass es sein, dann aber auch in allen Threads.
 
Ich würde mir wünschen das wir hier - im Gegensatz zu anderen Foren - bei Fakten und Infos zu Meltdown & Spectre bleiben.
 
So hab ich das noch gar nicht betrachtet. Ob die Chiparchitekten bei Intel (und Co.) die Fehler in den Chips nicht geändert haben, weil sie Angst hatten, dass der dann nicht mehr so schön leuchtet? ;D
 
Hat aber nichts mit dem Thema hier zu tun.
 
Complicated schrieb:
Ich will jetzt hier keine Quellen sehen, da Offtopic. Doch ich fordere dich auf einen Thread auf zu machen wo die Scheunentore von Epyc diskutiert werden können, die du dort aufzeigst. Oder lass es sein, dann aber auch in allen Threads.
Zum Vergrößern anklicken....

eratte schrieb:
Ich würde mir wünschen das wir hier - im Gegensatz zu anderen Foren - bei Fakten und Infos zu Meltdown & Spectre bleiben.
Zum Vergrößern anklicken....
Bitte Ja.
 
Nur für Ryzen? ???
This new firmware disables branch prediction on AMD family 17h processor
to mitigate a attack on the branch predictor that could lead to
information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715).
Zum Vergrößern anklicken....
Das erscheint irgendwie nicht sinnvoll. Es sei denn die neue Branchprediction mit Deep Learning wäre betroffen. Bisher hatte sie auch nur eine schwammige Erwähnung in dem Spectre Dokument, die auch sehr unwissenschaftlich war.

AMD states that its Ryzen processors have “an artificial intelligence neural network that learns to predict what future pathway an application will take based on past runs” [3, 5], implying even more complex speculative behavior. As a result, while the stop-gap countermeasures described in the previous section may help limit practical exploits in the short term, there is currently no way to know whether a particular code construction is, or is not, safe across today’s processors – much less future designs.
Zum Vergrößern anklicken....
Also wenn eine solche Erwähnung ausreicht um den branch predictor zu deaktivieren, müsste man ja alle Intel CPUs sofort händisch aus den Rechnern reißen.
huh.gif
 
Zuletzt bearbeitet:
Warum nichts mit dem Thema zu tun?

Aussagen von Torvalds mal genauer betrachten. Das mit Meltdown und Spectre ist nur die Spitze vom Eisberg. Die Software kann einfach nicht die Fehler der Hardware beseitigen. Nach dem einen Flicken folgt der nächste oder was?

Es brodelt doch schon länger, warum sollte man in x86 noch weiter Zeit investieren? Wenn sich Hardwareseitig nichts ändert.
 

Ähnliche Themen

eratte
News Intel/ARM/AMD: Sicherheitslücken Meltdown & Spectre V1, V2 etc. (Links in Post 1)
29 30 31
Antworten
763
Aufrufe
100K
drSeehas
D
Dr@
Fujitsu STYLISTIC Q572 mit AMD Z-60 APU
Antworten
0
Aufrufe
52K
Dr@
Dr@
mj
Doping für CPUs - Möglichkeiten der Leistungssteigerung
Antworten
0
Aufrufe
33K
mj
mj
Zurück
Oben Unten