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

Re: [MiNT] kernel 1.15.10b fragmentation




Thomas Binder wrote:
> 
> Hi!
> 
> On Wed, Jan 03, 2001 at 03:45:06PM +0100, Konrad M. Kokoszkiewicz wrote:
> > 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
> > remove the F_OS_SPECIAL flag, which is simply a dangerous idiotism, and
> > creates a security hole big like the Baltic Sea.
> 
> Not to mention that both N.AES and Atari AES 4.x seem to "rely" on the
> bug that a child always has full access to its parent's memory. That's
> why I introduced the new MPFLAGS variable for mint.cnf, where you have
> to explicitly enable the bug fix, as you wouldn't be able to use an AES
> if I made a simple fix :(
> 

I am currently developing a malloc package that makes it possible to have
a multiple of allocation bases. This makes it thread save.

If information residing in XaAES has to be passed to a client, it is copied
to memory allocated on behalf of the client.

Memory allocated for clients is completely disjunct from other clients and
the private memory of the AES. Each base has its own allocation flags and
chunk size.
It is buffered the same way as standard malloc.

The package already contains leak and sanity checking functions and options.

When it is finished it will be published as a free standing product capable
of replacing the standard library functions.

As for the use in XaAES, it is a intermediate solution. One of the reasons I
write it is avoiding fragmentation.
It should be possible to allocate the GEMDOS blocks for clients in shared memory.
Just an idee.

-- 
Groeten; Regards.
Henk Robbers.    mailto:h.robbers@chello.nl
                   http://members.ams.chello.nl/h.robbers/Home.html
A free multitasking GEM for MiNT: XaAES (heavily under construction);
Interactive disassembler: TT-Digger;  Experimental text editor: AHCX;