Re: [Xen-devel] [PATCH 03/10] tools/insn-fuzz: Don't use memcpy() for zero-length reads

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 27.03.17 at 14:22, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 27/03/17 12:32, Jan Beulich wrote:
>>>>> On 27.03.17 at 13:05, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 27/03/17 12:02, George Dunlap wrote:
>>>> On 27/03/17 10:56, Andrew Cooper wrote:
>>>>> For control-flow changes, the emulator needs to perform a zero-length
>>>>> instruction fetch at the target offset.  It also passes NULL for the
>>>>> destination buffer, as there is no instruction stream to collect.
>>>>>
>>>>> This trips up UBSAN, even with a size of 0.  Exclude zero-length reads 
>>>>> from
>>>>> using memcpy(), rather than excluding NULL destination pointers, to still
>>>>> catch unintentional uses of NULL.
>>>> So memcpy() will actually try to write to dst even if bytes == 0?
>>>>
>>>> That seems a bit strange, but OK:
>>>>
>>>> Acked-by: George Dunlap <george.dunlap@xxxxxxxxxx>
>>> This is the undefined behaviour sanitiser, which actually objects to
>>> passing NULL to a function annotated with
>>> __attribute__((notnull(...))).  The check is performed before making the
>>> call, and doesn't account for nothing happening if size is 0.
>> But then why is the function annotated "nonnull"? Iirc there's
>> nothing in the standard disallowing NULL to be passed here so
>> long as length is also zero, or even only calling this undefined
>> behavior.
> 
> From n1570,
> 
> 7.24.1 "String function conventions"
> 
> "Where an argument declared as size_t n specifies the length of the
> array for a function, n can have the value zero on a call to that
> function. Unless explicitly stated otherwise in the description of a
> particular function in this subclause, pointer arguments on such a call
> shall still have valid values, as described in 7.1.4. On such a call, a
> function that locates a character finds no occurrence, a function that
> compares two character sequences returns zero, and a function that
> copies characters copies zero characters."
> 
> And from 7.1.4: "Use of library functions"
> 
> "If an argument to a function has an invalid value (such as a value
> outside the domain of the function, or a pointer outside the address
> space of the program, or a null pointer, or a pointer to non-modifiable
> storage when the corresponding parameter is not const-qualified) or a
> type (after promotion) not expected by a function with variable number
> of arguments, the behavior is undefined."
> 
> 
> Therefore, by my reading, the nonnull attribute is correct.

Hmm, indeed. I continue to be surprised by how many unnecessary
restrictions the standard sets up. With the above, I'm afraid we have
a number of undefined function calls in our tree.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel