Intel kämpft mit schwerer Sicherheitslücke (Update: Intel veröffentlicht Server-Benchmarks)

Veröffentlicht am: von

intelVor, während und zwischen den Feiertagen herrschte ein wildes Treiben in der Linux-Community. Zunächst war nicht ganz klar, was hier genau vor sich geht, inzwischen aber scheinen die Auswirkungen deutlich zu werden: Intel hat nach einer Lücke in der Management Unit eines jeden Prozessors offenbar auch einen Designfehler in der Adressierung der virtuellen Speicherbereiche.

Dies kann dazu führen, dass nicht privilegierte Prozesse auf den Speicher des Betriebssystem-Kernels zugreifen können. Erste Hinweise gab es bereits wegen Umbauarbeiten des NT-Kernels im November. Nun aber scheinen die Auswirkungen vollends ans Tageslicht zu gelangen.

Inhaltesverzeichnis der News:

Um für etwas mehr Übersicht zu sorgen, haben wir die vielen Updates auf weitere Seiten verteilt. Daher hier ein kleines Inhaltesverzeichnis:

  1. Einleitung
  2. 1. Update: Benchmarks
  3. 2. und 3. Update: Proof-of-Concept und Stellungnahme von Intel
  4. 4. Update: Statements und Analysen
  5. 5. Update: Weitere Analyse und die wichtigsten Fragen
  6. 6., 7. und 8. Update: Einschätzung durch Apple, Microsoft, Amazon und Google
  7. 9. Update: Überprüfung der Mitigation gegen Spectre und Meltdown
  8. 10. Update: Wann kann Intel die Lücken auf Hardware-Ebene schließen?
  9. 11. Update: Mehr Benchmarks
  10. 12. und 13. Update: NVIDIA und Qualcomm anfällig
  11. 14. und 15. Update: NVIDIA und Apple veröffentlichen weitere Updates
  12. 16. und 17. Update: Intel meldet eigenen Leistungsdaten
  13. 18. und 19. Update: BIOS-Updates von ASUS, Gigabyte und MSI
  14. 20. Update: AMD und Intel äußern sich erneut
  15. 21. Update: Intel versieht hunderte Prozessoren mit Microcode-Update

Vom Fehler betroffen sind offenbar alle CPU-Architekturen, die einen virtuellen Speicher vorsehen. Inzwischen kann dies aber auf Prozessoren aus dem Hause Intel eingeschränkt werden, da AMD bestätigt hat nicht von der Lücke betroffen zu sein:

AMD processors are not subject to the types of attacks that the kernel page table isolation feature protects against. The AMD microarchitecture does not allow memory references, including speculative references, that access higher privileged data when running in a lesser privileged mode when that access would result in a page fault.

Disable page table isolation by default on AMD processors by not setting the X86_BUG_CPU_INSECURE feature, which controls whether X86_FEATURE_PTI is set."

Derzeit scheint es eine Responsible Disclosure zum Hardware-Bug zu geben. Dies bedeutet, dass einige Personen und Unternehmen alle Details kennen, diese aber bis zur finalen Behebung zurückhalten. Daher sind viele Details des Fehlers noch unbekannt oder basieren auf Spekulationen. Klar ist aber, dass es ein Problem bei der Zuweisung des virtuellen Speichers gibt, so dass nicht privilegierte Prozesse auf womöglich heikle Daten anderer Prozesse zugreifen können.

Bestätigt ist inzwischen auch, dass Intel den Fehler nicht durch ein BIOS/Microcode-Update beheben kann. Es handelt sich um eine fehlerhafte Hardware-Implementation, die nur durch eine Überarbeitung der entsprechenden Architektur behoben werden kann. Bis dahin sollen Updates des Virtual-Memory-Subsystem des Betriebssystems Abhilfe schaffen.

Programme können aus ihrem virtuellen Speicherbereich ausbrechen

Gefunden wurde die Sicherheitslücke offenbar von Wissenschaftlern der TU Graz, die eine Attacke untersucht haben, die zum Ziel hatte, den Speicherbereich des Kernels vom Process Page Table zu unmappen. Die Memory Management Hardware des Prozessors soll sicherstellen, dass der Kernel Address Space nicht Teil des nicht privilegierten Userspace wird – dies schlägt hier fehl. Eine Zugriffsprüfung findet nicht mehr statt.

Einige Core-Kernel-Entwickler haben daraufhin einen Patch namens KASLR entwickelt. Dieser Patch versteckt den Kernel Address Space vor der Memory Management Hardware des Prozessors – macht ihn für andere Prozesse damit unsichtbar. Zudem ist der Address Space Layout Randomization (ASLR) weiterhin in der Lage einem Prozess zufällige Daten für den Adressbereich  zu liefern.

KASLR implementiert den ASLR direkt im Kernel. Mit jedem Reboot wird der Adressbereich für den Kernel neu erstellt. Angreifern ist es damit nicht mehr möglich aus einem laufenden Prozess heraus auf den Adressbereich des Kernels zuzugreifen. Auch andere, weniger direkte Methoden sollen damit ausgeschlossen werden.

Software-Workaround kostet Leistung

Der Software-Workaround für Linux, inzwischen auch als Kernel Page-Table Isolation oder kurz PTI, bzw. KPTI bekannt, trennt den Speicherbereich des Kernels von dem der oder des Nutzers. Dies wird üblicherweise nicht getan, so dass die Memory Management Hardware des Prozessors schnell und einfach zwischen dem Adressbereich des Nutzers und des Kernels wechseln kann. Caches des Prozessors müssen dazu nicht geleert werden.

Da der KPTI-Patch das Virtual Memory Layout nun aber ändert und zwei getrennte Bereiche erstellt, kann der Translation Lookaside Buffer (TLB), der virtuelle Adressen den echten Speicheradresse zuteilt, bzw. diese Werte im Cache hat, nicht mehr von der Memory Management Hardware des Prozessors verarbeitet werden. Der TLB beschleunigt die Speicherzugriffe, was nicht mehr möglich ist, wenn der Kernel- und Nutzer-Speicherbereich getrennt voneinander behandelt werden müssen. Jedes mal, wenn nun der Kernel und Nutzer auf den Speicher zugreifen muss, werden die Caches mit der Zuordnung des virtuellen Speichers gelöscht und neu geladen, was natürlich Leistung kostet.

Am Beispiel eines AMD-Prozessors wurde das Abschalten des TLB gemessen:

Nun handelt es sich dabei um eine AMD-Prozessor, die Auswirkungen bei den Modellen von Intel sind aber ähnlich. Inzwischen gibt es aber einige Benchmarks mit Intel-Prozessor unter Verwendung des ungepatchten und gepatchten Kernels.

Die von Phoronix gemachten Benchmarks zeigen einen Leistungsverlust von bis zu 30 % unter Verwendung synthetischer Syscall-Anfragen, die in der Praxis aber einen Worst-Case darstellen. Anwendungen, die wenige Speicherzugriffe vorsehen, zum Beispiel des Transcodieren von Videos mittels FFmpeg oder das Compilen von Programmen, sehen geringe Einbußen. Datenbankzugriffe und Anwendungen, die auf eine hohe I/O-Leistung angewiesen sind, werden aber stärker beeinflusst.

Bisher ist Linux aber das einzige Betriebssystem, welches ein Update für den Kernel vorsieht, bzw. für das bereits ein Update vorhanden ist. Windows und macOS müssen ebenfalls ein Update erhalten, um die Lücke zu schließen. Derzeit ist aber nicht bekannt, wann dies geschehen wird und wie groß die Auswirkungen auf die Leistung hier sein werden. Erste Messungen der Spieleleistung unter Linux sehen keine große Leistungsverluste.

In den kommenden Stunden werden sicherlich weitere Informationen folgen. Offiziell soll die Lücke am 4. Januar veröffentlicht werden. Derzeit haben sich wieder Intel, noch Software-Unternehmen wie Microsoft und Apple zum Thema geäußert. Die größten Probleme dürften ohnehin die Cloud-Anbieter wie Amazon mit EC2, Microsoft mit Azure und Google mit der Compute Engine haben, denn hier laufen auf einem Server gleich mehrere Instanzen, deren Schutz vor Zugriffen aus anderen Instanzen heraus nun nicht mehr sichergestellt ist.

Der Linux-Kernel 4.14.11 mit KPTI-Implementierung kann bereits heruntergeladen werden. Hier ist KPTI allerdings für alle Prozessoren aktiv, auch für solche von AMD. Da dieser aber nicht vom Fehler betroffen sind, ist dies natürlich eine unnötige Einschränkung, die durch einen weiteren Patch (Linux 4.14.12) behoben werden soll.

Während der Recherche zu dieser News sind wir häufig auf folgende Aussage gestoßen, die offenbar treffender kaum sein könnte: 2018 beginnt mit der „mother of all hypervisor privilege escalation bugs".


Wir haben inzwischen einige Benchmarks machen können. Dazu haben wir unser altes Grafikkarten-Testsystem verwendet.

Das Testsystem
Prozessor Intel Core i7-3960X 3,3 @ 3,9 GHz
Kühlung Corsair H110i GT All-in-One-Wasserkühlung
Mainboard ASUS P9X97 Deluxe
Arbeitsspeicher G.Skill
SSD OCZ Arc 100 240 GB
Netzteil Seasonic Platinum Series 1.000 Watt
Betriebssystem Windows 10 64 Bit
Gehäuse Fractal Design Define R5

Darauf installiert ist ein Windows 10 mit dem Fall Creators Update (Build 1709). Wir haben nun den aktuellen Insider Preview (Build 17063) installiert, der den KPTI-Patch schon enthalten soll. Neben einigen Spielen haben wir auch einige I/O- und Compute-Benchmarks verwendet, um eventuelle Leistungseinbußen durch den KPTI-Patch darstellen zu können. Als Grafikkarte kam eine GeForce GTX 1080 Ti zum Einsatz.

Benchmarks in UHD:

Windows Build 1709 vs. Build 17063

Fire Strike Extreme

Futuremark-Punkte
Mehr ist besser

Windows Build 1709 vs. Build 17063

The Witcher 3 – 3.840 x 2.160 Pixel

Bilder pro Sekunde
Mehr ist besser

Windows Build 1709 vs. Build 17063

DOOM (Vulkan) – 3.840 x 2.160 Pixel

Bilder pro Sekunde
Mehr ist besser

Auf die Leistung in Spielen scheint der KPTI-Patch schon einmal keinen Einfluss zu haben. Gerade in hohen Auflösungen limitiert allerdings auch die Grafikkarte, so dass der Einfluss des Prozessors geringer wird. Aber auch in 1080p konnten wir keinerlei Abweichungen zu den oben präsentierten Ergebnissen finden.

Benchmarks in FHD:

Windows Build 1709 vs. Build 17063

DOOM (Vulkan) – 1.920 x 1.080 Pixel

Bilder pro Sekunde
Mehr ist besser

Windows Build 1709 vs. Build 17063

The Witcher 3 – 1.920 x 1.080 Pixel

Bilder pro Sekunde
Mehr ist besser

Windows Build 1709 vs. Build 17063

Star Wars Battlefront II (DX12) – 1.920 x 1.080 Pixel

Bilder pro Sekunde
Mehr ist besser

Wir haben noch einige weitere Spielebenchmarks in niedrigerer Auflösung gemacht, um den Einfluss des Prozessors zu erhöhen. Bei 1.920 x 1.080 Pixeln ist ein Leistungsunterschied von 2 bis 4 Prozent zu beurteilen. Für Star Wars Battlefront mit der DirectX-12-API kommen wir auf fast 5 Prozent. Die größten Unterschiede scheinen bei Low-Lewel-APIs wie eben Vulkan und DirectX 12 aufzutreten.

Synthetische Benchmarks sowie Compute-Workloads:

Windows Build 1709 vs. Build 17063

Luxmark 3.0 Sala

Punkte
Mehr ist besser

Windows Build 1709 vs. Build 17063

GPUPI 1000M

Sekunden
Weniger ist besser

Windows Build 1709 vs. Build 17063

FFmpeg

Sekunden
Weniger ist besser

Windows Build 1709 vs. Build 17063

Adobe After Effects – 4K-Intro Rendering

Zeit in Sekunden
Weniger ist besser

Windows Build 1709 vs. Build 17063

Blender-Benchmark

Zeit in Sekunden
Weniger ist besser

Windows Build 1709 vs. Build 17063

Unreal Engine Infiltrator Rendering

Zeit in Sekunden
Weniger ist besser

Windows Build 1709 vs. Build 17063

V-Ray-Benchmark

Zeit in Sekunden
Weniger ist besser

Für Anwendungen, die wenige Syscalls benötigen, scheint die Kernel Page-Table Isolation auch keine großen Auswirkungen auf den Leistung zu haben. Bei Spielen liegen wir ebenso in den Messungenauigkeiten wie für Anwendungen, deren Leistung hauptsächlich von der Grafikkarte beeinflusst wird.

» zur Galerie

Die Kollegen von Computerbase konnten einige Tests mit einer Samsung 960 Pro machen und stellten hier größere Leistungsunterschiede fest. Diese beziehen sich auf die erwähnten häufigen Syscalls, wo die Leistungseinbußen durch KPTI am größten sein dürften. Zwei von acht ermittelten Werten zeigen einen Unterschied von knapp 7 %. Links ist der Durchlauf mit dem Fall Creators Update (Build 1709) zu sehen, rechts mit Insider Preview (Build 17063).

Spannender dürften weitere Benchmarks sein, die sich vermehrt dem Einsatz von Netzwerkservices, sonstige I/O-intensive Geschichten und natürlich der Virtualisierung widmen. Für den Alltag der meisten Nutzer stellt sich derzeit aber kein Szenario dar, nachdem es zu großen Leistungseinbrüchen durch die Behebung des Fehlers per Software-Fix kommen sollte. Sollten sich im Serverbereich allerdings größere Einbrüche in praxisrelevanten Anwendungen darstellen lassen, könnte dies zu einem echten Stolperstein für Intel werden.


Da immer wieder die Frage auftaucht, ob der Fehler ausgenutzt werden kann und wie dies vonstatten geht, hier einmal ein Beispiel: Fast alle Cloud-Instanzen und Server-Anbieter, wo Rechen- bzw. Server-Kapazitäten zur Miete angeboten werden, verwenden Hardware, die sich mehrere Nutzer teilen. Auch sollen Nutzer eines Systems, die nicht über Root-Zugriff verfügen, keine Kontrolle über das System selbst haben bzw. auf den Kernel zugreifen können. Kernel- und Userspace sollen getrennt voneinander im Speicher bleiben und gegenseitige Zugriffe nicht möglich sein.

Können Programme nun aber aus ihrem virtuellen Speicherbereich ausbrechen, können sie auch auf Speicherbereiche zugreifen, die ihnen eigentlichen verwehrt bleiben sollen. Beispielsweise wäre der Zugriff auf eventuell vorhandene Krypto-Schlüssel möglich. Die Szenarien sind hier vielfältig.

Ein Proof-of-Concept des Exploits zeigt, wie auf fremden Adressbereich zugegriffen wird:

3. Update: Stellungnahme von Intel

Offenbar hat sich Intel dazu genötigt gesehen eine Stellungnahme zu veröffentlichen:

"Intel and other technology companies have been made aware of new security research describing software analysis methods that, when used for malicious purposes, have the potential to improperly gather sensitive data from computing devices that are operating as designed. Intel believes these exploits do not have the potential to corrupt, modify or delete data.

Recent reports that these exploits are caused by a "bug" or a "flaw" and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices -- with many different vendors' processors and operating systems -- are susceptible to these exploits.

Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Intel has begun providing software and firmware updates to mitigate these exploits. Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time.

Intel is committed to the industry best practice of responsible disclosure of potential security issues, which is why Intel and other vendors had planned to disclose this issue next week when more software and firmware updates will be available. However, Intel is making this statement today because of the current inaccurate media reports.

Check with your operating system vendor or system manufacturer and apply any available updates as soon as they are available. Following good security practices that protect against malware in general will also help protect against possible exploitation until updates can be applied.

Intel believes its products are the most secure in the world and that, with the support of its partners, the current solutions to this issue provide the best possible security for its customers."

In der Stellungnahme weist Intel die bisherigen Annahmen und Aussagen zurück, nur Intel-Prozessoren seien von dem Problem betroffen. Allerdings nennt Intel keine Namen und spricht nur von "vielen unterschiedlichen Herstellern von Prozessoren und Betriebssystemen". Man arbeite auch mit Unternehmen wie AMD und ARM zusammen, um eventuelle Sicherheitsrisiken auszuschließen. Dies impliziert natürlich auch, dass deren Prozessoren ebenfalls betroffen sein könnten.


Nachdem Intel gestern Abend eine erste Stellungnahme abgegeben hat, folgte auch noch ein ausführliches Investorenmeeting. Darin wurden weitere Details veröffentlicht. AMD, Google und ARM haben sich ebenfalls zur aktuellen Situation geäußert und wir wollen die Ereignisse der Nacht einmal zusammenfassen. Google hat zudem eine ausführliche Zusammenfassung der nun als Spectre und Meltdown bekannten Sicherheitslücke erstellt. Darin sind alle Details enthalten, die wichtig für eine Analyse sind und das Problem näher beschreiben.

Inzwischen haben die Sicherheitslücken auch schon ihre eigenen Logos erhalten:

» zur Galerie

Wie gestern bereits bekannt wurde, ermöglicht die Lücke das Auslesen von Speicher, der eigentlich unzugänglich sein sollte – "Reading privileged memory with a side-channel". Es gibt drei Varianten der Lücke:

Die ersten beiden Varianten werden als Spectre bezeichnet, die dritte als Meltdown. 

In der Stellungsnahme von Intel ist die Rede davon, dass nicht nur Prozessoren aus dem eigenen Hause betroffen seien, sondern auch andere Hersteller. Außerdem arbeite man mit AMD und ARM zusammen, um eine Lösung zu finden. Diese Aussagen sorgten für einige Verwirrung, denn bisher hieß es immer, ausschließlich Intel-Prozessoren seien betroffen. Wir haben die Aussagen von Intel, AMD und ARM einmal in einer Tabelle zusammengetragen sowie mit der Analyse von Google ergänzt.

» zur Galerie

Demnach ist Intel für Meltdown theoretisch mit allen Prozessoren ab dem Jahre 1995 anfällig. Ausnahmen bilden hier die Itanium-Prozessoren und die Atom-Modelle vor 2013. Die Spectre-Lücke ist ebenfalls in allen relavanten Intel-Prozessoren vorhanden. Intel spricht hier von allen aktuellen Prozessoren, ohne dabei genauer auf bestimmte Architekturen einzugehen. Ein Workarround ist bei Meltdown mit einem Software-Update möglich. Spectre hingegen sei laut Intel schwerer zu beheben und verlange auch nach VMM- (Virtual Machine Monitor) und Firmware-Updates. Erst mit einer neuen CPU-Architektur lässt sich Spectre aber gänzlich verhindern – insofern wird Spectre Intel auch noch einige Zeit beschäftigen.

Von der Side-Channel-Lücke betroffene Prozessoren
  Spectre Variante 1 Spectre Variante 2 Meltdown
Intel
  Ja Ja alle CPUs ab 1995 (Pentium Pro)
AMD
  Ja fast kein Risiko, bisher nicht mit AMD-CPU demonstriert nicht betroffen
ARM
Cortex-R7 Ja Ja Nein
Cortex-R8 Ja Ja Nein
Cortex-A8 Ja Ja Nein
Cortex-A9 Ja Ja Nein
Cortex-A15 Ja Ja Nein
Cortex-A17 Ja Ja Nein
Cortex-A57 Ja Ja Nein
Cortex-A72 Ja Ja Nein
Cortex-A73 Ja Ja Nein
Cortex-A75 Ja Ja Ja

Auch zu AMD gibt es nun weitere Informationen. Demnach sind AMD-Prozessoren nicht für Meltdown anfällig. Spectre hingegen ist in den beiden Varianten bis zu den Ryzen-Prozessoren möglich. Auch AMD verzichtet auf eine genaue Aufschlüsselung der betroffenen CPU-Architekturen. Die Variante 1 sei allerdings durch Software lösbar und Variante 2 stelle durch eine andere CPU-Architektru kein Risiko dar. Bisher sei Variante 2 auch noch nicht mit AMD-Prozessoren demonstriert worden.

Sehr ausführlich stellt ARM eine Liste aller betroffenen Architekturen online und hat auch ein Whitepaper dazu veröffentlicht. Demnach sind ab der Cortex-R7- bis zur Cortex-A75-Architektur alle ARM-Prozessoren von Spectre betroffen. Für Meltdown anfällig scheint nur die Cortex-A75-Architektur zu sein. Alle zukünftigen Cortex-Architekturen sollen nicht mehr von den Lücken betroffen sein.


Wer ist betroffen? Welche Systeme sind besonders anfällig? Wie kann eine Lösung aussehen? All das wollen wir uns nun etwas genauer anschauen. Zunächst einmal wollen wir uns die Unterschiede zwischen Spectre und Meltdown anschauen:

Meltdown bricht den Mechanismus, der Programme daran hindern soll auf anderen Speicherbereiche zuzugreifen. Solche Programme können dann auch auf den Systemspeicher zugreifen, in dem sich gegebenenfalls sensible Informationen befinden. Spectre bringt andere Programme dazu auf fremden Speicherbereich zuzugreifen. In beiden Fällen werden sogenannte Side Channels genutzt, die mitunter eines bestimmten Timings bedürfen. Ausführlich werden die technischen Hintergründe in den wissenschaftlichen Papers zu Meltdown und Spectre beschrieben.

Welche Systeme sind von Meltdown betroffen?

Alle Desktop-, Laptop- und Cloud-Rechner mit Intel-Prozessor sind davon betroffen. Genauer gesagt alle mit einer Out-of-Order Execution – das heißt alle ab dem Pentium Pro von 1995 bis auf die Itanium-Modelle und alle Atom-Variante vor 2013. Via Proof-of-Concept wurde Melton auf allen aktuellen CPU-Architekturen von Intel bis 2011 nachgestellt, ältere Modelle sind aber wie gesagt ebenso anfällig. Meltdown konnte derzeit nur auf Intel-Prozessoren verifiziert werden. Derzeit ist unklar, ob AMD- und ARM-Prozessoren davon gänzlich ausgenommen sind.

Alle Cloud-Provider sind von Meltdown betroffen, die Intel-Prozessoren einsetzen. Die virtuellen Instanzen bzw. die eingesetzte Software muss aktualisiert werden. Auch solche Cloud-Anbieter mit verschiedenen Containern, die sich einen Kernel teilen, sind betroffen. Dazu gehören Docker, LXC oder OpenVZ.

Meltdown in Aktion:

Können Systeme gegen Meltdown abgesichert werden?

Ja, können sie. Via Software-Patch und die beschriebene Kernel Page-Table Isolation ist dies möglich. Der Linux-Kernel 4.14.11 mit KPTI-Implementierung kann bereits heruntergeladen werden. Hier ist KPTI allerdings für alle Prozessoren aktiv, auch für solche von AMD. Für Windows ist der Patch bereits Bestandteil der Windows 10 Insieder Preview 17063 und dürfte in Kürze veröffentlicht werden. Das aktuelle macOS 10.13.2 enthält bereits den KPTI-Patch. Mit dem derzeit in der Beta-Phase befindlichen 10.13.3 soll es weitere Verbesserungen der Sicherheit geben. Details dazu stehen aber noch aus.

Welche Systeme sind von Spectre betroffen?

Für Spectre sind theoretisch alle aktuellen Prozessoren anfällig – Desktops, Laptops, Cloud-Server und auch Smartphones sowie Tablets. Spectre wurde bereits auf Intel-, AMD- und ARM-Prozessoren demonstriert, wenngleich hier zwischen den beiden Varianten unterschieden werden muss (siehe Tabelle).

Können Systeme gegen Spectre abgesichert werden?

Spectre ist schwieriger zu implementieren, kann aber auch nicht so einfach verhindert werden. Software-Patches können es hier nur schwerer machen die Sicherheitslücke auszunutzen, sie können sie aber nicht gänzlich verhindern. Erst zukünftige CPU-Architekturen sollen dahingehend abgesichert sein. ARM gibt ab, dass alle zukünftigen Architekturen gegen Spectre abgesichert sein werden. Im Investoren-Meeting soll Intel davon gesprochen haben, dass alle Produkte, die 2018 auf den Markt kommen werden, ebenfalls gegen Spectre abgesichert sind.

Diese Aussage muss allerdings etwas relativiert werden. Das Transkript der Investoren-Telefonkonferenz liest sich ganz anders:

"Your second, your earlier part of the question was, what's the time frame for implementing changes? And I'll just say that as part of the mitigation, as we learned the root causes of these issues, Ronak and his team are accountable for doing the microarchitecture of our cores and they started making the changes in the products for our future. And you can look at those as, I'll call it refinements, so that the OS and firmware have to do less heavy lifting. We just kind of build the updates into our hardware in a more -- in a way that's more transparent to software. And you'll start seeing the first of those products within this calendar year. We have a general direction that all of our products going forward that are not yet, if you will, in silicon and committed to launch in a very short period of time, all those future products will incorporate those enhancements as Ronak and team learn more. And that will just make the mitigations more efficient"

Demnach spricht Intel für 2018 nun von Produkten, die sich nicht schon in der Fertigung befinden – ob damit das erste Tape Out oder die Massenfertigung gemeint ist, bleibt unklar. Im Frühjahr werden die Core-H-Prozessoren erwartet, es dürften auch noch einige Coffee-Lake-Prozessoren folgen. All diese Modelle können noch nicht verbessert worden sein.


6. Update: Statement von Linus Torvalds

Linus Torvalds hat sich nun abermalig zum Thema geäußert und übt harte Kritik an Intel:

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation doesn't happen across protection domains. Maybe even a L1 I$ that is keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look at their CPU's, and actually admit that they have issues instead of writing PR blurbs that say that everything works as designed.

.. and that really means that all these mitigation patches should be written with "not all CPU's are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the ARM64 people more.

Please talk to management. Because I really see exactly two possibibilities:

- Intel never intends to fix anything

OR

- these workarounds should have a way to disable them.

Which of the two is it?

Linus

7. Update: Liste der betroffenen Prozessoren von Intel

Recht allgemein gehalten sprach Intel bisher immer nur davon, dass Prozessoren ab 1995 von Meltdown und Spectre betroffen sind. Nun hat man eine konkrete Liste veröffentlicht, die allerdings nicht ganz bis 1995 zurückreicht:

8. Update: Einschätzung der Leistungsreduzierung durch Apple, Microsoft, Amazon und Google

Apple, Microsoft, Amazon und Google haben zur vermeintlichen Reduzierung der Leistung durch die Patches Stellung genommen. Gerade die Cloud-Anbieter wie Microsoft, Amazon und Google setzen nicht nur tausende Server für die eigenen Services ein, sondern sie bieten die Rechenleistung auch ihren Kunden an. Hier stellt sich nun die Frage, auf welche Reduzierung der Leistung sich die Kunden abhängig von der jeweiligen Anwendung einstellen müssen. Netzwerkservices und sonstige I/O-intensive Anwendungen sind hier besonders betroffen.

Amazon hat seine EC2-Instanzen bereits aktualisiert. Die AWS-Instanzen werden am kommenden Wochende aktualisiert. Bei Microsoft soll die komplette Azure-Infrastruktur inzwischen mit den entsprechenden Patches versorgt worden sein. Auch Google hat gegen Meltdown bereits die wichtigsten Maßnahmen ergriffen und die besagten KPTI-Patches installiert. Für die Spectre-Varianten sind neben Software-Anpassungen auch noch Firmware-Updates notwendig. Intel's IBRS Microcode soll dahingehend noch Updates erhalten.

Während Windows, Linux und macOS bereits die Patches erhalten haben und diese noch weiter mitigiert werden, damit die Betriebssysteme vor allem gegen die beiden Spectre-Varianten besser geschützt sind, liefert Intel inzwischen auch die entsprechenden Firmware-Updates aus. Laut Intel sollen alle Updates für die meistverkauften Prozessoren aus den vergangenen fünf Jahren bereits verfügbar sein. Ende kommender Woche sollen dann 90 % aller Prozessoren der letzten fünf Jahre abgedeckt sein.

"Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years"


Viele Nutzer fragen sich derzeit, wie sich die gegen Spectre und Meltdown absichern und überprüfen können, ob die bisher erhobenen Sicherheitsmaßnahmen auch greifen. Dazu sei zunächst noch einmal gesagt:

Da die meisten hier ein Windows einsetzen, wollen wir einmal erläutern, wie überprüft werden kann, ob und welche Patches bisher auf dem eigenen System funktionieren:

Microsoft beschreibt in einem Support-Dokument, wie via PowerShell-Skript eine Überprüfung stattfinden kann. Für Windows Server ist dies ebenfalls möglich. Das Skript funktioniert mit Windows 10 (RTM, 1511, 1607, 1703, 1709), Windows 8.1 und Windows 7 SP1. Zunächst muss die PowerShell installiert werden, danach sollte überprüft werden, um die letzten Updates für die Antiviren-Programm installiert sind, denn diese können Probleme machen. Am besten sollte diese zunächst deaktiviert werden.

Mittels PS > Install-Module SpeculationControl wird das von Microsoft erstellte Skript geladen. Danach kann mit PS > Get-SpeculationControlSettings das Skript gestartet werden. Es wird eine Log-Datei ausgegeben, wenn alle Lücken geschlossen wären wie folgt aussehen sollte:

Speculation control settings for CVE-2017-5715 [branch target injection]
Hardware support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is present: True
Windows OS support for branch target injection mitigation is enabled: 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

» zur Galerie

Dies ist in der Praxis aber kaum der Fall, zumal das Skript nur Variante 2 von Spectre und die Meltdown-Sicherheitslücke überprüfen kann. Daher werden hier auch nur CVE-2017-5715 (Branch Target Injection) und CVE-2017-5754 (Rogue Data Cache Load) aufgeführt. Noch einmal: Spectre in der Variante 1 CVE-2017-5753 (Bounds Check Bypass) kann nur duch ein Update der jeweiligen Verwendung gepatcht werden.

Dennoch gibt das Skript eine eindeutige Auskunft über den Status des Systems für Spectre und Meltown. Es wird auch zwischen dem Schließen der Lücke auf Ebene des Betriebssystems und durch die Hardware in Form der Firmware der Prozessoren unterschieden.


Sowohl Meltdown als auch die beiden Spectre-Varianten bedürfen einer grundsätzlichen Überarbeitung der CPU-Architekturen, damit die jeweiligen Prozessoren dahingehend nicht mehr anfällig sind. Zwar lässt sich Meltdown durch einen Workaround auf OS-Ebene verhindern, dabei büßen die Prozessoren aber je nach Anwendungen einen gewissen Anteil ihrer Leistung ein. Spectre hingegen kann in beiden Varianten über OS- und Firmware-Update nur abgemildert werden. Letztendlich hilft hier nur ein komplettes Redesign der Architektur.

Die Frage ist also, was müssen Intel, AMD und Co tun, damit ihre Prozessoren wieder sicher sind. Die genauen Prozeduren dazu sind bisher unbekannt und vermutlich werden auch niemals Details dazu öffentlich werden. Intel erwähnte auf dem Investoren-Call, dass man alle ab 2018 entwickelten Prozessoren dahingehend absichern möchte. Da eine Launch-Pipeline für Prozessoren mehrere Monate wenn nicht Jahre Vorlauf hat, werden 2018 aber auch noch Prozessoren erscheinen, deren Architektur nicht abgepasst werden konnte – namentlich dürften dies die Core-H bzw. 8th Gen Intel Core mit Radeon RX Vega M sein. Wohl ebenfalls geplant sind weitere Coffee-Lake-Modelle.

Ex-Intel-Mitarbeiter Joe Fitz hat sich per Twitter zum Thema baldiger Änderungen auf Hardware-Ebene geäußert. Per Twitter hat er in einem Thread gleich mehrere Tweets abgegeben, die Änderungen in der Entwicklung und deren Auswirkungen beschreiben.

Fitz rechnet zwar damit, dass es im Sommer 2018 theoretischen die ersten Änderungen auf Hardware-Ebene geben könnte, diese seien aber wenn überhaupt nur Hotfixes. Es könnte weiter zu einer Beeinflussung der Leistung kommen. Erst 2019/2020 rechnet er mit weiteren Änderungen, die sich das Problem dann endgültig annehmen könnten. Möglich wäre aber auch, dass es bis 2021 dauert. Dies hänge auch davon ab, wie viel Manpower und Entwicklungskosten Intel auf das Problem verteile. Joe Fitz hat Intel vor fünf Jahren verlassen, geht aber noch immer davon aus, dass entsprechende Entwicklungszyklen nicht maßgeblich beschleunigt werden konnten. Da auch die anderen Hersteller bzw. die meisten Prozessren anfällig sind, gilt obigen natürlich auch für AMD, ARM, Qualcomm, Apple usw.


Es gibt weitere Benchmarks, die offenbar näher an der Praxis der durch die Patches betroffenen Anwendungen sind. Einige der Werte betreffen den auf den Amazon AWS EC2 Instanzen installierten Hypervisor, der einen Patch erhalten hat und auf denen Kafka Brokers [d2.xlarge] läuft. Sie sollen einen Leistunsgeinbruch von 5 bis 20 % sehen, was sicherlich als signifikant zu bezeichnen ist.

Auf Reddit hat ein Nutzer mit dem Realbench 2.56 einige Tests mit installierten OS-Patches sowie Firmware-Update präsentiert. Dabei eingesetzt wurde ein Intel Core i7-8700 auf einem ASUS Prime Z-370-A. Während der OS-Patch eine um 0 bis 5,5 % geringere Leistung zeigte (was im Rahmen der bisherigen Tests liegt), bedeutet ein BIOS- bzw. Firmware-Update mit neuem Microcode einen Einbruch um bis zu 21 %.

» zur Galerie


Da von den beiden Varianten von Spectre potenziell jede Software betroffen ist, hat natürlich auch NVIDIA geprüft, ob dies für seine Grafikkarten-Treiber der Fall ist. Offenbar ist dem so. In einem Security Bulletin hat man dazu die wichtigsten Informationen veröffentlicht.

Für die beiden Varianten von Spectre arbeitet man also an Update für die eigene Hardware. Zum jetzigen Zeitpunkt geht NVIDIA für die GPUs nicht davon aus, von Meltdown betroffen zu sein. Die Treiber für die GeForce-, Quadro- und Tesla-Serie sollen noch in der kommenden Woche veröffentlicht werden. Ein Update erhalten werden die Driver-Branches R390 und R384. Ähnliches gilt für die Tegra-SoCs aus, die sehr wohl von Meltdown betroffen sein könnten – NVIDIA geht nach einer Prüfung aber nicht davon aus. Dennoch wird NVIDIA hier in Kürze erste Updates anbieten. So sollen noch im Januar die Updates für die Shield-Geräte erscheinen, welches das Ausnutzen der Spectre-Sicherheitslücken erschweren sollen. Selbst das 3 1/2 Jahre alte Shield Tablet wird noch ein Update bekommen. Damit dürfte es zu den ältesten Android-Geräten gehören, die noch versorgt werden. Bei den meisten Smartphone-Herstellern ist nicht davon auszugehen, dass ältere Geräte noch mit einem Patch versorgt werden.

13. Update: Qualcomm äußert sich

Natürlich sind aufgrund der Out-of-order Execution des Designs auch einige Prozessoren von Qualcomm betroffen. Gegenüber dem Sender CNBC hat Qualcomm nun bestätigt, dass auch der kommende Snapdragon 845 von der Sicherheitslücke betroffen sei. Der Chipentwickler gab gleichzeitig an, dass das Unternehmen mit Hochdruck an einer Lösung zur Schließung der Sicherheitslücke arbeiten würde. Die Schließung dieser sei über ein Patch möglich. "Wir sind dabei, entsprechende Maßnahmen unseren Kunden zur Verfügung zu stellen und empfehlen unseren Kunden, ihre Geräte schnellstmöglich zu aktualisieren, sobald Patches verfügbar sind“, so Qualcomm gegenüber CNBC. Damit folgt Qualcomm dem Weg vieler anderer Hersteller.


Heute haben zwei weitere Unternehmen ihre Updates veröffentlicht, um sich gegen Spectre abzusichern. Mit dem GeForce 390.65 aus dem R390-Branche schließt NVIDIA auch wie angekündigt die Spectre-Sicherheitslücke für seine eigenen Treiber.

Zudem hat Apple iOS 11.2.2 für iPhones und iPads veröffentlicht. Auch dieses adressiert die beiden Spectre-Varianten. Ein kleines Update für macOS High Sierra 12.13.2 zielt ebenfalls auf ein Schließen von Spectre ab.

15. Update: Micrsoft stoppt Auslieferung des Updates auf AMD-Systemen

Nachdem es offenbar zu Problemen auf Windows-10-Systemen mit AMD-Prozessor kommt, hat Microsoft die Auslieferung des entsprechendes Patches eingestellt. Man arbeite mit AMD zusammen, um das Problem schnellstmöglich zu beseitigen.

"Microsoft has reports of some customers with AMD devices getting into an unbootable state after installing this KB. To prevent this issue, Microsoft will temporarily pause Windows OS updates to devices with impacted AMD processors at this time.

Microsoft is working with AMD to resolve this issue and resume Windows OS security updates to the affected AMD devices via Windows Update and WSUS as soon as possible. If you have experienced an unbootable state or for more information see KB4073707. For AMD specific information please contact AMD."

Ein Sprecher von Microsoft schiebt die Schuld für den Fehler auf AMD, denn hier habe man sich nicht an die Dokumentation gehalten:

"Microsoft has reports of customers with some AMD devices getting into an unbootable state after installing recent Windows operating system security updates,” says a Microsoft spokesperson. “After investigating, Microsoft has determined that some AMD chipsets do not conform to the documentation previously provided to Microsoft to develop the Windows operating system mitigations to protect against the chipset vulnerabilities known as Spectre and Meltdown."

AMD hat folgendes Statement dazu veröffentlicht:

"AMD is aware of an issue with some older generation processors following installation of a Microsoft security update that was published over the weekend. AMD and Microsoft have been working on an update to resolve the issue and expect it to begin rolling out again for these impacted shortly."


Intel hat weitere, eigene Leistungswerte genannt. Bisher sprach man immer nur von einem geringen Einfluss auf die Leistung sowie der Tatsache, dass dies extrem von der jeweiligen Anwendung abhängig ist. Intel bleibt dabei, dass bei Alltagsanwendungen keine Leistungseinbußen zu verzeichnen sind. Im SYSmark 2014 SE sollen 8th Generation Core Prozessoren 6 % langsamer sein. Die individuellen Testergebnisse zeigen einen Leistungseinbruch von 2 bis 14 %.

Intel will noch weitere, genauere Tests machen. Diese sollen dann zum entsprechenden Zeitpunkt nachgereicht werden. Allerdings will Intel zunächst einmal abwarten, bis die OEM-Partner die entsprechenden Patches und Firmware-Updates eingespielt haben. Für den jetzigen Test kamen ein Intel Core i7-8650U und Core i7-8700K zum Einsatz.

» zur Galerie

Microsoft schlüsselt in einem Blogeintrag noch einmal genauer auf, welche Maßnahmen für die beiden Spectre-Varianten und Meltdown ergriffen werden müssen. Dabei geht man natürlich besonders auf die Patches für Windows 10  ein. Noch einmal genauer erwähnt wird aber auch, dass Spectre Variante 1 (Bounds Check Bypass - 2017-5753) und Meltdown (Rogue Data Cache Load - 2017-5754) mit Software-Updates weitestgehend geschlossen werden können. Für die Variante 2 von Spectre (Branch Target Injection - 2017-5715) aber wird ein Microcode-Update für den Prozessor notwendig sein.

Microsoft hat ebenfalls eigene Leistungsmessungen gemacht und spricht dabei von "signifikanten Reduzierungen" auf älteren Systemen. Basierend auf Skylake, Kaby Lake und neuer soll der Einfluss auf die Leistung geringer sein. Haswell und älter sollen aber besonders betroffen sein.

17. Update: MSI veröffentlicht BIOS-Updates mit neuem Microcode

MSI hat inzwischen alle Mainboards bis runter zu den X99-Modellen mit einem BIOS-Update versorgt. Die Z87-Serie hingegen bekommen keine Updates mehr. In allen neuen BIOS-Versionen ab Ende Dezember erwähnt MSI "Update CPU Microcode". Damit sollen die Systeme gegen die Variante 2 von Spectre (Branch Target Injection - 2017-5715) geschützt werden. Die BIOS-Updates von MSI findet ihr im Support-Center des Herstellers.


Die beiden Linux-Distributionen Debian und Ubuntu sind nun auch mit dem KPTI-Patches versorgt worden. Offenbar ebenfalls enthalten sind die Microcode-Updates für einige Intel-Prozessoren.

Die Pakete Wheezy, Jessie, Jessie-backports, Stretch sowie Unstable/Sid von Debian sind in der 64-Bit-Version gegen Meltdown abgesichert. Die Paketes Stretch-Backports, Testing/Buster sowie Experimental sind es noch nicht. Gegen Spectre abgesichert werden müssen der Kernel, Browsers und andere Software. In Teilen sind die dazugehörigen Patches bereits auf Debian gelandet.

In einem Wiki-Eintrag hat Ubuntu die Maßnahmen gegen Meltdown und Spectre zusammengefasst. Gegen Meltdown (CVE-2017-5754) abgesichert sind:

Ubuntu version 

Kernel Version 

Variant 

USN 

17.10 

4.13 

generic/lowlatency 

USN-3523-1

16.04 LTS 

4.13 HWE 

generic/lowlatency/gke/gcp/oem/azure/lpae 

USN-3523-2

16.04 LTS 

4.4 

generic/lowlatency/euclid/aws/kvm 

USN-3522-3

14.04 LTS 

4.4 HWE 

generic/lowlatency/aws 

USN-3522-4

14.04 LTS 

3.13 

generic/lowlatency 

USN-3524-1

12.04 ESM 

3.13 HWE 

generic 

USN-3524-2

12.04 ESM 

3.2 

generic 

USN-3525-1

Patches für Spectre (CVE-2017-5715 und CVE-2017-5753) fehlen bislang, sollen aber in Kürze nachgereicht werden.

19. Update: BIOS-Updates von ASUS, Gigabyte und MSI

Die Microcode-Updates wurden bereits durch Intel an die Mainboard-Hersteller übermittelt, damit diese entsprechende BIOS-Updates bereitstellen können. Den Anfang machen dabei ASUS und auch MSI. ASUS hat für die meisten der eigenen Z370-Mainboards bereits entsprechende BIOS-Updates veröffentlicht. MSI hat bereits alle Z370-Platinen abgedeckt. Generell wird empfohlen, die BIOS-Updates zeitnah einzuspielen.

ASUS-Z370-Modell
BIOS
Prime Z370-A 0606
Prime Z370-P 0606
ROG Maximus X Apex folgt
ROG Maximus X Code folgt
ROG Maximus X Formula folgt
ROG Maximus X Hero folgt
ROG Maximus X Hero (Wi-Fi AC) folgt
ROG Strix Z370-E Gaming 0606
ROG Strix Z370-F Gaming 0606
ROG Strix Z370-G Gaming 0606
ROG Strix Z370-G Gaming (Wi-Fi AC) 0606
ROG Strix Z370-H Gaming folgt
ROG Strix Z370-I Gaming 0606
TUF Z370-Plus Gaming 0606
TUF Z370-Pro Gaming folgt
MSI-Z370-Modell
BIOS
Z370 Godlike Gaming 7A98vA3
Z370 Gaming M5 7B58v12
Z370 Gaming Pro Carbon AC 7B45vA3
Z370 Gaming Pro Carbon 7B45vA3
Z370I Gaming Pro Carbon AC 7B43v12
Z370 Krait Gaming 7B46v12
Z370 Gaming Plus 7B61v12
Z370 Tomahawk 7B47v12
Z370M Gaming Pro AC 7B44v12
Z370 SLI Plus 7B46vA2
Z370-A Pro 7B48v23
Z370 PC Pro 7B49v12

Zum gegenwärtigen Zeitpunkt gibt es noch keine BIOS-Updates von ASRock und Gigabyte, diese sollten allerdings bald folgen. MSI hat darüber hinaus zu verstehen gegeben, dass entsprechende BIOS-Updates für ältere Intel-Plattformen folgen werden. Damit sind die Intel-100- und 200-Chipsatz-Boards gemeint, welche Skylake-S und Kaby Lake-S aufnehmen. Ob MSI sogar noch bis zum Sockel LGA1150 (Haswell und Broadwell) hinab gehen wird, bleibt abzuwarten. Auch Gigabyte angekündigt, zunächst für Mainboards mit den Chipsätzen Z370, X299 und B250 die entsprechenden Updates anzubieten. Die weiteren Modelle sollen folgen.

Gigabyte Z370
Z370 AORUS Ultra Gaming
Z370 AORUS Gaming 7
Z370 AORUS Gaming 5
Z370 AORUS Gaming WIFI
Z370 AORUS Gaming 3
Z370 AORUS Gaming K3
Z370 UD3H
Z370XP SLI
Z370 HD3P
Z370 HD3
Z370P D3
Z370M DS3H
Z370M D3H
Z370N WIFI
Gigabyte X299
X299 DESIGNARE EX
X299 AORUS Ultra Gaming Pro
X299 AORUS Ultra Gaming
X299 AORUS Gaming 9
X299 AORUS Gaming 7 Pro
X299 AORUS Gaming 7
X299 AORUS Gaming 3 Pro
X299 AORUS Gaming 3
X299 AORUS Gaming
X299 UD4 EX
X299 UD4 Pro
X299 UD4
Gigabyte B250
B250-D3A
B250-HD3P
B250-HD3
Gaming B8
B250M-Gaming 5
B250M-Gaming 3
B250M-DS3H
B250M-D3H
B250M-D3V
B250M-D2V
B250M-HD3
B250M-EVO
B250N-Phoenix WIFI

AMDs Senior Vice President und Chief Technology Officer, Mark Papermaster, hat sich noch einmal genauer zur Sicherheit der AMD-Prozessoren geäußert. Dies wurde auch notwendig, da unterschiedliche Berichte zur Anfälligkeit der AMD-Prozessoren gegen Spectre und Meltdown aufgetaucht sind. Einerseits seien Software-Updates ausreichend, andererseits werden aber auch Kernel-Updates verteilt, in denen Microcode-Updates enthalten sind. Dies dürfte nach der Argumentation gar nicht notwendig sein.

Nun zunächst zu dem, was AMD an detaillierteren Informationen veröffentlicht hat.

Spectre Variante 1: Bounds Check Bypass

Spectre Variante 2: Branch Target Injection

Meltdown: Rogue Data Cache Load

AMDs GPU-Architekturen sind für keine der genannten Sicherheitslücken anfällig und daher bedarf es laut AMD hier auch keiner Maßnahmen.

Intel geht Probleme mit Broadwell und Haswell an

In den vergangenen Tagen sind vermehrt Berichte aufgetaucht, die von ungewollten Reboots nach den ersten Firmware-Updates sprachen. Intel analysiert die Problematik derzeit und will entsprechend weitere Informationen bekanntgeben. Falls nötig, würde auch ein Update angeboten, welches die Firmware wieder auf den alten Stand bringt.

As Intel CEO Brian Krzanich emphasized in his Security-First Pledge, Intel is committed to transparency in reporting progress in handling the Google Project Zero exploits.

We have received reports from a few customers of higher system reboots after applying firmware updates. Specifically, these systems are running Intel Broadwell and Haswell CPUs for both client and data center. We are working quickly with these customers to understand, diagnose and address this reboot issue. If this requires a revised firmware update from Intel, we will distribute that update through the normal channels.  We are also working directly with data center customers to discuss the issue.

End-users should continue to apply updates recommended by their system and operating system providers.

Offener Brief von Brian Krzanich, CEO von Intel

Brian Krzanich, CEO von Intel, hat zudem einen offenen Brief veröffentlicht:

Following announcements of the Google Project Zero security exploits last week, Intel has continued to work closely with our partners with the shared goal of restoring confidence in the security of our customers’ data as quickly as possible. As I noted in my CES comments this week, the degree of collaboration across the industry has been remarkable. I am very proud of how our industry has pulled together and want to thank everyone for their extraordinary collaboration. In particular, we want to thank the Google Project Zero team for practicing responsible disclosure, creating the opportunity for the industry to address these new issues in a coordinated fashion.

As this process unfolds, I want to be clear about Intel’s commitments to our customers.  This is our pledge:

1. Customer-First Urgency: By Jan. 15, we will have issued updates for at least 90 percent of Intel CPUs introduced in the past five years, with updates for the remainder of these CPUs available by the end of January. We will then focus on issuing updates for older products as prioritized by our customers.

2. Transparent and Timely Communications: As we roll out software and firmware patches, we are learning a great deal. We know that impact on performance varies widely, based on the specific workload, platform configuration and mitigation technique. We commit to provide frequent progress reports of patch progress, performance data and other information. These can be found at the Intel.com website.

3. Ongoing Security Assurance: Our customers’ security is an ongoing priority, not a one-time event. To accelerate the security of the entire industry, we commit to publicly identify significant security vulnerabilities following rules of responsible disclosure and, further, we commit to working with the industry to share hardware innovations that will accelerate industry-level progress in dealing with side-channel attacks. We also commit to adding incremental funding for academic and independent research into potential security threats.

We encourage our industry partners to continue to support these practices. There are important roles for everyone: Timely adoption of software and firmware patches by consumers and system manufacturers is critical. Transparent and timely sharing of performance data by hardware and software developers is essential to rapid progress.

The bottom line is that continued collaboration will create the fastest and most effective approaches to restoring customer confidence in the security of their data. This is what we all want and are striving to achieve.

— Brian Krzanich 


Intel hat versprochen am Ende der vergangenen Woche für 90 % der Prozessoren aus den letzten fünf Jahren das zur Schließung der Meltdown-Lücke notwendige Microcode-Update anzubieten. Für die meisten Linux-Distributionen steht das entsprechende Update inzwischen bereit. Das Linux Processor Microcode Data File führt unter anderem Red Hat Enterprise Linux, SUSE Linux Enterprise Server, CentOS, Debian, Fedora, Ubuntu und einige mehr in verschiedenen Versionen auf. Das nur 3,51 MB große Microcode-Update wird also über ein Software-Update eingespielt – ähnlich soll nun auch unter Windows vorgegangen werden, denn ausschließlich auf BIOS-Updates zu setzen wäre laut Intel ein administrative hassle geworden. Seit Windows 7 ist Microsoft in der Lage ein Microcode-Update auch per OS-Update zu realisieren.

Auch was die Abdeckung der unterstützten Prozessoren angeht scheint Intel sein Versprechen halten zu können. Hier nennt Intel zahlreiche Modelle, deren Microcode bereits ein Update erhalten hat bzw. noch erhalten wird. Darunter sind auch Core-Duo- und Pentium-3-Prozessoren. Intel kann die Sicherheitslücke also auch schon bei den älteren Modellen schließen. Allerdings muss die Liste für jedes einzelne Modell weiter im Auge behalten werden, denn noch ist das Update nicht für jeden Prozessor verfügbar.

Hier die vollständige Liste:

Nun stellt sich für Windows-Nutzer nur noch die Frage, wann und wie das Microcode-Update auch hier für die oben genannten Modelle veröffentlicht wird. Immerhin hat sich Intel eingestanden, dass reine BIOS-Updates keine praktikable Lösung sind. Allerdings kann der Nutzer von Windows 10 Updates ebenfalls gänzlich ausschließen oder nur ein ganz bestimmtes deaktivieren. Insofern ist ein Schließen der Lücke nicht sichergestellt.


Wie nun bekannt wurde, hat Google nach eigenen Angaben bereits im September bzw. im Oktober die entsprechenden Patches eingespielt – lange bevor die Finder der Lücken dies gegenüber den Firmen öffentlich gemacht haben sollen. Die Kunden sollen von einem Leistungsverlust durch die Patches nichts gespürt haben. Googles Sicherheitsteam Project Zero war an der Erforschung der Lücken Spectre und Meltdown beteiligt, insofern hatte man recht früh Einblick.

Bisher deuten alle Erkenntnisse zu Spectre daraufhin, dass die beiden Variante nicht komplett geschlossen werden können. Die Angriffsvektoren können nur erschwert werden. Google will mit Retpoline eine Compiler-Modifikation entwickelt haben, die darauf kompilierte Software komplett gegen die beiden Spectre-Varianten immun machen soll. Damit wiederspricht Google auch den wissenschaftlichen Papieren zu Spectre. Natürlich ist Google stolz auf Retpoline, bisher gibt es aber keine gesicherten Erkenntnisse, ob damit wirklich jede spekulative Ausführung von Befehlen verhindert werden kann. Laut dem Spectre-Paper sie es unmöglich sicherzustellen, dass es nicht irgendwelchen Code gibt, der eine spekulative Ausführung ermöglicht.

Laut Google ist mit Retpoline nicht nur ein komplettes Schließen der Spectre-Sicherheitslücke möglich, auch sieht Google kaum Leistungseinbußen durch die eigenen Maßnahmen. Google bleibt damit beim eigenen Statement: "On most of our workloads, including our cloud infrastructure, we see negligible impact on performance."

Andere Unternehmen mit einem ähnlichen Anwendungsprofil sprechen von signifikanten Leistungseinbußen – wie es zu diesen unterschiedlichen Einschätzungen kommt, ist derzeit nicht bekannt. Womöglich hat Google einen besseren Weg der Implementation gefunden oder aber wirft einfach nur mehr Hardware-Ressourcen auf das Problem.

Googles Prioritäten nach der Entdeckung von Spectre und Meltdown stehen nun in der Kritik. Das Project-Zero-Team konnte natürlich recht schnell und einfach sicherstellen, dass Googles eigene Teams bereits an einem Fix arbeiten konnten. Damit hatte man einen Vorsprung gegenüber der Konkurrenz. Nun mehren sich die Stimmen, Google hätte mehr Energie in die Entwicklung einer allgemeinen Lösung stecken sollen, anstatt die eigenen Server abzusichern. Allerdings kann es auch als rechtens angesehen werden, das Google als einer der Entdecker sich zunächst um die eigenen Sicherheit kümmert. An die allgemeine Ethik des Responsible Disclosure hat sich Google gehalten. Die betroffenen Unternehmen hatten demnach Zeit ihre Systeme abzusichern, bevor Spectre Anfang des Jahres öffentlich gemacht wurde.


Intel hat nach einer weiteren Analyse weitere Benchmarks zu den Leistungseinbußen in Server-Anwendungen veröffentlicht. In diesen unterscheidet Intel natürlich je nach Anwendung.

Für Integer und Floating Point Throughput, Linpack, STREAM, Server-side Java und damit die häufigsten Enterprise- und Cloud-Kunden spricht Intel von einer Reduzierung der Leistung von 0 bis 2 %. Für Online Transaction Processing (OLTP) und damit Broker-Stock-Exchange-Anwendung misst Intel einen Einbruch der Leistung von bis zu 4 %. Bei hohen I/O-Loads scheine die Nachteile am größten zu sein. Bei hoher CPU-Last (100 % Write Case), sieht Intel eine um 18 % reduzierte Leistung. Bei weniger extremen Fällen wie 70/30 Read/Write spricht Intel von 2 %.

» zur Galerie

Für das Storage Performance Development Kit (SPDK) bzw. die entsprechenden Tests spricht Intel von großen Unterschieden. Im SPDK iSCSI auf einem Kern wird die Leistung um 25 % reduziert. Mit mehreren SPDK vHosts sind wiederum keinerlei Einbußen zu erwarten.

Weitere Details schlüsselt Intel in der entsprechenden Meldung mit den zahlreichen Fußnoten auf.