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 ;)

Meltdown

Bisherige Kommentare

  1. Avatar for wusel wusel says:

    Yepp, auch vorhin geprüft :slight_smile: Inflexible & Thunderflare waren die, die aus der alten Charge noch hätten weiterlaufen sollen; das hat sich dann wohl erledigt :frowning:

    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 …

  2. Avatar for Cord Cord says:

    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.

  3. Avatar for wusel wusel says:

    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:

    PCIDs are generally available on Sandybridge and newer CPUs. However,
    the accompanying INVPCID instruction did not become available until
    Haswell (the ones with “v4”, or called fourth-generation Core). This
    instruction allows non-current-PCID TLB entries to be flushed without
    switching CR3 and global pages to be flushed without a double
    MOV-to-CR4.

    Without INVPCID, PCIDs are much harder to use. TLB invalidation gets
    much more onerous:

    […]

    So, for now, we fully disable PCIDs with KAISER when INVPCID is
    not available. This is fixable, but it’s an optimization that
    we can do later.

    Hugh Dickins also points out that PCIDs really have two distinct
    use-cases in the context of KAISER. The first way they can be used
    is as “TLB preservation across context-swtich”, which is what
    Andy Lutomirksi’s 4.14 PCID code does. They can also be used as
    a “KAISER syscall/interrupt accelerator”. If we just use them to
    speed up syscall/interrupts (and ignore the context-switch TLB
    preservation), then the deficiency of not having INVPCID
    becomes much less onerous.

    Potentielles Problem, weil:

    wusel@ysabell:~$ ssh root@colosses.4830.org grep -i pcid /proc/cpuinfo | uniq -c
         24 flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 popcnt aes lahf_lm epb tpr_shadow vnmi flexpriority ept vpid dtherm ida arat
    wusel@ysabell:~$ ssh root@colosses.4830.org grep -i inv /proc/cpuinfo | uniq -c
    wusel@ysabell:~$ ssh root@nihil.4830.org grep -i pcid /proc/cpuinfo | uniq -c
         24 flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid dca sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx lahf_lm epb tpr_shadow vnmi flexpriority ept vpid xsaveopt dtherm ida arat pln pts
    wusel@ysabell:~$ ssh root@nihil.4830.org grep -i inv /proc/cpuinfo | uniq -c
    

    Aber ob das nun in den finalen (Ubuntu-) Patches drin ist? Schätze, das kommt auf einen Versuch an :frowning:

  4. Avatar for wusel wusel says:

    Hmm. Eine andere VM auf dem HV, von “Nehalem” auf “kvm64” umgestellt, hat kein PCID. WTF?!

Weitere Diskussion über diesen Beitrag bitte im Forum forum.freifunk-kreisgt.de

3 more replies

Diskussionsteilnehmer

Avatar for Cord Avatar for wusel