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

Intetessanter Punkt von fefe:
http://blog.fefe.de/?ts=a4ac7405
Bei dem Meltdown-Bug ist mir gerade was aufgefallen, das ich mal mit euch teilen will.

Und zwar hat Intel seit Jahren in ihrem Prozessoren "Hyperthreading", deren Markennamen für eine Technik namens Simultaneous Multithreading (SMT). Bei Intel bringt das so 20% Mehrleistung, wenn man einen zweiten Thread startet und der auf dem virtuellen Core läuft. Kommt natürlich immer auf den Code an, klar.

AMD hat seit Ryzen auch SMT, aber bei denen bringt das 40%. Ich habe mich die ganze Zeit gefragt, wieso. Jetzt glaube ich, die Erklärung zu haben.

Und zwar hat Intel ja, wie wir jetzt wissen, bei ihrer spekulativen Ausführung von Instruktionen beschissen, und hat den Load vor den Zugriffscheck vorgezogen. Der Load wird schon gemacht, wenn die CPU sich noch nicht sicher ist, ob der Load erlaubt sein wird (die Prüfung davon kostet auch Zeit). Wenn Intel dann feststellt, dass der Load nicht erlaubt war, ist es nicht schlimm, wenn die Daten in den Cache geladen wurden, denkt sich Intel. Und das lief auch jahrelang prima, bis jemandem auffiel, dass das ein Sicherheitsproblem ist.

So, nehmen wir mal an, Intel hätte nicht auf diese Art für Benchmarks beschissen. Was wäre der Effekt gewesen? Die Latenz für die Load-Instruktionen wäre hoch gegangen. Und was macht die CPU, wenn gerade irgendwas hängt (weil die Latenz zu hoch ist)? Sie führt per SMT einen anderen Thread aus. Das ist die Idee von SMT.

Was, so frage ich mich gerade, wenn die 20% mehr SMT-Performance bei AMD genau die 20% sind, die Intel hier durch Senken der Sicherheit rausgeschummelt hat? AMD hat einfach ehrlich gestallt in den Fällen. Und das geht jetzt dank SMT nicht mehr verloren.

Ich fühlte mich spontan an Dieselgate erinnert. :-)
 
https://twitter.com/chanian/status/949457156071288833
The <s>#</s>Meltdown patch (Update on above, this was a <s>#</s>Spectre patch (CVE-2017-5715), impacting HVM performance on a very high IO workload) (presumably) being applied to the underlying AWS EC2 hypervisor on some of our production Kafka brokers [d2.xlarge]

DS0h-eHVoAAMfjh.jpg:large
 
Ich kann nicht sagen welcher Patch dafuer verantwortlich ist, aber ich habe auf meinem Ryzen Sys in in ArmA3 (sehr sehr CPU und RAM lastig) etwas mehr als 10% verloren in der letzten Woche.

Vorher 51-52 FPS im YAAB
Jetzt 45-46 FPS im YAAB

Gibts eine moeglichkeit den Spectre Patch testweise abzuschalten? Meltdown sollte ja nicht scharf sein.

@MusicIsMyLife

Ihr habt ArmA3 doch beim Threadripper Test gebencht. Kannst du das reproduzieren?
 
Zuletzt bearbeitet:
Verstehe ich irgend wie nicht so richtig.......
Die Lücken sind doch schon seit Jahren da........
Ist wie mit Menschen,sie leben 30 Jahre mit ner Krankheit wovon sie nix wissen, auf einmal wir Ihnen gesagt was sie haben und nach nem Halben Jahr fallen sie um....*buck*

Komisch find ich auch das ausgerechnet Jetzt wo AMD mit Ryzen nicht mehr ausgebremst und Intel gefährlich wird diese Sache ans Licht kommt und AMD HW komischerweise viele Probleme und der Gleichen hat......
 
Dann wussten bisher eben nur Intel, NSA und Co, davon.
http://www.tomshardware.de/NSA-Geheimdienst-Back-door-Prozessoren,news-249410.html

Wenn sich Tage nach Veröffentlichung und entweder überzogenen oder halbgaaren Workarounds tausende Blackhats aufmachen um daraus Kapital zu schlagen, wird das für die Betroffenen mit entwendeten Accounts und Identitäten sehr ungemütlich. Sich selbst schützen ist zudem nur die halbe Miete wenn serverseitig noch lange die betroffenen Xeons arbeiten.
 
Ersetze "Keiner" durch "kaum einer". Das trifft die Realität.
So lange die Lücke weitestgehend unbekannt ist, schlummert sie nur im Arsenal der Geheimdienste.
Wenn sie öffentlich wird, stürzt sich jeder Hobbyprogrammierer drauf.
 
Wenn man Serversysteme verkauft dann kann einem ein Vertreter viel erzählen. Da wird neue Hardware untersucht und abgeklopft. Man will ja ein dichtest System das man einfach hinstellt und mit wenig Wartungsaufwand sicher über Jahre läuft.

Das war eben bei Intel nicht mehr gegeben.
 
Hi,

ich weiss nicht ob das nun schon gepostet wurde oder nicht. Aber der Blog von Anders Fogh ist recht interessant zu lesen:
https://cyber.wtf/2018/01/

Außerdem ist es wohl so dass Spectre wohl eher ein "Software"-Problem ist, da es in Hardware vermutlich nicht lösbar ist, es sei denn man schafft Speculative Execution ab ODER flusht den Speicher jedes mal wenn man SpecEx ausführen möchte, was den Performance-Vorteil damit quasi vollständig aufhebt bzw. sogar negiert (Quelle Peter Cordes via Stackexchange):
https://security.stackexchange.com/...ess-vulnerable-to-meltdown-and-spectre/177101

Spectre affects any "normal" CPU design with branch prediction + speculative execution for indirect branches. In Spectre, the attacker primes / trains the branch predictor to mispredict the target of an indirect branch in kernel code or in another process. Until the mis-predict is discovered, the privileged process will speculatively execute some instructions that change the micro-architectural state of the machine in a way that depends on secret data.

Nur Meltdown ist ein Design-Fehler der offenbar nur in Intel-CPUs enthalten ist. Offenbar (spekulation) ist es wohl so dass Intel CPUs hier nicht richtig prüfen ob bestimmter Code über Ring-Grenzen hinweg eigentlich überhaupt ausgeführt werden darf (man könnte salopp sagen Intel nutzt ein "aggressivers Branch Prediction Verhalten").
The key to Meltdown is that Intel CPUs (but apparently not ARM or AMD) don't squash under-privileged TLB hits. The load executes, and so do following instructions, and it only actually faults when the faulting load tries to retire.
Presumably AMD's load execution units / TLB are designed differently, with privilege checking for loads applied earlier or differently.
 
Zuletzt bearbeitet:
Nur Meltdown ist ein Design-Fehler der offenbar nur in Intel-CPUs enthalten ist.

ARM Designs sind auch betroffen siehe Liste.
 
@ Casi
Eine Luecke von der keiner weiss ist nicht gefaehrlich.
Wenn du dir mal die Interviews mit dem Grazer Jungen anschaust, wirst du feststellen, dass Intel mindestens seit 2014 davon wusste

Und die Blackhat hatte ähnliches zu ähnlicher Zeit.
Erste Vermutungen, dass das unsicher wäre, kamen schon 2007 auf...
 
Zuletzt bearbeitet:
Ja das aufbauschen und nicht differenzieren scheint hier auch reines Selbstinteresse der TU Graz zu sein - traurig, doch auch Forscher leben von Aufmerksamkeit und Bekanntheit.
Wir reden hier, gerade wenn wir jetzt Meltdown und Spectre zusammennehmen - das sind die beiden Angriffe -, dann reden wir hier nicht von einigen Tausend oder Millionen Rechnern, sondern wir sind hier im Milliardenbereich an Prozessoren, die davon betroffen sind.
Da ist niemand daran interessiert zu differenzieren. Auch die Presse nicht. ich schrieb es schon einmal -es ist das erste mal, dass zwei unterschiedlcihe Exploits so in einen Topf geworfen werden und wirklich überall in einem Atemzug genannt werden.

Ich sage es voraus, dass es keine Woche mehr dauert bis die Medien da etwas "Brangelina"-mäßiges daraus machen wie "Specdown" oder "Meltre".
 
Zuletzt bearbeitet:
POWER7+, POWER8 und POWER9 sind im Referenzdesign von IBM ebenfalls (eingeschränkt) betroffen.

Quelle: https://www.ibm.com/blogs/psirt/potential-impact-processors-power-family/

Wie es um die SPARC(64) Familie von Sun/Oracle/Fujitsu bestellt ist, ist derzeit noch nicht verlautbart worden.
Die wichtigste und häufig einzige Aufgabe des PSP neben Measured Boot (u.a. Absicherung der Firmware) und Secure Boot (Absicherung des Bootloaders) ist als Ablageort von Bitlocker-Schlüsseln (fTPM 2.0) zu dienen. Microsoft schreibt das Vorhandensein eines diskreten TPM 2.0 oder eines fTPM 2.0 für Komplettrechner mit vorinstalliertem Windows 10 vor und legt fest, dass dieses im Auslieferungszustand eingeschaltet sein muss. Natürlich ließe sich damit noch jede Menge anderer Unsinn anstellen, aber das unterbleibt im Regelfall; abgesehen von einigen DRM-Anwendungen und dergleichen.

Die ARM TrustZone wird leider von vielen Chipherstellern mangelhaft umgesetzt. Selbst von namhaften Größen wie Qualcomm und Samsung. Der nun bei AMD aufgedeckte Fehler geht nicht einmal auf AMD oder ARM zurück, sondern auf die TCG deren Codebeispiele AMD weitgehend unverändert übernommen hat und daraus das anfällige Trustlet gebastelt hat. Laut Google Project Zero waren bereits die Codebeispiele der TCG kompromittiert.

Siehe auch: https://googleprojectzero.blogspot.de/2017/07/trust-issues-exploiting-trustzone-tees.html

Das ist natürlich fatal, weil sich der PSP wie alle anderen vergleichbaren Lösungen ungehindert und unbemerkt auf dem Ring 0 austoben darf.
;D
Du hast es immer noch drauf! 8)

 
Zuletzt bearbeitet:
;D
Du hast es immer noch drauf! 8)
Was mir nicht gefällt, ist dieses "We / I believe" usw. aber das ist wohl eine Eigenheit. Wenn mir einer erzählt: dass er glaubt, dann ist diese Information fuer mich wertlos, weil ich fakten wissen will und nicht was irgendwer "glaubt".

Gruß,
skell.
 
Wenn du dir mal die Interviews mit dem Grazer Jungen anschaust, wirst du feststellen, dass Intel mindestens seit 2014 davon wusste

Also das kann ich beim besten Willen da nicht raus lesen.

Erste Vermutungen, dass das unsicher wäre, kamen schon 2007 auf...

Es ist halt so dass sich das ganze ja auch entwickelt hat. Siehe Blog von Anders Fogh den ich paar Posts weiter oben verlinkt habe. Selbst IT-Experten Wie Hr. Fogh oder den Leuten der TU Graz etc. war lange Zeit gar nicht klar was für einen "bug" sie da gejagt haben.

Angefangen hat das mal mit Problemen die man im ASLR gefunden hat und die man fixen wollte mittels KASLR, was leider wiederum anfällig war und wofür die TU Graz'ler Jahrelang an dem KASLR Patch namens KAISER gebrütet haben.

Unabhängig davon kam vor ein paar Jahren der Rowhammer-RAM-Exploit raus...der ist im Grunde durchaus was ähnliches zu Meltdown (also zumindest in der Art und Weise wie man ihn auslöst/ausnutzt.
...aufbauend auf Rowhammer und mit dem Wissen um ASLR/KASLR/KAISER kamen dann die IT-Experte nach und nach auf den Trichter das man einem viel gravierenderen Problem aufgesessen ist. Meltdown und Spectre. (so ca. kann man zusammenfassen was Hr. Fogh schreibt).

Das Problem ist dass auf diesem Level sich selbst die Fachleute noch nicht einig sind wie man damit umgehen soll....mit einem schnellen Fix der nur Probleme schafft ist ja schliesslich auch keinem geholfen.

Hr. Gruss von der TU Graz differenziert schon ein wenig. Im weiteren Verlauf des Interviews differenziert er deutlich Meltdown und Spectre jedoch ohne Nennung von CPU-Hersteller Eigenheiten.
Es ist ja auch für unabhängige ITler nicht so einfach da man ja die internen Abläufe in den CPUs zum Großteil ja reverse engineered weil die Hersteller ja nichts/kaum was offen legen.

Agner Fog betreibt über seine Reverse Engineering Ergebnisse seit Jahren einen sehr frequentierten Blog und hat hunderte Seiten Manuals mit den Ergebnissen veröffentlicht.
http://www.agner.org/optimize/blog/?r=1&o=5

--- Update ---

https://www.heise.de/newsticker/mel...ert-Patches-und-Leistungsschwund-3937462.html
https://cloudblogs.microsoft.com/mi...-and-meltdown-mitigations-on-windows-systems/

Wird interessant sein zu sehen ob AMD CPUs denselben Performance impact haben werden...

Am Ende gleicht sich die IPC dann plötzlich dramatisch an :-)
 
Zuletzt bearbeitet:
Am Ende gleicht sich die IPC dann plötzlich dramatisch an :-)

Durchaus möglich. Aber da Intel ja seit Jahren nur portionsweise Leistung nachschiebt (5% im Mittel pro Generation) wird man durch den Patch quasi eine Generation zurück gestuft. Während AMD einen Schritt vor geht, geht Intel einen zurück. Spätestens beim nächsten Schritt wird man sich dann treffen, sollte die Richtung beibehalten werden ;)
 
Die TU Graz hat mittlerweile eine sehr übersichtliche Seite online gebracht mit viel relevanten infos und vor allem ein paar netten Demo Videos wie der Exploit in der Realität genutzt werden kann.
https://meltdownattack.com/
 
Zurück
Oben Unten