qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jason Wang
Subject: Re: [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers
Date: Tue, 21 Jul 2020 21:21:20 +0800
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0


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 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



For
e1000e and other networking devices we need make sure such DMA doesn't
break anything.
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

Simply git grep loopback in hw/net tells me we probably need only to audit dp8393x and rtl8139.

Qiang, want to help to audit those devices?

Thanks



thanks
-- PMM





reply via email to

[Prev in Thread] Current Thread [Next in Thread]