[MiNT] Security again

[Joerg_Westheide@su.maus.de (Jörg Westheide)]

Hi Jo!

JE>Then why not just use the TSR under MiNT as well??
Oh, I will not hinder you ;-)
But I think MiNT can benefit from knowldege which TSR bends which vector

JE>Who has said anything about denying vector-bending?
Frank? ;-)
If you don't want to deny it, why don't you want to improve (not promote!)
it?

JE>It certainly did,
OK, right, no information is too not quite correct

JE>but there will always be cases where somebody feels that vector-bending
JE>is the only solution
And possibly he's right with that.
But besides that the problem is that most people write their programs not
only for MiNT (well, in most cases the opposite seems to be true) and the XDD
and XFS interfaces are MiNT only

JE>I'm 99% sure that somebody eventually will find a need to circumvent
JE>TraPatch too.
I know the vulnerable spots of TraPatch.
One is the overhead to hook into a single function. For some few functions
this doesn't matter, but if you want to hook in many or all functions it's
more simple for the programmer to make one handler (at least they think so)

JE>The most serious problem with TSRs and stability (apart from bugs in
JE>the TSR itself) is that the TSR can be damaged by other processes
JE>writing to it's memory-space. XDDs are under complete control of the
JE>kernel. You are allocated kernel-memory.
I think it's possible to protect the TraPatch TSRs too.

JE>The interface between the "TSR" and user-application (if you have such
JE>a thing) goes through proper GEMDOS-calls and not some cookie-based
JE>shared memory scheme.
With a little extension to the TraPatch interface there will be no need for
the cookies anymore. Every call to functions of the TSR could be made through
GEMDOS calls

Bye

                Joerg