Intel hat nach eigenen Angaben die ersten überarbeiteten Microcode-Updates an seine Partner und OEMs ausgeliefert. Sie stehen bisher allerdings nur für bestimmte Skylake-Prozessoren zur Verfügung, darunter die Serien Skylake U, Y, H, S und U23e. In den kommenden Tagen sollen Updates für weitere Plattformen folgen.
Ende Januar identifizierte Intel den Grund für Neustart-Probleme, die vor allem bei Broadwell- und Haswell-Prozessoren nach der Installation der ersten Patches für die CPU-Sicherheitslücken Meltdown und Spectre auftraten. Zudem forderte es seine Kunden und Partner auf, die vorhandenen Patches nicht mehr zu installieren und stattdessen Vorabversion von neuen Patches zu testen.
„Wir veröffentlichen weiterhin Beta-Microcode-Updates, damit Kunden und Partner die Gelegenheit haben, intensive Tests durchzuführen, bevor wir sie für den produktiven Einsatz freigeben“, schreibt Navin Shenoy, Executive Vice President der Intel Data Center Group, in einer Pressemitteilung. „Letztendlich werden diese Updates in den meisten Fällen über OEM-Firmwareupdates verfügbar gemacht. Ich kann nicht genug betonen, wie wichtig es für jeden ist, immer seine Systeme auf dem neuesten Stand zu halten.“
Der aktuelle Stand bei Intel ist, dass mehr als einen Monat nach Bekanntwerden der Meltdown- und Spectre-Lücken nicht einmal für alle Prozessoren der Skylake-Generation die benötigten Microcode-Updates vorliegen. Wann die Generationen Coffee Lake, Kaby Lake, Broadwell, Haswell, Ivy Bridge und Sandy Bridge versorgt werden, ist derzeit nicht bekannt.
Einer PDF-Datei zufolge, die über die Verfügbarkeit von Microcode-Updates informiert, prüft Intel derzeit auch noch eine weitere Option. In Zusammenarbeit mit OEM-Partnern sollen BIOS-Updates angeboten werden, die auf den eigentlich fehlerhaften Microcode-Version basieren, ohne den Fix für die Variante 2 (Spectre) zu enthalten, die die Neustartprobleme verursacht. Sie sollen keinen Einfluss auf die Fixes für Variante 1 (Spectre) und Variante 3 (Meltdown) haben.
Nutzer von PCs mit Core-Prozessoren der fünften Generation und älter (Broadwell, Haswell, Ivy Bridge und Sandy Bridge) werden möglicherweise nie ein Microcode-Update erhalten. Hersteller wie Asus, Gigabyte, MSI und ASRock kündigten an, lediglich für Mainboards, die Prozessoren der sechsten, siebten und achten Generation unterstützen, BIOS-Updates zu entwickeln, die Intels Microcode-Updates für Spectre und Meltdown enthalten. Wann Nutzer älterer Systeme auf neue Intel-Prozessoren umsteigen können, die nicht von Meltdown und Spectre betroffen sind, ist bisher nicht bekannt.
Studie zu Filesharing im Unternehmen: Kollaboration im sicheren und skalierbaren Umfeld
Im Rahmen der von techconsult im Auftrag von ownCloud und IBM durchgeführten Studie wurde das Filesharing in deutschen Unternehmen ab 500 Mitarbeitern im Kontext organisatorischer, technischer und sicherheitsrelevanter Aspekte untersucht, um gegenwärtige Zustände, Bedürfnisse und Optimierungspotentiale aufzuzeigen. Jetzt herunterladen!
Tipp: Wie gut kennen Sie sich mit Prozessoren aus? Überprüfen Sie Ihr Wissen – mit dem Quiz auf silicon.de.
Neueste Kommentare
4 Kommentare zu Meltdown/Spectre: Intel liefert erste überarbeitete Firmware-Updates aus
Kommentar hinzufügenVielen Dank für Ihren Kommentar.
Ihr Kommentar wurde gespeichert und wartet auf Moderation.
Immer schön nachfragen bei Intel.
Intel soll ruhig merken, dass diese Geheimniskrämerei mit signierten, verschlüsselten Microcodes nur mehr Arbeit für Intel bedeutet.
@Intel & @AMD:
Wo bleiben die Microcode-Updates für die alten CPUs?
Hier mal etwas Rechts-Kunde, gültig in diesem Land:
1. Gewährleistung – für Produkte bis 2 Jahre
– der Kunde kann wandeln oder zurückgeben
2. Produkt-Haftungsgesetz – für Produkte bis 10 Jahre
– der Kunde kann Schadens-Ersatz einfordern
3. Produzenten-Haftung – für Produkte >10 Jahre
– Schadens-Ersatz für Kunden nach § 823 Abs. 1 BGB
– Verjährung 3 Jahre ab Bekanntwerden des versteckten Sach-Mangels
D. h. die beiden CPU-Hersteller sind rechtlich gebunden, hier für ihre fehlerhaften Produkte Patches zu liefern oder Schadensersatz zu leisten. Intel muss wg. Meltdown Schadens-Ersatz leisten.
Bekanntwerden des Fehlers: 03.01.2018.
Fahrlässigkeit der Hersteller: ungenügende Tests und Bruch der eigenen x86 Architektur-Vorgaben.
Fehler: Verletzung der Speicher-Schutz-Mechanismen im Protected Mode.
Es könnten auch noch Straf-Anzeigen wg. §§ 263 und 303 StGB folgen…insofern würde Ich die Auslieferung der notwendigen Patches für ALLE BETROFFENEN CPUs dringend empfehlen.
Fehlerhafte Produkte?
Dass diejenigen Mikrochips sich insistent an ihre Dokumentation halten haben Sie aufgrund Ihrer Inkompetenz zum Theorem „Out-of-order execution“ und „Speculative execution“ nicht bedacht!?
Begreifen Sie zuerst einmal nur ansatzweise die Didaktik von einer solchen Cachehierarchie, worauf diejenigen Sicherheitslücken abzielen – deren Privilegierungsstufen betreffend -, bevor Sie in Ihrer Ingnoranz mittels nicht präliminarischer Polemik das Postulat – die Weiche – zur Agitation stellen!
@KnSNaru
Oh, ein Intel-Freund fühlt sich auf dem Schlips getreten… und kommt mit der (dümmlichen) Argumentation des Chefs daher: it worked as designed.
Ja, das hat auch keiner bestritten, dass es nicht funktioniert wie es designed wurde!
ABER, das DESIGN ist eben FEHLERHAFT – und widerspricht der eigenen Architektur-Vorgaben!
Ja, es handelt sich um fehlerhafte Produkte, weil sie nicht der eigenen Architektur-Vorgabe folgen. Im Gegenteil: sie brechen eben mit ihrem fehlerhaften Design die gegebenen Architektur-Vorgaben und kreieren Fehler und Lücken, die es nicht geben sollte.
Wikipedia, Protected Mode, Auszug:
„… oder Daten anderer Programme ausspähen können“.
Wikipedia, IA-32 Architektur, Auszug:
„Protected Mode, der bis zu 4 GB Speicher durchgängig (linear) adressieren kann und einen hardwareseitigen Speicherschutz garantiert …“
Den Rest kann man selber suchen – so man interessiert ist.
Ob Caches, In-Order-Execution, Out-of-Order-Execution oder Sonstiges die Architektur-Vorgabe bricht, ist völlig egal. Das Produkt ist eben fehlerhaft, weil die Ober-Direktive der Architektur-Vorgabe (hardwareseitiger Speicherschutz) gebrochen wurde – egal welches Detail der Implementierung diesen Bruch erzeugt.
Da meint doch ein Intel-Fan hier tatsächlich, weil das Rot der Ampel im Straßen-Verkehr nicht HKS15 entsprach, dass er die rote Ampel überfahren durfte (damit auch den vorfahrtsberechtigten Fußgänger).
Ich hingegen argumentiere, das Rot eben Rot im Straßen-Verkehr ist – und das das ANHALTEN zwingend anordnet!
Mal aus der Detail-Ecke herauskommen – und zu den Wurzeln und Ansätzen des Ursprungs finden. Hilft vielleicht zu verstehen, warum etwas falsch ist. Derivate Works und Vererbungs-Theorie hilft hier.