From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 11:33:28 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 970D54D3; Sun, 18 Aug 2013 11:33:28 +0000 (UTC) (envelope-from des@des.no) Received: from smtp.des.no (smtp.des.no [194.63.250.102]) by mx1.freebsd.org (Postfix) with ESMTP id 5454C22C8; Sun, 18 Aug 2013 11:33:27 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 1985543D9; Sun, 18 Aug 2013 11:33:26 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 2F13D98A; Sun, 18 Aug 2013 13:33:31 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: Mark R V Murray Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion References: <20130807183112.GA79319@dragon.NUXI.org> <86pptfnu33.fsf@nine.des.no> <20130815231713.GD76666@x96.org> <20130816002625.GE76666@x96.org> <9B274F48-0C88-4117-BEAC-1A555772A3C5@grondar.org> <86a9kf733d.fsf@nine.des.no> <0C97B866-A169-4141-8368-AA7F5B5382F4@grondar.org> <861u5r71zi.fsf@nine.des.no> <892B11BD-396D-4F82-B97C-753F72CA494D@grondar.org> Date: Sun, 18 Aug 2013 13:33:30 +0200 In-Reply-To: <892B11BD-396D-4F82-B97C-753F72CA494D@grondar.org> (Mark R. V. Murray's message of "Sun, 18 Aug 2013 11:20:03 +0100") Message-ID: <86r4dr5j3p.fsf@nine.des.no> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (berkeley-unix) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: Arthur Mesh , freebsd-arch@freebsd.org, secteam@freebsd.org, Philip Paeps 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: Sun, 18 Aug 2013 11:33:28 -0000 Mark R V Murray writes: > OK - in the context of what is currently there, it makes less sense than > that; loading RDRAND/Ivy and Nehemiah simultaneously is silly because > they are different architectures, and only one can ever work on a particu= lar > box; so what happens is some script selects the wrong one? I suppose > the probe is there to prevent this. I don't know offhand whether we support them, but there are discrete HWRNGs which might be present alongside an on-die HWRNG; and in all cases, Yarrow and / or Fortuna may be present in the kernel alongside a supported HWRNG. > We still have the anachronism where the older hardware RNGs are turned > into /dev/random devices and the newer ones supply their entropy to > the software (Yarrow) for further processing. Provided the HWRNG is of sufficient quality, the user should be allowed to use it directly (through /dev/random) without Yarrow / Fortuna. At the same time, we do not want to lose the ability to feed their output to Yarrow / Fortuna. Plugging all {P,HW}RNGs into a common framework makes it *easier*, not *harder*, to support both options. DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no