text: Analyse und Erklärung Meltdown und Spectre Sicherheitsproblemen | Proact Blog
  Sie sind hier: Home / Analyse und Erklärung zu den Meltdown und Spectre Sicherheitsproblemen
  Das Bild zeigt die Sicht auf RAM ohne die Verwendung von "Virtual Memory". Jeder Prozess hat vollständige Sicht auf alles. Wenn also jetzt Prozess1 (Speicherbereich 0x50000000 bis 0x8FFFFFFF) auf eine Adresse außerhalb dieses Bereich zugreifen will, dann kann er das einfach tun, da die Adressen bekannt sind und die Speicherbereiche sichtbar sind.
  Reg01 := 23 + 42 Reg02 := Reg01 * 17
  Reg01 := 10 ; LOOPSTART # Sprungmarke # Schleifenblock # mehrere Instruktionen Reg01 := Reg01 - 1 BNEZ Reg01, LOOPSTART # Branch if Not Equal to Zero; falls Reg01 nicht 0 ist, springe zu LOOPSTART # falls Reg01 0 war, geht es hier weiter
  Reg01 := Reg01 - 1
  Update 12.1.2018, 10:44: Cisco, NetApp Advisories
  Danke für den sehr guten Beitrag – deutlich besser als was in der normalen Presse zu lesen ist.
  nach meinem Verständnis (und so steht es auch explizit im vmware bulletin) sind mit spectre sehr wohl Hypervisorausbrüche möglich. Zumindest nenne ich das so, wenn eine Gast VM lesend auf eine andere VM zugreifen kann.
  6. Januar 2018 at 15:28
  Hallo und Danke für das Feedback. Ich habe mir das VMware Bulletin nochmal genau durchgelesen und daraufhin weiter recherchiert: Du hast recht!
  Ich habe die Artikel entsprechend angepasst.
  Mein Fehler beruhte darauf, dass ich irgendwie implizit angenommen hatte, dass für den verdeckten Kanal eine Kommunikation zwischen dem betroffenen Kernel und dem Angreifer notwendig ist, aber genau das ist es ja, was der Seitenkanal aushebelt. Die Research Papers erwähnen auch zu keine Zeitpunkt irgendwo VMs, so dass mir der Fehler nicht aufgefallen ist, weil da nur von Prozessen und "dem Kernel" die Rede ist.
  Kleines Addendum: "Hypervisorausbruch" würde ich ebenfalls in so einem Kontext immer so weit wie möglich fassen. Kann der Angriff irgendwas außerhalb seiner eigenen VM bewirken, was er nicht sollte? Falls ja, dann ist das ein Hypervisorausbruch. Hier mit unnötig eng gefassten Begriffen zu hantieren wäre IMO unredlich.
  27. Januar 2018 at 09:09
  Super Artikel. Sehr schön und verständlich erklärt
  VSAN ESXi 6 Automatisierung teamix OnCommand Horizon Workspace Update Debian Monitoring Security Hacking Ontap itsa 7-mode Citrix Netzwerk VMware vSphere 6 junos VMware vSphere 5.5 Performance Juniper VMware NSX 7mode Clustered Data ONTAP NetApp storage Upgrade vCenter 6 Linux-Schulungen vSphere 6 Backup XenApp VMware Microsoft Horizon Firewall Linux Virtualisierung IT security FlexVault VMware vSphere Ransomware VMware vCenter Server Trend Micro Deep Security