[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Security again



> > > > > So, outlawing TRAP-hooking is not really an option.
> > > >
> > > > It's always an option. Tell me any useful reason to allow an 
> > application
> > > > to override the system.
> > > 
> > > The AES is a pretty useful application, atleast to me...
> > 
> > I think Frank is talking about 'the system' as in MiNT here.
> > The AES and VDI is on another vector, so they don't override that.
> > 
> > They do of course require redirection of exception vectors,
> > though, and they
> > are far from the only programs that do that. It's apparently quite common
> > to redirect things like bus error, address error, divide by zero, etc.
> > Since most programs don't know about MiNT, or are intended to work under
> > normal TOS as well, they have no choice about this, of course.
> 
> They can use Setexc() for this. This works everywhere.

Uhm, I've never said anything else. I even mentioned that call a couple of
letters back.
The point is that Frank is against vector bending as a concept, which I
can fully understand. One reason for this thread is that I maintain that
_some_ control over this is better than _none_.
We _can't_ forbid this, or a significant portion of Atari software will
stop working.

Setexc() will of course need to be available in the future too, as well as
Super() etc, but at the very least newer programs could use a feature that
is somewhat safer, to do the same thing.
In principle, I don't see why it shouldn't be possible for the kernel to
call an actual 'exception handler' in user mode in some cases (specifically
asked for at the 'TraPatch' call, naturally), but that's beside the point.

In any case, the TRAP-chains are mainly an 'AUTO-folder' problem. I'm not
focusing on what applications do later here.