Date: Thu, 8 Aug 2013 14:15:17 -0700 From: "David O'Brien" <obrien@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> 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: <20130808211517.GB95000@dragon.NUXI.org> In-Reply-To: <223174A5-A146-4969-A3CF-6923EF7ECCF2@bsdimp.com> References: <20130807182858.GA79286@dragon.NUXI.org> <223174A5-A146-4969-A3CF-6923EF7ECCF2@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Aug 08, 2013 at 01:20:19PM -0600, Warner Losh wrote: > The sheer number of config files you changed says this is a bad idea, > or you are during something very wrong. Why? That's the sheer number of config files that have "device random" in them. How it reasonable for "device random" to be in them but not random(4) options? We did not like having to change so many config files -- the ARM kernel configs seems to be in need of additional refactoring. > Also, you bogusly changed way too many config files rather than the > underlying std.* files for the ARM port. If that is the case, why isn't "device random" in the std.* files? Please address that before saying that random(4) options should live somewhere else than where "device random" lives. > What's wrong with having yarrow as the default, fallback mechanism. And > why do you have a design that seems to force one, and only one, into > the kernel? The way it is now we fail bad rather than fail to yarrow > fallback. This seems unwise. How does it force 1 and only 1 into the kernel? If there were some MIPS or ARM HW they would also be in the kernel. When markm@ completes his Fortuna work, it could (and likely would) also live beside Yarrow. Or a NIST SP 800-90-A compliant HMAC_DRBG can also live in the kernel beside Yarrow (and Fortuna). Obviously at the point of having more than one SW PRNG we'll have a selection mechanism to "break ties". Right now the code only handles that for HW. > I haven't read the code in detail, but I don't see how I'd override > the CPU's random number unit with one from a plug-in board when it is > present. Please read the code to see how that is handled in sys/dev/random/probe.c:random_ident_hardware(). Note that my commit did not change the logic here (just updated the implementation of it). It's the same logic we've had since 2004 (r128059 and updated in 2012(r240135)). -- -- David (obrien@FreeBSD.org)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130808211517.GB95000>