Re: unitialized memory is all zeros...why not garbage instead?
On Jun 11, Dag-Erling Smrgrav wrote: Mike Hunter [EMAIL PROTECTED] writes: I have a feeling that I'm missing something really obvious, but I'm having trouble understanding why the following program: [...] Never prints anything but 0's. Because the kernel always hands processes pre-zeroed pages. I ran less up to my hw.physmem by feeding it /dev/random and watching top, and then ran the program, so I know there was tons of non-zero bits in memory. If your program had been able to see leftovers from less in its own address space, we'd have a huge security hole on our hands. I'm curious because I am worried about information leaks between processes on the same machine...did somebody decide to solve this problem while I wasn't paying attention? :) It's always been this way. Thanks for setting me straight. I guess it wasn't this way on DOS where I first learned C++ and I've assumed garbage ever since :) Is the pre-zeroing of malloc'd memory documented somewhere? By my reading of the malloc manapge... The calloc() function allocates space for number objects, each size bytes in length. The result is identical to calling malloc() with an argument of ``number * size'', with the exception that the allocated memory is explicitly initialized to zero bytes. ...it seems like it's saying that malloc (as opposed to calloc) is NOT pre-zeroed. Is there a different document I should be reading? Tussen Tak! Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unitialized memory is all zeros...why not garbage instead?
Mike Hunter [EMAIL PROTECTED] wrote: On Jun 11, Dag-Erling Smrgrav wrote: Mike Hunter [EMAIL PROTECTED] writes: I have a feeling that I'm missing something really obvious, but I'm having trouble understanding why the following program: [...] Never prints anything but 0's. Because the kernel always hands processes pre-zeroed pages. Thanks for setting me straight. I guess it wasn't this way on DOS where I first learned C++ and I've assumed garbage ever since :) Is the pre-zeroing of malloc'd memory documented somewhere? By my reading of the malloc manapge... Careful now: The return value in memory from malloc() is not directly related to the return value in memory from sbrk(). malloc() may give the application back memory that was free()d previously by the same application. New pages that come out of sbrk() are 0s, but those aren't always needed to fulfill a malloc() request. The calloc() function allocates space for number objects, each size bytes in length. The result is identical to calling malloc() with an argument of ``number * size'', with the exception that the allocated memory is explicitly initialized to zero bytes. ...it seems like it's saying that malloc (as opposed to calloc) is NOT pre-zeroed. Is there a different document I should be reading? And if calloc() grabs something from the in-process used, now free pool, it will be zeroed. If malloc() grabs something from that same pool, it won't be. -- Steve Watt KD6GGD PP-ASEL-IA ICBM: 121W 56' 57.8 / 37N 20' 14.9 Internet: steve @ Watt.COM Whois: SW32 Free time? There's no such thing. It just comes in varying prices... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unitialized memory is all zeros...why not garbage instead?
On Mon, Jun 13, 2005 at 12:31:50PM -0700, Mike Hunter wrote: On Jun 11, Dag-Erling Smrgrav wrote: Mike Hunter [EMAIL PROTECTED] writes: I have a feeling that I'm missing something really obvious, but I'm having trouble understanding why the following program: [...] Never prints anything but 0's. Because the kernel always hands processes pre-zeroed pages. I ran less up to my hw.physmem by feeding it /dev/random and watching top, and then ran the program, so I know there was tons of non-zero bits in memory. If your program had been able to see leftovers from less in its own address space, we'd have a huge security hole on our hands. I'm curious because I am worried about information leaks between processes on the same machine...did somebody decide to solve this problem while I wasn't paying attention? :) It's always been this way. Thanks for setting me straight. I guess it wasn't this way on DOS where I first learned C++ and I've assumed garbage ever since :) That is a good assumption. It is not true everywhere, but it rarely hurts being on the safe side. Is the pre-zeroing of malloc'd memory documented somewhere? By my reading of the malloc manapge... The calloc() function allocates space for number objects, each size bytes in length. The result is identical to calling malloc() with an argument of ``number * size'', with the exception that the allocated memory is explicitly initialized to zero bytes. ...it seems like it's saying that malloc (as opposed to calloc) is NOT pre-zeroed. Is there a different document I should be reading? Note that this pre-zeroing is not done by malloc, but is done by the kernel before it hands over memory to a process. Memory is not necessarily returned to the system when free() is called, but is often retained within the process and reused by the next malloc(). This means that if you have a sequence like the following: foo=malloc(1234); bar=malloc(1234); /* do something that fills the memory that foo points to with garbage */ free(foo); baz=malloc(1234); Then there is no guarantees whatsoever that baz will not point to garbage. The memory that malloc() returns in the third call to malloc() will most likely be the same as that previously pointed to by foo and will still be filled with garbage. If your program needs zeroed memory you should use calloc() or do the zeroing yourself - malloc doesn't do it. What is guaranteed is that any garbage in the memory returned by malloc() will have been created by the same process, so that information is not leaked from another process in this way. In short memory from malloc() may or may not be pre-zeroed, but it is not a security problem in either case. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unitialized memory is all zeros...why not garbage instead?
Mike Hunter [EMAIL PROTECTED] writes: Is the pre-zeroing of malloc'd memory documented somewhere? By my reading of the malloc manapge... malloc() does not pre-zero memory, but it hands you memory which has been pre-zeroed by the kernel unless you've used it before. Your test program makes only one malloc() call, so you get memory that has never been used before. ...it seems like it's saying that malloc (as opposed to calloc) is NOT pre-zeroed. Is there a different document I should be reading? No, but nowhere in the standard does it say that memory allocated with malloc() must contain non-zero garbage. If that is what you want, though, read the TUNING section in the malloc(3) man page. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unitialized memory is all zeros...why not garbage instead?
On Jun 13, Erik Trulsson wrote: Is the pre-zeroing of malloc'd memory documented somewhere? By my reading of the malloc manapge... The calloc() function allocates space for number objects, each size bytes in length. The result is identical to calling malloc() with an argument of ``number * size'', with the exception that the allocated memory is explicitly initialized to zero bytes. ...it seems like it's saying that malloc (as opposed to calloc) is NOT pre-zeroed. Is there a different document I should be reading? Note that this pre-zeroing is not done by malloc, but is done by the kernel before it hands over memory to a process. Memory is not necessarily returned to the system when free() is called, but is often retained within the process and reused by the next malloc(). This means that if you have a sequence like the following: foo=malloc(1234); bar=malloc(1234); /* do something that fills the memory that foo points to with garbage */ free(foo); baz=malloc(1234); Then there is no guarantees whatsoever that baz will not point to garbage. The memory that malloc() returns in the third call to malloc() will most likely be the same as that previously pointed to by foo and will still be filled with garbage. If your program needs zeroed memory you should use calloc() or do the zeroing yourself - malloc doesn't do it. What is guaranteed is that any garbage in the memory returned by malloc() will have been created by the same process, so that information is not leaked from another process in this way. In short memory from malloc() may or may not be pre-zeroed, but it is not a security problem in either case. I got it. Thanks! This all stemmed from a discussion I was having with a coworker about vmware. I wondered aloud if information might leak from one VM to another via malloc. Whatever the answer is to that question (it's a linux VM server), I can now say I understand how FreeBSD behaves. Thanks again! Mike ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unitialized memory is all zeros...why not garbage instead?
In message: [EMAIL PROTECTED] Mike Hunter [EMAIL PROTECTED] writes: : Is the pre-zeroing of malloc'd memory documented somewhere? By my reading : of the malloc manapge... : : The calloc() function allocates space for number objects, each size : bytes in length. The result is identical to calling malloc() with an : argument of ``number * size'', with the exception that the allocated : memory is explicitly initialized to zero bytes. : : ...it seems like it's saying that malloc (as opposed to calloc) is NOT : pre-zeroed. Is there a different document I should be reading? The memory isn't given to the process by malloc. It is given to it by some other means. That memory is zeroed for security reasons. The first time malloc returns the memory, with our current implementation, it will be all zeros. After that, all bets are off with out implementation. One should not rely on this behavior because one never knows when the first malloc happens, nor if our malloc might start writing into the memory it is about to return... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unitialized memory is all zeros...why not garbage instead?
Mike Hunter [EMAIL PROTECTED] writes: I have a feeling that I'm missing something really obvious, but I'm having trouble understanding why the following program: [...] Never prints anything but 0's. Because the kernel always hands processes pre-zeroed pages. I ran less up to my hw.physmem by feeding it /dev/random and watching top, and then ran the program, so I know there was tons of non-zero bits in memory. If your program had been able to see leftovers from less in its own address space, we'd have a huge security hole on our hands. I'm curious because I am worried about information leaks between processes on the same machine...did somebody decide to solve this problem while I wasn't paying attention? :) It's always been this way. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
unitialized memory is all zeros...why not garbage instead?
Hey everybody,
I have a feeling that I'm missing something really obvious, but I'm having
trouble understanding why the following program:
#include stdlib.h
#include stdio.h
int main (int argc, char * argv[])
{
void * ptr = malloc(65536);
size_t i;
for (i = 0; i 65536; i++)
{
printf (%x, *((unsigned char *)ptr + i));
if ((i % 16) == 0)
{
puts(\n);
}
}
return 0;
}
Never prints anything but 0's.
I ran less up to my hw.physmem by feeding it /dev/random and watching
top, and then ran the program, so I know there was tons of non-zero
bits in memory.
I'm curious because I am worried about information leaks between processes
on the same machine...did somebody decide to solve this problem while I
wasn't paying attention? :)
%gcc -v
Using built-in specs.
Configured with: FreeBSD/i386 system compiler
Thread model: posix
gcc version 3.4.2 [FreeBSD] 20040728
%uname -a
FreeBSD mylabtop.berkeley.edu 5.4-STABLE FreeBSD 5.4-STABLE #1: Wed May
11 12:05:39 PDT 2005
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unitialized memory is all zeros...why not garbage instead?
In the last episode (Jun 10), Mike Hunter said:
I have a feeling that I'm missing something really obvious, but I'm
having trouble understanding why the following program:
int main (int argc, char * argv[])
{
void * ptr = malloc(65536);
Never prints anything but 0's.
The kernel zeros out memory before handing it to processes.
--
Dan Nelson
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: unitialized memory is all zeros...why not garbage instead?
At 3:40 PM -0700 6/10/05, Mike Hunter wrote: Hey everybody, I have a feeling that I'm missing something really obvious, but I'm having trouble understanding why the following program: Never prints anything but 0's. Kernel generally clears out memory in the background. See also the man page for 'malloc', which will describe some options that you can set by creating an appropriate symlink at /etc/malloc.conf. In particular, the -J flag. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
