News CPU-Sicherheitslücken: Mehrere neue Spectre-Varianten, Meltdown trifft AMD
- Ersteller Volker
- Erstellt am
- Zur News: CPU-Sicherheitslücken: Mehrere neue Spectre-Varianten, Meltdown trifft AMD
Sorry, aber wieso soll es erinnern Unterschied machen, ob Daten und Befehle im selben Addressraum liegen oder nicht?kisser schrieb:
Ergänzung ()
Genau, das ist natürlich die einzige Erklärung, warum eine Redaktion bis zum Sonntag nicht über einem Artikel berichtet, der am Freitag (abends?) auf einer der wenigen Tech-Seiten im Internet veröffentlicht wird.Denniss schrieb:
Zuletzt bearbeitet:
dMopp
Banned
- Registriert
- März 2007
- Beiträge
- 9.688
1.) Nicht der erste Artikel dazu
2.) Wird mit der Headline gegen AMD gewettert OHNE im Artikel darauf hin zu weisen, dass AMD nur von „Meltdown“ betroffen ist, weil es eine umbenannte Spectre Lücke ist
3.) Tauchen immer wieder CPU-Ergebnisse auf die sich NICHT mit vielen anderen Seiten decken
4.) Verzichet CB immer wieder (auch bei Threadripper) auf sinnvolle Benchmarks unter Linux
Ergo: Die Kombination aus vielen „komischen Zufällen“ lässt darauf schließen!
2.) Wird mit der Headline gegen AMD gewettert OHNE im Artikel darauf hin zu weisen, dass AMD nur von „Meltdown“ betroffen ist, weil es eine umbenannte Spectre Lücke ist
3.) Tauchen immer wieder CPU-Ergebnisse auf die sich NICHT mit vielen anderen Seiten decken
4.) Verzichet CB immer wieder (auch bei Threadripper) auf sinnvolle Benchmarks unter Linux
Ergo: Die Kombination aus vielen „komischen Zufällen“ lässt darauf schließen!
Kaleo Meow
Banned
- Registriert
- Aug. 2008
- Beiträge
- 2.123
Also grundsätzlich bin ich auch nicht pingellig was diese Lücken anbelangt, ob ich nun schutz habe oder nicht ist mir als Hobby Nutzer (ohne Geld und Sicherungs Zwang) ziemlich egal.
Aber ganz egal darf es mir dann auch nicht sein, denn sonst wird es wie Bahn fahren ohne Schaffner. ^^
Aber ganz egal darf es mir dann auch nicht sein, denn sonst wird es wie Bahn fahren ohne Schaffner. ^^
C
cbolaf
Gast
Schöne Zusammenfassung von Iscaran!
Nachdem ich den Originalbericht (siehe https://arxiv.org/pdf/1811.05441) durchgearbeitet habe, sind mir noch folgende Punkte aufgefallen:
- Die einzige neue "MELTDOWNartige" Lücke bei AMD ist wohl MELTDOWN #BR (Bounds Check Bypass). Diese Lücke existiert ausschließlich bei 32bit-Systemen (IA-32 ISA-Befehlssatz). ARM ist davon nicht betroffen. Bei 64bit-Systemen (AMD64 bzw. x86-64 ISA) wurde der Maschinenbefehl (BNDCL/BNDCN/BNDCU?) entfernt, so dass AMD mit einem 64bit-Betriebssystem auch für MELTDOWN #BR nicht anfällig ist:
"While the bound instruction was omitted in the subsequent x86-64 ISA, modern
Intel processors ship with Memory Protection eXtensions (MPX) for efficient array bounds checking."
Intels MPX ist MELTDOWNanfällig, gibt es eben aber ausschließlich nur bei Intel.
Meine Schlussfolgerung:
Mit einem 64bit-Betriebssysteme ist AMD für alle MELTDOWNartigen Lücken weiterhin nicht anfällig.
Ich bin wie "Iscaran" der Meinung, dass man diesen neuen MELTDOWNartigen Lücken eine eigene Bezeichnung hätte geben müssen, da diese eben nicht die für die bisherigen MELTDOWN-Lücken charakteristische gefährliche Cross-CPL-Eskalation ermöglichen?
- MELTDOWN #RW (ehemals SPECTRE V1.2) ist bei AMD und ARM laut Tabelle 5 nicht möglich, bzw. nicht anwendbar, ebensowenig alle anderen neuen "Meltdown Negative Results":
Meltdown-DE (Division Errors)
Meltdown-AC (Alignment Faults)
Meltdown-UD (Instruction Fetch) -> following an invalid opcode exception
Meltdown-SS (Segmentation Faults)
Meltdown-XD (Instruction Fetch) -> transiently executing instructions residing in non-executable memory
Meltdown-SM (Supervisor Access).
- In der Danksagung am Ende des Berichtes steht:
"Additional funding was provided by generous gifts from ARM and Intel."
Warum haben ARM und Intel die Arbeit gesponsert?
Für Intel hat sich durch den Bericht die Lage doch noch verschlechtert(?).
Warum schreiben Computerbase und Heise pauschal, dass AMD auch anfällig ist für MELTDOWN, ohne auf die oben genannten Punkte einzugehen?
Nachdem ich den Originalbericht (siehe https://arxiv.org/pdf/1811.05441) durchgearbeitet habe, sind mir noch folgende Punkte aufgefallen:
- Die einzige neue "MELTDOWNartige" Lücke bei AMD ist wohl MELTDOWN #BR (Bounds Check Bypass). Diese Lücke existiert ausschließlich bei 32bit-Systemen (IA-32 ISA-Befehlssatz). ARM ist davon nicht betroffen. Bei 64bit-Systemen (AMD64 bzw. x86-64 ISA) wurde der Maschinenbefehl (BNDCL/BNDCN/BNDCU?) entfernt, so dass AMD mit einem 64bit-Betriebssystem auch für MELTDOWN #BR nicht anfällig ist:
"While the bound instruction was omitted in the subsequent x86-64 ISA, modern
Intel processors ship with Memory Protection eXtensions (MPX) for efficient array bounds checking."
Intels MPX ist MELTDOWNanfällig, gibt es eben aber ausschließlich nur bei Intel.
Meine Schlussfolgerung:
Mit einem 64bit-Betriebssysteme ist AMD für alle MELTDOWNartigen Lücken weiterhin nicht anfällig.
Ich bin wie "Iscaran" der Meinung, dass man diesen neuen MELTDOWNartigen Lücken eine eigene Bezeichnung hätte geben müssen, da diese eben nicht die für die bisherigen MELTDOWN-Lücken charakteristische gefährliche Cross-CPL-Eskalation ermöglichen?
- MELTDOWN #RW (ehemals SPECTRE V1.2) ist bei AMD und ARM laut Tabelle 5 nicht möglich, bzw. nicht anwendbar, ebensowenig alle anderen neuen "Meltdown Negative Results":
Meltdown-DE (Division Errors)
Meltdown-AC (Alignment Faults)
Meltdown-UD (Instruction Fetch) -> following an invalid opcode exception
Meltdown-SS (Segmentation Faults)
Meltdown-XD (Instruction Fetch) -> transiently executing instructions residing in non-executable memory
Meltdown-SM (Supervisor Access).
- In der Danksagung am Ende des Berichtes steht:
"Additional funding was provided by generous gifts from ARM and Intel."
Warum haben ARM und Intel die Arbeit gesponsert?
Für Intel hat sich durch den Bericht die Lage doch noch verschlechtert(?).
Warum schreiben Computerbase und Heise pauschal, dass AMD auch anfällig ist für MELTDOWN, ohne auf die oben genannten Punkte einzugehen?
cbolaf schrieb:
Eventuell besteht einfach das ehrliche Interesse daran, Lücken zu finden, Sachverhalte zu verstehen, um dem in Zukunft möglichst effektiv entgegenwirken zu können. Nicht wieder dieselben Fehler zu schaffen, die unter Umständen direkt in der Konzeption entstehen.
Intel mag dadurch erst einmal ein PR-technisches Problem haben, dennoch ist das Wissen über solche Dinge wohl mehr wert, denn so kann man in Zukunft sagen: "Hey, wir haben alles getan, um alles zu finden und zu beheben!"
Egal wie groß nun Intel ist, es ist nie verkehrt auch dritte Spezialisten forschen und suchen zu lassen, wenn es eben einen Nutzen generieren kann. Ich gehe daher wirklich davon aus, dass dies im Grunde Forschungsbudget ist. Wenn man alle Fehler kennt, kann man umfassendere, hoffentlich auch komplett abdichtende Gegenmaßnahmen entwerfen. Wäre ja fatal, wenn man immense Arbeit daran setzt, alles zu fixen, nur um dann kurz darauf festzustellen, dass etwas anderes, genauso schlimmes, noch immer offen steht, einfach weil man es nicht früh genug mitbekam.
Das ist so Usus bei wissenschaftlichen Arbeiten. (zumindest wenn die Wissenschaftler ehrlich sind).
Danke Das ist ja eine nette Zusatzinfo ! Wenn das wirklich nur in 32bit geht dann dürfte das ja eigentlich relativ "safe" sein...zumal es ja eh kein Cross-CPL-Exploit ist.
Naja Hauptsache "Meltdown" drüberschreiben :-).
Wäre wirklich besser gewesen die sortieren die 2 Meltdown-Kategorien in ein "eigenes" Namensschema.
Und von den Fachjournalen hats bislang auch noch keiner wirklich klargestellt.
Gibt mal wieder neue Lücken bei - wen wundert's - Intel: https://www.heise.de/newsticker/mel...-in-Intel-Prozessoren-ZombieLoad-4421217.html
Alles betroffen außer Whisky Lake, Cascade Lake und i9000 mit neuerem R0 stepping
Alles betroffen außer Whisky Lake, Cascade Lake und i9000 mit neuerem R0 stepping
Zuletzt bearbeitet:
- Registriert
- Aug. 2004
- Beiträge
- 11.699
Ob Intel wohl ein Umtauschen der alten Steppings (prä R0) anbieten wird? Immerhin haben sie die ja verkauft, obwohl sie davon wussten.
Flomek
Vice Admiral
- Registriert
- Dez. 2011
- Beiträge
- 6.369
https://www.hardwareluxx.de/index.p...ifft-alle-intel-cpus-mit-hyper-threading.html
Hardwareluxx sagt dass die 8. und 9. Generation nicht betroffen ist.
Dazu im Anhang die PDF von Intel zu dem Thema.
Hardwareluxx sagt dass die 8. und 9. Generation nicht betroffen ist.
Dazu im Anhang die PDF von Intel zu dem Thema.
- Registriert
- Aug. 2004
- Beiträge
- 11.699
Nicht alle steppings laut heise
Flomek
Vice Admiral
- Registriert
- Dez. 2011
- Beiträge
- 6.369
Ned Flanders schrieb:
https://www.intel.com/content/www/u...ngineering-new-protections-into-hardware.html
Intel hat dazu auch schon ne Webseite. Sieht so aus als sei Heise da besser informiert als Hardwareluxx.
- Registriert
- Aug. 2004
- Beiträge
- 11.699
Wenn Intel alles richtig machen will, bieten sie einen kostenlosen Tausch der betroffenen 9er Serie CPUs gegen das neue Stepping an, ähnlich wie AMD damals beim Segfault. Davon machen am Ende eh wenige gebrauch, das schafft aber vertrauen.
Naja, schaun wir mal.
Hat einer einen 9900k und macht mal nen cpuz screenshot und sagt wann er/sie ihn gekauft hat?
Naja, schaun wir mal.
Hat einer einen 9900k und macht mal nen cpuz screenshot und sagt wann er/sie ihn gekauft hat?
Und ich dacht es ging hier um AMD und es gäbe zu ZombieLoad schon einen Thread.
Also mal zum Thema dieses Thread: Spectre — AMD-Microcodeupdate-Chaos seit über einem Jahr (Planet3dnow) und die stehen wohl kaum im Verdacht AMD Bashing zu betreiben.
Also mal zum Thema dieses Thread: Spectre — AMD-Microcodeupdate-Chaos seit über einem Jahr (Planet3dnow) und die stehen wohl kaum im Verdacht AMD Bashing zu betreiben.
- Registriert
- Aug. 2004
- Beiträge
- 11.699
MK one
Banned
- Registriert
- März 2017
- Beiträge
- 4.889
https://arxiv.org/pdf/1811.05441.pdf
steht fast am Ende des PDF direkt über Conclusion
To show the overall decrease on a Linux 4.19 kernel with the default mitigations enabled, Larabel [57] performed multiple benchmarks to determine the impact. One of those benchmarks was CompileBench, which is suitable to determine the performance loss. On Intel, the slowdown was 7-16% compared to a non-mitigated kernel, on AMD it was 3-4%.
Wie man es dreht und wendet , AMD kommt wesentlich besser dabei weg , bei vielen Lücken gar nicht erst betroffen , und dort wo man betroffen war haben die Patches kaum Leistung gekostet
Mit den neuen Intel only Lücken und Patches dürften da noch mal 2-4 % hinzukommen , da wären dann 9 - 20 % Verlangsamung durch die Patches zu AMD s 3-4 % ....
Bei Intels üblichen 5 % pro Generation sind das schon 2 Generationen Rückschritt
steht fast am Ende des PDF direkt über Conclusion
To show the overall decrease on a Linux 4.19 kernel with the default mitigations enabled, Larabel [57] performed multiple benchmarks to determine the impact. One of those benchmarks was CompileBench, which is suitable to determine the performance loss. On Intel, the slowdown was 7-16% compared to a non-mitigated kernel, on AMD it was 3-4%.
Wie man es dreht und wendet , AMD kommt wesentlich besser dabei weg , bei vielen Lücken gar nicht erst betroffen , und dort wo man betroffen war haben die Patches kaum Leistung gekostet
Mit den neuen Intel only Lücken und Patches dürften da noch mal 2-4 % hinzukommen , da wären dann 9 - 20 % Verlangsamung durch die Patches zu AMD s 3-4 % ....
Bei Intels üblichen 5 % pro Generation sind das schon 2 Generationen Rückschritt
- Registriert
- Feb. 2005
- Beiträge
- 5.502
Bevor wir hier ergebnisorientiert Synergien im Loop syncen, sollten wir uns erst committen ob das Tool einen skalierbaren Workflow besitzt um alle Probleme zu entdecken!Ned Flanders schrieb:
SCNR, aber "Submittest" hat meinen B-Bingo-Detektor voll anspringen lassen
.Bin selbst auch schon auf die Ryzen 3xxx-Benchmarks gegen "komplett" gepatchte (inkl. der Benchmark-SW) Intel-Systeme gespannt. Könnte sehr interessant werden.MK one schrieb:
