From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NHZ5e-0005XH-0Y for qemu-devel@nongnu.org; Mon, 07 Dec 2009 03:37:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NHZ5Z-0005Wg-FT for qemu-devel@nongnu.org; Mon, 07 Dec 2009 03:37:05 -0500 Received: from [199.232.76.173] (port=37179 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NHZ5Z-0005Wd-9k for qemu-devel@nongnu.org; Mon, 07 Dec 2009 03:37:01 -0500 Received: from mx1.redhat.com ([209.132.183.28]:23157) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NHZ5Y-0004Cx-On for qemu-devel@nongnu.org; Mon, 07 Dec 2009 03:37:01 -0500 Message-ID: <4B1CBE53.5010906@redhat.com> Date: Mon, 07 Dec 2009 09:35:31 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends References: <4B193DA5.6040507@codemonkey.ws> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: malc Cc: Paul Brook , Markus Armbruster , qemu-devel@nongnu.org Am 06.12.2009 13:00, schrieb malc: > On Sun, 6 Dec 2009, Markus Armbruster wrote: > >> malc writes: >> >>> On Sun, 6 Dec 2009, Markus Armbruster wrote: >>> >>>> malc writes: >>>> >>> >>> [..snip..] >>> >>>> >>>> read(fd, malloc(0), 0) is just fine, because read() doesn't touch the >>>> buffer when the size is zero. >>>> >>> >>> [..snip..] >>> >>> Yet under linux the address is checked even for zero case. >> >> Any value you can obtain from malloc() passes that check. >> >> Why does the fact that you can construct pointers that don't pass this >> check matter for our discussion of malloc()? >> >>>>> I don't know what a "valid pointer" in this context represents. >>>> >>>> I can talk standardese, if you prefer :) >>>> >>>> malloc() either returns either a null pointer or a pointer to the >>>> allocated space. In either case, you must not dereference the pointer. >>>> >>>> OpenBSD chooses to return a pointer to the allocated space. It chooses >>>> to catch common ways to dereference the pointer. >>>> >>>> Your "p = (void *)-1" is neither a null pointer nor can it point to >>>> allocated space on your particular system. Hence, it cannot be a value >>>> of malloc() for any argument, and therefore what read() does with it on >>>> that particular system doesn't matter. >>>> >>> >>> Here, i believe, you are inventing artificial restrictions on how >>> malloc behaves, i don't see anything that prevents the implementor >>> from setting aside a range of addresses with 31st bit set as an >>> indicator of "zero" allocations, and then happily giving it to the >>> user of malloc and consumming it in free. >> >> Misunderstanding? Such behavior is indeed permissible, and I can't see >> where I restricted it away. An implementation that behaves as you >> describe returns "pointer to allocated space". That the pointer has >> some funny bit set doesn't matter. That it can't be dereferenced is >> just fine. >> >> I'm not sure what your point is. If it is that malloc(0) can return a >> value that cannot be passed to a zero-sized read(), then I fear you have >> not made your point. > > One more attempt to make it clearer. If you agree that this behaviour > is permissible then the game is lost as things stand now under Linux, > since replacing [1]: > > void *p = (void *) -1 > with: > void *p = (void *) 0x80000000 Then this implementation of malloc(0) isn't suitable for a libc running on Linux - despite its general permissibility. You have a point if, and only if, you can reproduce such misbehaviour with a real malloc of a real libc that isn't constructed to work against the kernel but to fit it. So far I can't see that you have found any. By the way, this whole discussion about theoretical malloc(0) return values doesn't even matter here. The patch replaces it by malloc(1), with which we both are very confident that you can pass its return value to read for reading 0 bytes, right? Kevin