Re: [PATCH] hw/misc/edu: restrict dma access to dma buffer

[Peter Maydell <peter.maydell@linaro.org>]

On Thu, 6 Nov 2025 at 10:45, Jiri Slaby <jslaby@suse.cz> wrote:
>
> On 06. 11. 25, 11:38, Peter Maydell wrote:
> > On Thu, 6 Nov 2025 at 06:29, Jiri Slaby <jslaby@suse.cz> wrote:
> >>
> >> On 05. 11. 25, 13:18, Torin Carey wrote:
> >>> The EDU device doesn't enforce any bound checks on the addresses provided,
> >>> allowing users of the device to perform arbitrary reads and writes to QEMU's
> >>> address space.
> >>
> >> Hmm, it was the intention to crash qemu before:
> >> commit 7b608e5d6c1d61430e81cd5c71b0277b99b03f3a
> >> Author: Chris Friedt <chrisfriedt@gmail.com>
> >> Date:   Tue Oct 18 08:25:51 2022 -0400
> >>
> >>       hw: misc: edu: use qemu_log_mask instead of hw_error
> >>
> >>       Log a guest error instead of a hardware error when
> >>       the guest tries to DMA to / from an invalid address.
> >>
> >>
> >>
> >> As with a standard device when you program it badly. I don't understand
> >> why the commit changed it to log only and let the code to corrupt the
> >> memory?
> >
> > It's a PCI device. Unless something in the spec of
> > the device says "if you try to DMA outside this range
> > it will be ignored", then typically devices will let you
> > DMA anywhere in the address space. If the guest chooses
> > to program the device to DMA somewhere silly, that's its choice.
> >
> > Is there a spec for this device anywhere? If so, we should
> > follow that. If not, then it's a "make a best guess", and
> > "don't arbitrarily constrain DMA" is a reasonable guess.
>
> It's an educational, fictional device, there is of course no spec for that.

I think that for teaching purposes you would want a decent
spec for the device: there will be a steady stream of new
students who need to know how it works.

In fact I've just noticed we do have a spec, in docs/specs/edu.rst.
(It doesn't specify the behaviour if you attempt to DMA outside
the range it documents.)

> > The reason for the commit above is that devices should
> > not call hw_error() as that crashes QEMU itself.
>
> But that was exactly my intention. Students should see an immediate
> crash, not random, undebuggable (in the given class hours) writes
> somewhere. And crashing a qemu instance was an intended pun.

Sorry, your educational device doesn't get to break QEMU's
usual rules. (Eventually we might be able to get rid of
hw_error() altogether, though it's hardly a high priority.)
People debugging drivers can turn on the GUEST_ERROR logging
which should be a big clue.

Incidentally, restricting DMA to "4K starting at 0x40000"
makes the device not usable on all machine types -- there is
no guarantee that the machine even has any RAM there at all.

thanks
-- PMM