[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions
From: |
Peter Maydell |
Subject: |
Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions |
Date: |
Thu, 3 Sep 2020 14:58:19 +0100 |
On Thu, 3 Sep 2020 at 14:37, Laszlo Ersek <lersek@redhat.com> wrote:
> Peter mentions an approach at the end of
> <https://bugs.launchpad.net/qemu/+bug/1886362/comments/5> that I believe
> to understand, but -- according to him -- it seems too much work.
It also would only be effective for MMIO, not for qemu_irq lines...
> I don't think such chains work unto arbitrary depths on physical
> hardware either.
Real hardware by and large doesn't get designed with this kind
of DMA-to-self as a consideration either, but unfortunately it's
not really very useful as a model to base QEMU's behaviour on:
(1) real hardware is usually massively parallel, so the logic
that handles incoming MMIO is decoupled anyway from logic
that does outgoing DMA. (Arguably the "do all DMA in a
bottom-half" idea is kind of following the hardware design.)
Similarly simple "raise this outbound signal" logic just
works as an instantaneous action that causes the device on
the other end to change its state/do something parallel,
whereas for QEMU we need to actually call some code in the
device on the other end and so we serialize this stuff,
sandwiching a bit of "device B code" in the middle of a
run of "device A code". So a lot more of this stuff "just
happens to work" on h/w than we get with QEMU.
(2) if software running on real h/w does do something silly with
programming a device to DMA to itself then the worst case is
generally that they manage to wedge that device (or the whole
machine, if you're really unlucky), in which case the response
is "don't do that then". There isn't the same "guest code
can escape the VM" security boundary that QEMU needs to guard
against [*].
[*] I do wonder about hardware-device-passthrough setups; I
don't think I would care to pass through an arbitrary device
to an untrusted guest...
thanks
-- PMM
- [PATCH 08/12] docs/devel/loads-stores: Add regexp for DMA functions, (continued)
- [RFC PATCH 12/12] dma: Assert when device writes to indirect memory (such MMIO regions), Philippe Mathieu-Daudé, 2020/09/03
- Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions, Laszlo Ersek, 2020/09/03
- Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions,
Peter Maydell <=
- Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions, Edgar E. Iglesias, 2020/09/03
- Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions, Paolo Bonzini, 2020/09/03
- Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions, Edgar E. Iglesias, 2020/09/03
- Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions, Paolo Bonzini, 2020/09/03
- Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions, Edgar E. Iglesias, 2020/09/03
- Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions, Jason Wang, 2020/09/03
Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions, Li Qiang, 2020/09/04
Re: [RFC PATCH 00/12] hw: Forbid DMA write accesses to MMIO regions, Stefan Hajnoczi, 2020/09/09