News CPU-Sicherheitslücken: Mehrere neue Spectre-Varianten, Meltdown trifft AMD

kisser schrieb:
@Miuwa

Einheitlicher Speicher für alles. Bei strikter Trennung in Daten- und Befehlsspeicher kannst du keine fremden Daten abgreifen, weil du deren Speicherbereich überhaupt nicht siehst.
Sorry, aber wieso soll es erinnern Unterschied machen, ob Daten und Befehle im selben Addressraum liegen oder nicht?
Ergänzung ()

Denniss schrieb:
Clickbait Intelbase halt
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.
 
Zuletzt bearbeitet:
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!
 
  • Gefällt mir
Reaktionen: MIWA P3D
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. ^^
 
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?
 
  • Gefällt mir
Reaktionen: MarcelGX, psYcho-edgE, Iscaran und 4 andere
cbolaf schrieb:
- 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(?).

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.
 
  • Gefällt mir
Reaktionen: Miuwa
In der Danksagung am Ende des Berichtes steht:
"Additional funding was provided by generous gifts from ARM and Intel."

Das ist so Usus bei wissenschaftlichen Arbeiten. (zumindest wenn die Wissenschaftler ehrlich sind).

- 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:

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.
 
Ob Intel wohl ein Umtauschen der alten Steppings (prä R0) anbieten wird? Immerhin haben sie die ja verkauft, obwohl sie davon wussten.
 

Anhänge

  • SA00233-microcode-update-guidance_05132019.pdf
    906,3 KB · Aufrufe: 893
Schätze die Cloudanbieter kotzen wieder im Strahl. Lösung: HTT ausschalten :-)
 
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?
 
Gibs dem i9-9900K mit R0 Stepping schon zu kaufen?
 
Wer immer noch Intel kauft, hat echt keine Ahnung von Hardware.
 
  • Gefällt mir
Reaktionen: jonderson
@Holt

Keine Sorge, alles bestens auf meinem ProBook645 G1

781967


Submittest du auch einen Screenshot?
 
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 :evillol::evillol:
 
  • Gefällt mir
Reaktionen: Strikerking und or2k
Ned Flanders schrieb:
Submittest du auch einen Screenshot?
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!

SCNR, aber "Submittest" hat meinen B-Bingo-Detektor voll anspringen lassen :D.

MK one schrieb:
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 % ....
Bin selbst auch schon auf die Ryzen 3xxx-Benchmarks gegen "komplett" gepatchte (inkl. der Benchmark-SW) Intel-Systeme gespannt. Könnte sehr interessant werden.
 
Zurück
Oben