Re: [MiNT] fVDI issues

["Konrad Kokoszkiewicz" <draco@obta.uw.edu.pl>]

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

This is mostly not necessary, if the caller passes wrong pointer, it will
receive bus error signal. This is the theory, since we all know that there
are unprotected areas :)

>>> 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)?

Well, any writes/reads done by the CPU are controlled by the PMMU, right? So
if the PMMU disallows the access, the program, that does the access,
receives bus error signal. This is why you cannot Fread() a file and
overwrite another process (other than the caller) this way.

But of course there's a question of DMA. In this case, unfortunately, the
Fread() *may* succeed.

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

As far as I know, the kernel itself is currently unprotected at all.

--
CVV
Konrad M.Kokoszkiewicz, http://draco.atari.org

** Ea natura multitudinis est, aut seruit humiliter, aut superbe dominatur.
** Taka to juz natura pospólstwa, albo sluzalczo sie plaszczy,
** albo bezczelnie sie panoszy. (T. Liuius XXIV, 25).