From owner-freebsd-hackers@FreeBSD.ORG Mon Jun 13 19:50:29 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 64A1816A41C for ; Mon, 13 Jun 2005 19:50:29 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: from pne-smtpout2-sn2.hy.skanova.net (pne-smtpout2-sn2.hy.skanova.net [81.228.8.164]) by mx1.FreeBSD.org (Postfix) with ESMTP id 03BF743D1F for ; Mon, 13 Jun 2005 19:50:28 +0000 (GMT) (envelope-from ertr1013@student.uu.se) Received: from falcon.midgard.homeip.net (212.181.162.201) by pne-smtpout2-sn2.hy.skanova.net (7.2.059.6) id 429C53B6002EEBEB for freebsd-hackers@freebsd.org; Mon, 13 Jun 2005 21:50:27 +0200 Received: (qmail 90096 invoked by uid 1001); 13 Jun 2005 21:50:26 +0200 Date: Mon, 13 Jun 2005 21:50:26 +0200 From: Erik Trulsson To: Mike Hunter Message-ID: <20050613195026.GA90010@falcon.midgard.homeip.net> Mail-Followup-To: Mike Hunter , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-hackers@freebsd.org References: <20050610224058.GA11336@malcolm.berkeley.edu> <86vf4lb110.fsf@xps.des.no> <20050613193150.GA75218@malcolm.berkeley.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20050613193150.GA75218@malcolm.berkeley.edu> User-Agent: Mutt/1.5.9i Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , freebsd-hackers@freebsd.org Subject: Re: unitialized memory is all zeros...why not garbage instead? X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2005 19:50:29 -0000 On Mon, Jun 13, 2005 at 12:31:50PM -0700, Mike Hunter wrote: > On Jun 11, "Dag-Erling Smrgrav" wrote: > > > Mike Hunter 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. -- Erik Trulsson ertr1013@student.uu.se