GC implementation

[Dave]

In article <dvgoeb$20it$1 at digitaldaemon.com>, Frank Benoit says...
>
>An attacker has as much time as needed. He will get all knowledge
>neccessary and perhaps he can calculate such addresses without physical
>access to the machine. But this is not the real problem. Random data in
>integers and floating point values can also make problems.
>

An attacker could even use the lib. source code to figure it out, but...

>I think, this is a really big security problem and makes reliable
>programs impossible. If only knowledge or random data can cause memory
>leaks, than this is a problem.
>
>What about a program running out of memory after 3 days. Is it a program
>bug, or because of randomly matching data values?
>
>If the solution is to call delete manually, then the gc makes no sense
>at all.
>
>This is a show stopper, because everything is base on gc allocated
>memory. You will only get a predictable behaviour with an precise (vs
>conservative) GC.

I agree that it can be a problem but disagree that it is a show-stopper...

What I think Sean's reply was getting at is that a "proper" design would go far
in mitigating the problem no matter the type of collector or memory mgmt.
strategy used.

That doesn't necessarily mean hack or work-around either, because in any case
good design of server type software shouldn't turn over control of resource
mgmt. to a "third party" like a GC (imho), it should be more tightly controlled
no matter how good the GC is.

One way to design for the issue you raise can be a "revolving buffer" where the
same chunk of memory is allocated once and used to service the requests and
responses until shutdown. e.g.: There can be a bound on the buffer because the
slice read (from e.g. a socket) is controlled, and buffer mgmt. is made alot
easier with D array semantics (like slicing). Then issues like data values
within the address range of the heap won't matter -- not only more secure but
potentially a lot more efficient as well. IIRC, that is similiar to what Mango
HTTP server does (as an example): http://mango.dsource.org/

The good news - since D's GC is not really a "bolt-on" like it has to be for C
or C++ - is that probably a type-aware collector can be done w/o affecting D's
current C-like pointer semantics. But I think ruling D out as-is for server
software is a little strong since D gives us so many options for managing
memory.