Life after free?

Kaleb Keithley kaleb at thyme.jpl.nasa.gov
Fri Oct 5 11:17:11 AEST 1990


In article <1990Oct5.002416.3196 at nntp-server.caltech.edu> manning at nntp-server.caltech.edu (Evan Marshall Manning) 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.
>
>brnstnd at kramden.acf.nyu.edu (Dan Bernstein) writes:
>
>>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.
>
>You're missing the point.  Of course you can do what you like with your
>data.  But when you free() it you return it to the OS.  And anybody else
>can end up with your data when they next malloc().

Which OS is that on?  At the risk of exhibiting "small world" syndrome,
in UNIX, malloc and free work within the confines of the heap, which
is given to the process through the sbrk system call.  No other process
can *normally* gain access to a process' heap space without generating 
a memory exception of some kind and dumping core.  Memory given to a process
through sbrk is returned to the system memory pool only when the program
terminates.  I'd hazard that other multi-tasking OS's like VMS behave
similarly.

-- 
Kaleb Keithley                      Jet Propulsion Labs
kaleb at thyme.jpl.nasa.gov

Stirring up trouble again.



More information about the Comp.lang.c mailing list