Life after free?

Bob Goudreau goudreau at dg-rtp.dg.com
Sat Oct 6 09:03:55 AEST 1990


In article <5360:Oct421:09:4890 at kramden.acf.nyu.edu>,
brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>
> In article <623 at demott.COM> kdq at demott.COM (Kevin D. Quitt) writes:
> >     It should be noted that in secure systems, free() will clear
> > the memory.
> 
> That would be quite amusing, since there's absolutely no concept of
> security within C. If you can free it, you can copy it out and save
> it first.

I think what he was thinking about was that on secure operating
systems, all memory that a process used should be wiped clean before
being made available to any other process.  This prevents the other
process from being able to accidentally see data it shouldn't.
There's no problem with the *original* process copying and storing
the data somewhere else; it's his data, after all.

But as you note, this is an OS issue, not a language issue; it must
be enforced at the system call layer.  On a UNIX system, this could
be accomplished by making the sbrk() call clear memory as it is
allocated.  The free() function, even if it actually calls sbrk()
to deallocate memory (it isn't required to), need not take any
memory-wiping action.

----------------------------------------------------------------------
Bob Goudreau				+1 919 248 6231
Data General Corporation
62 Alexander Drive			goudreau at dg-rtp.dg.com
Research Triangle Park, NC  27709	...!mcnc!rti!xyzzy!goudreau
USA



More information about the Comp.lang.c mailing list