Re: [hatari-devel] Disk driver memory access checks |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Disk driver memory access checks
- From: Uwe Seimet <Uwe.Seimet@xxxxxxxxx>
- Date: Sat, 13 Oct 2018 18:39:43 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1539448783; s=strato-dkim-0002; d=seimet.de; h=In-Reply-To:References:Message-ID:Subject:To:From:Date: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=YBD0Cps2yNu6I9HEej77pu9yhafwKoRYmUKz9Iwr+OU=; b=T/oLXsR9wtlvm5lVFqDEUOaEgZ2owZUeuR3D6LlpYUAnzu4JtoHQQ1bOHVixEMvhoc hGhQkGEqxJFXQLZLtmNxDbb635o1+USqNITbsgnGVYIqz4gxHu6A5HS5ggnks5FeoayA THFIsUGPbrrkiEJngHhoeNqOH+jRA+KJTqLudX484Cw0NsNDg728sp8jfWsmmJBaXUMk n+i1+Am0EODrzl/z+YUGQ+KoxCCpdYZe3vAA+m8fbsgGmjIPY/CTVLcUE00NC7IUc6+N 74eQ21alGicWym7P0C8cGCiI/1gvEgiPK9cMd3teYUzVROrekX6HPbXVyJnCE+ThNp6X 6GQg==
Also consider this: If I try to read data from IDE/ACSI/SCSI, where the device
is mapped to a device file /dev/sd*, to a ROM area, a real Atari will crash. At
least I assume so, because I'm not aware of any hard disk driver that would
prevent this and just abort the transfer.
Now assume that the same device file is accessed not via /dev/sd* but by
nf_scsidrv. In this case the actual device is the same, but the device file
is /dev/sg*. For the caller of the SCSI Driver (or the hard disk/CD-ROM
etc. driver) this is transparent, i.e. the caller does not know how the
device is mapped. Would you expect the same to happen in both cases when
trying to load data into ROM, or would you expect a different behavior?
> Hi,
>
> > * should not be able to read ROM file from disk and overwrite ROM memory
> > area (as that's not writable on real device).
>
> Sure, but on a real system, it's not the device layer preventing that.
> If on a real Atari I read data from floppy or hard disk and provide a
> ROM address, the device layer will not prevent me from doing this. The
> system will crash instead, for instance, during the transfer.
> That's why I'm wondering what the most compatible approach is.
>
> Best regards
>
> Uwe
>
>