lkml.org 
[lkml]   [2014]   [Oct]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: drivers: random: Shift out-of-bounds in _mix_pool_bytes
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)

Alan


\
 
 \ /
  Last update: 2014-10-25 22:41    [W:0.102 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site