Meltdown, Spectre & Hana

Es ist nicht das erste Mal, dass ein Sicherheitshinweis die Anfälligkeit von PCs und Servern aufzeigt. Im Fall von Meltdown und Spectre sprechen aber viele seriöse IT-Experten von einem Security-GAU, weil eine Eindämmung der Gefahr zwar möglich ist und sein wird, aber die Auswirkungen noch nicht abschätzbar sind.

Der Unterschied zu früheren Sicherheitsproblemen: Es geht bei Meltdown und Spectre nicht um die Beseitigung eines „ärgerlichen“ Programmierfehlers, sondern um eine grundsätzliche Architekturentscheidung des Prozessor-Designs.

Rechenschritte, die der Prozessor optional und prädiktiv ausführt, sind nicht gleich sicher und umfassend geschützt wie der „offizielle“ Programmcode. Damit keine Zeit beim Warten auf Zwischenergebnisse verloren geht, berechnen die meisten modernen Mehrkern-Prozessoren als „Fleißaufgabe“ im vorauseilenden Gehorsam mögliche Ergebnisse.

Was nicht gebraucht wird, wird aussortiert. Was notwendig ist, liegt dann schon bereit. Leider wird diese vorauseilende Fleißaufgabe im „Niemandsland“ des Prozessors ausgeführt, wo zwar richtige Ergebnisse entstehen, aber unter Ausschluss aller Sicherheitsmaßnahmen.

Inwieweit die Reparatur von Meltdown und Spectre dringend und notwendig wird, weil dieser Security-GAU durch kriminelle Machenschaften genutzt werden kann, werden zukünftige Analysen zeigen. Für einen Hana-Anwender hingegen stellt sich eine ganz andere Frage: Wird die „Reparatur“ die Leistung der Hana-Datenbank beeinflussen?

Abgeleitet aus dem öffentlichen Wissen über Meltdown und Spectre und den Lösungen zur Beseitigung der Schwachstelle entweder auf BIOS- oder Betriebssystemebene lässt sich erkennen, dass die Prozessorleistung definitiv verringert wird.

Das renommierte IT-Journal „Magazin für Computer-Technik“ (c’t) konnte bereits einige Tests durchführen, die in der Ausgabe vom 20. Januar dieses Jahres veröffentlicht wurden. Das Ergebnis zusammengefasst:

Bei einfachen Office-Funktionen wird man am PC kaum einen signifikanten Leistungseinbruch feststellen, bei Computerspielen kann es selten vorkommen, aber bei sehr intensiven Input/Output-Befehlen, wie sie vorrangig im Datenbank-Umfeld vorkommen, können deutliche und spürbare Leistungseinbrüche beobachtet werden.

Hana ist eine In-memory-Computing-Datenbank, die überwiegend von der Geschwindigkeit des Prozessors sowie der Größe und Geschwindigkeit der Caches und des Hauptspeichers abhängig ist.

Theoretisch können also Reparaturmaßnahmen (Patches) auf Prozessorebene inklusive BIOS (Basic Input/Output System) und Betriebssystemebene (Linux von Suse und Red Hat) die Gesamtleistungsfähigkeit der Hana-Datenbank deutlich beeinflussen.

Läuft die Hana-Datenbank in einer virtualisierten Systemumgebung (Hypervisor), sind natürlich auch die Maßnahmen in einem VMware-System mitentscheidend.

Der Hana-Bestandskunde sollte also auf dem SAP’schen Servicemarktplatz Antworten finden, die SAP zusammen mit den Partnern Intel, IBM, Suse, Red Hat und VMware erarbeitet hat. Fehlanzeige – siehe Screenshot.

Das Schweigen von SAP an dem Platz, wo zuerst der Bestandskunde nach Rat und Hilfe sucht, ist besorgniserregend: Weiß es SAP nicht oder will SAP dazu nichts sagen? Wie gefährdet sind die Hana-Systeme? Warum schweigen Intel und IBM, auf deren Prozessoren Hana läuft?

Meltdown und Spectre werden nach aktuellem Wissensstand Auswirkungen auf alle In-memory-Computing-Datenbanken haben. Damit ist in erster Linie Hana (on-premise und Cloud) von diesem Security-GAU betroffen.

Die aktuelle Situation ist für alle Bestandskunden dahingehend sehr unangenehm und besorgniserregend, weil SAP versucht, die Verantwortung auf die zertifizierten Hana-Serverhersteller und Betriebssystemlieferanten abzuwälzen, siehe Text der SAP Note 2586312.

SAP Note: 2586312

Linux: How to protect against speculative execution vulnerabilities? (Version 3 vom 19. Januar 2018)

In early January 2018, a design flaw in modern CPUs was disclosed. By exploiting this design flaw, user mode applications can gain access to any physical memory, even if the memory is mapped in kernel mode only and thus should not be accessible. The design flaw manifests in several bugs, referred to as Common Vulnerabilities and Exposures. These bugs cannot be fixed in the CPUs themselves, but require both microcode and OS kernel updates. Affected are recent and older CPUs from Intel (Xeon) and IBM (Power), amongst others.

SAP strongly recommends to follow the recommendations and apply the updates provided by the hardware vendors, virtualization vendors and OS distributors as appropriate. These updates may impact the system’s performance. In virtualized systems, both host OS as well as guest OS should be patched and both can affect performance. The severity of the performance regression depends on the workload and on the CPU type. In virtualized systems, host OS as well as guest OS can be affected.

Contact the vendor of your server. Look for a BIOS update which includes microcode patches for the actual CPU bug(s). Several servers may require a complete disconnect from power after certain BIOS updates which ship new microcode. Refer to the installation guide for the BIOS update.

Contact the operating system distributor.
Install the required patches and reboot your host.