Re: [MiNT] Security again

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

On Fri, Dec 03, 1999 at 02:10:37PM +0100, Frank Naumann wrote:
> Ok, so we focus on resident system tools that are at the moment started
> before MiNT.
> 
> > From the beginning (of TraPatch as well as my letters on the subject), the
> > major reasons for proposing a kernel addition has been to improve the
> > efficiency of system calls and to provide a 'standardized' interface for this.
> 
> As MiNT have full control over it's system calls too I don't see why it
> improve the efficiency of system calls.

No, you don't. You may well end up with a situation where the trap#1-vector
points to a lot of TSRs, and the last of them actually jumps into the MiNT
kernel. I would not call this efficient in any way.

And yes, this is also true if all those TSRs are started in the auto folder
before MiNT, since some of them will move their way back up to the beginning
of the trap chain, when they detect that someone else (eg. MiNT) has
hooked before them.

> I see now that you mean. But in this case I see no enhancement
> (control enhancement, stability enhancement).

 - Performance enhancement: lower syscall latency (from trap instruction
   until entering kernel code)

 - Control enhancement: The kernel can control what functions TSRs may hook
   into. Currently, a TSR can steal any Gemdos function. Access protcetion
   just as with other priviledges system calls will prevent non-root
   applications from hooking into vectors if you want a safe system.

The performance gain alone would be enough benefit in my eyes to implement
such a scheme, since it has no negative side-effects when compared with the
current situation (at least you have not named any until now).

> At the moement are all tools that are loaded before MiNT part of the kern.
> If you load it after MiNT it must be explicitly hacked into the kern
> area.
> 
> If you crash inside the kern there is mostly no way of restauration ->
> kernel panic.
> 
> So what control do you mean?

A TSR which is started after the kernel does not have to be in kernel space.
It may have its own address space, provided some global mapping is in action
which allows access to everything it needs. You could even protect the MiNT
kernel space from accesses from these TSRs.

The kernel can detect that eg. a bus error occured inside a TSR, and can
terminate that TSR *and unhook* it from the system vector tables which the
kernel maintains. With the current scheme, you can only crash the whole
system, since the bus error seemd to happen somewhere in the kernel, and you
can't clean up.

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