News Meltdown & Spectre: Details und Bench­marks zu den Sicherheits­lücken in CPUs

Derweil gibt es weitere PTI-Benchmarks auf Phoronix, denen zu Folge es bei synthetischen Dateisystem-Benchmarks auf NVMe-SSDs dramatische Einbrüche um Faktor 2 und mehr gibt
@CB Könnt ihr die NVMe-Problematik näher untersuchen? Klingt zumindest sehr interessant, dass NVMe so schwer betroffen ist.
 
Hah, als die Russen vor etwas längerer Zeit eigene CPUs entwickelt haben aus Angst vor Backdoors oder eben solcher Sicherheitslücken hat man sie noch ausgelacht, aber jetzt... 😊
 
mikro schrieb:
Naja der Satz "In Linux 4.14.11 fehlt noch der oben erwähnte Patch des AMD-Entwicklers, der PTI auf AMD-CPUs standardmäßig deaktiviert."

Der Satz hat mich stolpern lassen. Danke für die Klarstellung und das ihr so ausführlich berichtet.
Ich hatte nicht gelesen, dass du ein AMD-System nutzt. Dort kannst du nach jetzigem Kenntnisstand einfach "n" sagen. :)
 
Aldaric87 schrieb:
Nur die erste Charge war vom Segfault Bug betroffen, die weiteren nicht.

Du verharmlost das etwas. Es gibt nach wie vor keine offizielle Angabe, welche Chargen betroffen waren und Austauschchips sind i.d.R. ab KW28 produziert. Es wurden in jedem Fall nach bekanntwerden des Problems weiterhin betroffene Chips verkauft, weil die Händler sie noch rumliegen haben. Erst so langsam hört man von Leuten, die ohne RMA einen fehlerfreien bekommen haben.

Was man jetzt den schlimmeren Fehler findet, ist Ansichtssache. Für meinen usecase sind falsche Rechenergebnisse unbemerkte Korrumption von Daten schlimmer als Crashes schlimmer als Sicherheitslücken. Für einen Gamer mag das anders aussehen.
 
Wofür möchten einige hier im Forum Intel denn haftbar machen? Das wäre lediglich legitim, wenn man Intel bewusstes Zurückhalten von Informationen bezüglich besagten Fehlers oder gar die gezielte Implementierung unterstellen würde.

Stand jetzt: Ein folgenschwerer Bug (denn das ist hier definitiv der Fall) wurde entdeckt, an dessen Behebung jetzt an allen Fronten gearbeitet wird. Für strafbares Verhalten irgendeines Beteiligten liegen bisher keine Erkenntnisse vor.
 
Es wäre zumindest wünschenswert, dass man KPTI auch unter Windows ein- und ausschalten kann. Gerade wenn man den Rechner zur Datenverarbeitung nutzt und nicht alle Naselang unbekannte Software installiert, ist eine solche Lücke zwar unangenehm, kann aber doch relativ einfach kompensiert werden.
 
Trochaion schrieb:
Es wäre zumindest wünschenswert, dass man KPTI auch unter Windows ein- und ausschalten kann.

Fraglich ob das durchgeführt wird.. Erinnere dich an den TLB Bug von AMD, den betraf auch nur 0,5% und dennoch wurde per Microcode TLB abgeschaltet, mit Katastrophalen Folgen. Ich befürchte es wird standardmäßig off werden. Aber die Frage ist auch, was kann ein Patch der Software da gegensteuern. Der phoronix Artikel liest sich ja schonmal ganz gut. Und ich bin gleicher Meinung wie du, wenn man das Umgebungsszenario kontrolliert, dann sollte man da ne Option haben

@Otsy:
Er meinte wohl die Performanceeinbrüche, dafür müsste man aber Beweisen, dass die Vermutungen 2010/11 von Intel nicht nachgegangen wurde und man BEWUSST etwas verschwiegen hat. Quasi unmöglich
Sehr wohl kann man Intel den Patch-Aufwand und die Mannstunden versuchen als Schadensersatz rauszuleiern.
 
DEFCON2 schrieb:
Du verharmlost das etwas. Es gibt nach wie vor keine offizielle Angabe, welche Chargen betroffen waren und Austauschchips sind i.d.R. ab KW28 produziert. Es wurden in jedem Fall nach bekanntwerden des Problems weiterhin betroffene Chips verkauft, weil die Händler sie noch rumliegen haben. Erst so langsam hört man von Leuten, die ohne RMA einen fehlerfreien bekommen haben.

Was man jetzt den schlimmeren Fehler findet, ist Ansichtssache. Für meinen usecase sind falsche Rechenergebnisse unbemerkte Korrumption von Daten schlimmer als Crashes schlimmer als Sicherheitslücken. Für einen Gamer mag das anders aussehen.

es gibt aber ein Microcode Update das den Segfault behebt bzw. einen Workaround einbaut damit das nicht mehr auftritt. AGESA 1.0.0.6b behebt das scheinbar.
 
Zuletzt bearbeitet:
Trochaion schrieb:
[...] und nicht alle Naselang unbekannte Software installiert, ist eine solche Lücke zwar unangenehm, kann aber doch relativ einfach kompensiert werden.


Trugschluss.

Es ist wichtig zu verstehen, dass bei einem Hack meistens mehrere Exploits zum Einsatz kommen.

In der Regel mindestens drei:
Das Einfallstor, das Hauptexploit, das Erlangen der Rechte - sprich das Ausführen von privilegiertem Code.

Schritt 2 und 3 werden von der Intel-Lücke abgedeckt. Wenn ich R/W auf den Kernelmemory habe, ist jedes System sicherheitstechnisch K.O. Das ist so ziemlich das schlimmste das passieren kann.

Bleibt das Einfallstor. Du sprichst von Dritt-Software, schön und gut, die hat man unter Kontrolle.
Wie sieht es mit Drive-By aus? Nicht, bzw. nur zum Teil unter Kontrolle. Natürlich helfen Werbe / Pixel und Script Blocker. Die haben die meisten aber leider nicht aktiv, zumindest keine Script-Blocker.

Es gab vor ein paar Jahren mal ein groß angelegten Drive-By über einen Werbeanbieter. Dieser war z.B. auf PC Games geschaltet. In der Werbung hatten Hacker nun einen drive-by untergebracht. Durch das Aufrufen einer völligst normalen Seite, wärst Du in dem Moment komplett ausgeliefert.

Ein kleines Webkit-Exploit und dein System liegt komplett brach, insofern PIT deaktiviert. Da kann man noch so gute Kontrolle über die Drittsoftware halten, das hilft leider nur bedingt.
 
Zuletzt bearbeitet:
Otsy schrieb:
Wofür möchten einige hier im Forum Intel denn haftbar machen? Das wäre lediglich legitim, wenn man Intel bewusstes Zurückhalten von Informationen bezüglich besagten Fehlers oder gar die gezielte Implementierung unterstellen würde.

Stand jetzt: Ein folgenschwerer Bug (denn das ist hier definitiv der Fall) wurde entdeckt, an dessen Behebung jetzt an allen Fronten gearbeitet wird. Für strafbares Verhalten irgendeines Beteiligten liegen bisher keine Erkenntnisse vor.

Sachschädenregulierung durch Sicherheitslücken ist wohl der häufigste Anwendungsfall des Produkthaftungsgesetzes.
Stell dir vor du hast ein Auto für das man einen Schlüssel braucht laut Hersteller aber man braucht durch das Verschulden des Herstellers dann doch keinen. Für dadurch enstehende Sachschäden muss der Hersteller in unbegrenzter Höhe haften.

Straftatbestände sehe ich nicht aber ich bin auch nur Laie.
 
Strafbar macht sich nur, wer einen Mangel bewusst versteckt oder arglistig verschweigt.
Insofern Intel den also nicht bewusst eingebaut hat, keine strafrechtlichen Konsequenzen.
 
der Wirtschaftliche Schaden der von dieser Lücke Ausgelöst (vor allem der Vertrauensverlust) wird ist wohl ee weit größer als ein "rechtstreit", man bedenke was sich im bereich "Datenbanken" abspielen wird denke da wird sich einiges richtung AMD in diesem Marktsegment verschieben.
 
Trochaion schrieb:
Es wäre zumindest wünschenswert, dass man KPTI auch unter Windows ein- und ausschalten kann. Gerade wenn man den Rechner zur Datenverarbeitung nutzt und nicht alle Naselang unbekannte Software installiert, ist eine solche Lücke zwar unangenehm, kann aber doch relativ einfach kompensiert werden.

Microsoft nutzt gerne die grobe Kelle, und mit jeder neuen Version von Windows hat man weniger Möglichkeiten irgendwas einzustellen. Vermutlich sind die in Redmond sogar so blöd und aktivieren das auch für AMD-CPUs, obwohl es total unnötig ist.
 
Einer hatte schon mal vorgesorgt. :rolleyes:
Der CEO von Intel soll Ende November alle Aktien verkauft haben, die er verkaufen durfte
 
@deo: Kluger Mann wie's aussieht. Hast Du auch den Register-Eintrag gelesen?
Ergänzung ()

Sinnfrei schrieb:
Vermutlich sind die in Redmond sogar so blöd und aktivieren das auch für AMD-CPUs, ...
Sollte das der Fall sein, dann gibt es hierfür mit Sicherheit recht schnell einen Patch.
Einen derartigen Blunder der Konkurrenz wird sich AMD wohl nicht entgehen lassen.
 
Zuletzt bearbeitet: (typo)
Benji18 schrieb:
es gibt aber ein Microcode Update das den Segfault behebt bzw. einen Workaround einbaut damit das nicht mehr auftritt.

Wo ist dazu die offizielle Stellungnahme von AMD?
Ergänzung ()

Sester schrieb:
Sachschädenregulierung durch Sicherheitslücken ist wohl der häufigste Anwendungsfall des Produkthaftungsgesetzes.

Beispiele dafür?
Ergänzung ()

Unnu schrieb:
In diesem Zusammenhang interessant:

Inwiefern? Das man aus steuerrechtlicher Taktik bestimmte Geschäfte zu bestimmten Zeiten abwickelt ist nun nicht ungewöhnlich.
 
kisser schrieb:
Wo ist dazu die offizielle Stellungnahme von AMD?
Ergänzung ()

Beispiele dafür?

Kein Microupdate behebt den Segfault Fehler. Das ist auch der Grund warum AMD die betroffenen Prozessoren ohne Probleme austauscht. Habe ich selbst hinter mir.
 
@kisser
ich hab die Aussage von Asus, hab grade recherchiert diese scheint aber wohl eine Fehlinformation gewesen zu sein zumindest auf reddit wird berichtet das dies noch nicht gefixt ist.

@mikro
sagt wer? gibts dazu eine Stellungnahme von AMD? Soweit mein wissenstand ist arbeiten diese an einem Fix
 
Zuletzt bearbeitet:
Das ist mit Sicherheit nicht die letzte Sicherheitslücke die bei irgendwem gefunden wird.
Ich finde die kriminelle Energie von Leuten oder Staaten die solche Sicherheitslücken ausnützen viel schlimmer als die Sicherheitslücke selbst.
 
Zurück
Oben