Meltdown & Spectre - mögliche Auswirkungen

Wichtige Updates – Erste Tests mit CentOS 7 und mögliche Auswirkungen

Das aktuelle Thema Meltdown und Spectre wurde in einem vorhergehenden Artikel bereits ausführlich besprochen. Dort gab es erste kleine Tests mit dem Auswirkungen von den relevanten Securitypatches auf die Geschwindigkeit des Systems. Kernelentwickler hatten bereits darauf hingewiesen, dass unter Umständen mit 5 bis 30 Prozent Geschwindigkeitseinbußen zu rechnen ist.

Es gab einige Fragen zu den Auswirkungen in CentOS 7, da einige der Securitypatches in den Kernel portiert wurden (und damit logischerweise auch in RHEL 7 zu finden sind). CentOS 7 bietet mit dem Kernel 3.10.0-693.11.6 einen aktuellen Patchlevel mit aktuellen Fixes für die beschriebenen Sicherheitsproblemen an, unter anderm auch die Backports für Kernel Page Tables Isolation (KPTI). Um vollständig alle Sicherheitsprobleme zu beheben, muss ferner die Aktualisierungen des Microcodes eingespielt werden (microcode_ctl-2.1-22.2). Red Hat hat hier einen entsprechenden Artikel online gestellt, der die Änderungen erläutert.

Ist das System nach aktuellem Kenntnisstand geschützt, kann dies über die jeweiligen debugfs Einträge abgefragt werden:

$ cat /sys/kernel/debug/x86/ibrs_enabled
0
 
$ cat /sys/kernel/debug/x86/ibpb_enabled
0
 
$ cat /sys/kernel/debug/x86/pti_enabled
1

Auf dem verwendeten virtuellen Testsystem waren IBRS und IBPB jeweils 0, da auf dem Host auch die relevanten Microcode Updates noch nicht zur Verfügung standen. Insbesondere die Variante 2 (Spectre, Branching Poisoning Attack) soll mit IBPB dann auch nicht mehr möglich sein. Ob und wie alle Einträge tatsächlich aktiviert sind, hängt von der verwendeten Plattform ab. Der Red Hat Artikel bietet hier ebenfalls eine Übersicht über die möglichen Konstellationen. Ein Folgeartikel wird sich mit den jeweiligen unterschiedlichen Einstellungen noch beschäftigen und die Performancemessungen hierfür ebenfalls wiederholen.

Mit den obigen Einstellungen für IBRS und IBPB ist das Testsystem gegen die Varianten 1 (Spectre mit Branch Bounds-checking exploit) und Variante 3 (Meltdown, Speculative Cache Loading) geschützt.

Die folgenden Messungen wurden im Vergleich mit dem vorhergehenden Patchlevel 3.10.0-693.11.1 durchgeführt, um die Auswirkungen zu testen.

Die Messungen

Wie alle Messungen sind die Zahlen im folgenden natürlich spezifisch für die verwendete Umgebung. Die Messungen sollen nicht prinzipiell die Leistungsfähigkeit demonstrieren, sondern die Auswirkungen von Änderungen im Kernel zeigen. Als Benchmark dient erneut der PostgreSQL^®-eigene Benchmark pgbench mit PostgreSQL^® HEAD vom 05.01.2018. Die Tests wurden auf einer CentOS 7 (7.4.1708) VM durchgeführt, ebenfalls jeweils mit 4 und 8 vCPUs. Anders als in den Tests auf der Fedora 27 Instanz standen jedoch 8 GByte RAM zur Verfügung, allerdings sollte das im wesentlichen keine Auswirkungen auf die Messung haben. pgbench wurde zunächst mit 16 Verbindungen und einem pgbench Thread gestartet. Der Testlauf hier ist SELECT-only.

Der ältere Kernel bietet bei dieser Teststellung bei 4 vCPUs ca. 10%, bei der Verwendung doppelt sovieler Prozessoren ca. 5% mehr Durchsatz (41045 zu 37050 respektive 53712 zu 51365 Transaktionen pro Sekunde). pgbench bietet auch die Möglichkeit, mehrere Threads für den Benchmark zu nutzen. Die folgende Teststellung verwendet für jede Datenbankverbindung einen eigenen Thread (Schalter -j für pgbench):

Der Vergleich verwendet jeweils 8 vCPUs und stellt die Durchsatzraten mit Prepared Statements (Schalter -Mprepared für pgbench) und normale Statements gegenüber (letzteres ist der Standard für pgbench). Hier ergibt sich sogar ein winziger Performancevorteil für den neuen Kernel mit den sicherheitsrelevanten Patches, dieser liegt zwischen 1 und 2%. Damit liegen diese bei diesem Benchmark quasi gleichauf. pgbench unterstützt die Möglichkeit benutzerdefinierte Skripte auszuführen die es gestattet, eigene SQL Befehle für einen Testlauf zu benutzen. KPTI hat seinen größten Geschwindigkeitsnachteil theoretisch bei Workloads, wo sehr viele Context Switches und Systemaufrufe stattfinden. Im folgenden wird ein unrealistisches Szenario getestet, indem pgbench mit den identischen Laufzeitparametern zu den vorhergehenden Testfällen immer ein

SELECT 1;

verwendet. Das Ergebnis stellt sich wie folgt dar:

Der Einbruch gegenüber dem Kernel mit KPTI ist hier deutlich. Er verliert knapp 16% gegenüber dem Kernel ohne die entsprechenden Fixes, in Zahlen sind es 167352 (3.10.0-693.11.1) gegenüber 147947 (Kernel 3.10.0-693.11.6) Transaktionen pro Sekunden.

Das ganze lässt sich noch weitertreiben, in dem gar keine Abfrage mehr ausgeführt und man daher Parser und alles nachgelagerte der Datenbank außen vor lässt. Man erreicht dies, indem pgbench lediglich ein „;“ als SQL-Skript vorgesetzt bekommt. Dies stresst hauptsächlich nur noch das System selbst, da die Datenbank im Endeffekt nichts mehr zu tun hat und lediglich Prozesse forked. Das Resultat gestaltet sich dann wie folgt:

In absoluten Zahlen stehen hier im Schnitt 254574 zu 230021 (Kernel 3.10.0-693.11.1 sowie 3.10.0-693.11.6) gegenüber. Dies entspricht 10% weniger Durchsatz im Falle des neuen Kernels. Interessant ist auch der Vergleich, falls die CPU und der verwendete Kernel kein PCID (Process-Context Identifiers) bieten. Dies bedeutet in den meisten hier getesteten Fällen einen deutlichen Einbruch der Durchsätze. Der Testfall mit pgbench und 16 Datenbankverbindungen SELECT-only (ohne Prepared Statements) mit jeweils einem eigenem pgbench Thread ergibt im Vergleich:

Im Vergleich zum Kernel ohne KPTI hat das Fehlen der Unterstützung von PCID einen Einbruch um ca. 7% zur Folge (56232 im Vergleich zu 52757 Transaktionen pro Sekunde). Noch deutlicher fällt das Resultat im Vergleich des „noop“-Benchmarks aus. Hier beträgt der Unterschied zwischen dem Kernel ohne KPTI, mit KPTI und dem Fehlen von PCID jeweils 10% und 16%:

Interessant bei diesen Vergleichen ist noch der Einfluss von schreibenden Transaktionen. Hierzu wurde pgbench anstatt im SELECT-only Modus (Schalter -S) im TPC-B Workload getestet. Der beobachtete Trend der Geschwindigkeitseinbußen von moderat beim Kernel mit KPTI Unterstützung hin zu bemerkenswert lässt sich auch hier beobachten:

Fazit

In den getesteten Fällen mit pgbench zeigt sich, dass die von den Kernelentwickler pauschal angegebenen Einbußen beim Kernelupgrade durchaus realistisch sind. Allerdings kann nicht pauschal eine spezifische Zahl genannt werden, da die Einbrüche sehr stark abhängig vom Workload sind. pgbench an sich ist bereits ein sehr synthetischer Workload, der zwar die Datenbank stark stressen kann, allerdings mit der realen Welt sehr wenig gemein hat. Selbst hier bedarf es stark unrealistischer Benchmarkkonfigurationen, um die Einbrüche in den genannten Bereichen tatsächlich aufzuzeigen, nie wurde aber der Worstcase von 30 % tatsächlich erreicht. Dies bedeutet nicht, dass es den Workload mit diesen Geschwindigkeitseinbußen tatsächlich nicht gibt. Eher unterstreichen die von uns ermittelten Ergebnisse die Bedeutung von eigenen, möglichst Anwendungsnahen Tests, die spezifisch den eigenen Workload und etwaige zu erwartende Einbußen überprüfen. In der Mehrzahl pendeln sich die Unterschiede zu Ungunsten des CentOS7 Kernels mit Sicherheitspatches in etwa bei 5% ein, es können jedoch durchaus mehr sein. Besonders wenn die Unterstützung von PCID von der Plattform nicht gewährleistet wird, so kann dies deutlich höhere Einbußen nach sich ziehen, bis zu 16% in den hier gezeigten Teststellungen.