Re: [PATCH] hw/virtio/virtio-mem: Prohibit unplugging when size <= requested_size

[Wei Chen]

> Please provide more information how this is supposed to work

We initially discovered that virtio-mem could be used by a malicious
agent to trigger the Rowhammer vulnerability and further achieve a VM
escape.

Simply speaking, Rowhammer is a DRAM vulnerability where frequent access
to a memory location might cause voltage leakage to adjacent locations,
effectively flipping bits in these locations. In other words, with
Rowhammer, an adversary can modify the data stored in the memory.

For a complete attack, an adversary needs to: a) determine which parts
of the memory are prone to bit flips, b) trick the system to store
important data on those parts of memory and c) trigger bit flips to
tamper important data.

Now, for an attacker who only has access to their VM but not to the
hypervisor, one important challenge among the three is b), i.e., to give
back the memory they determine as vulnerable to the hypervisor. This is
where the pitfall for virtio-mem lies: the attacker can modify the
virtio-mem driver in the VM's kernel and unplug memory proactively.

The current impl of virtio-mem in qemu does not check if it is valid for
the VM to unplug memory. Therefore, as is proved by our experiments,
this method works in practice.

> whether this is a purely theoretical case, and how relevant this is in
> practice.

In our design, on a host machine equipped with certain Intel processors
and inside a VM that a) has a passed-through PCI device, b) has a vIOMMU
and c) has a virtio-mem device, an attacker can force the EPT to use
pages that are prone to Rowhammer bit flips and thus modify the EPT to
gain read and write privileges to an arbitrary memory location.

Our efforts involved conducting end-to-end attacks on two separate
machines with the Core i3-10100 and the Xeon E2124 processors
respectively, and has achieved successful VM escapes.

> Further, what about virtio-balloon, which does not even support
> rejecting requests?

virtio-balloon does not work with device passthrough currently, so we
have yet to produce a feasible attack with it.

> I recall that that behavior was desired once the driver would support
> de-fragmenting unplugged memory blocks.

By "that behavior" do you mean to unplug memory when size <=
requested_size? I am not sure how that is to be implemented.

> Note that VIRTIO_MEM_REQ_UNPLUG_ALL would still always be allowed

That is true, but the attacker will want the capability to release a
specific sub-block.

In fact, a sub-block is still somewhat coarse, because most likely there
is only one page in a sub-block that contains potential bit flips. When
the attacker spawns EPTEs, they have to spawn enough to make sure the
target page is used to store the EPTEs.

A 2MB sub-block can store 2MB/4KB*512=262,144 EPTEs, equating to at
least 1GB of memory. In other words, the attack program exhausts 1GB of
memory just for the possibility that KVM uses the target page to store
EPTEs.


Best regards,
Wei Chen

On 2024/11/26 20:29, David Hildenbrand wrote:
> On 26.11.24 09:02, Wei Chen wrote:
> > A malicious guest can exploit virtio-mem to release memory back to the
> > hypervisor and attempt Rowhammer attacks.
>
> Please provide more information how this is supposed to work, whether 
> this is a purely theoretical case, and how relevant this is in practice.
>
> Because I am not sure how relevant and accurate this statement is, and 
> if any action is needed at all.
>
> Further, what about virtio-balloon, which does not even support 
> rejecting requests?
>
> The only case reasonable for
> > unplugging is when the size > requested_size.
>
> I recall that that behavior was desired once the driver would support 
> de-fragmenting unplugged memory blocks. I don't think drivers do that 
> today (would have to double-check the Windows one). The spec does not 
> document what is to happen in that case.
>
> Note that VIRTIO_MEM_REQ_UNPLUG_ALL would still always be allowed, so 
> this change would not cover all cases. VIRTIO_MEM_REQ_UNPLUG_ALL could 
> be ratelimited -- if there is a real issue here.
>
>
> > Signed-off-by: Wei Chen <weichenforschung@gmail.com>
> > Signed-off-by: Zhi Zhang <zzhangphd@gmail.com>
> > ---
> >   hw/virtio/virtio-mem.c | 4 ++++
> >   1 file changed, 4 insertions(+)
> >
> > diff --git a/hw/virtio/virtio-mem.c b/hw/virtio/virtio-mem.c
> > index 80ada89551..4ef67082a2 100644
> > --- a/hw/virtio/virtio-mem.c
> > +++ b/hw/virtio/virtio-mem.c
> > @@ -671,6 +671,10 @@ static int 
> > virtio_mem_state_change_request(VirtIOMEM *vmem, uint64_t gpa,
> >           return VIRTIO_MEM_RESP_NACK;
> >       }
> >   +    if (!plug && vmem->size <= vmem->requested_size) {
> > +        return VIRTIO_MEM_RESP_NACK;
> > +    }
> > +
> >       /* test if really all blocks are in the opposite state */
> >       if ((plug && !virtio_mem_is_range_unplugged(vmem, gpa, size)) ||
> >           (!plug && !virtio_mem_is_range_plugged(vmem, gpa, size))) {