Date: Fri, 9 Aug 2013 00:57:48 -0600 From: Warner Losh <imp@bsdimp.com> To: obrien@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: <3E657C33-CA0D-4CDB-8CCD-72BCCC43B085@bsdimp.com> In-Reply-To: <20130808211517.GB95000@dragon.NUXI.org> References: <20130807182858.GA79286@dragon.NUXI.org> <223174A5-A146-4969-A3CF-6923EF7ECCF2@bsdimp.com> <20130808211517.GB95000@dragon.NUXI.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Aug 8, 2013, at 3:15 PM, David O'Brien wrote: > 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. >=20 > 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? For the most part, those are wrong too. > We did not like having to change so many config files -- the ARM = kernel > configs seems to be in need of additional refactoring. You need to use the mechanisms that are already present in the arm = kernel config files to accomplish this. You are doing it the wrong way, = and I'm telling you the right way. Don't argue, just fix it then. You = yourself just admitted you don't like the way you chose, why are you = arguing with me about this? >> Also, you bogusly changed way too many config files rather than the >> underlying std.* files for the ARM port. >=20 > If that is the case, why isn't "device random" in the std.* files? Because that was slavishly, and bogusly, copied from GENERIC on other = architectures. > Please address that before saying that random(4) options should live > somewhere else than where "device random" lives. No. I'm telling you the proper place to put your changes. This isn't = about making a perfect system, only how you can help to get there. I = won't be drawn into the perfect system argument. >> 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. >=20 > 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. Forcing one and only one into the kernel is wrong. You are approaching = the problem wrong if that's a requirement. That's like saying you can = have one and only one time keeping thing compiled into the kernel. You = can have several, but only use one. It is use that's important here, not = the number that are compiled in. Only one can be in use at any given = time, true. Have a design that enforces that, not that there can be only = one compiled into or loaded into the kernel at a time. This would allow = a fail-safe mechanism, as well as the knobs to disable it, rather than a = fail stupid mechanism you've proposed. >> 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. >=20 > 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)). If you can override it, then I fail to see why the fallback is so hard? Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3E657C33-CA0D-4CDB-8CCD-72BCCC43B085>