Re: Just my 2 penny worth..

[Michael Schwingen <rincewind@tubul.dascon.de>]

On Sat, Jun 27, 1998 at 12:12:17PM +0100, Stephen Usher wrote:
> 
> I'm afraid that you missed the point here.. this is a different thread from
> the hard disk driver problem, this is the program/system protection problem.

And in what way does having an integrated disk driver improve the security?

> I just chose a common use for DMA, it could just as well been an example of
> two programs trying to use DMA to the sound system on the TT. The point is
> that in a protected environment nothing but the kernel should have direct
> access to the hardware.. and in a full virtual memory environment only the
> kernel knows where the memory the program is using actually IS anyway, so it
> HAS to do the I/O for the process so as to translate the virtual address to
> the real one.

Wrong.

First, no user program should do direct hardware accesses - with a PMMU,
this can easily be disables.

If a user program uses an OS function to get DMA sound running, the kernel
can easily detect that the second program is trying to access a resource
that is not available and either give back an error code ('busy') or block
the process.

And the kernel does know about virtual and physical addresses, so it can
easily translate them before passing them down to an existing low-level
driver - that is exactly what Outside does to make harddisk accesses working
although using virtual addresses.

> And on the subject of using the old disk drivers.. if the system has
> basically been re-initialised with a fully virtual addressing system, the
> old drivers will not be able to interact with the new programs trying to
> access them as the new programs would be passing virtual addresses and
> wouldn't have direct access to the driver anyway as it would not appear in
> their memory map anyway.

Programs will not be passing any addresses to the disk driver - because
programs are not supposed to access the disk driver, bypassing the
filesystem. Programs call the kernel to get something done, and the kernel
calls the driver, and can easily translate when necessary.

> other than by the kernel forwarding on the requests. Remember, by this time,
> all you know about TOS memory management has totally gone out of the window,
> you're in a totally different mode of operation, ALL programs but the OS are
> seeing an illusion of what the system state is.

Why?

We can simply keep the TOS memory model - at least the addresses for OS ROM
and the hardware ports can be mapped 1:1 without losing flexibility - you
can virtualize them nevertheless, if you need to.

As the driver is part of the OS, it would probably run in super mode, anyway
- and the super PMMU mapping could allow access to the hardware. A driver
which is built-in to the kernel would need the same privileges, so this does
not weaken security.

> Maybe, but a user program can always subvert this by going straight for the
> hardware and doing all its disk access directly.

But this is neither the fault of the disk driver, nor of the defined
interface - it's a lack of IO protection. If you switch MiNT to secure mode,
the program can't switch to super mode anymore, and thus can't access the
hardware directly.

cu
Michael
-- 
Michael Schwingen, Ahornstrasse 36, 52074 Aachen