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

[Kevin Wolf <kwolf@redhat.com>]

Am 06.12.2009 13:00, schrieb malc:
> On Sun, 6 Dec 2009, Markus Armbruster wrote:
> 
>> malc <av1474@comtv.ru> writes:
>>
>>> On Sun, 6 Dec 2009, Markus Armbruster wrote:
>>>
>>>> malc <av1474@comtv.ru> 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