Es ist Wochenende und (je nach wie man will) spät (oder früh) am Abend , daher sorry, falls ich etwas nicht blicke. Aber Deine Antwort enhält einige Wiedersprüche. Vermutlich meintest Du mit "Und das innerhalb der VM" eher "von der VM hraus". Ja der Hypervisor ist auf dem Host auch nur ein Programm. Aber nach meinem Verständnis, auf Grund der Technik, dennoch vom Host isoliert. Ich verstehe, worauf hinaus willst.
Ja, du hast recht, die beiden Sätze sind nicht richtig... Sie hätten lauten sollen: "Nicht also nur IN der VM, sondern potentiell im kompletten Userspace des Hosts... Und das
von innerhalb der VM
herraus"
-> sollte meinen, du hast potentiell die Möglichkeit, aus der VM auszubrechen - da der Spaß IN der VM auch nur im Userspace läuft.
Konkret in Produkten, du kannst mit Typ 1 oder 2 Hypervisor bspw. relativ sicher gehen, dass du aus einer VM nicht auf den Kernelspace des Hosts und auch nicht auf den den Kernelspace der VMs kommst. Weil das ganze in Hardware gelöst wird.
Bei einer Software-Virtualisierung, bspw. einem Emulator oder bei der Arbeit mit virtuellen CPUs ist das hingegen wiederum potentiell sogar möglich. Da hier der Hardwareschutzt nicht greift und auch der Meltdown fix nicht hilft. Letzteres zumindest nicht um zwischen den VMs zu schützen. VM 1 hätte potentiell Zugriff auf VM 2 Kernelspace via Spectre an dem Punkt, wo die Daten in den Speicher geladen wurden.
Am Ende lässt sich das aber eher schwer beschreiben, da so oder so konkret gewusst werden muss, was für Daten da wo stehen um was abgreifen zu können. Der Spaß setzt auf spekulative Ausführung von Code - gefolgt von Zeitmessungen für den Zugriff. Es ist alles weit entfernt von einem simplen Laden einer Speicheradresse... Der Aufwand ist ziemlich enorm.
Aber die Antwort lasse ich so nicht gelten. Ich sehe den Userspace der VM von dem des Host isoliert, daher greift Spectre imo nicht vom Userspace der VM auf den Userspace des Host. Anderenfalls, bitte um valide Erklärung.
Nein, Spectre macht keinen Unterschied um welchen Speicher es sich handelt. Du kannst via Spectre nicht vom Userspace auf den Kernelspace zugreifen, denn das wäre dann Meltdown - Kernalspace Access. Spectre heist Userspace. Welche Daten ist dabei nicht entscheidend. Nur eben nicht Kernelspace. Und damit potentiell aus der VM herraus auf einen Datenbestand vom Host (oder auch einer anderen VM)
Problem dabei nur (was das ganze so unwahrscheinlich macht - vor allem mit VMs), als Angreifer musst du ziemlich genau wissen, wo die Daten stehen. Und der Angriff ist noch dazu recht lahm. Also mal so eben auf die Schnelle alles auslesen ist nicht... Wahrscheinlich hat sich über die Zeit der Bestand schon geändert und du bekommst da gar nichts verwertbares raus.
Das PoC bis jetzt zeigte ja bspw. Zugriffe auf Passwörter im Browser gespeichert - was vergleichbar einfach zu erreichen ist. Da du vor allem bei OpenSource Geschichten oder durch Analyse der Software auch ohne Quellcode da an Infos kommst. Wer den Code versteht weis genau was das Ding macht... Und kann entsprechend angreifen. Wie eben der Dieb, der genau weis, wann du zur Arbeit gehst früh und nicht einfach auf gut glück mal klopfen geht ob da vllt niemand Zuhause ist. letzteres wäre, wenn du versuchen würdest aus der VM herraus auf andere Speicherbereiche zuzugreifen. (VM übergreifend/Userspace des Hosts)
Aber egal, gegen Meltdown brauchst du keine VM - weil die Meltdown-Fixes auf Hostebene dies schon verhindern. Gegen Spectre hilft dir die VM auch nur bedingt - sie machts potentiell vielleicht wieder unwahrscheinlicher, lösbar ist das aber so nicht. Wie auch native auf dem Blech nicht...
Es gibt nicht den Bug, sondern 4 Bugs 1=Meltdown, 2 bis 4 = die 3 Spectre Varianten. Du beziehst Dich auf 1 und der ist durch ein OS Update gefixt. Ich will nicht sagen, dass ich ggf. nicht unrecht habe. Aber das ist keine valide Antwort, um mich zu wiederlegen.
Wieso vier?
Es sind drei...
Spectre v1/Sectre v2 und "Spectre v3" aka Meltdown.
Man könnte sagen, Meltdown ist Spectre mit Kernelspace access. Die Idee dahinter ist nicht wirklich anders. Aber Zugriff auf höher priviligierte Speicherbereiche wird perse von der CPU normal verhindert. Bei eigentlich allen modernen Architekturen. Dummerweise lässt sich der Schutz bei Intel umgehen, da die Zugirffsverletztung zu spät auslöst und man vorher schon Daten abfingern kann.
Spectre wirft aber keine Verletzung. Spekulative Codeausführung wirft diese so nicht. Getätigt werden die Ausführungen aber halt trotzdem - und durch Zeitmessungen bekommt man das auch abgefingert wie belegt wurde.
AMD -> Ich sehe zwischen dem Pinken (ungefixt) und dem grauen (AMD-Retpoline) Balken so gut wie keinen Performanceunterschied, außer für den Threadripper 1950X im "Flexible IO"-Test
Intel -> Ich sehe durch den Intel-Retpoline-Fix (hellgrün) gegenüber dem Kernel ohne Fix (blau) in einigen Benchmarks ca. 10% Leistungsverlust, und beim Kopieren von Dateien sogar ca. 40% (wie 50% sah es aus, als ich beim Aussteigen aus der U-Bahn hektisch noch den Beitrag von oben abgesendet habe)
Edit: Man sieht hier auch, dass AMD und Intel-CPUs jeweils verschiedene Patches brauchen - bei AMD reicht ein "Minimal-Retpoline" offensichtlich aus, während Intel das Vollprogramm braucht, und Intel Kaby- und Skylake-CPUs zusätzlich noch RETPOLINE_UNDERFLOW.
Du hast meine Fragen nicht verstanden... Du verlinkst nen Artikel wo der AMD Wert überhaupt nicht drin ist. (das war Frage 1)
Und du erzählst von nur halb so viel Kopierspeed bei Frage 2, obwohl das überhaupt nicht gemessen wurde in dem Artikel.
Schau dir doch bitte einfach mal an, was der FS-Mark Wert überhaupt ist...
.
... Der Rest geht ja...
