svn commit: r241373 - head/lib/libc/stdlib

[Andrey Chernov]

On 11.10.2012 19:23, Peter Wemm wrote:
> On Thu, Oct 11, 2012 at 6:14 AM, Andrey Chernov <ache at freebsd.org> wrote:
>> On 11.10.2012 15:44, Pawel Jakub Dawidek wrote:
>>> On Tue, Oct 09, 2012 at 01:51:05PM -0400, Eitan Adler wrote:
>>>> On 9 October 2012 13:27,  <mdf at freebsd.org> wrote:
>>>>> The original behavior can be recovered by using inline assembly to
>>>>> fetch the value from a register into a local C variable; this would at
>>>>> least not rely on undefined behavior.  But I agree it's of dubious
>>>>> value anyways.
>>>>
>>>> I proposed this (with a patch). We want to move to not using
>>>> /dev/random and instead make a kernel system call directly. The patch
>>>> for this is not finished yet though.
>>>
>>> You should do something similar to:
>>>
>>>       http://people.freebsd.org/~pjd/patches/libc_arc4random.c.patch
>>>
>>
>> Already half of year I told people of our serious problem with kernel's
>> arc4 (used here in sysctl) - it have very weak initialization at the
>> kernel start (only from processor clock) which is auto-fixed because of
>> its periodic reseeds, but only at the next reseed which happens late. I
>> post two patches (both working, one using atomic, another don't use it)
>> which reseeds kernel's arc4 as fast as we have enough real entropy.
>> NetBSD don't have this problem because of their different kernel's arc4
>> implementation.
> 
> How "late" is late?  Since this was a userland patch, has it been
> reseeded by then?

See /sys/libkern/arc4random.c
#define ARC4_RESEED_SECONDS 300
i.e. first 5 minutes at least it is very bad seeded and vulnerable. But
we don't have guarantee to have enough entropy even after first 5
minutes, it very depends of entropy sources turned on the machine
configuration at whole (diskless, etc).

Moreover, arc4random(3) code have its own reseed happens after
arc4_count = 1600000;
(divided by 4) iterations which increases bad seeded bytes initially
taken from kernel's arc4 until whole count will be exhausted which is
_very_ long time (consider that typical application issue only several
rare arc4random(3) calls and exits, left arc4_count not decreased
globally at all).

> Regardless, this is getting way off topic from using an xor of an
> uninitialized userland variable and what the compiler optimizer might
> do with it.
> 
> Of course that's assuming it is even a memory based stack.  The sparc
> or ia64 register stack makes that xor even more dubious.

I pass this subj to the people who knows clang compiler better to say
for sure is it right to generate LLVM intermediate
call void @srand(i32 undef)
or not. Xoring the stack (or register) there is not essential step.