From owner-freebsd-arch@FreeBSD.ORG Fri Aug 9 06:57:59 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id BA3F347E for ; Fri, 9 Aug 2013 06:57:59 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f175.google.com (mail-ie0-f175.google.com [209.85.223.175]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 876BF21EC for ; Fri, 9 Aug 2013 06:57:59 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id s9so3615088iec.34 for ; Thu, 08 Aug 2013 23:57:53 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=4N7QxnD3KMQzIxavbAv37R9SebSwax5N0xF6u8hDyWI=; b=n7iVUnVwE/7E1hWsGVBcb7zK/VJ2IJQU3IqatT5vuT5m6ApMoUS/2l5l16M33EGDO0 mjzIV5CWZ4A8GpmihHc+gVr/LoGH1Dyu1XzjxEbWu0kTFtInC7VqEnkM9HZ/3bvjx7j9 21i2wwuxLJMnen2YyFEgUYcbdP4skINfCGzOEMZ9/13L9/cXJ6iiRw0xfWOsJYA7nfw/ Y+Fh9o0U7CduDf1t5yP2HuN9wSYRDHD8mZAlU+xERrZ3worwi4TOI0sTuOiroqQgHVVb 4ZAmTWHOWSuNlYer08d6oTGv7SPCnWTo0OIsGJt4pjmXqa3C/qDlxo3HJwJvALV0wjPd HT8A== X-Gm-Message-State: ALoCoQkLp8IUmuMj4aglt3I6uqjwmerO80gJNCiSxLOsOccn/FGWbn3zMWkevz/UbTUwJMb+IiMO X-Received: by 10.50.88.7 with SMTP id bc7mr1369387igb.37.1376031473613; Thu, 08 Aug 2013 23:57:53 -0700 (PDT) Received: from [10.0.0.53] (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id ht10sm2271001igb.2.2013.08.08.23.57.52 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 08 Aug 2013 23:57:52 -0700 (PDT) Sender: Warner Losh Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130808211517.GB95000@dragon.NUXI.org> Date: Fri, 9 Aug 2013 00:57:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <3E657C33-CA0D-4CDB-8CCD-72BCCC43B085@bsdimp.com> References: <20130807182858.GA79286@dragon.NUXI.org> <223174A5-A146-4969-A3CF-6923EF7ECCF2@bsdimp.com> <20130808211517.GB95000@dragon.NUXI.org> To: obrien@freebsd.org X-Mailer: Apple Mail (2.1085) Cc: Arthur Mesh , secteam@freebsd.org, freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 06:57:59 -0000 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