From owner-freebsd-arch@FreeBSD.ORG Thu Aug 15 10:10:20 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 21EA0EF6; Thu, 15 Aug 2013 10:10:20 +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 D8E1524A8; Thu, 15 Aug 2013 10:10:19 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 39BDC425E; Thu, 15 Aug 2013 10:10:18 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id E7F8C3C5; Thu, 15 Aug 2013 12:09:52 +0200 (CEST) From: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= To: obrien@freebsd.org Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion References: <20130807183112.GA79319@dragon.NUXI.org> Date: Thu, 15 Aug 2013 12:09:52 +0200 In-Reply-To: <20130807183112.GA79319@dragon.NUXI.org> (David O'Brien's message of "Wed, 7 Aug 2013 11:31:12 -0700") Message-ID: <86pptfnu33.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: Thu, 15 Aug 2013 10:10:20 -0000 "David O'Brien" writes: > 20120913: > The random(4) support for the VIA hardware random number > generator (`PADLOCK') is no longer enabled unconditionally. > Add the PADLOCK_RNG option in the custom kernel config if > needed. The GENERIC kernels on i386 and amd64 do include the > option, so the change only affects the custom kernel > configurations. I still haven't received an answer to my question about options vs devices. AFAICT there is no reason whatsoever to have padlock or yarrow as kernel options rather than devices. The fact that they are available as modules is be a big hint that they should be devices, not options. The fact that we haven't been consistent in the past is not an excuse to continue making the same mistake in the present and future. I also believe that randomness is sufficiently important that we should have yarrow (or fortuna, when it materializes) in DEFAULTS. Users who don't want it (or prefer to load it as a module) can disable it with a nodevice entry in their kernel config. Also, rc scripts for services which require a PRNG (such as sshd) should complain and abort if kern.random.adaptors is empty. BTW, I see that the sysctl was changed (per my request) to return an empty string if no adaptors are present: if (LIST_EMPTY(&adaptors)) error =3D SYSCTL_OUT(req, "", strlen("")); LIST_FOREACH(rpp, &adaptors, entries) { if (0 !=3D SYSCTL_OUT(req, rpp->name, strlen(rpp->name))) break; } but if I read the code correctly, if multiple adaptors are present, their names will be concatenated with no separator. You probably want something like this: int comma =3D 0; /* ... */ LIST_FOREACH(rpp, &adaptors, entries) { if (!comma) { if (0 !=3D SYSCTL_OUT(req, ",", 1)) break; comma =3D 1; } if (0 !=3D SYSCTL_OUT(req, rpp->name, strlen(rpp->name))) break; } (and a minor nit: strlen("") is a strange way to spell 0...) DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no