From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 19:28:09 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 5D3BE36F; Sun, 18 Aug 2013 19:28:09 +0000 (UTC) (envelope-from tim@kientzle.com) Received: from monday.kientzle.com (99-115-135-74.uvs.sntcca.sbcglobal.net [99.115.135.74]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 38CA527EB; Sun, 18 Aug 2013 19:28:08 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r7IJRw3O059028; Sun, 18 Aug 2013 19:27:58 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id 83vqcakykdm7txg688pzx567y2; Sun, 18 Aug 2013 19:27:58 +0000 (UTC) (envelope-from tim@kientzle.com) Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Tim Kientzle In-Reply-To: <537622E1-F785-4BFA-B829-09DCDB484606@grondar.org> Date: Sun, 18 Aug 2013 12:27:58 -0700 Content-Transfer-Encoding: 7bit Message-Id: <932AB5CA-778E-438D-8FD3-8C0F29F3D117@kientzle.com> 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> <86r4dr5j3p.fsf@nine.des.no> <4C1BD77C-8C6B-4044-9285-5978A3BC4B70@kientzle.com> <537622E1-F785-4BFA-B829-09DCDB484606@grondar.org> To: Mark R V Murray X-Mailer: Apple Mail (2.1283) Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , secteam@freebsd.org, FreeBSD-arch Arch 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 19:28:09 -0000 On Aug 18, 2013, at 10:20 AM, Mark R V Murray wrote: >> Users could compile the null mixer into the kernel >> and load a single HW RNG driver to have precise >> control over /dev/random. Interrupt harvesting would >> be the lowest-quality source as a fall back. > > There are lots of harvest points in the kernel. Why not > take the lot? I think everyone agrees that the GENERIC kernel should use Yarrow or Fortuna to mix the available entropy sources. But clearly some people really want to be able to force /dev/random to be the unconditioned output of a particular HW RNG. I don't know if this is a good idea or not, but clearly there are people who want this. I think my proposed "null mixer" is a reasonably simple way to allow that. (Should probably call it a "passthrough mixer" rather than "null.") And I think it does so in a way that doesn't introduce horrible failure modes. >> In particular, this has a reasonable failure mode if >> someone built a kernel with only a single HW entropy >> source and the null mixer: >> * On hardware with that source, they would get >> full-speed HW entropy. > > OK. Works for me. This is me accepting a point and > changing my stance. > > This will need to be written. Yes, the "passthrough mixer" would need to be written as an alternative to Yarrow or Fortuna. My key claims: * Entropy mixers such as Yarrow, Fortuna, or passthrough are different from entropy sources. Mixers specify how /dev/random is generated from available entropy. * It makes sense to only allow one mixer in a particular kernel. That could be done via kernel options; I suppose it could be done as device modules but only one of them can actually own /dev/random. * It makes sense to access HW RNGs via device modules and to allow any number of them to be loaded and active at the same time. The above provides a good answer for GENERIC (Yarrow/Fortuna mixing all available entropy). The above also allows people to build custom kernels that connect a single entropy source to /dev/random without having horrible failure modes. >> * On hardware without that source, they would get >> the old blocking /dev/random that we had before >> Yarrow, the one that used only interrupt harvesting. > > Disagree. The fallback should be Yarrow/Fortuna. Both > do a better job with the same input. I agree Yarrow/Fortuna are better. But some people really want to only have their preferred HW RNG and are going to demand that Yarrow/Fortuna not be compiled in if they don't need it. For example, some embedded processors are starting to get HW crypto; a passthrough mixer plus HW RNG could be significant code savings compared to Yarrow or Fortuna. I am NOT claiming the old blocking /dev/random is "good"; just that it is not an entirely unacceptable failure mode for badly mismatched kernel/hardware combinations. Keep in mind such mismatches may happen accidentally: add-on HW RNG cards can fail. Tim