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

@yummycandy: Sind das Sachen, worüber ich mir als Anwender Gedanken machen muss? Wer weiß wie viele Lücken es in Hard- und Software noch gibt, die eventuell schon heute von Hackern genutzt werden, aber sonst gänzlich unbekannt sind?

Fakt ist doch inzwischen: Meltdown ist vernachlässigbar, da patchbar und wohl auch im großen Umfang (siehe Google) nicht dramatisch was die Leistung angeht und Spectre ist relativ schwierig auszunutzen und zukünftige CPU-Generationen können das Problem beheben.

Vielleicht nicht viel Wind um nichts, aber etwas übertrieben schon. Wobei es für den IT-Enthuasten sehr interesserant zu verfolgen ist.
 
kachiri schrieb:
@yummycandy: Sind das Sachen, worüber ich mir als Anwender Gedanken machen muss? Wer weiß wie viele Lücken es in Hard- und Software noch gibt, die eventuell schon heute von Hackern genutzt werden, aber sonst gänzlich unbekannt sind?

Wie gesagt, du kannst nur Updates installieren. Sonstige Gedanken und Panik bringen nichts, genau wie das runterspielen der Lücken keinem hilft. Als Anwender bist du nunmal auf den Support der Soft- und Hardwarehersteller angewiesen.
 
@ComputerBase:

Vielen Dank an die Redaktion für die hervorragende Aufbereitung dieses nicht ganz einfachen Themas.

Das Beste was ich bislang im Netz darüber gesehen habe.
Da können sich andere nicht nur eine Scheibe davon abschneiden.
 
Bei mir sieht es aktuell so aus:
In wie weit sind die übrig gebliebenen roten Punkte noch kritisch?

Speculation control settings for CVE-2017-5715 [branch target injection]

Hardware support for branch target injection mitigation is present: False
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: False
Windows OS support for branch target injection mitigation is disabled by system policy: False
Windows OS support for branch target injection mitigation is disabled by absence of hardware support: True

Speculation control settings for CVE-2017-5754 [rogue data cache load]

Hardware requires kernel VA shadowing: True
Windows OS support for kernel VA shadow is present: True
Windows OS support for kernel VA shadow is enabled: True
Windows OS support for PCID optimization is enabled: True

Suggested actions

* Install BIOS/firmware update provided by your device OEM that enables hardware support for the branch target injection mitigation.
* Follow the guidance for enabling Windows support for speculation control mitigations are described in https://support.microsoft.com/help/4072698

BTIHardwarePresent : False
BTIWindowsSupportPresent : True
BTIWindowsSupportEnabled : False
BTIDisabledBySystemPolicy : False
BTIDisabledByNoHardwareSupport : True
KVAShadowRequired : True
KVAShadowWindowsSupportPresent : True
KVAShadowWindowsSupportEnabled : True
KVAShadowPcidEnabled : True
 
Zuletzt bearbeitet:
Laut Intel werden ja Firmware-Patches implementiert, um dieses Problem anzugehen. Zumindest wegen Spectre, evtl auch, um noch was an der Performance zu ändern. Ich bin gespannt, wie lange die Mainboard-Hersteller brauchen, um das zu implementieren. Hier ein Auszug aus dem "neuesten" UEFI, Rampage VI APEX von Asus, Mitte Dezember
Anhang anzeigen 659518

Die Skylake-X Prozessoren werden durch CPUID 00050654 repräsentiert - einfach einen der i9 Prozessoren mit der Nummer in google eingeben. Das erste Ergebnis sollte cpu.userbenchmark sein, da wird diese Nummer auch in der Produktbezeichnung angezeigt. Lange Rede, kurzer Sinn: Der neueste Microcode datiert hier vom 09. August.
Inzwischen gibt es von Intel bereits mehrere neue, die alle noch nicht implementiert sind, der letzte vom 17.10.2017.
Wohlgemerkt: Das UEFI von Dezember enthält die Microcode-Patches von Oktober nicht. Deswegen ist es u.U sinnvoll, das selber in die Hand zu nehmen und den Microcode nach dem Download von Intel direkt in das aktuellste UEFI reinzupatchen. Mehr kann man als User dann auch nicht mehr machen. Das sorgt zumindest mal dafür, dass man in Sachen Microcode nicht mehr auf die MoBo-Hersteller angewiesen ist, die ja immer noch mit der Intel-ME-Lücke hadern. Was die angeht, müssen wir tatsächlich auf die neuen UEFI-Versionen inklusive ME-Update warten, es sei denn, man will auch noch diese Updates selbst im UEFI verankern.
 
CompuJoe schrieb:
Irgendwie habe ich das Gefühl das wie gerade den Hauptgrund sehen warum Coffee-Lake vorgezogen würde.
Die hatten wohl Angst das sie nix mehr verkaufen wenn das raus kommt.

Nee, das ist Quatsch!
Eher hätte man dann die Produktion gar nicht erst angefahren (man wußte ja im Juni schon, was da im Busche ist), als daß man riskieren würde, auch mit den teuren neuen CPUs auf die F... zu knallen.

Nein, die Kaffee-Lache ist eine Reaktion auf Ryzen. Da gab es ja auch einen Vorlauf, und Intel wird schon seit langem wissen, daß die neue AMD-Architektur konkurrenzfähig sein würde. Also hat man die Dinger fix entwickelt und als Schnellschuß mit einer schon bei Produkteinführung abgekündigten Plattform ruasgehauen, um die Schlagzeilen für osich zu habne, die da heißen "Intel ist immer noch besser!"

Und im Gegensatz zu AMD kann sich Intel Parallelentwicklungen leisten. Die können auch mal einen Prozessor basteln und wegschmeißen. Sie haben da sGeld udn die Ressourcen, dennoch gleichzeitig andere Serien weiterzuentwickeln. So haben sie sich ja auch vom Netburst-Desaster erholt (von den fiesen MArkttricks mal ganz abgesehen). Sie haben einfach parallel zu Netburst die alte PIII-Architektur überarbeitet und auf Stromsparen getrimmt. Die Teile kamen dann als Pentium-M-Mobilprozessoren in die Laptops, und als das klappte, entwickelte man daraus die Core-Serie.

AMD dagegen kann sich immer nur auf eine x86-Entwicklung konzentrieren. Und als Bulldozer so abk....te, war erst mal ein paar Jahre Sense.
 
Hat schon jemand getestet wie sich die performance mit patch auf langsameren CPUs wie Intel Atom auswirkt?
 
Hm... Synchrones DRAM wird also seit seiner Einführung von den beiden verbliebenen Architekturen mehr oder weniger fehlerhaft angesteuert.

Gleichzeitig wird kolportiert, dass der letzte RISC-Abkömmling Itanium (†) in dieser Hinsicht fehlerfrei gewesen sei.

Falls das so stimmt, kann man wohl ab der übernächsten Generation von ARM/i86-Prozessoren erwarten, dass der Fehler behoben sein wird.
 
760_Torr schrieb:
Falls das so stimmt, kann man wohl ab der übernächsten Generation von ARM/i86-Prozessoren erwarten, dass der Fehler behoben sein wird.
ARM schrieb, daß die nächste Generation schon fehlerfrei sein soll.
 
nex86 schrieb:
Hat schon jemand getestet wie sich die performance mit patch auf langsameren CPUs wie Intel Atom auswirkt?

Wenn es ein Atom vor 2013 war, dann bist du sicher denn die hatten schlichtweg kein Out-of-order-Design.
 
Trotzdem bekommt auch der alte Atom den (Linux)-Patch angewendet. Wie es MS umgesetzt hat ist eine andere Frage.
 
Tolles Update! Blauer Bildschirm nach dem Update!!! Nachdem ich jetzt nach ca. 1Std. den wieder den PC gestartet habe.:grr:
 
BBX8995-1 schrieb:
Wenn es ein Atom vor 2013 war, dann bist du sicher denn die hatten schlichtweg kein Out-of-order-Design.

ne ist ein Z8700 von 2015. Ich meine nur, wenn die performance einbuße bei Desktop CPUs schon 5% ist was ist sie dann bei Atoms? 20%?
mir ist die CPU jetzt ungepatcht schon lahm genug :D
 
nex86 schrieb:
ne ist ein Z8700 von 2015. Ich meine nur, wenn die performance einbuße bei Desktop CPUs schon 5% ist was ist sie dann bei Atoms? 20%?

Ich tippe mal, daß NAS mehr drunter leiden werden als Desktops.
 
Ist dieses Update wirklich so schlimm? Laut den Benchmarks sind es eher 1 %. Ich habe noch einen 5820K in Betrieb und mit jedem Monat der vergeht wird meine Lust größer das sinkende Schiff (Intel) zu verlassen.
 
Ich schätze mal das kommt auf die CPU und den Awendungsbereich an.
Theoretisch wird man die performance einbuße bei sparsamen, langsamen CPUs wie Atoms wohl deutlicher merken als bei schnellen Desktop CPUs wie einem 7700K
 
piet369 schrieb:
Tolles Update! Blauer Bildschirm nach dem Update!!! Nachdem ich jetzt nach ca. 1Std. den wieder den PC gestartet habe.:grr:
Ich nutze Windows nur selten, aber mein erster Versuch wäre jetzt, im abgesicherten Modus zu starten und systemnahe Software wie den Virenscanner testweise abzuschalten.
 
Zurück
Oben