All the mail mirrored from lore.kernel.org
 help / color / mirror / Atom feed
From: Li Qiang <liq3ea@gmail.com>
To: Jason Wang <jasowang@redhat.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
	Bug 1886362 <1886362@bugs.launchpad.net>,
	Qemu Developers <qemu-devel@nongnu.org>,
	Paolo Bonzini <pbonzini@redhat.com>
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:46:11 +0800	[thread overview]
Message-ID: <CAKXe6SJvrTx=X2kQk6cKOwHczzTM0nocCj22m1eQaNtw-9yOuQ@mail.gmail.com> (raw)
In-Reply-To: <28d42c0f-99eb-a9c1-e3fc-98f11ee686ab@redhat.com>

Jason Wang <jasowang@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 <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

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


  parent reply	other threads:[~2020-07-21 13:47 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-06  2:44 [Bug 1886362] [NEW] Heap use-after-free in lduw_he_p through e1000e_write_to_rx_buffers Alexander Bulekov
2020-07-07  4:52 ` [Bug 1886362] " Philippe Mathieu-Daudé
2020-07-09 15:51 ` [Bug 1886362] [NEW] " Li Qiang
2020-07-09 17:36   ` Paolo Bonzini
2020-07-10 10:37     ` Li Qiang
2020-07-14  8:56       ` Jason Wang
2020-07-14  8:56         ` Jason Wang
2020-07-14 10:48         ` Li Qiang
2020-07-15  8:35           ` Jason Wang
2020-07-15  8:35             ` Jason Wang
2020-07-21 12:31             ` Peter Maydell
2020-07-21 12:31               ` Peter Maydell
2020-07-21 13:21               ` Jason Wang
2020-07-21 13:21                 ` Jason Wang
2020-07-21 13:44                 ` Peter Maydell
2020-07-21 13:44                   ` Peter Maydell
2020-07-21 14:37                   ` Alexander Bulekov
2020-07-21 14:37                     ` Alexander Bulekov
2020-07-22  3:25                   ` Jason Wang
2020-07-22  3:25                     ` Jason Wang
2020-07-21 13:46                 ` Li Qiang [this message]
2020-07-22  3:27                   ` Jason Wang
2020-07-22  3:27                     ` Jason Wang
2020-07-21 12:14 ` [Bug 1886362] " P J P
2021-05-26 14:34 ` Thomas Huth
2021-06-14 23:40 ` Alexander Bulekov
2021-06-15 18:19 ` Thomas Huth

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKXe6SJvrTx=X2kQk6cKOwHczzTM0nocCj22m1eQaNtw-9yOuQ@mail.gmail.com' \
    --to=liq3ea@gmail.com \
    --cc=1886362@bugs.launchpad.net \
    --cc=jasowang@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.