On 06. 11. 25, 11:45, Jiri Slaby 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.
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.
Which effectively translates the intent into: either we crash again
(revert the commit above), or we only log a warning (is it by default
logged at all?), but won't corrupt memory = no write happens.
thanks,
--
js
suse labs
