Spectre, Meltdown und FDS (aktualisiert)

In den vergangenen Wochen war es fast unmöglich, an Nachrichten zu einer ganzen Gruppe von IT-Angriffs-Szenarien, die unter den Namen „Spectre“ und „Meltdown“ zusammengefasst wurden, vorbei zu kommen. Die Besonderheit ist, dass es sich bei den zugrundeliegenden Fehlern nicht um Software-Fehler handelt, sondern um Hardware-Fehler, die praktisch alle CPUs der letzten Jahre betreffen. Um das Ausnutzen der zugrundeliegenden Fehler zu verhindern, stellen CPU-Hersteller und diverse Software-Entwickler erste Updates bereit, erstere in Form von Microcode-Updates für die jeweilige CPU.

Das Problem hierbei: Die betroffenen Systeme verlieren durch die Updates an Rechengeschwindigkeit und das teilweise signifikant.

Während beispielsweise Matthew Dillon, der Chefentwickler von DragonFlyBSD, in seinem sehr detaillierten (und launischen) Forenbeitrag davon ausgeht, dass sich der Overhead jedes einzelnen System Calls und Interrupts von 100 ns auf 250 bis 350 ns vergrößern wird, versichert Microsoft, dass „normale Anwender“ mit aktuellen CPUs keinen Unterschied merken werden. Während EPIC Games wiederum als einer der Ersten Intel verklagt und in einer offiziellen Mitteilung einen Anstieg der Prozessorlast um knapp 30 Prozentpunkte meldet, äußert sich der Chefentwickler von OpenBSD bekannt pragmatisch: 30 % Geschwindigkeitseinbußen interessieren ihn nicht, solange die CPUs wie spezifiziert funktionieren.

Kaum dass im offiziellen Forum die erste Frage zu Auswirkungen auf die Simulationsdauer von FDS gestellt wird, meldet mein Firmen-Laptop (wie der Zufall es will) ein Microcode-Update für den entsprechenden CVE-Eintrag. Eine gute Gelegenheit für einen vorher-nachher-Vergleich, die ich dankend annehme.

Als Testfall dient die Simulation plume5c_bench.fds aus dem Examples-Ordner. Simuliert wird hier ein Zeitraum von 40 Sekunden. Für die Benchmarks werden weitestgehend alle im Hintergrund laufenden Dienste deaktiviert. Die Simulation wird auf dem ungepatchten System (Lenovo ThinkPad, Windows 7, Intel Core i5 5200U mit 8 GB Ram) 4 mal nacheinander durchgerechnet. Der erste Durchlauf dient ausschließlich der Konditionierung der CPU und wird nicht ausgewertet. Die 3 folgenden Durchläufe werden gemittelt.

Danach werden die Microcode-Updates installiert und das Prozedere wiederholt.

Die grafische Auswertung kann dem untenstehenden Diagramm entnommen werden.

Zu beachten ist, dass sich der durchgeführte Benchmark ausschließlich auf das Microcode-Update bezieht und die Zeitachse, zur besseren Visualisierung, abgeschnitten wurde. Der negative Effekt wurde bei allen Simulationen festgestellt. Die Streuung untereinander liegt bei unter 2 s.
Nahezu alle Betriebssysteme werden weitere Patches erhalten, die einen mehr oder weniger großen, aber immer negativen Einfluss auf die Rechengeschwindigkeit haben werden. Trotzdem überrascht das Ergebnis. Nach den Horror-Meldungen der letzten Wochen, ist ein Anstieg der Simulationsdauer um weniger als 2 % überraschend gering.

Wir sind jedoch gespannt, wie groß die Auswirkung der folgenden Software-Patches ausfallen wird.

Update:
Zwischenzeitlich hat Lenovo ein weiteres Microcode-Update gegen eine Gruppe ähnlicher Angriffsszenarien zur Verfügung gestellt und wir haben den beschriebenen Testfall ein weiteres mal berechnet. Während die Rechengeschwindigkeit beim letzten mal fast vernachlässigbar nachließ, fällt der Geschwindigkeitsverlust diesmal deutlicher aus.

Ca. 10 % längere Rechenzeiten für eine Simulation sind in der praktischen Anwendung ein Thema. Administratoren von Servern sollten sich jetzt Gedanken über die Nutzung der Rechner und daraus resultierende Angriffsszenarien machen und in Abhängigkeit davon sorgfältig abwägen, wie sie weiter vorgehen.

WordPress Cookie Hinweis von Real Cookie Banner