Re: [MiNT] fVDI issues

[Johan Klockars <rand@cd.chalmers.se>]

> > Does MiNT currently do anything about pointers passed to system calls
> > under memory protection, by the way?
>
> What, for example?

Somehow checking that they point to memory owned by the calling process
(and that the operation in question will not access beyond the owned block).

> > Or will for example an Fread to
> > memory not owned by the calling process succeed?
>
> No, it won't (the MMU disallows the access).

Hmm. Are you saying that the kernel/driver (which is responsible for doing
the Fread, after all) is constrained to writing to memory owned by the
calling process (and that DMA is never used to write directly to the
specified buffer)?
That can't be right, or the kernel would not be able to update its own
internal variables, or use the stack. And if it can do that, what's
stopping the application from passing an address of one of those places
to its Fread?

I suppose you could set things up so that the kernel/driver could only
access its own memory and that of the calling process, but then you'd
have some trouble with operations that don't complete immediately
(and it still wouldn't stop the Fread from destroying kernel data).

On some other operating systems I've used, part of the problem is solved
by the virtual addressing, where all process addresses need to be converted
to something usable by the kernel, anyway. And/or by using special functions
to copy from kernel buffers to user space buffers.

AFAICT from the MiNT sources, the device drivers are passed the buffer
pointers directly, without any MMU trickery going on.
But I might be missing something.

> > Actually, it would make sense to make parts of the VDI actually
> > execute
> > in user mode. It's unfortunate that we're stuck with the Trap #2.
>
> Yes, the same for the AES. Ideally, the AES should be a bunch of shared
> libraries executing completely in user mode, plus one screen manager
> process, perhaps. This would solve memory access problems to a great extent,
> I suppose.

Yes.
That's how fVDI was supposed to work under the Fenix OS, incidentally.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |
                        | so hard to do |  WWW:      http://www.klockars.net
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)