Date: Wed, 7 Aug 2013 11:31:12 -0700 From: "David O'Brien" <obrien@FreeBSD.org> To: Philip Paeps <philip@freebsd.org> Cc: Arthur Mesh <arthurmesh@gmail.com>, secteam@freebsd.org, freebsd-arch@freebsd.org Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130807183112.GA79319@dragon.NUXI.org> In-Reply-To: <20130731104009.GG59509@rincewind.paeps.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
Replying to an earlier comments made:
On Wed, Jul 31, 2013 at 12:40:09PM +0200, Philip Paeps wrote:
> On 2013-07-29 20:26:27 (+0000), David E. O'Brien <obrien@FreeBSD.org> wrote:
> > New Revision: 253779
> > Log:
> > Decouple yarrow from random(4) device.
> > * Make Yarrow an optional kernel component -- enabled by
> > "YARROW_RNG" option.
..
> Of course, we expect
> people to read UPDATING, but disabling functionality that has been
> enabled by default "forever" without any warning, especially in a
> security-related context is not cool.
20120913:
The random(4) support for the VIA hardware random number
generator (`PADLOCK') is no longer enabled unconditionally.
Add the PADLOCK_RNG option in the custom kernel config if
needed. The GENERIC kernels on i386 and amd64 do include the
option, so the change only affects the custom kernel
configurations.
This changed a kernel that was secure since 2004-04-09 into less secure
one [if you had the right hardware].
So we do have some precedence to look at.
Besides the UPDATING file, we also have the release notes for a .0
release. Folks should not be blindly moving to a .0 release with out
reading them if they have a custom kernel.
There must be some what forward to making changes like this in FreeBSD.
I don't recall any other desired changes in the past that simply weren't
possible because it would cause someone with a custom kernel a problem.
> Please change YARROW_RNG to
> RNG_NO_YARROW or something similar and keep it in by default.
Given the direction of the patch, I'm don't know how to cleanly inverse
logic this.
As MarkM has mentioned he's working on another RNG that could be used in
place of Yarrow. For $WORK's FIPS-140 and Common Criteria requirements
we're working on a NIST SP 800-90-A compliant HMAC_DRBG that we would use
instead of Yarrow.
> > Unplugging random_adaptor from random(4) is not supported, and is
> > probably a bad idea anyway, due to potential loss of entropy
> > pools.
>
> I agree.
> But what happens to the adaptors if you kldunload random?
The same thing that happens today. We allow the kldunloading of today's
random.ko. As noted, kldunloading of the adaptors is disallowed -- their
*_modevent() routines MOD_UNLOAD returns EINVAL.
This changeset does not change this behavior. This changeset is intended
to only be an infrastructure change.
> > * If the kernel doesn't have any random_adaptor adapters present
> > then the creation of /dev/random is postponed until next
> > random_adaptor is kldload'ed.
>
> This worries me. A fast-booting system might want random numbers in
> userland before a random_adaptor is loaded (and properly seeded?). We
> don't have particularly stellar support for early random numbers, but we
> should be careful not to make it worse.
>
> Also: what happens to in-kernel consumers of random (like TCP) before
> the first random_adaptor is attached (and properly seeded)?
What specific routine(s)? When do they first run during boot?
If they are called early in boot, the behavior is the same.
If they are called late in boot, you get less secure randomness.
It is interesting to instrument a GENERIC kernel's arc4rand() and see
how many times it is called before becoming more secure:
FreeBSD/SMP: 1 package(s) x 2 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
*** random device not loaded; using insecure entropy
*** arc4rand(): arc4_randomstir()ed
...
Timecounters tick every 1.000 msec
*** arc4rand(): Didn't arc4_randomstir()
[6 times]
...
cd0: Attempt to query device size failed: NOT READY, Medium not present
*** arc4rand(): Didn't arc4_randomstir()
Trying to mount root from ufs:/dev/ada0s1a [rw,noatime]...
*** arc4rand(): Didn't arc4_randomstir()
*** random_yarrow_unblock(): arc4rand_iniseed_state set ARC4_ENTR_NONE -> ARC4_ENTR_HAVE
*** arc4rand(): arc4_randomstir()ed
*** initrandom_start()
...
Starting Network: lo0 em0.
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
--
-- David (obrien@NUXI.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130807183112.GA79319>