jcjgraf · HackerTrans

vor 9 Monatendiscuss

Yes, Xen is indeed protected thanks to using Dom0 for running the pendant of Linux's userspace hypervisor (QEMU, fircracker, etc.).This is because transitions to Dom0 lead to a branch predictor flush. See my other comment for more information. As you say, firecracker is equally affected by VMScape as QEMU is...

jcjgraf

vor 9 Monatendiscuss

Please see my other comment where I share more details about VMScape and why Xen is not affected. In short, it is because branch predictor state is flushed when transitioning to Dom0. Indeed, it has nothing to do with type of kernel... And yes, LLMs were at work. The "quote" in the article is not an actual quote...

jcjgraf

vor 9 Monatendiscuss

VMScape does not allow an attacker to read memory of Dom0 or the host. Dom0 is safe because branch predictor state is flushed when transitioning to Dom0, and the host is secured as it runs as supervisor, while VMScape only targets userspace. See my comment further up for more information.

jcjgraf

vor 9 Monatendiscuss

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.

jcjgraf

vor 9 Monatendiscuss

Author of the VMScape paper here.

It's great to see an article highlighting the impact of VMScape on Xen, especially since our paper [1] does not discuss Xen in detail (we only briefly mention it in the blog post [2]).

That said, the article unfortunately lacks technical precision. Some statements are vague, and "our quote" ("According to the ETH team") is misleading, as those are not our words. To be clear: VMScape is not a cross-VM attack. So please treat such summaries with caution.

Here are some clarifications:

The core issue lies in the hardware. On all AMD Zen CPUs, the branch prediction unit cannot natively distinguish between host user, guest-1 user, and guest-2 user domains (newer Intel CPUs can do to some extend). Supervisor domains (host or guest kernel) are protected by the CPU effectively disabling speculative execution in those domains. But because user domains share branch predictor state, execution in one can control speculation in another - the fundamental root of Spectre-BTI. To enforce isolation, predictors must be flushed (IBPB) whenever transitioning between such domains.

On Linux KVM, an IBPB is issued on guest-1 to guest-2 switches and on process switches. However, because a guest runs in the same process as its userspace hypervisor (e.g. QEMU, firecracker, etc), there is no isolation mechanism in place for this transition. VMScape exploits exactly this gap. The mitigation is to add an IBPB on guest to host userspace transitions.

Xen, while also running on the same flawed hardware, is not vulnerable to VMScape. But the reason is not (just) asynchronism. Asynchronism makes exploitation only harder. Instead, the key reason is that the equivalent of Linux's userspace hypervisor runs inside Dom0 on Xen, which is itself "treated like a guest". Because Xen already issues IBPBs between guest transitions, Dom0 is protected from DomU.

Assigning responsibility for vulnerabilities at the hardware–software boundary is inherently challenging and often depends on implicit assumptions about the threat model. VMScape introduces a novel threat model that had not been considered before. Consequently, the responsible entities concluded that the lack of host/guest branch predictor state isolation does not qualify as a hardware issue, since adequate mitigations, such as IBPB, are readily available, but insufficiently used by software.

[1] https://comsec-files.ethz.ch/papers/vmscape_sp26.pdf [2] https://comsec.ethz.ch/research/microarch/vmscape-exposing-a...

comments