Re: [Qemu-devel] [PATCH] Permit zero-sized qemu_malloc() & friends

[malc]

On Sun, 6 Dec 2009, Markus Armbruster wrote:

> malc <address@hidden> writes:
> 
> > On Sun, 6 Dec 2009, Markus Armbruster wrote:
> >
> >> malc <address@hidden> 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

or anything else with said bit set will yield EFAULT. Consequently the
code you cited as a well behaving malloc(0) call site will bomb.

[1] Under 32bit Linux that is, with the usual split.

-- 
mailto:address@hidden