RE: [MiNT] Security again

[Jo-Even.Skarstein@gjensidige.no]

> -----Original Message-----
> From: Michael Schwingen [mailto:rincewind@discworld.dascon.de]
> Sent: Sunday, December 05, 1999 10:23 PM
> To: mint@fishpool.com
> Subject: Re: [MiNT] Security again
> 
> > > The current situation and the idea of a stable kernel are 
> even more
> > > concurrent
> > 
> > I can't agree.
> 
> Then please tell us why.
> 
> The current situation is this: *any* program can hook in to 
> the trap vector
> chain before MiNT, regardless if it was started before or 
> after MiNT. The
> proposed change would give MiNT some control over that 
> process, and it would

This assumes that you actually start to *use* this API, which is far from
likely. The current situation is that everybody *can* hook into traps, but
very few of them are actually started by MiNT. I would estimate that atleast
90% of the TSRs that bend vectors are started in the autofolder long before
MiNT. I have only one vector-bending application on my Falcon currently, and
that's N.AES. The rest (NVDI, Nova-VDI, HS-Modem, Freedom, Clocky and
BetaDOS) are started from the autofolder.

Don't get me wrong, I believe that TraPatch-like functionality is a great
idea, but IMO it makes much more sense in it's current form (a TSR started
early in the autofolder) than in the kernel. OK, many of the TSRs we use
today could be started by MiNT instead *if* they were patched, but do we
really want that? I agree with Frank, having this functionality (and even
support it with a GEMDOS-call) would probably just invite people to bend
vectors in applications and not just TSRs. And I really can't see the need
for such a call, as there's extremely little use of it. If the situation
arise that you really, really must bend vectors from your MiNT-application
(including TSRs), then there's nothing that prevents you from using TraPatch
or something similar.

I'm not concerned about security at all, as I find it highly unlikely that
anybody would find it worthwhile to hack my Falcon. What concerns me is
stability, and I can't see how that can be improved by promoting
vector-bending. As multitasking (MiNT and MagiC) is now considered the
minimum platform by most developers, vector-bending is becoming less and
less used. Let's not reverse this situation. Instead of trying to find new
ways to bend vectors, let's try to find ways to eliminate it. Here's a few
suggestions:

1. Remove HS-Modem and fpatch in favour of real device-drivers like Frank's
uart.xdd for the Milan.
2. Stop using MetaDOS for CD-ROM drivers, write device-drivers instead. I
believe the latest Spin! can use the SCSIDRV-API directly thus eliminating
the need for MetaDOS.
3. Let the various AES-developers agree on a common way to hook a
fileselector into the AES. IIRC only N.AES has an API for this currently,
although it's not documented.
4. A common dispatcher (something like TraPatch) could speed up the
AES/VDI-trap greatly.

OK, implementing this requires effort, but so does updating older TSRs to
use TraPatch (or similar functionality in the kernel). The reward would be
that very few TSRs (if any at all if you disregard the AES/VDI-replacements)
would have to bend any vectors. And those that does can use TraPatch.

Jo Even Skarstein