Re: drivers: random: Shift out-of-bounds in _mix_pool_bytes

[Andrey Ryabinin <ryabinin.a.a@gmail.com>]

2014-10-25 23:30 GMT+03:00 One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>:
> On Fri, 24 Oct 2014 20:50:46 -0400
> Sasha Levin <sasha.levin@oracle.com> wrote:
>
>> On 10/24/2014 06:22 PM, H. Peter Anvin wrote:
>> >> By the principle of least surprise, I would expect "__u32 >> N", where
>> >> > N >= 32 to return zero instead of random garbage.  For N < 32 it will
>> >> > return progressively smaller numbers, until it has shifted away all of
>> >> > the set bits, at which turn it will return 0.  For it suddenly to jump
>> >> > up once N = 32 is used, is counter-intuitive.
>> >> >
>> > That's why it is undefined.
>>
>> Now I'm curious about things like "memcpy(ptr, NULL, 0)". According to the
>> standard they're undefined, and since we're using gcc's implementation for
>> memcpy() we are doing "undefined memcpy" in quite a few places in the kernel.
>>
>> Is it an issue, or would you expect memcpy() to not deref the "from" ptr
>> since length is 0?
>
> No. Furthermore gcc 4.9 actually has optimiser magic around this. See the
> "Porting to gcc 4.9" notes.
>
> --------
>
>  GCC might now optimize away the null pointer check in code like:
>
>
>   int copy (int* dest, int* src, size_t nbytes) {
>     memmove (dest, src, nbytes);
>     if (src != NULL)
>       return *src;
>     return 0;
>   }
>
> The pointers passed to memmove (and similar functions in <string.h>) must
> be non-null even when nbytes==0, so GCC can use that information to
> remove the check after the memmove call. Calling copy(p, NULL, 0) can
> therefore deference a null pointer and crash.
>
> -------------
>
> Which is unfortunate because an operating system has a lot of legitimate
> reasons to copy data to address 0 (on many processors its the exception
> vectors for example)

That is why kernel builds with -fno-delete-null-pointer-checks.

>
> Alan



-- 
Best regards,
Andrey Ryabinin