Re: [PATCH v10 0/8] memory: prevent dma-reentracy issues

[Alexander Bulekov]

On 230427 1710, Alexander Bulekov wrote:

<snip>
> These patches aim to solve two types of DMA-reentrancy issues:
> 
> 1.) mmio -> dma -> mmio case
> To solve this, we track whether the device is engaged in io by
> checking/setting a reentrancy-guard within APIs used for MMIO access.
> 
> 2.) bh -> dma write -> mmio case
> This case is trickier, since we dont have a generic way to associate a
> bh with the underlying Device/DeviceState. Thus, this version allows a
> device to associate a reentrancy-guard with a bh, when creating it.
> (Instead of calling qemu_bh_new, you call qemu_bh_new_guarded)
<snip>

Later on there was also a guard added by Akihiko Odaki for
network-backends.
7d0fefdf81f: net: Provide MemReentrancyGuard * to qemu_new_nic()

Recently a talk came out about re-entrancy bugs in qemu
(unfortuantely I could not find a non-video version of the slides):
https://www.youtube.com/watch?v=wL3LK9Dp4os

The talk gives an overview of these bugs and also demonstrates how they
can be used for VM escapes. It lists the following vectors:
 1. MMIO
 2. Bottom-Halves
 3. Netqueues
 4. IOEventfd
 5. Timers

The first three should be covered by the current defenses. However,
afaik IOEventfds and Timers are still unprotected. The talk demonstates
an attack via IOEventFd, but not one with timers. In any case, it might
make sense to revist the guard to ensure that we are covering all types
of code that perform DMA.