On Thu, 6 Nov 2025 at 10:45, Jiri Slaby <[email protected]> wrote: > > On 06. 11. 25, 11:38, Peter Maydell wrote: > > On Thu, 6 Nov 2025 at 06:29, Jiri Slaby <[email protected]> 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 <[email protected]> > >> 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
