Life after free?

Kevin D. Quitt kdq at demott.COM
Sun Oct 7 03:10:49 AEST 1990


In article <1990Oct05.020434.12344 at virtech.uucp> cpcahil at virtech.uucp (Conor P. Cahill) 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.
>
>There is no requirement for this.  The only requirement is that memory that 
>is made available to a process must have no information left in it
>from the previous process that used that memory. 
>
>Since free() does not release memory to the system on most implementations,
>it doesn't matter what it does (from an object reuse point of view) since 
>the only process that has access to it is the one that wrote the data there.


    If free() does not release the memory to the OS, it's less of a problem.


>Even if free() did release the memory to the OS, as long as the object
>reuse policy of the OS cleared the free'd pages prior to allocating them
>to a new process it would meet secure system requirements.

    This is not as safe as clearing it before releasing it.  An operting
system can often be coerced into giving dirty pages to a task.  Unless
the system can be mathematically proven to be immune from this, the
memory should be cleared before being released - whether it's free() or
exit() that does this makes little difference, but it must be done. 

    Paranoid? You bet! (When it's my job to be) Remember - terrorists
can get past a retinal scanner and a palm/fingerprint machine by taking
along the head and hand of someone who's been cleared. 

-- 
 _
Kevin D. Quitt         demott!kdq   kdq at demott.com
DeMott Electronics Co. 14707 Keswick St.   Van Nuys, CA 91405-1266
VOICE (818) 988-4975   FAX (818) 997-1190  MODEM (818) 997-4496 PEP last

                96.37% of all statistics are made up.



More information about the Comp.lang.c mailing list