Does Linux process exist information leakage?
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!
On Wed, Jan 11, 2012 at 08:53:07PM +0800, 夏业添 wrote:
As the man page of malloc said:"The memory is not initialized"
That means, if malloc returns a region that has previously been malloc'd, written to and free'd, you may get the these previously written data. HTH, Jonathan Neuschäfer
Hi, On Wed, Jan 11, 2012 at 4:53 AM, 夏业添 <summerxyt@gmail.com> 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.
Yeah - so if it were possible for one process to get information about another process like that you would have a security leak.
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?
All pages allocated from the OS will be initially zero'd, however, once your process owns the page, if you filled it with Z's and then freed it and reallocated you might very weill get your Z's back instead of 0's. You'll never get data from another process though. -- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
On Wed, Jan 11, 2012 at 11:45, Dave Hylands <dhylands@gmail.com> wrote:
Hi,
On Wed, Jan 11, 2012 at 4:53 AM, 夏业添 <summerxyt@gmail.com> 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.
Yeah - so if it were possible for one process to get information about another process like that you would have a security leak.
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?
All pages allocated from the OS will be initially zero'd, however, once your process owns the page, if you filled it with Z's and then freed it and reallocated you might very weill get your Z's back instead of 0's. You'll never get data from another process though.
Real world example in C; I fixed a security bug in Samba that dealt with this exact problem. Credential files were read to memory as the root user and then the memory was freed without being zeroed. A user could therefore read the contents of a file that they didn't have permission to read because the whole thing was put in memory by a user that had permission to view the file. Someone clever could churn through memory and find the credentials if they knew that the mount command was just run. I added a memset() to the end of the parsing function to zero out the memory before freeing back to the OS. http://git.samba.org/?p=cifs-utils.git;a=commitdiff;h=6c917ebf360b3dbbc4c7ad... (you can skip to the end of the patch if you don't want to follow the entire flow of the code) Does this help express the idea any better? -- Peace and Blessings, -Scott.
Yeah, it is the countermeasure of a similar secure risk. But I know little about Samba, and could you explain more precisely about how the attacker seek the credentials? That is exactly what I want to test but failed... Thanks! 2012/1/12 Scott Lovenberg <scott.lovenberg@gmail.com>
On Wed, Jan 11, 2012 at 11:45, Dave Hylands <dhylands@gmail.com> wrote:
Hi,
On Wed, Jan 11, 2012 at 4:53 AM, 夏业添 <summerxyt@gmail.com> 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.
Yeah - so if it were possible for one process to get information about another process like that you would have a security leak.
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?
All pages allocated from the OS will be initially zero'd, however, once your process owns the page, if you filled it with Z's and then freed it and reallocated you might very weill get your Z's back instead of 0's. You'll never get data from another process though.
Real world example in C; I fixed a security bug in Samba that dealt with this exact problem. Credential files were read to memory as the root user and then the memory was freed without being zeroed. A user could therefore read the contents of a file that they didn't have permission to read because the whole thing was put in memory by a user that had permission to view the file. Someone clever could churn through memory and find the credentials if they knew that the mount command was just run.
I added a memset() to the end of the parsing function to zero out the memory before freeing back to the OS.
http://git.samba.org/?p=cifs-utils.git;a=commitdiff;h=6c917ebf360b3dbbc4c7ad... (you can skip to the end of the patch if you don't want to follow the entire flow of the code)
Does this help express the idea any better? -- Peace and Blessings, -Scott.
On Wed, Jan 11, 2012 at 12:52:33PM -0500, Scott Lovenberg wrote:
Real world example in C; I fixed a security bug in Samba that dealt with this exact problem. Credential files were read to memory as the root user and then the memory was freed without being zeroed. A user could therefore read the contents of a file that they didn't have permission to read because the whole thing was put in memory by a user that had permission to view the file. Someone clever could churn through memory and find the credentials if they knew that the mount command was just run.
I added a memset() to the end of the parsing function to zero out the memory before freeing back to the OS.
Could you please clarify how this "churning through memory" would work? Of course someone could find another security bug and access heap space, but that requires said other bug. Debuggers are also irrelevant to this, because you need certain parmissions to run a program through a debugger, and if you do that, you might also set a breakpoint in the function and catch the credentials when it's run. Swap disk are a real issue under some circumstances, though. A page containing sensitive data may be swapped out and not be over- written before an attacker can boot from an external medium (CD etc.) and peek through the swap disk. If you don't suspend (which means writing all pages to persistent storage), mlock() would be the solution here (CMIIW). (Which doesn't mean zeroing isn't also a good idea) Of course, people should also encrypt their disks on this kind of server. Thanks, Jonathan Neuschäfer
On Thu, Jan 12, 2012 at 12:00, Jonathan Neuschäfer <j.neuschaefer@gmx.net>wrote:
On Wed, Jan 11, 2012 at 12:52:33PM -0500, Scott Lovenberg wrote:
Real world example in C; I fixed a security bug in Samba that dealt with this exact problem. Credential files were read to memory as the root user and then the memory was freed without being zeroed. A user could therefore read the contents of a file that they didn't have permission to read because the whole thing was put in memory by a user that had permission to view the file. Someone clever could churn through memory and find the credentials if they knew that the mount command was just run.
I added a memset() to the end of the parsing function to zero out the memory before freeing back to the OS.
Could you please clarify how this "churning through memory" would work?
Of course someone could find another security bug and access heap space, but that requires said other bug. Debuggers are also irrelevant to this, because you need certain parmissions to run a program through a debugger, and if you do that, you might also set a breakpoint in the function and catch the credentials when it's run.
Swap disk are a real issue under some circumstances, though. A page containing sensitive data may be swapped out and not be over- written before an attacker can boot from an external medium (CD etc.) and peek through the swap disk. If you don't suspend (which means writing all pages to persistent storage), mlock() would be the solution here (CMIIW). (Which doesn't mean zeroing isn't also a good idea)
Of course, people should also encrypt their disks on this kind of server.
Thanks, Jonathan Neuschäfer
Sorry for taking so long to reply. Let me walk you guys through how this bug could be exploited. The file that you want to access is blocked from you by file system permissions. The root user (uid==0) can access this file (that contains credentials) and read it into memory that it has malloc()'ed. After the process running as root is done, it free()'s the memory without zeroing it out. Now you (you clever hacker) spawn a process that requests memory in large hunks. It then searches for the string "password=" in that memory. Since the memory was free()'ed back to the pool without being changed, it still contains the original information that was in the file that you cannot read. Does this make sense, or should I go into t a bit more detail? -- Peace and Blessings, -Scott.
On Mon, Jan 16, 2012 at 01:19:22PM -0500, Scott Lovenberg wrote:
Let me walk you guys through how this bug could be exploited. The file that you want to access is blocked from you by file system permissions. The root user (uid==0) can access this file (that contains credentials) and read it into memory that it has malloc()'ed. After the process running as root is done, it free()'s the memory without zeroing it out. Now you (you clever hacker) spawn a process that requests memory in large hunks. It then searches for the string "password=" in that memory. Since the memory was free()'ed back to the pool without being changed, it still contains the original information that was in the file that you cannot read. Does this make sense, or should I go into t a bit more detail?
But can you actually get this dirty memory on Linux? I know two sources of memory that are used by malloc. One is brk(), the other is mmapped pages of /dev/zero. With /dev/zero it's obvious that you get empty pages (all-zero); with brk I wasn't sure so I wrote the test program below and ran it. I didn't find any dirty (non-zero) memory. Thanks, Jonathan Neuschäfer -- #include <unistd.h> #include <stdio.h> #define BLOCKSZ (1024 * 1024) /* one Mibi */ int main(void) { int maxmb = 1024; unsigned i; void *BRK; BRK = sbrk(0); for (i = 0; i < maxmb; i++) { void *block = sbrk(BLOCKSZ); unsigned j, *p; if (block == (void *) -1) { printf("sbrk failed after %u blocks (%u bytes)\n", i, i * BLOCKSZ); break; } for (p = block, j = BLOCKSZ/sizeof(unsigned int); j--; p++) if (*p) printf("found data at BRK+%p: %u\n", ((void *)p) - BRK, *p); } return 0; }
On Mon, Jan 16, 2012 at 18:45, Jonathan Neuschäfer <j.neuschaefer@gmx.net>wrote:
On Mon, Jan 16, 2012 at 01:19:22PM -0500, Scott Lovenberg wrote:
Let me walk you guys through how this bug could be exploited. The file that you want to access is blocked from you by file system permissions. The root user (uid==0) can access this file (that contains credentials) and read it into memory that it has malloc()'ed. After the process running as root is done, it free()'s the memory without zeroing it out. Now you (you clever hacker) spawn a process that requests memory in large hunks. It then searches for the string "password=" in that memory. Since the memory was free()'ed back to the pool without being changed, it still contains the original information that was in the file that you cannot read. Does this make sense, or should I go into t a bit more detail?
But can you actually get this dirty memory on Linux?
I know two sources of memory that are used by malloc. One is brk(), the other is mmapped pages of /dev/zero. With /dev/zero it's obvious that you get empty pages (all-zero); with brk I wasn't sure so I wrote the test program below and ran it. I didn't find any dirty (non-zero) memory.
Thanks, Jonathan Neuschäfer
-- #include <unistd.h> #include <stdio.h>
#define BLOCKSZ (1024 * 1024) /* one Mibi */
int main(void) { int maxmb = 1024; unsigned i; void *BRK;
BRK = sbrk(0);
for (i = 0; i < maxmb; i++) { void *block = sbrk(BLOCKSZ); unsigned j, *p;
if (block == (void *) -1) { printf("sbrk failed after %u blocks (%u bytes)\n", i, i * BLOCKSZ); break; }
for (p = block, j = BLOCKSZ/sizeof(unsigned int); j--; p++) if (*p) printf("found data at BRK+%p: %u\n", ((void *)p) - BRK, *p); }
return 0; }
Thanks for posting this. I'm embarrassed that I never even bothered to check if dirty memory was given back. I guess I just assumed. You know what they say about assumptions... Anyways, I think this is a great discussion. :) -- Peace and Blessings, -Scott.
On Thu, Jan 12, 2012 at 12:00 PM, Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote:
On Wed, Jan 11, 2012 at 12:52:33PM -0500, Scott Lovenberg wrote:
Real world example in C; I fixed a security bug in Samba that dealt with this exact problem. Credential files were read to memory as the root user and then the memory was freed without being zeroed. A user could therefore read the contents of a file that they didn't have permission to read because the whole thing was put in memory by a user that had permission to view the file. Someone clever could churn through memory and find the credentials if they knew that the mount command was just run.
I added a memset() to the end of the parsing function to zero out the memory before freeing back to the OS.
Could you please clarify how this "churning through memory" would work?
Of course someone could find another security bug and access heap space, but that requires said other bug. Debuggers are also irrelevant to this, because you need certain parmissions to run a program through a debugger, and if you do that, you might also set a breakpoint in the function and catch the credentials when it's run.
Swap disk are a real issue under some circumstances, though. A page containing sensitive data may be swapped out and not be over- written before an attacker can boot from an external medium (CD etc.) and peek through the swap disk.
Boot CDs mean physical access. If the bad guy has physical access, all is lost. === specifically If you want to defend against reboots to a boot CD, then all of memory is potential leak. http://citp.princeton.edu/research/memory/ My personal favorite is when they actually move the RAM chips from one PC to another to get the data out of it. After removing power, they immediately spray freon (or something similarly cold) on the RAM chips to stabilize them, then move them to another PC and recover the content. I can't get the video to work right now, but here's a walk-thru with photos. I quote: === We stored data in these memory modules, then cooled them, removed them from the computer, and placed them in a container of liquid nitrogen for an hour. After returning them to the computer, we found practically no information had been lost. (Using liquid nitrogen would be overkill for most attacks, since cheap, widely-available duster spray would adequately cool the chips.) === Greg
On Mon, Jan 16, 2012 at 13:45, Greg Freemyer <greg.freemyer@gmail.com>wrote:
On Thu, Jan 12, 2012 at 12:00 PM, Jonathan Neuschäfer <j.neuschaefer@gmx.net> wrote:
On Wed, Jan 11, 2012 at 12:52:33PM -0500, Scott Lovenberg wrote:
Real world example in C; I fixed a security bug in Samba that dealt with this exact problem. Credential files were read to memory as the root user and then the memory was freed without being zeroed. A user could therefore read the contents of a file that they didn't have permission to read because the whole thing was put in memory by a user that had permission to view the file. Someone clever could churn through memory and find the credentials if they knew that the mount command was just run.
I added a memset() to the end of the parsing function to zero out the memory before freeing back to the OS.
Could you please clarify how this "churning through memory" would work?
Of course someone could find another security bug and access heap space, but that requires said other bug. Debuggers are also irrelevant to this, because you need certain parmissions to run a program through a debugger, and if you do that, you might also set a breakpoint in the function and catch the credentials when it's run.
Swap disk are a real issue under some circumstances, though. A page containing sensitive data may be swapped out and not be over- written before an attacker can boot from an external medium (CD etc.) and peek through the swap disk.
Boot CDs mean physical access. If the bad guy has physical access, all is lost.
=== specifically If you want to defend against reboots to a boot CD, then all of memory is potential leak.
http://citp.princeton.edu/research/memory/
My personal favorite is when they actually move the RAM chips from one PC to another to get the data out of it.
After removing power, they immediately spray freon (or something similarly cold) on the RAM chips to stabilize them, then move them to another PC and recover the content.
I can't get the video to work right now, but here's a walk-thru with photos.
I quote: === We stored data in these memory modules, then cooled them, removed them from the computer, and placed them in a container of liquid nitrogen for an hour. After returning them to the computer, we found practically no information had been lost. (Using liquid nitrogen would be overkill for most attacks, since cheap, widely-available duster spray would adequately cool the chips.) ===
Greg
I should clarify (because someone asked), the memory that I was talking about wouldn't be allocatable until after the process that read it and freed it exited. -- Peace and Blessings, -Scott.
Hi, Could you explain more about how the OS initialize the malloced pages? Or which part of the kernel code can do thatThanks! 2012/1/12 Dave Hylands <dhylands@gmail.com>
Hi,
On Wed, Jan 11, 2012 at 4:53 AM, 夏业添 <summerxyt@gmail.com> 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.
Yeah - so if it were possible for one process to get information about another process like that you would have a security leak.
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?
All pages allocated from the OS will be initially zero'd, however, once your process owns the page, if you filled it with Z's and then freed it and reallocated you might very weill get your Z's back instead of 0's. You'll never get data from another process though.
-- Dave Hylands Shuswap, BC, Canada http://www.davehylands.com
"夏业添" <summerxyt@gmail.com> 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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
I guess you know what a zombie is? Someone that is dead, but is still hanging around. When a linux process dies, it first becomes a zombie and the parent process is signaled. The parent process at that point can still do various things. If the parent is a debugger, it can get all sorts of details from the zombie. When the parent acknowledges the death of child signal, the zombie is really killed and removed from the system tables, etc. But in my mind when the child process becomes a zombie it is dead and basically everything about the task/process is still maintained in memory. To test this write a simple c program that initializes some ram then calls exit(). Then run it in a debugger like gdb and see what details you can get out while the program is in a zombie state. Fyi: I haven't done this in years, so it may not be easy to actually do that. Greg -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
On 01/11/2012 01:44 PM, Greg Freemyer wrote:
When a linux process dies, it first becomes a zombie and the parent process is signaled.
The parent process at that point can still do various things. If the parent is a debugger, it can get all sorts of details from the zombie.
When the parent acknowledges the death of child signal, the zombie is really killed and removed from the system tables, etc.
The memory of a process is freed before it becomes a zombie.
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@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
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@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@kernelnewbies.**org <Kernelnewbies@kernelnewbies.org> http://lists.kernelnewbies.**org/mailman/listinfo/**kernelnewbies<http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies>
am not sure about my answer but regarding kmalloc if i am going out of context ..but when u do a* kmalloc it doesnt clear *the memory obtained and still holds the prvious contents...what happens in that case ..and as far as i know when u take the case of reparenting ....during process termination exit_mm() is called to release the mm_struct held by this process. If no other process is using this address space, if the address space is not shared―the kernel then destroys it and also there is the senario of zombie exit...i mean PDT remains after parent exits.... 2012/1/19 夏业添 <summerxyt@gmail.com>
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@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@kernelnewbies.**org <Kernelnewbies@kernelnewbies.org> http://lists.kernelnewbies.**org/mailman/listinfo/**kernelnewbies<http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies>
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- *Regards, Santosh Kulkarni*
sorry guys did not read tat properly..he is just referring to user space....as far malloc is concerned it basically calls *brk*() and *sbrk() * tand they basically end up changing the location of thelocation of program break which is nothing but the end of the process's data segment so it has nothing to do with u getting any info or any memory leaks...i mean not too specific to PDT...or any such previously exited processes... 2012/1/19 SaNtosh kuLkarni <santosh.yesoptus@gmail.com>
am not sure about my answer but regarding kmalloc if i am going out of context ..but when u do a* kmalloc it doesnt clear *the memory obtained and still holds the prvious contents...what happens in that case ..and as far as i know when u take the case of reparenting ....during process termination exit_mm() is called to release the mm_struct held by this process. If no other process is using this address space, if the address space is not shared―the kernel then destroys it and also there is the senario of zombie exit...i mean PDT remains after parent exits....
2012/1/19 夏业添 <summerxyt@gmail.com>
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@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@kernelnewbies.**org <Kernelnewbies@kernelnewbies.org> http://lists.kernelnewbies.**org/mailman/listinfo/**kernelnewbies<http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies>
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
-- *Regards, Santosh Kulkarni*
-- *Regards, Santosh Kulkarni*
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@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@kernelnewbies.__org <mailto:Kernelnewbies@kernelnewbies.org> http://lists.kernelnewbies.__org/mailman/listinfo/__kernelnewbies <http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies>
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
On Tue, Jan 17, 2012 at 20:53, Fredrick <fjohnber@zoho.com> wrote:
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
Thanks for clearing that up. I learned something today. :) -- Peace and Blessings, -Scott.
participants (8)
-
Dave Hylands -
Fredrick -
Greg Freemyer -
Jonathan Neuschäfer -
Rik van Riel -
SaNtosh kuLkarni -
Scott Lovenberg -
夏业添