[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Supexec/Super patch?
>>>>> ""Konrad" == "Konrad M Kokoszkiewicz" <draco@mi.com.pl> writes:
> OK, what about another way: implement a system call allowing to access
> (to read) vital GEMDOS variables, like p_cookie or hz_200, from any user
> process and prepare a whole MiNT distribution (like KGMD is) supporting
> it?
That's more or less what I was talking about all the time. But I think
we should have an own system call for each variable. Otherwise we get
problems with the return types (one is long, one is short, one is
pointer, one is time_t, etc.). This is also less vulnerable to changes
in the future. Probably we can group some variables that belong
together somehow.
> I realize it may take a while, but it may be worth doing, otherwise,
> if any user is able to do anything with the system resources using TOS
> calls, the Unik-like MiNT environment with access permissions etc doesn't
> make much sense.
That's exactly the point. A program should not be able to
1. read or modify memory not owned by it
2. interfere with other processes or threads without using the
appropriate communication mechanisms provided by the system
3. use resources it is not allowed to
Ok, 1. is not really possible without memory protection. So we won't
get a secure system on a 68000. But on versions supporting a (real)
MMU this is possible. But this implies that a program must not be
allowed to change it's own status or get direct access to system
resources. It has to use the mechanisms provided by the kernel, and no
abbreviations are allowed. So as a fact a program simply must not get
access to supervisor mode.
Bye,
Hartmut
+-------------------------+-----------------------------------------------+
| Hartmut Keller | Internet: keller@informatik.uni-stuttgart.de |
| Inst. fuer Informatik +-----------------------------------------------+
| Breitwiesenstr. 20-22 | "Home is where the heart lies - but when the |
| 70565 Stuttgart | heart lies, where is home?" (Marillion) |
+-------------------------+-----------------------------------------------+