Yes you are right.
Each architecture implements clear_page() differently. Some may just use 
memset. Some may use architecture specific instructions to perform the 
zero-ing faster.

I guess x86's fast_clear_page does that.

-Fredrick

On 01/18/2012 05:27 PM, ??? wrote:

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 <mailto:fjohnber@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
        <mailto:Kernelnewbies@kernelnewbies.org>
        http://lists.kernelnewbies.__org/mailman/listinfo/__kernelnewbies <http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies>






_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies