Re: [MiNT] Security again

["Anthony Jacques" <AnthonyJ@btinternet.com>]

Note that I am not commenting on TraPatch as I havent seen the API of that,
or how it is implemented... lets leave that out of this discussion for now,
and talk about the concept...

> > FN>The idea of TraPatch and the idea of a stable kernel are concurrent.
> > The current situation and the idea of a stable kernel are even more
> > concurrent
>
> I can't agree.

I agree with Johan and Joerg - at the moment, anything can hook into the
traps and call ptermres and sit there stealing system calls, and cycles
every time any system call is made.

There are many many examples of applications that do this, ranging from
Atari provided programs such as SAM, through extremely common utils like
Freedom, NVDI, VidelInside, WDialog, various bug-fixes, and many other
auto-folder applications.

The concept of Auto folder TSR's is supported by MiNT (it even explicitly
starts them) for the reason that they are something that many Atari users
will not wish to use an OS where they cannot use the tools/bugfixes that
they are used to. If the concept of Auto-folder TSRs is not thought good
enough for MiNT, these should no longer be executed, and Ptermres() should
not succeed. I'm sure this will not be done as long as compatibility is
considered important.

IIRC, Johan started looking at this problem when he was working with the
XaAES code and discovered that the overheads on OS calls was a significant
factor [although also IIRC other changes have been made to improve this
situation] - therefore, any change that can produce a speed increase in
every single system call is surely worth considering?

IMO it would be sensible to make this as clean + efficient as possible - it
is not possible to make it a 100% clean design without breaking
functionality significantly, but an improvement is still an improvement,
even if it is not perfection.

Frank - please list some solid examples of things that are wrong with the
proposal - as far as I have seen, all your points so far have been countered
by one/more replies.

Anthony