[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.

Frank is, IMO, quite right in that the concept of modifying exception
vectors is an extremely bad idea. He doesn't seem to agree that it would
be better to at least try to do something about it, though.
We obviously can't remove the possibility and still have something that
could even remotely be called TOS-compatible. As you say, it wouldn't even
be possible to use the AES or VDI.

If everything had used the proposed TraPatch-like functionality to hook
into whatever it needs to, MiNT would at least have a little bit of control
over it, and there wouldn't be all this chaining.


In QDOS (the Sinclair QL OS), you could redirect most exception vectors but,
IIRC, not the ones actually used by the system. QDOS did this by having a
separate vector table for each process and the actual exception routines
were all called indirectly via this.
To make this foolproof, the real vectors must of course be fixed, which isn't
possible for us. On the QL, the first 48kbyte was ROM...

The latest versions of the Eclipse specific AB040 toolkit actually move
the entire vector table and indirect through the normal addresses. This was 
necessary since several programs modify the bus error vector and thus
disable the MMU based frame buffer banking.

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