Re: [MiNT] kernel 1.15.10b fragmentation

[Johan Klockars <rand@cd.chalmers.se>]

> > > > > However, IMHO, the more proper solution would be to develop an AES which
> > > > > works completely in user context. This would allow (in some future) to

I disagree, except possibly for AES functions that don't modify the internal
state of the AES in any way (and then only for performance reasons).

> > > > > remove the F_OS_SPECIAL flag, which is simply a dangerous idiotism, and
> > > > > creates a security hole big like the Baltic Sea.

Well, if that flag is only ever used by the AES, I don't think it's too bad.
Except for user defined objectes, but it might be possible to execute
those in a safe (if not entirely compatible) way.

F_OS_SPECIAL does not seem to be terribly well documented (at least I didn't
find it when grep:ing through the docs, but there was some comments in the
sources), but from what I could see it grants others supervisor access to
the memory space of the process that has it set. At least for an AES, that
seems like a huge unnecessary risk (but it is of course necessary if the
AES is also called in user context).

To make it much safer, without sacrificing functionality, the kind of
access rights that are granted by F_OS_SPECIAL could be limited to processes
which allow it explicitly. The AES Trap #2 handler could then activate it
on appl_init() and deactivate it on appl_exit(), or even for specific AES
calls.
I guess this could complicate the memory protection mechanisms in MiNT
significantly, however, and it would not be of use to much software
besides XaAES. Then again, a certain well known software company apparently
decided to move their GUI stuff into the kernel itself...   ;-)

> > > You do not understand. Running in user context means that there is no such
> > > process an "AES" anymore, and structures obviously can be accessed
> > > directly, because all this is done in the context of the calling

But you must remember that the AES is much more than a graphics function
library. It deals with a lot of things that concern more than one process.
It isn't a good idea to make a normal process able to corrupt structures
that affect other processes.
I don't think you can get around having an AES process of some kind in
any case, since for example the menu should work even if no process is
waiting for events.

> > > applications. In this case no F_OS_SPECIAl neither any other "more
> > > elaborate authentication procedures" would be necessary.
> > > 
> > OK I see what you mean.
> > Well, such a AES does not exist. And I am not working on such a thing.
> 
>  Hmm.. this statement made me extremely disappointed. I thought this was
> the whole idea behind XaAES originally. We don't need another "n.aes",

It's rather the other way around.
Originally, XaAES was an AES server only. That is, a separate process that
took care of messages sent to it via pipes. As has been noted here, that
requires the AES to have access to the caller's memory space.
This turned out to be rather slow, though, which caused Craig to add the
'direct call' mechanism, which does indeed run the AES in user context.
Naturally, this requires a bunch of semaphores for synchronization, and
those are, unfortunately, quite slow and limited in MiNT.

IIRC, Henk has mentioned that his improvements have been successful enough
that the speed increases given by the 'direct calls' may no longer be
necessary.

> which is as good as the "old" not-very-stable/secure Atari spec can get.

I would have thought that N.AES did not go the AES server way, but did
indeed have some variant of the 'direct calls'.

> Why don't you go the "correct" way with this?

IMO, the current way _is_ the correct one, under the limitations that
the AES specification (and the MiNT implementation) sets.
Unlike certain other people on this list, I _do_ like the X way of
doing things.  ;-)

It's unfortunate that the people who designed the AES (and the VDI for
that matter) didn't think ahead. Things would have been much better if
the user had not been allowed direct access to resources, for example,
since then the AES could have kept all such things in its own memory
space and had no need to access the callers' (though that would have
required sending a bit more data via the pipe for some AES calls).

> > > AES is perhaps an important part of the operating environment, but the
> > > system should not be brought down, when the AES fails. If you think you

And the AES should not be brought down when an application fails.

> > My aim is to provide the atari community with a perfect working open source
> > AES that is reasonable fast and small and is at least not worse than 
> > atari multitos. Thats all for the moment.
> 
>  I appreciate that very much, but in my opinion it is going in the wrong
> direction... as an AES for MiNT.

Opinions differ.
Still, the 'direct call' method, which was still in XaAES last time I
looked, does do more or less what you want.

IIRC, oAESis was much more 'direct call' oriented from the beginning.
I do seem to recall hearing that they wanted to change that, though.

-- 
  Chalmers University   | Why are these |  e-mail:   rand@cd.chalmers.se
     of Technology      |  .signatures  |            johank@omicron.se
                        | so hard to do |  WWW:      rand.thn.htu.se
   Gothenburg, Sweden   |     well?     |            (fVDI, MGIFv5, QLem)