Date: Thu, 11 Oct 2012 19:40:48 +0400 From: Andrey Chernov <ache@freebsd.org> To: Peter Wemm <peter@wemm.org> Cc: mdf@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, svn-src-all@freebsd.org, David Chisnall <theraven@freebsd.org>, svn-src-head@freebsd.org, Eitan Adler <eadler@freebsd.org> Subject: Re: svn commit: r241373 - head/lib/libc/stdlib Message-ID: <5076E880.9010502@freebsd.org> In-Reply-To: <CAGE5yCrTJ=Z72YwRPhW-gui0meYoi7DUOqKGPGsk19QwDDb3FA@mail.gmail.com> References: <201210091425.q99EPFS6020787@svn.freebsd.org> <507451DE.9060909@freebsd.org> <977E1107-46D4-476F-A04D-AEFD87D1DE53@FreeBSD.org> <CAMBSHm8GCDvJCHYcrPBQ6awKWnmNpnS-9YgX1uAoOePjZhf9QA@mail.gmail.com> <CAF6rxgkaoQKdrKBUj1GFcEDtoZ8gM0w68zxn-S2bgJdntp88Kg@mail.gmail.com> <20121011114425.GA1562@garage.freebsd.pl> <5076C650.4040508@freebsd.org> <CAGE5yCrTJ=Z72YwRPhW-gui0meYoi7DUOqKGPGsk19QwDDb3FA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11.10.2012 19:23, Peter Wemm wrote: > On Thu, Oct 11, 2012 at 6:14 AM, Andrey Chernov <ache@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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5076E880.9010502>