Supernodes mit fastd auf Virtualisierung ohne PCID cpu feature (Meltdown/Spectre-Fixes)


#1

Wenn ich
https://groups.google.com/forum/m/#!topic/mechanical-sympathy/L9mHTbeQLNU
richtig deute, dann könnten die Meltdown-Fixes jeglicher Form von Contextswitch-intensive Szenarien erheblichst bremsen, wenn in den CPU capabilities kein PCID ankommt.
Erster Ansatzpunkt für die Blechbetreibenden wird sein, ihre Hypervisor entsprechend zu befähigen, wenn es noch nicht tun derzeit.


Spectre/Meltdown Konsequenzen
#2

nach dem Update


kommt das feature “pcid” in /proc/cpuinfo des guest-VMs an.

Dann braucht es jetzt nur noch finale Kernel bei Ubuntu&Co.

https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown

(Leute mit Opteron und anderen anderen AMDs haben aber evl. noch etwas mehr “Spass”, siehe Proxmox-Forum. Und nein, das ist noch alles nicht der finale Fix. Aber schon mal mal mindestens die halbe Miete und die Hoffnung, dass die Menschen, die sich Exploits bauen, dann eine andere “Baustelle” suchen.)


#3

Vielleicht verstehe ich das ja alles doch nicht, aber … “die Menschen, die sich Exploits bauen” brauchen doch einen Shell-Account auf meinem angreifbaren Server? Dieser ganze Meltdown- und Spectre-Rotz ist doch vollkommen uninteressant, solange man keinen (Shell-) Zugriff auf einen Server hat, auf welchem man das exploiten kann?


#4

Oft sind Supernodes auf Maschinen, deren Virtualierung auch andere “Kunden” hat, z.B. weil eine Serverspende sowohl “Supernode” wie auch “Warenwirtschaft für einen Kleingewerbetreibenden” macht.
Und häufig gibt es auch “Spielplatz-VMs”, wo viele Leute "im Bereich ‘Nachwuchs’ Logins bekommen. Und diese sogar mal einen kompletten Desktop laufen lassen.
Da hat man dann auch verschiedene (disjunkte) Personengruppen, sich in diese Maschinen einloggen können.
Aus einem Gebot der Fairness (oder des Datenschutzes) wüsste ich gern in so einem Szenario die Kisten gern gegeneinandere “abgedichtet”.


#5

Man denkt halt grunsätzlich immer noch an RCE, sonst würden die ganzen Daemons ja ohne Probleme als root und nicht als eigene User (ggf. mit eigenen chroots) laufen.

Wenn man dann zwar keine Privilege Escalation hat, sondern “nur” fremde Daten auslesen kann hat man immerhin schon quasi Heartbleed (wenn auch nach aktuellem Kenntnisstand viel unzuverlässiger zu provozieren)


#6

Ich antworte Mal hierein, weil es thematisch besser passt.

(Referenz: Spectre/Meltdown Konsequenzen)

@adorfer, natürlich ist das Einspielen der Aktualisierungen erstrebenswert. Aber wenn man sauber getrennte VMs hat, scheint es nicht so dringend zu sein.

Eine Frage wäre z. B., ob man mit Meltdown aus einer VM Bereiche des Hosts auslesen kann.


#7

Genau darum ging es.
Prinzipiell muss man natürlich überhaupt erstmal Code zur Ausführung bekommen.
Grundsätzlich will man das aber gefixt haben, denn Meltdown ruiniert sämtlichen Speicherschutz. Sowohl den “priviledge escalation” (“werde root”), als eben auch "kapere auch noch alle anderen VMs des gleichen Bleches und natürlich auch den Hypervisor selbst.

Das will man fixen, wenn es irgendwie geht.


#8

Ubuntu-Status:
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/SpectreAndMeltdown

Proxmox-Status:

Zum Testen des Zustands hat sich der hier bewährt:

Näher komme ich derzeit auf Hypervisorebene bei Proxmox (hier Opteron) nicht:
Meltdown: Not affected
Spectre Teil1: fixed
Spectre Teil2: irgenwie unklar

Intel i7:

In einen Supernode reicht man das PCID-Flag dann entsprechend durch:

Ubuntu ist leider noch etwas schläfrig… daher noch nichts im stable/production für Spectre: