Re: [MiNT] Security again

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

> > _some_ control over this is better than _none_.
> 
> I understand what you mean and what is your intention.

Good.

> > We _can't_ forbid this, or a significant portion of Atari software will
> > stop working.
> 
> What software do you mean?

Many GEM applications (granted, I've not tried all that many myself, but
there's little reason to believe that I've run into the worst ones).
There are lots of these that install their own vector handlers. Mostly,
of course, for things like divide by zero, but also bus/address error and
some interrupts.

The point is, they _do_ these things. Often, in my experience, not even
bothering to use Setexc().
(These things have caused me lots of trouble over the years when debugging
 XaAES and fVDI.)

> > In any case, the TRAP-chains are mainly an 'AUTO-folder' problem. I'm not
> > focusing on what applications do later here.
> 
> Ok, so we focus on resident system tools that are at the moment started
> before MiNT.

Yes, that's my main intention.

> As MiNT have full control over it's system calls too I don't see why it
> improve the efficiency of system calls.

The point is that everything that hooks into the TRAP-chains somehow has
to know if a specific call was what they were interested in. So, they all
include a sequence of instructions to check for this. If they don't find
anything they like, the call is sent on to the next one.

If instead there was a centralized 'dispatcher' (such as TraPatch) all
this could be avoided. Sure, in some cases there could still be collisions
over a specific call, but it would be much less common.

Whether the chain occurs before of after the MiNT entry isn't very
relevant when it comes to efficiency (assuming that the 'post-chain' is
something that MiNT calls itself).

Also, this TraPatch-like functionality was supposed to be available for
normal TOS and MagiC as well. TraPatch itself already is, of course, but
a new API that fits as well as possible into MiNT would much be preferable.
Such an API could, for example, include the 'call vector in user mode'
functionality I mentioned earlier.

> > Frank refuses to see that I'm _not_ talking about application-level
> > redirection here.
> 
> I see now that you mean. But in this case I see no enhancement
> (control enhancement, stability enhancement).

I've always said that the improvement in those areas would be minor.

MiNT would know what specific calls were 'patched', which could potentially
be useful.
More importantly, it would know who had patched them, so if such a program
crashed, for example, it could be unhooked again (an AUTO program crashing
during startup, after installing its vectors (not a very nice thing to do,
admittedly), for example).
Also, something patched in via TraPatch wouldn't need XBRA, so there would
be no such links for anyone else to need access to.
AFAICS, it could eventually even be possible to use separate address spaces
for separate 'hookees', since the kernel would know who they were and would
call them directly.

> At the moement are all tools that are loaded before MiNT part of the kern.

Yes, and I would feel a little better if MiNT had some control over them.
Sure, that control doesn't amount to a whole lot.

> If you load it after MiNT it must be explicitly hacked into the kern
> area.

Do you mean something other than 'Super(), modify vectors, Super()' here?
That is of course rather explicit, but not terribly uncommon.

Or are you talking about memory protection?

> If you crash inside the kern there is mostly no way of restauration ->
> kernel panic.

Naturally.
Hopefully things will be better with Fenix, where the kernel only does what
it has to, leaving the rest for 'servers'.

> So what control do you mean?

Not much, but see above.
This has always been a relatively minor point.

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