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

[Jiri Slaby <jslaby@suse.cz>]

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