Jason Wang <jasow...@redhat.com> 于2020年7月21日周二 下午9:21写道: > > > On 2020/7/21 下午8:31, Peter Maydell wrote: > > On Wed, 15 Jul 2020 at 09:36, Jason Wang <jasow...@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
IMO I think this is not related-loopback. It happens when the guest write the MMIO address to the device's DMA-related registers. The one we see UAF occurs in loopback device because the same structure uses in re-entry. But we can't say there are no issue for non-loopback device. > > 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? No problem. Once I finish the e1000e patch I will try to audit those and also try to audit some no-loopback device re-entry issue. Thanks, Li Qiang > > Thanks > > > > > > thanks > > -- PMM > > >