Re: [MiNT] Security again

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

I'd like to bring up a thread that died a couple of weeks ago.
Like many other threads recently it became a bit agitated, so I've taken
the liberty to summarize it.

This was about the addition of some kind of TraPatch like functionality to
the kernel. TraPatch is a TSR (by Joerg, IIRC) that helps reduce the,
unfortunately, otherwise unavoidable TRAP-chains by making it possible to
hook onto individual function codes.

Apparently an experimental implementation was done of TraPatch for the
MiNT kernel. This was later axed for somewhat unclear reasons.
One reason given on the thread was that one of the kernel developers
(no names here ;-) didn't like the possibility that programs hook into
GEMDOS traps/functions.


Now, I agree completely that it's generally a very bad idea to hook into
OS functions. Unfortunately, the design of our OS makes it necessary to do
so for many things that people consider useful. It's also a fact that most
people _have_ quite a few programs in their AUTO-folders that do just that.

So, outlawing TRAP-hooking is not really an option. This leaves the current
situation where a system call can easily have to pass through four or five
layers of code before reaching it's destination (I don't use all that many
AUTO-folder programs, but still reach such numbers).

The reason why everyone does their own TRAP-hooks is of course that there
is no standard way of dealing with this. Most of these programs are really
only interested in one or a few functions, so they would really benefit
from a 'master hook'.
Naturally, TraPatch in it's current form can be used. Most people have never
heard of it, however, and since it's an optional extra, very few programs
use it (the authors in question may never have heard of it either).

Including something like TraPatch in the kernel would make it immediately
available for everyone running MiNT. Hopefully, that would result in more
programs using it (instead of direct hooking (I certainly wouldn't want to
promote hooking in the first place ;-)).
In many cases it is even be possible to 'retro-fit' support for it into old 
TSRs (or those were the author isn't interested in doing anything about it).
Another important thing is that the kernel would get some kind of control
over what goes on. The current TRAP-hooking is obviously entirely outside
its 'jurisdiction'.

Note that I'm not advocating adding the actual TraPatch API to the kernel,
only something with similar functionality.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johan@rand.thn.htu.se
                        | so hard to do |  WWW/ftp:  rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (MGIFv5, QLem, BAD MOOD)