Vorab: Frohes Neues Jahr!
Aus gegebenem Anlaß ein kurzes Statement zum Computerproblem »Meltdown« (und »Spectre«).
Es ging letzten Donnerstag ja sogar durch Funk und Fernsehen (ab 00:14:53):
Tja … Die Art und Weise, wie die Prozessoren in Computern (PCs, Laptops; ja, selbst Smartphones sind z. T. betroffen) in den letzten 10 Jahren immer leistungsfähiger wurden, hat leider einen unerwünschten Nebeneffekt, denn sie öffnet auf vielen Systemen ein Sicherheitsloch: Bei Intel-Prozessoren ein größeres, bei anderen ein nicht unerhebliches — oder gar keines, siehe Raspberry Pi (da gibt’s auch eine anschauliche Beschreibung des eigentlichen Problems; allerdings auf Englisch).
Ohne ins Detail gehen zu wollen nur soviel: auch unsere Serversysteme sind von den »Meltdown« und »Spectre« getauften Problemen betroffen. Dies bedeutet ein wenig Arbeit für uns, denn alle gut 50 virtuellen Maschinen sowie die auf verschiedene Rechenzentren verteilten ca. 10 physischen Serversysteme, auf denen jene VMs laufen, müssen aktualisiert, und dabei neu gestartet, werden. Da auf jedem physischen Serversystem mehrere VMs laufen, wir aber nicht in allen Rechenzentren mehrere Serversysteme haben und zur Absicherung sowieso jedes System neu gestartet werden muß, werden einige Dienste kurzzeitig ausfallen. Die Arbeiten werden voraussichtlich in den Abendstunden bzw. an Wochenenden vorgenommen werden.
Wichtig: Das Freifunknetz an sich sollte in der Zeit weiterhin funktionieren ;-)
Aktuell ist die Faktenlage noch etwas unklar, und daher auch noch keine konkreteren Pläne vorhanden; die Entwickler der generischen Virtualisierungslösung QEMU schreiben zum Beispiel, daß über die »Meltdown«-Lücke aus virtuellen Maschinen kein Zugriff auf Speicher des Serversystems (des sog. Hypervisors) möglich wäre. Auch die Virtualisierungstechnik Xen (worauf z. B. die Amazon-Wolke setzt) meldet, daß bei hardware-gestützter Virtualisierung kein Zugriff von einem Gast-System auf den Speicher des Hypervisors möglich wäre.
Wir setzen die Virtualisierungslösung KVM mit hardware-gestützter Virtualisierung ein. Somit könnten wir uns Zeit lassen mit dem Aktualisieren, denn es wäre kein Zugriff auf Daten anderer VMs möglich.
Allerdings: Über die »Spectre«-Lücke soll dies auch bei hardware-gestützter Virtualisierung möglich sein — nur daß es gegen diese Lücke zur Zeit noch wenig bis gar keine Korrekturen (vgl. Abschnitt zu »Spectre«) gibt.
Alles in allem schätzen wir die Gefahr bezogen auf unsere Freifunk-Infrastruktur nach aktuellem Kenntnisstand aber als gering ein; bis auf bei 4 VMs (VMs für zwei Nachbarcommunities sowie unsere mtr.sh-Node) hat kein Dritter Zugriff auf unsere Systeme; jene Systeme werden wir sicherheitshalber vorübergehend auf einem Host zusammenziehen. Da wir nur auf »eigener« Hardware arbeiten (Bare-Metal-Virtualisierung, keine angemieteten VMs), geht eine Gefahr nur von eigenen System aus (mit obiger Ausnahme).
Letztlich gibt es auch nicht sonderlich viele lohnende »Geheimnisse« auf unseren Systemen, die auszuspähen sich lohnte: der Traffic, den wir transportieren, stammt aus einem unverschlüsselten WLAN und kommt/geht unverschlüsselt aus dem/ins Internet – weshalb wir ja seit Jahr und Tag den Einsatz von Ende-zu-Ende-Verschlüsselung (HTTPS, IMAPS, SMTPS/SMTP mit STARTTLS usw.) predigen –, die meisten Statistiken sind öffentlich zugänglich, wir arbeiten nicht mit System-Passwörtern, …
Eine Veränderung von Daten ist nach aktuellem Informationsstand nicht möglich, ›nur‹ ggf. das Auslesen von eigentlich nicht zugänglichen Speicherbereichen (und auch dies vergleichsweise langsam).
Dennoch werden natürlich auch wir unsere Systeme zeitnah aktualisieren (ab dem 9. Januar sollen erste Fixes verfügbar sein; es werden über die nächsten Wochen noch weitere Aktualisierungen jener erwartet, die etwaige neue Probleme adressieren) — und leider wird’s an der einen oder anderen Stelle in den nächsten Wochen daher etwas rumpeln.
Und Ihr wißt nun auch Bescheid, warum ;)
sieht so aus als würden wir insbesondere mit diesen Servern mangels pcid-Support mit Performanceeinbussen rechnen müssen:
azrael
blackstar
conquest
inflexible
steadfast
thunderflare
willikins
Reference: https://www.theregister.co.uk/2018/01/09/meltdown_spectre_slowdown/
Yepp, auch vorhin geprüft Inflexible & Thunderflare waren die, die aus der alten Charge noch hätten weiterlaufen sollen; das hat sich dann wohl erledigt
blackstar ist bißchen doof, da die Kiste am Community-IX in BER, aber Austausch durch potenteres Blech stand eh’ auf Agenda.
Spannend wird auch, PCID an die VMs durchzureichen; das geschieht aktuell auch noch nicht …
kvm tut das (noch?) nicht. Andererseits können wir die VMs aber auch mit ‘nopti’ laufen lassen. Wenn sich die VM selber Daten “klaut” ist bei unserem Setup ja eher ungefährlich. Und wenn die Hosts abgesichert sind, sollte keine VM mehr irgendwohin greifen können wo Sie nicht soll.
Das hoffe ich auch, so ganz sicher bin ich mir da aber nicht; wieso soll Meltdown für HVM (hardware-gestützte Wirrtualisierung) bei den VMs nicht greifen, Spectre aber doch? (Meine Frage ist also eigentlich: wenn Spectre auch bei HVM greift, warum dann nicht Meltdown?)
Mit “kvm64” als CPU habe ich nun auf einem meiner Microserver Gen8 eine VM mit PCID. Allerdings unterstützt die CPU (
Intel(R) Celeron(R) CPU G1610T @ 2.30GHz
) nur PCID, nicht aber auch INVPCID — was evtl. ein Problem ist:Potentielles Problem, weil:
Aber ob das nun in den finalen (Ubuntu-) Patches drin ist? Schätze, das kommt auf einen Versuch an
Hmm. Eine andere VM auf dem HV, von “Nehalem” auf “kvm64” umgestellt, hat kein PCID. WTF?!