Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers

[Alexander Bulekov]

On 200721 1444, Peter Maydell wrote:
> On Tue, 21 Jul 2020 at 14:21, Jason Wang <jasowang@redhat.com> wrote:
> > On 2020/7/21 下午8:31, Peter Maydell wrote:
> > > On Wed, 15 Jul 2020 at 09:36, Jason Wang <jasowang@redhat.com> wrote:
> > >> I think the point is to make DMA to MMIO work as real hardware.
> > > I wouldn't care to give a 100% guarantee that asking a real
> > > h/w device to DMA to itself didn't cause it to misbehave :-)
> > > It's more likely to happen-to-work because the DMA engine bit
> > > of a real h/w device is going to be decoupled somewhat from
> > > the respond-to-memory-transactions-for-registers logic, but
> > > it probably wasn't something the designers were actively
> > > thinking about either...
>
I searched around but couldn't find anything talking about this case for
real hardware. I also looked at some HDL code for FPGAs that do DMA, but
it seems most of the PCI DMA components are contained in proprietary
IPs, though maybe I'm missing something (I've never programmed
a DMA-capable FPGA).

> > I think some device want such peer to peer transactions:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/driver-api/pci/p2pdma.rst
> 
> That's a device DMAing to another device, not DMAing to *itself*
> (device-to-another-device DMA should work fine in QEMU). And only
> a very few devices will ever be sensible targets of the DMA --
> basically things like nvme that have a looks-like-memory area,
> or special cases like doorbell registers.
> 
> > > Yeah, this is the interesting part for QEMU. How should we
> > > structure devices that do DMA so that we can be sure that
> > > the device emulation at least doesn't crash? We could have
> > > a rule that all devices that do DMA must always postpone
> > > all of that DMA to a bottom-half, but that's a lot of
> > > refactoring of a lot of device code...
> >
> >
> > It looks to me the issue happens only for device with loopback
> 
> I think in principle we have a problem for any device that
> (a) has memory mapped registers and (b) does DMA reads
> whose address is guest-controlled. Loopback isn't a
> requirement -- if the guest programs, say, an RX descriptor
> base address to point at the device's own registers, you
> get exactly the same kind of unexpected-reentrancy.

Could this be something that we check for in the
pci_dma_* functions in hw/pci/pci.h? There we still have context about
the source device for the dma read/write and could, compare addr against
the device's PCI BARr's. Not sure about:
1.) How to do this without the overhead of convering the addr
to a MemoryRegion, which is normally done, once, at the flatview_write
stage.
2.) What to do if we catch such a DMA request? Quietly drop it?
3.) Non-PCI devices.

I think this still doesn't cover the even crazier case where:
CPU writes to DEV_A's MMIO
DEV_A writes to DEV_B's MMIO
DEV_B writes to DEV_A's MMIO
and neither DEV_A or DEV_B use BHs...

-Alex

> thanks
> -- PMM
>