[AtlasBarfed]

So this requires the two VMs to be sharing execution on a core? Or perhaps a shared cache? Or would it work across VMs "pinned" to different CPUs?

It's weird to me that cloud hosts aren't absolutely swimming in cores now, but with Intel struggling and AMD somewhat resting on its laurels, which it stupidly did in the Hector Ruiz days, nothing is pushing the envelope. In 2010, fifteen years ago, we had 12 core CPUs.

In 2010 we had a billion or so transistors. In 2020, we had 50 billion. In 2010 we were at 28nm, now we're at 3nm.

We should have 100x the CPUs on die now or more. a thousand x86 cores, god knows how many Arms, and god knows how much you could do with hi-low core counts.

Anyway, what I'm getting at is all of these vulnerabilities across process execution or VM execution could be moot: if the processes were isolated to a core or set of cores, and the VM isolated to its own dedicated branch predictors in its own cores. Then go ahead and do whatever tricks you want. Obviously you don't want hyper-threading.

[jcjgraf]

Indeed, victim (e.g. userspace hypervisor like QEMU, firecracker, etc) and attacker (e.g. malicious guest) need to run on the same core. But with VMScape this is always give, because a guest runs as the same process as its hypervisor. Before VMScape, developers only isolated different VMs, different processes and supervisor domains from malicious users. VMScape explits a novel threat model.

[pjmlp]

Modern Windows is already using two VMs as well, or even more if WSL is being used.

Hyper-V is a type 1 hypervisor, when enabled, which is required for many security measures in modern Windows, the first Windows instance is a privileged guest, just like with Xen.

Additionally anyone using WSL 2.0, is running another set of VMs alongside Windows, depending on how many flavours of Linux and containers are configured.