# SELECT datname, xact_commit, xact_rollback
  FROM pg_stat_database
  WHERE datname !~ 'template(0|1)'
  ORDER BY datname;
 
 datname  | xact_commit | xact_rollback
----------+-------------+---------------
 foo      |        8881 |             0
 omdb     |       29149 |         18926
 postgres |       43780 |          1754
(3 Zeilen)

sql_pg_stat_database{col="xact_commit", datname="omdb", host=":5432", sql_job="10/main", user="postgres"} 29149
sql_pg_stat_database{col="xact_rollback", datname="omdb", host=":5432", sql_job="10/main", user="postgres"} 18926

Vergangene Woche fand die deutschsprachige PostgreSQL^®-Konferenz am Müggelsee im Süd-Osten von Berlin statt. credativ war mit insgesamt neun Personen vertreten. Vier unserer Kollegen haben als Speaker zum Vortragsprogramm beigetragen. Auch in der Event-Organisation war credativ vertreten und hat mitgeholfen, die Konferenz zu stemmen und zu einem Erfolg zu machen. Aufgrund der langen Anfahrt sind wir schon am Vortag angereist und konnten uns am Freitag dann ganz auf die Konferenz und das Publikum am credativ-Stand konzentrieren.

Das Vortragsprogramm war abwechslungsreich gestaltet. Den Auftakt machte Peer Heinlein mit der Keynote „Umdenken! 11 Gebote zum IT-Management“, in der er unter anderem die Diskrepanz im Investitionsverhalten zwischen Hardware und Personal ansprach. In der Praxis beobachtet er oft, dass für Hardware wesentlich mehr Geld ausgegeben wird, als für Personal. Zitate wie: „Nehmen wir gleich ein Terabyte RAM, dann haben wir was für die Zukunft!“ seien keine Seltenheit. Bei Schulungen und Stellen werde dagegen nicht selten gespart. Auch „zu komplexe“ hochverfügbare Systeme, bei denen der „nicht redundante“ Admin der Single Point of Failure ist, seinen die Regel. Viele seiner Beobachtungen können wir von credativ aus der Praxis bestätigen.

In seinem Vortrag „Modernes SQL: Wie PostgreSQL^® die Konkurrenz aussticht“ stellte Markus Winand einige SQL-Sprachkonstrukte vor, die zwar Teil des SQL-Standards sind (teilweise auch schon seit SQL:2003), trotzdem aber ausschließlich von PostgreSQL^® implementiert werden – aber nicht von der Konkurrenz. Beispiele sind FILTER, boolean-Aggregate und DOMAINs.

Während dessen hat Devrim Gündüz in seinem Talk „WAL for DBAs – Everything you want to know“ Details über Interna des PostgreSQL^®-Write Ahead Logs vorgestellt und ist darauf eingegangen, was Administratoren zu beachten haben.

Bruce Momjian stellte den aktuellen Stand von Sharding in PostgreSQL^®“ vor. Leider blieb im Vortrag nicht mehr viel Zeit um auf die Zukunft zu blicken, so dass hier lediglich die vergangene Entwicklung beleuchtet wurde.

Mit eigenen Vorträgen waren wir durch Alexander Sosna und Adrian Vondendriesch vertreten, die die Hintergründe unserer PostgreSQL^®-Appliance Elephant Shed vorstellten, sowie durch Christoph Berg, der vorstellte, wie man mit Prometheus und Grafana ein Monitoring für PostgreSQL^® einrichtet. Michael Meskes stellte in seiner Closing Session die Frage „Hat Open Source eine Zukunft?“ und mahnte, auf völlig offene Produkte zu setzen, die ohne Open Core und Vendor Lock-In auskommen.

Insgesamt war die Konferenz eine lohnende Erfahrung für uns, insbesondere die Live-Demo von Elephant Shed am credativ-Stand war ein guter Einstieg zu interessanten Gesprächen.

Die nächste PGConf.DE findet im Mai 2019 in Leipzig statt. Wir freuen uns jetzt schon!

vagrant init credativ/elephant-shed
vagrant up

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.

Mit Beginn des Jahres 2018 wurden Probleme mit dem Speichermanagement und Intel-Prozessoren öffentlich. Laut diesen Reports ist es offensichtlich möglich, beliebige Bereiche des Kernel- und Userspace Speicherbereiches auszulesen und damit unter Umständen auf sensitive Bereiche zugreifen zu können.

Im Laufe der letzten Tage gab es einige Gerüchte und Vermutungen, in welche Richtung dies alles geht, mittlerweile gibt es ein offizielles Statement der Hacker von Project Zero (Google), die die Erkenntnisse zusammenfassen.

Was ist genau passiert?

Im wesentlichen wurden Angriffsvektoren identifiziert, die über die nicht erfolgreiche, spekulative Ausführung von Code auf einem Prozessor und geschicktes Timing privilegierte Informationen trotz fehlender Berechtigung aus dem Cache der CPU auslesen kann. Hierbei ist es möglich, trotz der fehlenden Berechtigung (sei es aus dem User- oder innerhalb des Kernelspace) Speicherbereiche zu lesen und deren Inhalte zu interpretieren. Dies ermöglich theoretisch breitflächige Einfallstore für Schadsoftware, wie etwa das Ausspionieren sensibler Daten oder der Mißbrauch von Berechtigungen. Man spricht hier von sogenannten Side Channel Attacks. Betroffen sind nach aktuellem Kenntnisstand nicht nur Intel CPUs (von denen man ausschließlich ursprünglich ausging), sondern auch AMD CPUs, ARM sowie POWER8 und 9 Prozessoren.

Was genau geschieht aktuell?

Project Zero fasst im Report die wesentlichen Probleme zusammen. Es existieren mehrere Exploits die mit unterschiedlichen Ansätzen privilegierte Speicherbereiche lesen und damit unberechtigterweise an Informationen in sensiblen Bereichen des Kernels oder anderer Prozesse gelangen können. Da fast alle modernen CPUs die spekulative Ausführung von Anweisungen unterstützen, um ein Leerlaufen ihrer Ausführungseinheiten und damit verbundene hohe Latenzen zu verhindern, sind eine Vielzahl von Systemen theoretisch betroffen. Ein weiterer Ansatzpunkt dieses Angriffsszenarios ist die in aktuellen Systemen vorhandene Art und Weise, wie die Speicherbereiche von User- und Kernelspace interagieren. Tatsächlich war es bisher so, dass diese Speicherbereiche nicht wirklich voneinander getrennt sind, sondern der Zugriff auf diese Bereiche mit einem speziellen Bit abgesichert sind. Der Vorteil dieser nicht vorhandenen Trennung sind insbesondere dann tragend, wenn beispielsweise häufig von User- auf Kernelspace umgeschaltet werden muss.

Die Angriffsszenarien im Einzelnen sind:

• Spectre

Dieses Angriffsszenario nutzt die in modernen CPUs vorhandene Branch Prediction, d.h. Vorabanalyse über die Wahrscheinlichkeit dass bestimmter Code bzw. -zweige erfolgreich ausgeführt werden können. Hierbei wird die CPU dazu verleitet eigentlich von der Vorhersage nicht berücksichtigten Code spekulativ auszuführen. Diese Attacke kann dann benutzt werden, um schadhaften Code auszuführen. Diese Attacke funktioniert theoretisch auf allen CPUs mit entsprechender Sprungvorhersage, allerdings ist es laut Project Zero hier schwer zusammenfassend zu sagen welche Prozessoren in welcher Art betroffen sind. Spectre hat vor allem Anwendungen im Userspace im Fokus. Da Spectre hauptsächlich dann funktioniert, wenn bereits fehlerhafter Code in entsprechenden Anwendungen vorhanden ist, sollte besonders auf entsprechende Updates geachtet werden.

• Meltdown

Bei Meltdown wird nun die spekulative Ausführung genutzt, um Code auszuführen, der eigentlich gar nicht final erreicht werden kann. Dies sind hier Exception-Anweisungen mit nachfolgenden Instruktionen, die nie ausgeführt würden. Durch die spekulative Ausführung der CPU werden diese Instruktionen dennoch von der CPU berücksichtigt. Zwar gibt es keine Seiteneffekte durch diese Art der Ausführung, dennoch verbleiben die von der Instruktion belegten Speicheradressen im Cache der CPU und können von dort genutzt werden, um alle Speicheradressen zu testen. Da aktuell der Speicherbereich des Kernels und des Userspaces gleichermaßen zusammenhängend organisiert sind, kann so nicht nur der gesamte Speicherbereich des Kernels, sondern auch aller auf dem System laufenden Prozesse ausgelesen werden. Eine detaillierte Beschreibung der Funktionsweise des Angriffs ist hier zu finden. Meltdown funktioniert nur auf Intel Prozessoren, da nur hier die Privilegien auf den adressierten Speicherbereich bei Out-Of-Order Ausführung nicht mehr geprüft werden.

Beide Szenarios machen sich auf unterschiedliche Art und Weise die entsprechenden Sicherheitslücken zunutze. Die CVEs zu den Lücken sind im einzelnen:

• CVE-2017-5753
• CVE-2017-5715
• CVE-2017-5754

Wie geht es weiter?

Um Meltdown-Attacken vorzubeugen gibt es für Linux, Windows und OSX bereits entsprechende Updates (Letzteres enthält entsprechende Änderungen bereits seit geraumer Zeit. Im wesentlichen trennen diese Updates die Speicherverwaltung für den Kernel- und Userspace völlig auf (unter Linux bekannt als KPTI-Patches, Kernel Page Table Isolation, formals auch KAISER). Hierdurch ist es nicht mehr möglich, durch die Privilege Escalation auf Intelprozessoren auf Speicherbereiche des Kernels ausgehend eines unprivilegierten Kontextes zuzugreifen. RedHat stellt diese ebenso wie CentOS und Fedora bereits mit aktualisierten Kerneln zur Verfügung.

Insbesondere die Meltdown-Attacken werden hierbei wirkungsvoll unterdrückt, für Spectre-Attacken selbst gibt es ausgehend der aktuellen Sachlage keine belastbaren, wirkungsvollen Maßnahmen. Wichtig ist jedoch, dass im Linuxkernel eBPF und die entsprechende Ausführung vom BPF-Code im Kernel deaktiviert wird.

sysctl -a | grep net.core.bpf_jit_enable
sysctl net.core.bpf_jit_enable=0

Die Änderung setzt „root“-Berechtigungen voraus.

Geschwindigkeit aktualisierter Kernel

Durch die Trennung der Speicherverwaltung für Kernel- und Userspace werden Kontextwechsel und Systemaufrufe teurer. Dies sorgt für deutlich höhere Latenzen, insbesondere wenn die Anwendung sehr viele Kontextwechsel (beispielsweise Netzwerkommunikation) verursacht. Die Einbußen hierbei sind schwierig zu bemessen, da nicht jeder Workload wirklich identische Zugriffsmuster zugrunde legt. Für kritische Systeme empfehlen sich daher Lasttests auf identischen Testsystemen falls möglich. Falls nicht möglich sollten die Lastparameter nach der Aktualisierung des Systems sorgfältig beobachtet werden. Man nimmt pauschal Geschwindigkeitseinbußen im Rahmen 5% an, letztendlich wurden jedoch auch Tests der Kernelentwickler mit bis zu 30% Einbußen beobachtet. Da die Page Table Isolation (bis jetzt) nur für x86_64 Architekturen verfügbar ist, treffen diese Zahlen tatsächlich nur auf Maschinen mit Intel Prozessoren zu. Tatsächlich wird KPTI vom Kernel Upstream standardmässig nicht für AMD aktiviert.

Ob KPTI aktiviert ist, lässt sich per Kernel-Log ermitteln:

dmesg -T | grep "page tables isolation"
[Fr Jan  5 10:10:16 2018] Kernel/User page tables isolation: enabled

Insbesondere Anwender von Datenbanken sind hier sensitiv, da zum Beispiel Systeme wie PostgreSQL^® in der Regel eine hohe Anzahl Context Switches bei hoher Last verursachen. Bei credativ haben wir den Impact auf einem kleinen virtualisierten System klassifiziert. Grundlage ist ein Fedora 27 System als KVM-Gast mit 4 GByte RAM und schnellem NVMe-Speicher als Grundlage. Dies spielt bei diesem Test jedoch eher ein unbedeutende Rolle, da die mit pgbench durchgeführten Datenbanktests lediglich eine Größe von knapp 750 MByte hat. Der Shared Buffer Pool der PostgreSQL^® Instanz war mit 1 GByte so konfiguriert, dass die komplette Datenbank in den Datenbankcache passt. Die Tests wurden jeweils mit 4 und 8 virtuellen Prozessoren durchgeführt. Das Hostsystem verfügt über einen Intel Core i7-6770HQ Prozessor.

Die größte Auswirkung ist zu beobachten, wenn PCID im Kernel nicht vorhanden bzw, deaktiviert ist. PCID ist eine Optimierung, die einen Flush des Translation Lookaside Buffers (TLB) verhindert, wenn ein Context Switch erfolgt. Virtuelle Speicheradressen werden nur dann erfolgreich per TLB aufgelöst, wenn die PCID zum aktuellen Thread auf der jeweiligen CPU passt. PCID steht ab kernel 4.14 zur Verfügung. Der Test vergleicht einen Entwicklerkernel mit Page Table Isolation (PTI) 4.15.0-rc6, aktuellen Fedora Upstreamkernel mit und ohne Sicherheitspatches. PTI kann deaktiviert werden, indem man dem Kernel mittels pti=off beim Booten ein entsprechendes Argument definiert.

Das Fedora Testsystem hat bereits einen sehr aktuellen Kernel (4.14). Der Unterschied zum alten Upstreamkernel 4.14.8 ohne Sicherheitsrelevante Patches beträgt zum neuen Kernel 4.14.11 ca. 6%. pgbench liefert dann folgende Durchsatzraten (Transaction per second):

Legt man den ehemaligen Standardkernel 4.14.8 von Fedora 27 mit 100% zugrunde, ergibt sich folgendes Bild:

Die PostgreSQL^® Community hat ebenfalls bereits kleinere Tests zum Messen der Auswirkungen durchgeführt. Die Ergebnisse decken sich mit unseren Erkenntnissen. Der neue Kernel 4.14.11 mit den relevanten Patches bietet in etwa diesselbe Performance wie der Entwicklerkernel 4.15.0-rc6 auf dieser Plattform. 4.14.11 ist in diesen Testcases sogar teilweise vor dem alten Upstreamkernel (8 vCPU, Vergleich 4.14.8, grün und 4.14.11, braun). Allerdings liegt der Vorteil hier bei knapp über 1%, so dass man hier eher davon ausgehen kann, dass bei dieser Teststellung keine großen Geschwindigkeitsunterschiede bestehen.

Für Interessierte gibt es zudem eine eigene Seite zu dem Thema. Diese fasst alle wesentliche Informationen zusammen. Empfehlenswert ist auch die Zusammenfassung des Journalisten Hanno Böck auf github, die eine sehr gute Liste aller Patches für Meltdown und Spectre bietet.

Dieser Artikel wurde ursprünglich von Bernd Helmle geschrieben.