Does Linux process exist information leakage?

[夏业添]

Thanks！

It seems that the function do_page_fault() will finally call
fast_clear_page()<http://lxr.oss.org.cn/plain/source/arch/x86/lib/mmx_32.c#L125>
 or slow_zero_page()<http://lxr.oss.org.cn/plain/source/arch/x86/lib/mmx_32.c#L336>
to
zero a new physical page for a process. So calling malloc() cannot get a
page used by another process which is dead already.

The assemble language is difficult to me, so please tell me if I am wrong.

2012/1/18 Fredrick <fjohnber at zoho.com>

> When you malloc a memory or mmap a MAP_ANON memory, it is virtually
> allocated. When you read or write to it, the process takes a page fault.
> The page fault handler zeroes those memory and hands it to the process. So
> I think there is no leak.
>
> -Fredrick
>
>
> On 01/11/2012 04:53 AM, 夏业添 wrote:
>
>> Hi,
>>    My tutor asked me to test whether one process leaves information in
>> memory after it is dead. I tried to search some article about such thing
>> on the Internet but there seems to be no one discuss about it. And after
>> that, I tried to write some program in the User Mode to test it, using
>> fork() to create lots of processes and filling char 'a' into a 102400
>> bytes char array in each process. Then I used malloc() to get some
>> memory to seek char 'a' in a new one process or many new processes, but
>> failed. All memory I malloced was full of zero.
>>    As the man page of malloc said:"The memory is not initialized", I
>> believe that the memory which was got by malloc() could be used by other
>> process, and therefor information leakage exists. But how can I test it?
>> Or where can I get related information?
>>    Thanks!
>>
>>
>> ______________________________**_________________
>> Kernelnewbies mailing list
>> Kernelnewbies at kernelnewbies.**org <Kernelnewbies at kernelnewbies.org>
>> http://lists.kernelnewbies.**org/mailman/listinfo/**kernelnewbies<http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies>
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120119/0de8b764/attachment.html