From owner-freebsd-arch@FreeBSD.ORG Mon Aug 19 07:18:26 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 D8C4AE9E for ; Mon, 19 Aug 2013 07:18:26 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9B1AF2787 for ; Mon, 19 Aug 2013 07:18:26 +0000 (UTC) Received: by mail-oa0-f49.google.com with SMTP id n10so2295638oag.22 for ; Mon, 19 Aug 2013 00:18:25 -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=UVvole1mAWEkpZT0AHM/RwES0xJzQ/XoSWgleYXKtVY=; b=GkMK5a9ib6PHI4hR8lEjUGFeXd2dxeFvskD9fWwd5ELqziJclEBVU6AGNXK5rqz1ZG MFLwPnQWwM9qhk1ECaM2245lDdPdIFZBz3M/ACOn0NE6G1bHLbE3bIFNsUJjjpH/A+PO rIjyifRfBejnoVo/boITygcqzvjZJMmD+GaHAhbMw3Xvc4mQSEid23DgvBOBBplNEy92 1SVyWq4fsG/YqjMUAbyHPODhTA/M9yPdgTzjwvrISclV7CMv0WHTpjEvYdc3w51vsrT2 xc6aHaWpNa8BgYTyMmoRXgNNmXecFuTU3vFRNnr9iXzfjtFzwEgTl1rTjw6EXI0gu6pA JCGQ== X-Gm-Message-State: ALoCoQkPbRvxOidy4YGpStR3veoiufwMfTEveL477F3QJvPJoAPn+t5AtSWxst/bYvZKClKmKfsM X-Received: by 10.60.140.168 with SMTP id rh8mr481023oeb.76.1376896705749; Mon, 19 Aug 2013 00:18:25 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id b5sm14872976obj.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 00:18:24 -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: Date: Mon, 19 Aug 2013 01:18:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <71A92486-2213-421E-B3D2-E55816C18924@bsdimp.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> <932AB5CA-778E-438D-8FD3-8C0F29F3D117@kientzle.com> To: Mark R V Murray X-Mailer: Apple Mail (2.1085) Cc: Tim Kientzle , FreeBSD-arch Arch , secteam@freebsd.org, =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= 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: Mon, 19 Aug 2013 07:18:27 -0000 On Aug 18, 2013, at 2:02 PM, Mark R V Murray wrote: > On 18 Aug 2013, at 20:27, Tim Kientzle wrote: >> 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. >=20 > Agreed. (This includes my change of position on the > subject.) >=20 > Others want Yarrow/Fortuna no matter what. If we're going to allow passthrough, we should require the kernel config = to explicitly do something to get pass through. nodevice yarrow device random_passthrough would be my suggestion. >> 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. >=20 > True. Yarrow and Fortuna were designed to shield against > those very failure modes. They treat ALL entropy sources > as suspect and endeavour to be secure irregardless. >=20 > I propose two-route device: >=20 > Route 1 (SW): > Yarrow/Fortuna (choosable between the two for now), > and a fallback for Route 2. It should be possible to > build a kernel without this route. >=20 > Route 2 (HW): > Minimally-processed randomness directly from a dedicated > source, similar to the rdrand/ivy device, but with the > actual source abstracted. If no suitable source is > available, then this whole route fails. This is where > some useful "pluggability" can come. If this fails to > fall back; then perhaps a "I don't care" vs "PANIC!!" > fallback can be supplied. Here lie the dragons. I'd go so far as to say that if you have random in your kernel, then you = need to specify some "filter" or you get a compile-time error. = Specifying yarrow via DEFAULTS or std.foo is fine by me, since both of = those can be overriden fairly easily.... I'd also think we'd want to = FAIL_PANIC or FAIL_BLOCKING, and have that choice hard wired at some = level too, to be explicit about things. But maybe that's gilding things = a bit too much and a tunable would suffice... Warner