Date: Tue, 30 Jul 2013 17:07:46 -0700 From: "David O'Brien" <obrien@FreeBSD.org> To: Andrey Chernov <ache@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r253786 - in head/sys: dev/random modules/padlock_rng modules/rdrand_rng modules/yarrow_rng Message-ID: <20130731000746.GA65806@dragon.NUXI.org> In-Reply-To: <51F6E0AB.3010001@freebsd.org> References: <201307292058.r6TKwA56031193@svn.freebsd.org> <51F6E0AB.3010001@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Jul 30, 2013 at 01:37:47AM +0400, Andrey Chernov wrote: > On 30.07.2013 0:58, David E. O'Brien wrote: > > Decouple yarrow from random(4) device. .. > > We currently have 3 random_adaptors: > > + yarrow > > + rdrand (ivy.c) > > + nehemeiah > > After this commit we again have a problem with badly initialized arc4 > (for rdrand and nehemiah cases, when yarrow isn't loaded), because only > yarrow have reinit code. I believe you're talking about this code in sys/libkern/arc4random.c:arc4rand() if (atomic_cmpset_int(&arc4rand_iniseed_state, ARC4_ENTR_HAVE, ARC4_ENTR_SEED) || reseed || (arc4_numruns > ARC4_RESEED_BYTES) || (tv.tv_sec > arc4_t_reseed)) arc4_randomstir(); Without setting 'arc4rand_iniseed_state' from ARC4_ENTR_NONE -> ARC4_ENTR_HAVE, we would still call arc4_randomstir() periodically due to (tv.tv_sec > arc4_t_reseed) and (arc4_numruns > ARC4_RESEED_BYTES). The lacking part is forcing a arc4_randomstir() call the next arc4rand()/arc4random() call after the PRNG is initialized. However, I don't think this has a large impact. But, this situation isn't the big issue. We have an existing bug where if one is using a hardware RNG, read_random() never gets changed from simply being read_random_phony() due to random_modevent() not calling random_yarrow_init_harvester() thru '(*random_systat->init)()'. Thus arc4random() has been weak for thus using the Intel RDRAND or Via Padlock. This is something we're going to address, but this commit is an infrastructure improvement commit (decoupling one thing from another), not addressing existing bugs or short comings. thoughts? -- -- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130731000746.GA65806>