From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 01:30:37 2013 Return-Path: Delivered-To: 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 1E6AF6F; Sun, 18 Aug 2013 01:30:37 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail109.syd.optusnet.com.au (mail109.syd.optusnet.com.au [211.29.132.80]) by mx1.freebsd.org (Postfix) with ESMTP id D6E782690; Sun, 18 Aug 2013 01:30:36 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail109.syd.optusnet.com.au (Postfix) with ESMTPS id CD8C5D621CC; Sun, 18 Aug 2013 11:30:23 +1000 (EST) Date: Sun, 18 Aug 2013 11:30:22 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Poul-Henning Kamp Subject: Re: suspend/resume time-gap and expiration timers in network stack In-Reply-To: <10980.1376759837@critter.freebsd.dk> Message-ID: <20130818101945.T880@besplex.bde.org> References: <20130817.173019.1478850854128616078.hrs@allbsd.org> <20130818004948.L4326@besplex.bde.org> <10980.1376759837@critter.freebsd.dk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=-G4Y16xk-08A:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=lWkSEhi8E8gA:10 a=F3WKRGcORFVHpHynyrcA:9 a=CjuIK1q_8ugA:10 Cc: 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: Sun, 18 Aug 2013 01:30:37 -0000 On Sat, 17 Aug 2013, Poul-Henning Kamp wrote: > In message <20130818004948.L4326@besplex.bde.org>, Bruce Evans writes: > >> The boot time is then set to the real time, >> to maintain the (buggy) invariant real_time = monotonic_time + boottime. > >> real_time = monotonic_time + base_time > > That was a lot of verbiage just to change the name of a variable :-) No, it just wasn't verbose enough to describe the full details for the boottime[bin,etc] variable. It must be maintained (with fixes) for use by the kern.boottime sysctl. In general, every clock id may have a different base with different initialization requirements. The bases for CLOCK_MONOTONIC and CLOCK_REALTIME differ by leap seconds and not much more. To avoid adding the base to the monotonic time every time it is used, the base for the monotonic time should be 0, with the offset from the boot time part of the timehands. You even get a free optimization from this. The difference between CLOCK_REALTIME and CLOCK_MONOTONIC becomes just the leap seconds adjustment. This is an integer, so it is easier to lock and more efficient to add than a full bintime. Bruce From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 04:00:14 2013 Return-Path: Delivered-To: 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 0DEF7FD; Sun, 18 Aug 2013 04:00:14 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail106.syd.optusnet.com.au (mail106.syd.optusnet.com.au [211.29.132.42]) by mx1.freebsd.org (Postfix) with ESMTP id 937D62CB6; Sun, 18 Aug 2013 04:00:13 +0000 (UTC) Received: from c122-106-156-23.carlnfd1.nsw.optusnet.com.au (c122-106-156-23.carlnfd1.nsw.optusnet.com.au [122.106.156.23]) by mail106.syd.optusnet.com.au (Postfix) with ESMTPS id 99C4E3C1F37; Sun, 18 Aug 2013 14:00:08 +1000 (EST) Date: Sun, 18 Aug 2013 14:00:07 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Bruce Evans Subject: Re: suspend/resume time-gap and expiration timers in network stack In-Reply-To: <20130818004948.L4326@besplex.bde.org> Message-ID: <20130818123906.A942@besplex.bde.org> References: <20130817.173019.1478850854128616078.hrs@allbsd.org> <20130818004948.L4326@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Optus-CM-Score: 0 X-Optus-CM-Analysis: v=2.1 cv=bpB1Wiqi c=1 sm=1 tr=0 a=ebeQFi2P/qHVC0Yw9JDJ4g==:117 a=PO7r1zJSAAAA:8 a=-G4Y16xk-08A:10 a=kj9zAlcOel0A:10 a=JzwRw_2MAAAA:8 a=lWkSEhi8E8gA:10 a=_Q7SZsZ_jrx4-4ViMhoA:9 a=CjuIK1q_8ugA:10 Cc: 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: Sun, 18 Aug 2013 04:00:14 -0000 On Sun, 18 Aug 2013, I wrote: > ... > just 3 types of jump should change the boot time. > > Types of jumps: > 1. when the system is initialized. Times are set by eventually calling > ... > 2. Many systems have the RTC on wall clock time. Both of the times set by > ... > 3. Many systems set the real time more precisely using ntp. This is best > ... > ... > The acpica code that fixes up the real time on resume is hard to find. > I can only find acpi_resync_clock(). This is under an __amd64__ ifdef > and a boolean sysctl that defaults to on. It is very broken: > > % static void > % acpi_resync_clock(struct acpi_softc *sc) > % { > % #ifdef __amd64__ > % if (!acpi_reset_clock) > % return; > % % /* > % * Warm up timecounter again and reset system clock. > % */ > % (void)timecounter->tc_get_timecount(timecounter); > % (void)timecounter->tc_get_timecount(timecounter); > % inittodr(time_second + sc->acpi_sleep_delay); > % #endif > % } > > The time_second + ... arg for inittodr() is probably out of date, but > it is only used if reading the RTC hardware fails. This function is > very broken since it doesn't use the RTC delta. It is basically missing > all of the initialization steps (1)-(3), plus any later tracking of the > real time done by ntp. The largest error is when the RTC is on wall > clock time. Then the above gives an error of 10 hours or so. Oops, inittodr() adds the current gmtoffset, so it has steps (1) and (2) built in and doesn't have a very large error. Starting in about FreeBSD-9, there is also periodic update of the RTC with a default period of 1800 seconds. This gives some of the preciseness of (3), but reading and writing of the RTC have errors of up to about 1 second each in at least the x86 implementation, so the preciseness is not nearly as much as ntp's, and these periodic updates are just bugs. They only help keep the error in the RTC small after a panic or power failure. Other cases are better handled by only reading the RTC at critical points like suspend and resume and keeping track of the difference between it and the current (timecounter) time then, except for writing it on reboot. Suspend/resume is unlike reboot on at least x86 since it retains enough state in memory variables that can keep track of the difference better than the RTC hardware. See Linux for the complications needed to read and write AT RTCs without losing a second for each. My version only has these complications for reading. For writing, it just skips the write if the change would be -1, 0, or 1 seconds. Writing differences of 0 (which turn into differences of up to 1 because of no synchronization) is obviously wrong. Forgetting about differences of -1 and 1 is no worse than getting errors of -1 or 1 from the missing synchronization. For larger differences, the fix is larger than the possible error from no synchronization, so it may as well be made provided nothing requires synchronization with the old readings of the RTC, Old i386 versions of inittodr() achieved essentially the same result as my resettodr() gives, by refusing to update the current time when the time difference is -1, 0 or 1 second. This has been lost. Writing the AT RTC is a heavyweight operation that also stops its interrupts, so may mess up synchronization of anything that uses it as an event timer. Its locking has always been completely broken. The non-hardware part of it used to be protected by spclock(). Now it is protected by Giant at best, so context switches may occur during the hareware part of the update during which its interrupts are disabled. Event timers using it are then broken for as long as the context switch... Reading of the AT RTC is lighter weight, and the locking in it is less broken. It used to be be almost all protected by splhigh(). Now it is not almost all protected by critical_enter(). The main critical_enter() be in the same place as the splhigh() was, but it is now a little later so there is a race between seeing RTC_TUP and acting on this. Reading and writing of the AT RTC should always have used a hard interrupt disable, to prevent any interference. Bruce From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 09:36:24 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 C35FC529; Sun, 18 Aug 2013 09:36:24 +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 82E1A27F3; Sun, 18 Aug 2013 09:36:24 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 70302425F; Sun, 18 Aug 2013 09:36:17 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id 80B0D85F; Sun, 18 Aug 2013 11:36:23 +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> Date: Sun, 18 Aug 2013 11:36:22 +0200 In-Reply-To: <9B274F48-0C88-4117-BEAC-1A555772A3C5@grondar.org> (Mark R. V. Murray's message of "Fri, 16 Aug 2013 18:26:06 +0100") Message-ID: <86a9kf733d.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 , Philip Paeps , 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: Sun, 18 Aug 2013 09:36:24 -0000 Mark R V Murray writes: > When I commit Fortuna, I'll also be adding (back) options YARROW_RNG > and FORTUNA_RNG, Why would you do that? What's wrong with "device fortuna"? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 09:43:09 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 B7C1E637; Sun, 18 Aug 2013 09:43:09 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B22C2831; Sun, 18 Aug 2013 09:43:09 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VAzVq-000Jxf-Ad; Sun, 18 Aug 2013 10:43:07 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_17AA819E-EF52-4F1B-A7C9-CBDB5719625D"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <86a9kf733d.fsf@nine.des.no> Date: Sun, 18 Aug 2013 10:42:58 +0100 Message-Id: <83B2EB1F-B308-486B-97A5-1988C0EF6C23@grondar.org> 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> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: Arthur Mesh , Philip Paeps , 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: Sun, 18 Aug 2013 09:43:09 -0000 --Apple-Mail=_17AA819E-EF52-4F1B-A7C9-CBDB5719625D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 18 Aug 2013, at 10:36, Dag-Erling Sm=F8rgrav wrote: > Mark R V Murray writes: >> When I commit Fortuna, I'll also be adding (back) options YARROW_RNG >> and FORTUNA_RNG, >=20 > Why would you do that? What's wrong with "device fortuna"? Nothing. :-) I'll do it that way. M --=20 Mark R V Murray --Apple-Mail=_17AA819E-EF52-4F1B-A7C9-CBDB5719625D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhCXKd58vKOKE6LNAQqA0AP9H0Mqt3RymK/pLUEIEQwv05quPBqUMwHi yis1FCVILZGjG3zL9arAD/g1+VfLz+DOVCcPVSmwmDyB9eokT8B8wSgMCtauy8IO iCE19jCyLVEYXO4NdnlJdcuV+xI2mwLK0G7QqFZ0jAtSMQsmaojXgQsPlmYexDpU Z1yY+tY1n6U= =YSu8 -----END PGP SIGNATURE----- --Apple-Mail=_17AA819E-EF52-4F1B-A7C9-CBDB5719625D-- From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 09:52:08 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 908BF9CF; Sun, 18 Aug 2013 09:52:08 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 541102891; Sun, 18 Aug 2013 09:52:08 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VAzeX-000Jya-8A; Sun, 18 Aug 2013 10:52:06 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_36FDA83C-4887-4B3D-BE0D-CB9CB55DC588"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <86a9kf733d.fsf@nine.des.no> Date: Sun, 18 Aug 2013 10:52:04 +0100 Message-Id: <0C97B866-A169-4141-8368-AA7F5B5382F4@grondar.org> 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> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: Arthur Mesh , Philip Paeps , 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: Sun, 18 Aug 2013 09:52:08 -0000 --Apple-Mail=_36FDA83C-4887-4B3D-BE0D-CB9CB55DC588 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 18 Aug 2013, at 10:36, Dag-Erling Sm=F8rgrav wrote: > Mark R V Murray writes: >> When I commit Fortuna, I'll also be adding (back) options YARROW_RNG >> and FORTUNA_RNG, >=20 > Why would you do that? What's wrong with "device fortuna"? As I said in a previous mail, "nothing". :-) I'm looking at the new "adaptors" code and wondering what its for. If the current three /dev/random drivers were each in KLDs, then kldloading the one you wanted would be sufficient without the extra complexity. Yes, this does represent a change of mind on my part; I was initially enthusiastic about this. M --=20 Mark R V Murray --Apple-Mail=_36FDA83C-4887-4B3D-BE0D-CB9CB55DC588 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhCZRN58vKOKE6LNAQqdOgP+OtwvmDfOpEq5NCqTXn1PulxLMd78V2R+ /xP3KcW2blaZd83dyDBUc+XyQq4sZ10r5J68J749Ia1xUVHz+Rh8gC4G02Q3loRe e4C9YbN2LSoN1nxgxiazqXmloWG5NB3Ph7x4kQyA6XPE7PNu8KCf+X2T+Zl7dhMb Cxk+2iwqq6E= =ALMJ -----END PGP SIGNATURE----- --Apple-Mail=_36FDA83C-4887-4B3D-BE0D-CB9CB55DC588-- From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 10:00:42 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 C5635B0F; Sun, 18 Aug 2013 10:00:42 +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 85F4B28E2; Sun, 18 Aug 2013 10:00:42 +0000 (UTC) Received: from nine.des.no (smtp.des.no [194.63.250.102]) by smtp-int.des.no (Postfix) with ESMTP id 8D01242D5; Sun, 18 Aug 2013 10:00:41 +0000 (UTC) Received: by nine.des.no (Postfix, from userid 1001) id A8ED4875; Sun, 18 Aug 2013 12:00:17 +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> Date: Sun, 18 Aug 2013 12:00:17 +0200 In-Reply-To: <0C97B866-A169-4141-8368-AA7F5B5382F4@grondar.org> (Mark R. V. Murray's message of "Sun, 18 Aug 2013 10:52:04 +0100") Message-ID: <861u5r71zi.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 10:00:42 -0000 Mark R V Murray writes: > I'm looking at the new "adaptors" code and wondering what its for. It allows you to have multiple RNGs loaded or compiled-in simultaneously and select which one to use at runtime. Seems eminently sensible to me. > If the current three /dev/random drivers were each in KLDs, > then kldloading the one you wanted would be sufficient without > the extra complexity. And what would happen if you loaded several? DES --=20 Dag-Erling Sm=C3=B8rgrav - des@des.no From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 10:20:17 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 8F3A1EDC; Sun, 18 Aug 2013 10:20:17 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5145D29A0; Sun, 18 Aug 2013 10:20:16 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VB05k-000K1D-DW; Sun, 18 Aug 2013 11:20:15 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A2C0E59A-C2F8-4DA4-96BD-236DF6E84307"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <861u5r71zi.fsf@nine.des.no> Date: Sun, 18 Aug 2013 11:20:03 +0100 Message-Id: <892B11BD-396D-4F82-B97C-753F72CA494D@grondar.org> 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> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: Arthur Mesh , Philip Paeps , 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: Sun, 18 Aug 2013 10:20:17 -0000 --Apple-Mail=_A2C0E59A-C2F8-4DA4-96BD-236DF6E84307 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 18 Aug 2013, at 11:00, Dag-Erling Sm=F8rgrav wrote: > Mark R V Murray writes: >> I'm looking at the new "adaptors" code and wondering what its for. >=20 > It allows you to have multiple RNGs loaded or compiled-in = simultaneously > and select which one to use at runtime. Seems eminently sensible to = me. 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 = particular box; so what happens is some script selects the wrong one? I suppose the probe is there to prevent this. 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. I would find this more useful if Nehemiah and RDRAND/Ivy were to go the same way as the others, and became entropy sources to the software = device. This current mechanism could then be useful as a switch between Yarrow/Fortuna, but that is only useful (for as long as|if) we keep both (not an issue for some time except for the embedded folks). >> If the current three /dev/random drivers were each in KLDs, >> then kldloading the one you wanted would be sufficient without >> the extra complexity. >=20 > And what would happen if you loaded several? "Failure", I would hope - whatever that unintuitive error is that means "you already have this" (that needs fixing). But see above, if this is a Yarrow/Fortuna switch, then I'm warming to it. M --=20 Mark R V Murray --Apple-Mail=_A2C0E59A-C2F8-4DA4-96BD-236DF6E84307 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhCf2958vKOKE6LNAQqZqgP+OXtZX7TzXdvRhq53HujnyKD3oESaFZzH nEVgoyKeP2mSnLFNaJX2nhwnwhmhCSJwqHs5/rbwzBiZ7rbKxoOQQmGw2y8D5T8K CSwwsKdq33qGjyK7BYsAi8eXJNM+CZ0k31gSAtPiaStbJ7CzQxyY6YzOLPCe81eK h7tw556JKMA= =Aez8 -----END PGP SIGNATURE----- --Apple-Mail=_A2C0E59A-C2F8-4DA4-96BD-236DF6E84307-- 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 From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 11:40:14 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 B91DA7A0; Sun, 18 Aug 2013 11:40:14 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7B5F5230D; Sun, 18 Aug 2013 11:40:14 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VB1L7-000K81-Qj; Sun, 18 Aug 2013 12:40:11 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7324AA12-2CDF-410B-B7F7-6F947D16DAE9"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <86r4dr5j3p.fsf@nine.des.no> Date: Sun, 18 Aug 2013 12:40:04 +0100 Message-Id: <445431BF-41DB-42B5-90C8-B73832B37BAF@grondar.org> 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> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 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:40:14 -0000 --Apple-Mail=_7324AA12-2CDF-410B-B7F7-6F947D16DAE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 18 Aug 2013, at 12:33, Dag-Erling Sm=F8rgrav wrote: > 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 = particular >> box; so what happens is some script selects the wrong one? I suppose >> the probe is there to prevent this. >=20 > 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 do support them; I sent a list. Its a black/white choice; either they get used as Yarroow source data, or they are straight /dev/random = drivers, not both. >> 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. >=20 > 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. The current code does not address that, but happens to be a useful, if small, step in getting That does not appear to be part of the design, rather a useful accident. M --=20 Mark R V Murray --Apple-Mail=_7324AA12-2CDF-410B-B7F7-6F947D16DAE9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhCymN58vKOKE6LNAQrqnQQAkOdrebQs6/3c7qYYXEFHYz26DBNBIY3+ BiLJlkDcw1XFnS6zAitc5nhRIW6iEUQ4spXLeBCxT/7JGi7ezUEs2pUnVYgMbNbl khMORPOYU8+mJzsdLOW5CyRbrdAvuTTRycu6QGsCirsXA73KTlL7lsDrRON+TIem Bt0AQ3pDUF4= =4Tfo -----END PGP SIGNATURE----- --Apple-Mail=_7324AA12-2CDF-410B-B7F7-6F947D16DAE9-- From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 16:53:36 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 3E604A34; Sun, 18 Aug 2013 16:53:36 +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 E83EA2015; Sun, 18 Aug 2013 16:53:35 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r7IGrVIT058031; Sun, 18 Aug 2013 16:53:31 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id f2u28njwyjhrebx8yrj5wqhaie; Sun, 18 Aug 2013 16:53:31 +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: <86r4dr5j3p.fsf@nine.des.no> Date: Sun, 18 Aug 2013 09:53:29 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C1BD77C-8C6B-4044-9285-5978A3BC4B70@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> To: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , Mark R V Murray X-Mailer: Apple Mail (2.1283) Cc: 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 16:53:36 -0000 On Aug 18, 2013, at 4:33 AM, Dag-Erling Sm=F8rgrav wrote: > 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 =85 Lots of folks build static kernels that they run on diverse hardware. The hardware RNG modules should be loadable simultaneously and should probe and activate only if their hardware is present, like any other driver for real hardware. > Provided the HWRNG is of sufficient quality, the user should be = allowed > to use it directly (through /dev/random) without Yarrow / Fortuna. We could have kernel options to choose mixers (e.g., Yarrow or Fortuna) for /dev/random and loadable device modules for entropy sources. Besides Yarrow and Fortuna mixers, we could then offer a "null mixer" option that selected the single "best" entropy source and passed it directly through. 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. 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. * 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. Tim From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 17:21:10 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 CC45E605; Sun, 18 Aug 2013 17:21:10 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8D9BA21E3; Sun, 18 Aug 2013 17:21:10 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VB6f3-000Keq-KT; Sun, 18 Aug 2013 18:21:08 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_CADBC39E-14A9-40DF-90A0-6B74F351B898"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <4C1BD77C-8C6B-4044-9285-5978A3BC4B70@kientzle.com> Date: Sun, 18 Aug 2013 18:20:57 +0100 Message-Id: <537622E1-F785-4BFA-B829-09DCDB484606@grondar.org> 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> To: Tim Kientzle X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 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 17:21:11 -0000 --Apple-Mail=_CADBC39E-14A9-40DF-90A0-6B74F351B898 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 18 Aug 2013, at 17:53, Tim Kientzle wrote: > We could have kernel options to choose mixers > (e.g., Yarrow or Fortuna) for /dev/random and > loadable device modules for entropy sources. >=20 > Besides Yarrow and Fortuna mixers, we could then > offer a "null mixer" option that selected the single > "best" entropy source and passed it directly through. =85 assuming that it is "real" entropy and not unprocessed stuff like keystrokes, mouse moves etc. Code needed. > 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? > 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. > * 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. See: Furguson, Niels & Schneier, Bruce. "Practical Cryptography" ISBN 0-471-22894-X 0-471-22357-3 There is a theoretical argument that real random data is better than = pseudorandom data from a PRNG. In certain cryptographic protocols you = can prove that certain attacks are impossible if you use real random = data. The protocol is unconditionally secure. If you use a PRNG, then = the protocol is only secure as long as the attacker cannot break the = PRNG; the protocol is computationally secure. this distinction, however, = is only relevant for people in ivory towers. All cryptographic protocols = use use computational assumptions for for almost everything. Removing = the computational assumption assumption for one particular type of = attack is an insignificant improvement, and generating real random data, = which you need for unconditional security, is so difficult that you are = far more likely to reduce the system security by trying to use real = random data. ...=20 M --=20 Mark R V Murray --Apple-Mail=_CADBC39E-14A9-40DF-90A0-6B74F351B898 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhECgN58vKOKE6LNAQopdAQAnqXrvAcJ8W/Iif7DPDaR7+xUVimN3soJ btCfGClEyYWktmtcbSkmktR0bgMEN5P5he4/uTjvGoWjrK/uSyI5sYps4o+MgRwS bSS5xhDKkeQFBb3lY+URl5g5r8fjHWiaAbktgDjICnuw4qBRYaTrzT0hy4EzD8+S 2NSaR/mwXNw= =z3Km -----END PGP SIGNATURE----- --Apple-Mail=_CADBC39E-14A9-40DF-90A0-6B74F351B898-- 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 From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 20:03:06 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 4870EE7; Sun, 18 Aug 2013 20:03:06 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DB63F29EF; Sun, 18 Aug 2013 20:03:05 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VB9Bj-000KzZ-2S; Sun, 18 Aug 2013 21:03:02 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_7C17E4A6-416E-4235-9325-B1156A587A18"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <932AB5CA-778E-438D-8FD3-8C0F29F3D117@kientzle.com> Date: Sun, 18 Aug 2013 21:02:46 +0100 Message-Id: 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: Tim Kientzle X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 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 20:03:06 -0000 --Apple-Mail=_7C17E4A6-416E-4235-9325-B1156A587A18 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=windows-1252 On 18 Aug 2013, at 20:27, Tim Kientzle wrote: > > 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. Not sure about the "everyone agrees", but I would like it to be so! > 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. Agreed. (This includes my change of position on the subject.) Others want Yarrow/Fortuna no matter what. > 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. Well, I haven't seen it, but if it is something like the ivy.c driver, then yes. This presumes that the Ivy/ Bull Mountain 'rdrand' instruction is safe, which I will presume. The ivy.c and nehemiah.c drivers could use some abstraction, and I suspect (and hope!) this is what you rate talking about. :-) >>> 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. OK. > 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. Yes! > * 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. OK; "One active" can own /dev/random, in the sense that (say) Yarrow and Fortuna may be present, but only one is active, and switching between the two takes an active decision from the machine's admin. > * 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. Yes. But if there is no mixer, which "wins"? > The above provides a good answer for GENERIC > (Yarrow/Fortuna mixing all available entropy). OK. > The above also allows people to build custom kernels > that connect a single entropy source to /dev/random > without having horrible failure modes. Agreed. In all cases, understanding (or lack thereof) of failure modes needs to be at least discussed. Yarrow and Fortuna have well-known cryptographers designing them, and their source (is|will be) available. For this, RDRAND, etc awareness of relevant attacks needs to be made public. For less well-known hardware, we need to ensure that problem areas are known. >>> * 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. Thanks :-) :-D > 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. Ok. NP. > 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. 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. I propose two-route device: 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. 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. M -- Mark R V Murray --Apple-Mail=_7C17E4A6-416E-4235-9325-B1156A587A18 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhEoct58vKOKE6LNAQqGegP+I1pycNcb6e/es79rNVqO5TVKBynie/7i brhPhWwwHuXbz+G97Q8fzsUW/B/GNzNRFRy5d+Dp6nGEo1l+746Fdh70yG9FOPNk tghAl1FlL6RbhkBYOQZJ8wUIW/Py19igutqn4mj+IF4Iq9l+1YYNCwz74VWWXafl 9rtPT/iQTVU= =hzeq -----END PGP SIGNATURE----- --Apple-Mail=_7C17E4A6-416E-4235-9325-B1156A587A18-- From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 21:50:45 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 243039F2; Sun, 18 Aug 2013 21:50:45 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0251.outbound.messaging.microsoft.com [213.199.154.251]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7EC082EE0; Sun, 18 Aug 2013 21:50:43 +0000 (UTC) Received: from mail37-db9-R.bigfish.com (10.174.16.249) by DB9EHSOBE014.bigfish.com (10.174.14.77) with Microsoft SMTP Server id 14.1.225.22; Sun, 18 Aug 2013 21:50:35 +0000 Received: from mail37-db9 (localhost [127.0.0.1]) by mail37-db9-R.bigfish.com (Postfix) with ESMTP id AF7B62007E; Sun, 18 Aug 2013 21:50:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:66.129.224.52; KIP:(null); UIP:(null); IPV:NLI; H:P-EMF01-SAC.jnpr.net; RD:none; EFVD:NLI X-SpamScore: 1 X-BigFish: VPS1(zz98dI1432Izz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6h1082kzz1de098h8275bh1de097hz2fh2a8h839hd25hf0ah1288h12a5h12a9h12bdh12e5h137ah139eh13b6h1441h14ddh1504h1537h162dh1631h1758h1898h18e1h1946h19b5h1ad9h1b0ah1b2fh1b88h1fb3h1d0ch1d2eh1d3fh1de2h1dfeh1dffh1e23h1fe8h1ff5h1155h) Received-SPF: pass (mail37-db9: domain of juniper.net designates 66.129.224.52 as permitted sender) client-ip=66.129.224.52; envelope-from=sjg@juniper.net; helo=P-EMF01-SAC.jnpr.net ; SAC.jnpr.net ; Received: from mail37-db9 (localhost.localdomain [127.0.0.1]) by mail37-db9 (MessageSwitch) id 1376862634739656_31494; Sun, 18 Aug 2013 21:50:34 +0000 (UTC) Received: from DB9EHSMHS015.bigfish.com (unknown [10.174.16.253]) by mail37-db9.bigfish.com (Postfix) with ESMTP id AEFA8260047; Sun, 18 Aug 2013 21:50:34 +0000 (UTC) Received: from P-EMF01-SAC.jnpr.net (66.129.224.52) by DB9EHSMHS015.bigfish.com (10.174.14.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Sun, 18 Aug 2013 21:50:34 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMF01-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.146.0; Sun, 18 Aug 2013 14:50:32 -0700 Received: from chaos.jnpr.net (chaos.jnpr.net [172.24.29.229]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id r7ILoVL93649; Sun, 18 Aug 2013 14:50:31 -0700 (PDT) (envelope-from sjg@juniper.net) Received: from chaos.jnpr.net (localhost [127.0.0.1]) by chaos.jnpr.net (Postfix) with ESMTP id F172658097; Sun, 18 Aug 2013 14:50:30 -0700 (PDT) To: Mark R V Murray Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion In-Reply-To: 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> Comments: In-reply-to: Mark R V Murray message dated "Sun, 18 Aug 2013 21:02:46 +0100." From: "Simon J. Gerraty" X-Mailer: MH-E 7.82+cvs; nmh 1.3; GNU Emacs 22.3.1 Date: Sun, 18 Aug 2013 14:50:30 -0700 Message-ID: <20130818215030.F172658097@chaos.jnpr.net> MIME-Version: 1.0 Content-Type: text/plain X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Tim Kientzle , FreeBSD-arch Arch , secteam@freebsd.org, des@des.no 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 21:50:45 -0000 On Sun, 18 Aug 2013 21:02:46 +0100, Mark R V Murray writes: >On 18 Aug 2013, at 20:27, Tim Kientzle wrote: >> 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. > >Yes! I think this is a key point. One of the problems we face dealing with NSA (or perhaps more accurately labs representing them) etc, is that they want us to be able to provide and substantiate claims of entropy *out* of /dev/random. We can "measure" and analyze the entropy going *into* a mixer like Yarrow, but it is hard to make assertions about the output beyond "if I collected N bits of entropy I cannot output more than that". (it wouldn't be doing a good job of mixing if you could). I suspect this is a key driver for the plugin arrangement - being able to address NSA concerns by using a PRNG of and in a manner of their choosing. Describing Yarrow/Fortuna as entropy "mixers" (or conditioning functions) rather than entropy "sources" might help. From owner-freebsd-arch@FreeBSD.ORG Sun Aug 18 21:53:40 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 EE3B0AC0; Sun, 18 Aug 2013 21:53:40 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AE28D2EED; Sun, 18 Aug 2013 21:53:40 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VBAul-000L7Y-6g; Sun, 18 Aug 2013 22:53:37 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8F44A057-305F-4220-ABFC-B2210AB2A57F"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <20130818215030.F172658097@chaos.jnpr.net> Date: Sun, 18 Aug 2013 22:53:26 +0100 Message-Id: <699CA617-7DBE-4BD5-8025-D8F1240824E0@grondar.org> 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> <20130818215030.F172658097@chaos.jnpr.net> To: Simon J. Gerraty X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: Tim Kientzle , FreeBSD-arch Arch , secteam@freebsd.org, des@des.no 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 21:53:41 -0000 --Apple-Mail=_8F44A057-305F-4220-ABFC-B2210AB2A57F Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii On 18 Aug 2013, at 22:50, Simon J. Gerraty wrote: > Describing Yarrow/Fortuna as entropy "mixers" (or conditioning > functions) rather than entropy "sources" might help. Has anybody done otherwise? M -- Mark R V Murray --Apple-Mail=_8F44A057-305F-4220-ABFC-B2210AB2A57F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhFCXt58vKOKE6LNAQreugP+N2yf8yVIIf8wd9a5hByueuLYBrvIEpfd FBeMk7gnir5z7ae3EGvfQ35O4emLahUG6tqaBdxXZo/w6gX+jsa3zDDjqnyWdHnO T41Oz0kPf2cajqizenEPUh/icqYfZF62kvB7ynGYJHyXnCFifktfDz90ejxkgUAR pxyDTGrd8i0= =d40F -----END PGP SIGNATURE----- --Apple-Mail=_8F44A057-305F-4220-ABFC-B2210AB2A57F-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 19 07:09: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 BF0EBC05 for ; Mon, 19 Aug 2013 07:09:28 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f177.google.com (mail-ob0-f177.google.com [209.85.214.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 828062730 for ; Mon, 19 Aug 2013 07:09:28 +0000 (UTC) Received: by mail-ob0-f177.google.com with SMTP id f8so4767234obp.36 for ; Mon, 19 Aug 2013 00:09:27 -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=KS/6ttd1DyQJlMTNh4s6nDU56omRkjW1FzRg34L+x5E=; b=D8h72WmaibT+sp6eGejpaGKvJHgLJcqV8gEH9kyVCTTUu5jHgUKdYF13bCzLymQrwL 7GEGCrqnvEz66FrkxD3aCfY+mwZ4ndtBNx2Pf+NaZAGFfQ1iZ9trwxFmJ2EaZ+Apxh/y 5n4KKDV9Gnf+V8Fc0JQcrcMETxtnL2YJaoGnTXEENet+dF/SDjsqmbqGGTHl1mysElQ/ 7Jiilp/gV0kKBACVaCGrjBLYCDiKjhn8nqfkc77z0mb2UcII3ZhFYI2jMTUzXmqCNi4J ewLN3WwK6v6loIDMK7eUoUXlgOycS0ZDMRynRB5EHJO24aUDqt2Bmm2iwpUekdmecpUP ayiQ== X-Gm-Message-State: ALoCoQm3x0qPQaOZ1d9hjeFs1KBbFLxPG3KRlwUJeGeJev4kfMuwPehUWm8uABAkaoJ2frim9OzH X-Received: by 10.182.101.198 with SMTP id fi6mr232533obb.79.1376896167410; Mon, 19 Aug 2013 00:09:27 -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 ps5sm14922567oeb.8.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 00:09:26 -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=windows-1252 From: Warner Losh In-Reply-To: <4C1BD77C-8C6B-4044-9285-5978A3BC4B70@kientzle.com> Date: Mon, 19 Aug 2013 01:09:24 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <12B58C72-CFE3-4AD4-AD03-462A10E431D9@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> To: Tim Kientzle X-Mailer: Apple Mail (2.1085) Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , secteam@freebsd.org, Mark R V Murray , 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: Mon, 19 Aug 2013 07:09:28 -0000 On Aug 18, 2013, at 10:53 AM, Tim Kientzle wrote: > On Aug 18, 2013, at 4:33 AM, Dag-Erling Sm=F8rgrav wrote: >=20 >> 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 =85 >=20 > Lots of folks build static kernels that they run on diverse > hardware. >=20 > The hardware RNG modules should be loadable simultaneously > and should probe and activate only if their hardware is present, > like any other driver for real hardware. Agreed, I made that point earlier in this thread... >> Provided the HWRNG is of sufficient quality, the user should be = allowed >> to use it directly (through /dev/random) without Yarrow / Fortuna. >=20 > We could have kernel options to choose mixers > (e.g., Yarrow or Fortuna) for /dev/random and > loadable device modules for entropy sources. >=20 > Besides Yarrow and Fortuna mixers, we could then > offer a "null mixer" option that selected the single > "best" entropy source and passed it directly through. I'm still wondering why timecounters aren't the right model to follow = here, where you can have several compiled into the kernel and the one = with the best score wins. > 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. >=20 > 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. > * 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. Assuming there was enough interrupt entropy to generate bits... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 19 07:14: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 3650DCE5; Mon, 19 Aug 2013 07:14:09 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EB82A276C; Mon, 19 Aug 2013 07:14:08 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VBJf7-000LfL-RN; Mon, 19 Aug 2013 08:14:04 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_FB4B5D4A-A92B-46C9-B973-2C04BF738D45"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <12B58C72-CFE3-4AD4-AD03-462A10E431D9@bsdimp.com> Date: Mon, 19 Aug 2013 08:13:53 +0100 Message-Id: <3513A465-AD8D-4DDC-9408-2F89F9B86404@grondar.org> 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> <12B58C72-CFE3-4AD4-AD03-462A10E431D9@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 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:14:09 -0000 --Apple-Mail=_FB4B5D4A-A92B-46C9-B973-2C04BF738D45 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 19 Aug 2013, at 08:09, Warner Losh wrote: >> Besides Yarrow and Fortuna mixers, we could then >> offer a "null mixer" option that selected the single >> "best" entropy source and passed it directly through. >=20 > I'm still wondering why timecounters aren't the right model to follow = here, where you can have several compiled into the kernel and the one = with the best score wins. How would they get a score, and how would it be decided which is better? = How is the score "calibrated"? >> 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. >>=20 >> 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. >> * 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. >=20 > Assuming there was enough interrupt entropy to generate bits=85 See Ferguson & Schneier on this (qv my follow-up). M --=20 Mark R V Murray --Apple-Mail=_FB4B5D4A-A92B-46C9-B973-2C04BF738D45 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhHFt958vKOKE6LNAQpttwP8DqaLAcLTQEWdfQCdrZkv+hdk/Rt5dPXT FIYqkknkPoLX6Ly6dyUmlOLtFAsyAkG428Y8gpN28pi/WkTIc5WHq/B2XMJsmDWN Zl2P0HeGH1IqrmwioKGBE92hASJ6x8hosmICFN7mkf5DVTUDs7NVkChHPPl31DG7 J9+w81Re2Xo= =zMFZ -----END PGP SIGNATURE----- --Apple-Mail=_FB4B5D4A-A92B-46C9-B973-2C04BF738D45-- 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 From owner-freebsd-arch@FreeBSD.ORG Mon Aug 19 07:24:29 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 53050F74 for ; Mon, 19 Aug 2013 07:24:29 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f41.google.com (mail-oa0-f41.google.com [209.85.219.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 1524B27C2 for ; Mon, 19 Aug 2013 07:24:28 +0000 (UTC) Received: by mail-oa0-f41.google.com with SMTP id j6so2937788oag.28 for ; Mon, 19 Aug 2013 00:24:22 -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=PTYnKTpQM6FMIlj8D70CLrFckCO02hAYlGs3bOqT05E=; b=azvPqd5gf0ZcGlqlWs9TevkSmO3nrg29edKyrjyHS15yO+fZZg4fnPPcjq64WTX2Xm A7A9IFx9J6y7SmsCywnyBWHcN9HQ6hHXnH9khjcCXniLECAFU1lR20XuJarWOBejGqW3 6AhXDGBOVcbm+YvdLC5pGI3zxaRALqMJsh1gHetoR0fuja9obpAR68PCzmsRUTDcNh2a zmPo93P4w1p2d8sXWKJF1240K2t7HQVArH1P1DdyPZIMjOszZr0+NWaXMMXsAELCJerT 3bP5AYEkcI4WZNzehxaYbBZ0ZqpOqDg8QYl5hBumJ3TYJEhe7Ej8mQD/uKTrXdvcmC2q 5KUg== X-Gm-Message-State: ALoCoQksEgDSQiroWgMjHmqM2YR8FZhnsR461GIZVoO5SM/uIx2S8FmBigHOi4tSYX7XoV8AN/Fp X-Received: by 10.182.96.169 with SMTP id dt9mr464009obb.76.1376897062116; Mon, 19 Aug 2013 00:24:22 -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 d3sm15016581oek.5.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 00:24:21 -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=windows-1252 From: Warner Losh In-Reply-To: <3513A465-AD8D-4DDC-9408-2F89F9B86404@grondar.org> Date: Mon, 19 Aug 2013 01:24:19 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <12B58C72-CFE3-4AD4-AD03-462A10E431D9@bsdimp.com> <3513A465-AD8D-4DDC-9408-2F89F9B86404@grondar.org> 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:24:29 -0000 On Aug 19, 2013, at 1:13 AM, Mark R V Murray wrote: >=20 > On 19 Aug 2013, at 08:09, Warner Losh wrote: >>> Besides Yarrow and Fortuna mixers, we could then >>> offer a "null mixer" option that selected the single >>> "best" entropy source and passed it directly through. >>=20 >> I'm still wondering why timecounters aren't the right model to follow = here, where you can have several compiled into the kernel and the one = with the best score wins. >=20 > How would they get a score, and how would it be decided which is = better? How is the score "calibrated"? For timecounters, we make judgements based on how good or bad we think = the timekeeping ability of the underlying device. I'd imagine that we'd = rate the hardware RNGs high, and the fallback means of harvesting = entropy from interrupts medium, and anything that's really really bad as = low. This would allow for the hardware RNGs to override the other = sources of entropy, while still allowing fallback to reasonable entropy = on devices that are known suspect (While still allowing the pig-headed = and/or externally constrained folks to use the bad sources). For the mixers, the scoring mechanism makes less sense. You'd want more = of an ordered list specified by the user to dictate policy to choose = between nothing, fortuna and yarrow. You'd also want a parameter to deal with failure here: panic or block. >>> 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. >>>=20 >>> 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. >>> * 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. >>=20 >> Assuming there was enough interrupt entropy to generate bits=85 >=20 > See Ferguson & Schneier on this (qv my follow-up). Saw that. I was worried only about starvation, but there's much more to = worry about than that it seems. Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 19 07:31:48 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 6A2AD21E; Mon, 19 Aug 2013 07:31:48 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 29C53281A; Mon, 19 Aug 2013 07:31:48 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VBJwD-000LhH-PY; Mon, 19 Aug 2013 08:31:46 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_0025415E-671A-467E-94BE-CD750558D597"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <71A92486-2213-421E-B3D2-E55816C18924@bsdimp.com> Date: Mon, 19 Aug 2013 08:31:35 +0100 Message-Id: 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> <71A92486-2213-421E-B3D2-E55816C18924@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 Cc: Tim Kientzle , =?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: Mon, 19 Aug 2013 07:31:48 -0000 --Apple-Mail=_0025415E-671A-467E-94BE-CD750558D597 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 19 Aug 2013, at 08:18, Warner Losh wrote: > If we're going to allow passthrough, we should require the kernel = config to explicitly do something to get pass through. >=20 > nodevice yarrow > device random_passthrough >=20 > would be my suggestion. I don't think it will sell; folks are asking for GENERIC with a run-time = switch to flip between the raw HW generator output and a SW = mixer/conditioner. > 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=85 Won't sell. Folks are saying they want the choice of the raw output. In = GENERIC. "What Will Sell" may be up for debate and mind-changing; I think that is = the route to explore. M --=20 Mark R V Murray --Apple-Mail=_0025415E-671A-467E-94BE-CD750558D597 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhHJ3N58vKOKE6LNAQqFFgP/ZRbON4H4Afhx4qqyDlacqY1j61yzIc4e hvLEl8pQHHoFeu3zJXOyPoVoVvcGzKVpiWl0e1ASzTeyYjDm0fk/tXcRyYIO8SCV fPGkiQ50soh+LJoj5m/WjTfdwKGCrFQSFC9/zqHQy7dHsg41mz+9T3PR4Ewbjxxi 0GkF0hW2z9o= =mczO -----END PGP SIGNATURE----- --Apple-Mail=_0025415E-671A-467E-94BE-CD750558D597-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 19 07:40:14 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 837AD658; Mon, 19 Aug 2013 07:40:14 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 444D02874; Mon, 19 Aug 2013 07:40:14 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VBK4N-000LiJ-K8; Mon, 19 Aug 2013 08:40:12 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_303BAD32-22C2-4AAD-80BF-6DA5FB281728"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: Date: Mon, 19 Aug 2013 08:40:06 +0100 Message-Id: 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> <12B58C72-CFE3-4AD4-AD03-462A10E431D9@bsdimp.com> <3513A465-AD8D-4DDC-9408-2F89F9B86404@grondar.org> To: Warner Losh X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 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:40:14 -0000 --Apple-Mail=_303BAD32-22C2-4AAD-80BF-6DA5FB281728 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 19 Aug 2013, at 08:24, Warner Losh wrote: >> How would they get a score, and how would it be decided which is = better? How is the score "calibrated"? >=20 > For timecounters, we make judgements based on how good or bad we think = the timekeeping ability of the underlying device. I'd imagine that we'd = rate the hardware RNGs high, and the fallback means of harvesting = entropy from interrupts medium, and anything that's really really bad as = low. This would allow for the hardware RNGs to override the other = sources of entropy, while still allowing fallback to reasonable entropy = on devices that are known suspect (While still allowing the pig-headed = and/or externally constrained folks to use the bad sources). Aaah - so its a coarse good/average/bad thing, rather than a = fine-grained number giving precise/critical ordering? > For the mixers, the scoring mechanism makes less sense. You'd want = more of an ordered list specified by the user to dictate policy to = choose between nothing, fortuna and yarrow. The mixers won't care, correct. As for the rest, its a bit of a tree of = choices: HW branch - choice of "good" sources only (?). SW branch - = choice of Yarrow/Fortuna and which sources (currently four, but will be = increased) to harvest from. > You'd also want a parameter to deal with failure here: panic or block. Right, and a default for GENERIC. M --=20 Mark R V Murray --Apple-Mail=_303BAD32-22C2-4AAD-80BF-6DA5FB281728 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhHL1t58vKOKE6LNAQrfxAP/c1hmEoOkG5Ty8aFjBUVm4vmx1nSFvHj1 LTVyMGNsCc6IkunN56msq2ACGmXxVd8is3EK0hIldlrwnL+couWwzNpHikqdbzDu pTSfPUCtMHYAW8Hx+R6T+aFaGjsXMeor94eT+OBMg97+T0eSgt17OB8Kxvq1kW+e iPkAy7TnK1o= =6a86 -----END PGP SIGNATURE----- --Apple-Mail=_303BAD32-22C2-4AAD-80BF-6DA5FB281728-- From owner-freebsd-arch@FreeBSD.ORG Mon Aug 19 22:01:18 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 4D1A0348 for ; Mon, 19 Aug 2013 22:01:18 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0EB192B9E for ; Mon, 19 Aug 2013 22:01:17 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id uz19so6155616obc.21 for ; Mon, 19 Aug 2013 15:01:11 -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=qwRG+Dpw1Sou4Dc3heoxaX56GgXdPbLuwdzloaqaX7g=; b=cNqg6eaGBEwNOIDSkEbPwGhaKdEkRkL4hWfHA+W3/Bvb3BxXwGq68TMzRdoGGtaoUC RY2cHVIjLdVn19glKTjtRwO03D9oA/vjMVaXMduH4nT5yQrh7+ptlAUM9ir4wHMG1RaT UbwP+3AQsY5lw6uyLcx+NqU9t6/w3p0YyRICxiT/U88tIoROwAvtRPJTGn4WwzrsOA2K e6l+GEEL429RhiccA5stWb4cgtduAaYa5y4SUVnNRW7fUTqnQE5q0S9fySGHza1M9t8C 5t+d4y90v7rJ86KLMp5rHWog7DH8q7nJkyWKCrXdsce9nSAMZX/N9mKdrUfvOJSPyxlL EoDA== X-Gm-Message-State: ALoCoQlLZLD/quaEXcx6oyKcW/7bNtmZpaKoWWpaSx2r1rA/iqPvQPDb2A1lB6MD1QXjCSvDYGHz X-Received: by 10.60.70.134 with SMTP id m6mr15135669oeu.14.1376949671165; Mon, 19 Aug 2013 15:01:11 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id g1sm19684576oeq.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 15:01:10 -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=windows-1252 From: Warner Losh In-Reply-To: Date: Mon, 19 Aug 2013 16:01:07 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <551C488B-D56A-4E9F-8617-17B96D3E7677@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> <71A92486-2213-421E-B3D2-E55816C18924@bsdimp.com> To: Mark R V Murray X-Mailer: Apple Mail (2.1085) Cc: Tim Kientzle , =?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: Mon, 19 Aug 2013 22:01:18 -0000 On Aug 19, 2013, at 1:31 AM, Mark R V Murray wrote: >=20 > On 19 Aug 2013, at 08:18, Warner Losh wrote: >> If we're going to allow passthrough, we should require the kernel = config to explicitly do something to get pass through. >>=20 >> nodevice yarrow >> device random_passthrough >>=20 >> would be my suggestion. >=20 > I don't think it will sell; folks are asking for GENERIC with a = run-time switch to flip between the raw HW generator output and a SW = mixer/conditioner. This is the config for no yarrow and pass through only. If you want = both, you should have both and a sysctl/tunable controlling the = wiring... >> 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=85 >=20 > Won't sell. Folks are saying they want the choice of the raw output. = In GENERIC. Nothing I've said will preclude it. What's in generic is policy, not = mechanism. > "What Will Sell" may be up for debate and mind-changing; I think that = is the route to explore. Maybe I need to be more articulate, since I'm trying to describe a = mechanism for having one or more filters, but having a compiler error = when there's zero... Warner= From owner-freebsd-arch@FreeBSD.ORG Mon Aug 19 22:02:01 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 BB431416 for ; Mon, 19 Aug 2013 22:02:01 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-oa0-f52.google.com (mail-oa0-f52.google.com [209.85.219.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7D8222BAC for ; Mon, 19 Aug 2013 22:02:01 +0000 (UTC) Received: by mail-oa0-f52.google.com with SMTP id n12so4457182oag.39 for ; Mon, 19 Aug 2013 15:01:54 -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=dpwboo5CV01TfcNfbWFFptxA1ZMeargsxHjt1kAE8jU=; b=gH8ZlsVhAJhlUIAeXA9wvFLAoaIId+LOvTI1oDsg+/2BP+YLljAg0oQyKcN+c98cXW JnAsB1ePCC+m7LBAvXUBhIaIeXdPjP1kFEYoNQGFWgX1CIBAQZBMQoNjtCho/vYZz9bo S71nOJrkXNCP8wn3zu337Z68usqMCAd9cdiNOGOKy5VdaAlm+Ol5Y7sDP6Xu2ZhiH9xk nXAUGck7xbkauWq07ml1z74TUu80MfFVsfi1e945evNMsW8Sz16WaTCAywB0INEDLNXj mhvGGq+NDusJ030mbxCljV10632gwVSaCcCkw8yDcJT9a6Y5Y6I+Z7ZI5Qp2wu5gvx1O ANpg== X-Gm-Message-State: ALoCoQnOMtUR3QCKbPdL8i3z4/v9TIo2r+oF6L0fk7YgBhrxlTuiGE9dLpe8KQcURtJusz5kmHqS X-Received: by 10.60.131.69 with SMTP id ok5mr4182947oeb.70.1376949713998; Mon, 19 Aug 2013 15:01:53 -0700 (PDT) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPSA id g1sm19684576oeq.6.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 19 Aug 2013 15:01:53 -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 16:01:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <629B621F-B166-4D66-A4E6-ED9B966E7A21@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> <12B58C72-CFE3-4AD4-AD03-462A10E431D9@bsdimp.com> <3513A465-AD8D-4DDC-9408-2F89F9B86404@grondar.org> 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 22:02:01 -0000 On Aug 19, 2013, at 1:40 AM, Mark R V Murray wrote: > On 19 Aug 2013, at 08:24, Warner Losh wrote: >>> How would they get a score, and how would it be decided which is = better? How is the score "calibrated"? >>=20 >> For timecounters, we make judgements based on how good or bad we = think the timekeeping ability of the underlying device. I'd imagine that = we'd rate the hardware RNGs high, and the fallback means of harvesting = entropy from interrupts medium, and anything that's really really bad as = low. This would allow for the hardware RNGs to override the other = sources of entropy, while still allowing fallback to reasonable entropy = on devices that are known suspect (While still allowing the pig-headed = and/or externally constrained folks to use the bad sources). >=20 > Aaah - so its a coarse good/average/bad thing, rather than a = fine-grained number giving precise/critical ordering? >=20 >> For the mixers, the scoring mechanism makes less sense. You'd want = more of an ordered list specified by the user to dictate policy to = choose between nothing, fortuna and yarrow. >=20 > The mixers won't care, correct. As for the rest, its a bit of a tree = of choices: HW branch - choice of "good" sources only (?). SW branch - = choice of Yarrow/Fortuna and which sources (currently four, but will be = increased) to harvest from. >=20 >> You'd also want a parameter to deal with failure here: panic or = block. >=20 > Right, and a default for GENERIC. Exactly... Warner From owner-freebsd-arch@FreeBSD.ORG Mon Aug 19 22:58:51 2013 Return-Path: Delivered-To: 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 06C72F75; Mon, 19 Aug 2013 22:58:51 +0000 (UTC) (envelope-from ken@kdm.org) Received: from nargothrond.kdm.org (nargothrond.kdm.org [70.56.43.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BF882E6C; Mon, 19 Aug 2013 22:58:49 +0000 (UTC) Received: from nargothrond.kdm.org (localhost [127.0.0.1]) by nargothrond.kdm.org (8.14.2/8.14.2) with ESMTP id r7JMwhFO096683; Mon, 19 Aug 2013 16:58:43 -0600 (MDT) (envelope-from ken@nargothrond.kdm.org) Received: (from ken@localhost) by nargothrond.kdm.org (8.14.2/8.14.2/Submit) id r7JMwgb3096682; Mon, 19 Aug 2013 16:58:42 -0600 (MDT) (envelope-from ken) Date: Mon, 19 Aug 2013 16:58:42 -0600 From: "Kenneth D. Merry" To: Bruce Evans Subject: Re: patches to add new stat(2) file flags Message-ID: <20130819225842.GA90548@nargothrond.kdm.org> References: <20130307000533.GA38950@nargothrond.kdm.org> <20130307222553.P981@besplex.bde.org> <20130308232155.GA47062@nargothrond.kdm.org> <20130310181127.D2309@besplex.bde.org> <20130409190838.GA60733@nargothrond.kdm.org> <20130418184951.GA18777@nargothrond.kdm.org> <20130419215624.L1262@besplex.bde.org> <20130426221023.GA86767@nargothrond.kdm.org> <20130429231638.N1440@besplex.bde.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="cNdxnHkX5QqsyA0e" Content-Disposition: inline In-Reply-To: <20130429231638.N1440@besplex.bde.org> User-Agent: Mutt/1.4.2i Cc: arch@freebsd.org, fs@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: Mon, 19 Aug 2013 22:58:51 -0000 --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Mon, Apr 29, 2013 at 23:34:30 +1000, Bruce Evans wrote: > On Fri, 26 Apr 2013, Kenneth D. Merry wrote: > > I haven't looked at this much. Just a quick reply since I will be away > for a while. I finally took the time to pick this back up again. I hope to commit this on Wednesday, August 21st, so it'll be in 10.0. > >On Fri, Apr 19, 2013 at 22:53:50 +1000, Bruce Evans wrote: > >>On Thu, 18 Apr 2013, Kenneth D. Merry wrote: > >> > >>>On Tue, Apr 09, 2013 at 13:08:38 -0600, Kenneth D. Merry wrote: > >>>>... > >>>>Okay, I think these issues should now be fixed. We now refuse to change > >>>>attributes only on the root directory. And I updatd deupdat() to do the > >>>>same. > >>>> > >>>>When a directory is created or a file is added, the archive bit is not > >>>>changed on the directory. Not sure if we need to do that or not. > >>>>(Simply > >>>>changing msdosfs_mkdir() to set ATTR_ARCHIVE was not enough to get the > >>>>archive bit set on directory creation.) > >>> > >>>Bruce, any comment on this? > >> > >>I didn't get around to looking at it closely. Just had a quick look at > >>the msdosfs parts. > >> > >>Apparently we are already doing the same as WinXP for ATTR_ARCHIVE on > >>directories. Not the right thing, but: > >>- don't set it on directory creation > >>- don't set it on directory modification > >>- allow setting and clearing it (with your changes). > > Further testing showed the same behaviour for ntfs under WinXP (you can > manage all the attribute bits for directories, but they don't control > anything for directories, at least using Cygwin utilities). > > About not setting the archive bit in for modifications of directories > in msdosfs: most settings of this bit are managed by the DETIMES() > macro. It is set when the directory mtime is set (the denode is first > marked for update of the mtime -- DE_UPDATE flag). But since > modifications of directories don't change the mtime (we are bug for > bug compatible with Win/DOS here), this never sets the archive bit for > directories. The mtime can be changed for directories using utimes() > in my version but not in -current, and using some Win/DOS syscall. I'm > setting the archive bit for this, but will change to be bug for bug > compatible with Win/DOS by not setting it. Then only chflags will set > it for directories. With the attached patch, we don't set the archive bit when changing the time on a directory. > >>@ *** src/lib/libc/sys/chflags.2.orig > >>@ --- src/lib/libc/sys/chflags.2 > >>@ *************** > >>@ *** 112,137 **** > >>@ ... > >>@ --- 112,170 ---- > >>@ ... > >>@ + .It Dv UF_IMMUTABLE > >>@ + The file may not be changed. > >>@ + Filesystems may use this flag to maintain compatibility with the DOS, > >>Windows > >>@ + and CIFS FILE_ATTRIBUTE_READONLY attribute. > >> > >>msdosfs doesn't use this yet. It uses ATTR_READONLY, and doesn't map this > >>to or from UF_IMMUTABLE. I think I want ATTR_READONLY to be a flag and > >>not affect the file permissions (just like immutable flags normally don't > >>affect the file permissions. > > > >Okay, done. The permissions are now always 755, and writeability is > >controlled by ATTR_READONLY. > > Should be 755 by default, but there is a mount option to change this. Yes, the mount option is still there. > >>Does CIFS FILE_ATTRIBUTE_READONLY have exactly the same semantics as > >>IMMUTABLE? That is, does it prevent all operations on the file and the > >>... > >Okay. I added a new flag, UF_READONLY that maps to ATTR_READONLY directly > >instead of using an immutable flag. > >... > >The other outstanding issue is the suggestion by Gordon Ross on the Illumos > >developers list to make ZFS not enforce the readonly bit. It looks like it > >has not yet gone into Illumos. We may not want to make the change in > >FreeBSD since it hasn't gone in upstream yet. > > This shows that we want to not enforce the readonly bit (or other > flags) even for msdosfs. msdosfs is a good place to test changing the > policy since there aren't many critical file systems using it. Done. Thanks, Ken -- Kenneth Merry ken@FreeBSD.ORG --cNdxnHkX5QqsyA0e Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="file_flags_head.20130819.3.txt" *** src/bin/chflags/chflags.1.orig --- src/bin/chflags/chflags.1 *************** *** 32,38 **** .\" @(#)chflags.1 8.4 (Berkeley) 5/2/95 .\" $FreeBSD: head/bin/chflags/chflags.1 213573 2010-10-08 12:40:16Z uqs $ .\" ! .Dd March 3, 2006 .Dt CHFLAGS 1 .Os .Sh NAME --- 32,38 ---- .\" @(#)chflags.1 8.4 (Berkeley) 5/2/95 .\" $FreeBSD: head/bin/chflags/chflags.1 213573 2010-10-08 12:40:16Z uqs $ .\" ! .Dd April 8, 2013 .Dt CHFLAGS 1 .Os .Sh NAME *************** *** 101,120 **** .Bl -tag -offset indent -width ".Cm opaque" .It Cm arch , archived set the archived flag (super-user only) .It Cm opaque set the opaque flag (owner or super-user only) - .It Cm nodump - set the nodump flag (owner or super-user only) .It Cm sappnd , sappend set the system append-only flag (super-user only) .It Cm schg , schange , simmutable set the system immutable flag (super-user only) .It Cm sunlnk , sunlink set the system undeletable flag (super-user only) .It Cm uappnd , uappend set the user append-only flag (owner or super-user only) .It Cm uchg , uchange , uimmutable set the user immutable flag (owner or super-user only) .It Cm uunlnk , uunlink set the user undeletable flag (owner or super-user only) .El --- 101,136 ---- .Bl -tag -offset indent -width ".Cm opaque" .It Cm arch , archived set the archived flag (super-user only) + .It Cm nodump + set the nodump flag (owner or super-user only) .It Cm opaque set the opaque flag (owner or super-user only) .It Cm sappnd , sappend set the system append-only flag (super-user only) .It Cm schg , schange , simmutable set the system immutable flag (super-user only) + .It Cm snapshot + set the snapshot flag (filesystems do not allow changing this flag) .It Cm sunlnk , sunlink set the system undeletable flag (super-user only) .It Cm uappnd , uappend set the user append-only flag (owner or super-user only) + .It Cm uarch , uarchive + set the archive flag (owner or super-user only) .It Cm uchg , uchange , uimmutable set the user immutable flag (owner or super-user only) + .It Cm uhidden , hidden + set the hidden file attribute (owner or super-user only) + .It Cm uoffline , offline + set the offline file attribute (owner or super-user only) + .It Cm urdonly , rdonly , readonly + set the DOS, Windows and CIFS readonly flag (owner or super-user only) + .It Cm usparse , sparse + set the sparse file attribute (owner or super-user only) + .It Cm usystem , system + set the DOS, Windows and CIFS system flag (owner or super-user only) + .It Cm ureparse , reparse + set the Windows reparse point file attribute (owner or super-user only) .It Cm uunlnk , uunlink set the user undeletable flag (owner or super-user only) .El *** src/bin/ls/ls.1.orig --- src/bin/ls/ls.1 *************** *** 232,237 **** --- 232,240 ---- Include the file flags in a long .Pq Fl l output. + See + .Xr chflags 1 + for a list of file flags and their meanings. .It Fl p Write a slash .Pq Ql / *** src/lib/libc/gen/strtofflags.c.orig --- src/lib/libc/gen/strtofflags.c *************** *** 62,74 **** #endif { "nouappnd", 0, UF_APPEND }, { "nouappend", 0, UF_APPEND }, { "nouchg", 0, UF_IMMUTABLE }, { "nouchange", 0, UF_IMMUTABLE }, { "nouimmutable", 0, UF_IMMUTABLE }, { "nodump", 1, UF_NODUMP }, { "noopaque", 0, UF_OPAQUE }, ! { "nouunlnk", 0, UF_NOUNLINK }, ! { "nouunlink", 0, UF_NOUNLINK } }; #define nmappings (sizeof(mapping) / sizeof(mapping[0])) --- 62,90 ---- #endif { "nouappnd", 0, UF_APPEND }, { "nouappend", 0, UF_APPEND }, + { "nouarch", 0, UF_ARCHIVE }, + { "nouarchive", 0, UF_ARCHIVE }, + { "nohidden", 0, UF_HIDDEN }, + { "nouhidden", 0, UF_HIDDEN }, { "nouchg", 0, UF_IMMUTABLE }, { "nouchange", 0, UF_IMMUTABLE }, { "nouimmutable", 0, UF_IMMUTABLE }, { "nodump", 1, UF_NODUMP }, + { "nouunlnk", 0, UF_NOUNLINK }, + { "nouunlink", 0, UF_NOUNLINK }, + { "nooffline", 0, UF_OFFLINE }, + { "nouoffline", 0, UF_OFFLINE }, { "noopaque", 0, UF_OPAQUE }, ! { "nordonly", 0, UF_READONLY }, ! { "nourdonly", 0, UF_READONLY }, ! { "noreadonly", 0, UF_READONLY }, ! { "noureadonly", 0, UF_READONLY }, ! { "noreparse", 0, UF_REPARSE }, ! { "noureparse", 0, UF_REPARSE }, ! { "nosparse", 0, UF_SPARSE }, ! { "nousparse", 0, UF_SPARSE }, ! { "nosystem", 0, UF_SYSTEM }, ! { "nousystem", 0, UF_SYSTEM } }; #define nmappings (sizeof(mapping) / sizeof(mapping[0])) *** src/lib/libc/sys/chflags.2.orig --- src/lib/libc/sys/chflags.2 *************** *** 112,137 **** the following values .Pp .Bl -tag -width ".Dv SF_IMMUTABLE" -compact -offset indent ! .It Dv UF_NODUMP ! Do not dump the file. ! .It Dv UF_IMMUTABLE ! The file may not be changed. ! .It Dv UF_APPEND The file may only be appended to. - .It Dv UF_NOUNLINK - The file may not be renamed or deleted. - .It Dv UF_OPAQUE - The directory is opaque when viewed through a union stack. .It Dv SF_ARCHIVED ! The file may be archived. .It Dv SF_IMMUTABLE The file may not be changed. - .It Dv SF_APPEND - The file may only be appended to. .It Dv SF_NOUNLINK The file may not be renamed or deleted. .It Dv SF_SNAPSHOT The file is a snapshot file. .El .Pp If one of --- 112,172 ---- the following values .Pp .Bl -tag -width ".Dv SF_IMMUTABLE" -compact -offset indent ! .It Dv SF_APPEND The file may only be appended to. .It Dv SF_ARCHIVED ! The file has been archived. ! This flag means the opposite of the DOS, Windows and CIFS ! FILE_ATTRIBUTE_ARCHIVE attribute. ! This flag has been deprecated, and may be removed in a future release. .It Dv SF_IMMUTABLE The file may not be changed. .It Dv SF_NOUNLINK The file may not be renamed or deleted. .It Dv SF_SNAPSHOT The file is a snapshot file. + .It Dv UF_APPEND + The file may only be appended to. + .It Dv UF_ARCHIVE + The file needs to be archived. + This flag has the same meaning as the DOS, Windows and CIFS + FILE_ATTRIBUTE_ARCHIVE attribute. + Filesystems in FreeBSD may or may not have special handling for this flag. + For instance, ZFS tracks changes to files and will set this bit when a + file is updated. + UFS only stores the flag, and relies on the application to change it when + needed. + .It Dv UF_HIDDEN + The file may be hidden from directory listings at the application's + discretion. + The file has the DOS, Windows and CIFS FILE_ATTRIBUTE_HIDDEN attribute. + .It Dv UF_IMMUTABLE + The file may not be changed. + .It Dv UF_NODUMP + Do not dump the file. + .It Dv UF_NOUNLINK + The file may not be renamed or deleted. + .It Dv UF_OFFLINE + The file is offline, or has the Windows and CIFS FILE_ATTRIBUTE_OFFLINE + attribute. + Filesystems in FreeBSD store and display this flag, but do not provide any + special handling when it is set. + .It Dv UF_OPAQUE + The directory is opaque when viewed through a union stack. + .It Dv UF_READONLY + The file is read only, and may not be written or appended. + Filesystems may use this flag to maintain compatibility with the DOS, Windows + and CIFS FILE_ATTRIBUTE_READONLY attribute. + .It Dv UF_REPARSE + The file contains a Windows reparse point and has the Windows and CIFS + FILE_ATTRIBUTE_REPARSE_POINT attribute. + .It Dv UF_SPARSE + The file has the Windows FILE_ATTRIBUTE_SPARSE_FILE attribute. + This may also be used by a filesystem to indicate a sparse file. + .It Dv UF_SYSTEM + The file has the DOS, Windows and CIFS FILE_ATTRIBUTE_SYSTEM attribute. + Filesystems in FreeBSD may store and display this flag, but do not provide + any special handling when it is set. .El .Pp If one of *************** *** 162,167 **** --- 197,209 ---- .Xr init 8 for details.) .Pp + The implementation of all flags is filesystem-dependent. + See the description of the + .Dv UF_ARCHIVE + flag above for one example of the differences in behavior. + Care should be exercised when writing applications to account for + support or lack of support of these flags in various filesystems. + .Pp The .Dv SF_SNAPSHOT flag is maintained by the system and cannot be toggled. *** src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c.orig --- src/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c *************** *** 6061,6066 **** --- 6061,6074 ---- XVA_SET_REQ(&xvap, XAT_APPENDONLY); XVA_SET_REQ(&xvap, XAT_NOUNLINK); XVA_SET_REQ(&xvap, XAT_NODUMP); + XVA_SET_REQ(&xvap, XAT_READONLY); + XVA_SET_REQ(&xvap, XAT_ARCHIVE); + XVA_SET_REQ(&xvap, XAT_SYSTEM); + XVA_SET_REQ(&xvap, XAT_HIDDEN); + XVA_SET_REQ(&xvap, XAT_REPARSE); + XVA_SET_REQ(&xvap, XAT_OFFLINE); + XVA_SET_REQ(&xvap, XAT_SPARSE); + error = zfs_getattr(ap->a_vp, (vattr_t *)&xvap, 0, ap->a_cred, NULL); if (error != 0) return (error); *************** *** 6076,6083 **** --- 6084,6106 ---- xvap.xva_xoptattrs.xoa_appendonly); FLAG_CHECK(SF_NOUNLINK, XAT_NOUNLINK, xvap.xva_xoptattrs.xoa_nounlink); + FLAG_CHECK(UF_ARCHIVE, XAT_ARCHIVE, + xvap.xva_xoptattrs.xoa_archive); FLAG_CHECK(UF_NODUMP, XAT_NODUMP, xvap.xva_xoptattrs.xoa_nodump); + FLAG_CHECK(UF_READONLY, XAT_READONLY, + xvap.xva_xoptattrs.xoa_readonly); + FLAG_CHECK(UF_SYSTEM, XAT_SYSTEM, + xvap.xva_xoptattrs.xoa_system); + FLAG_CHECK(UF_HIDDEN, XAT_HIDDEN, + xvap.xva_xoptattrs.xoa_hidden); + FLAG_CHECK(UF_REPARSE, XAT_REPARSE, + xvap.xva_xoptattrs.xoa_reparse); + FLAG_CHECK(UF_OFFLINE, XAT_OFFLINE, + xvap.xva_xoptattrs.xoa_offline); + FLAG_CHECK(UF_SPARSE, XAT_SPARSE, + xvap.xva_xoptattrs.xoa_sparse); + #undef FLAG_CHECK *vap = xvap.xva_vattr; vap->va_flags = fflags; *************** *** 6115,6121 **** return (EOPNOTSUPP); fflags = vap->va_flags; ! if ((fflags & ~(SF_IMMUTABLE|SF_APPEND|SF_NOUNLINK|UF_NODUMP)) != 0) return (EOPNOTSUPP); /* * Unprivileged processes are not permitted to unset system --- 6138,6153 ---- return (EOPNOTSUPP); fflags = vap->va_flags; ! /* ! * XXX KDM ! * We need to figure out whether it makes sense to allow ! * UF_REPARSE through, since we don't really have other ! * facilities to handle reparse points and zfs_setattr() ! * doesn't currently allow setting that attribute anyway. ! */ ! if ((fflags & ~(SF_IMMUTABLE|SF_APPEND|SF_NOUNLINK|UF_ARCHIVE| ! UF_NODUMP|UF_SYSTEM|UF_HIDDEN|UF_READONLY|UF_REPARSE| ! UF_OFFLINE|UF_SPARSE)) != 0) return (EOPNOTSUPP); /* * Unprivileged processes are not permitted to unset system *************** *** 6167,6174 **** --- 6199,6220 ---- xvap.xva_xoptattrs.xoa_appendonly); FLAG_CHANGE(SF_NOUNLINK, ZFS_NOUNLINK, XAT_NOUNLINK, xvap.xva_xoptattrs.xoa_nounlink); + FLAG_CHANGE(UF_ARCHIVE, ZFS_ARCHIVE, XAT_ARCHIVE, + xvap.xva_xoptattrs.xoa_archive); FLAG_CHANGE(UF_NODUMP, ZFS_NODUMP, XAT_NODUMP, xvap.xva_xoptattrs.xoa_nodump); + FLAG_CHANGE(UF_READONLY, ZFS_READONLY, XAT_READONLY, + xvap.xva_xoptattrs.xoa_readonly); + FLAG_CHANGE(UF_SYSTEM, ZFS_SYSTEM, XAT_SYSTEM, + xvap.xva_xoptattrs.xoa_system); + FLAG_CHANGE(UF_HIDDEN, ZFS_HIDDEN, XAT_HIDDEN, + xvap.xva_xoptattrs.xoa_hidden); + FLAG_CHANGE(UF_REPARSE, ZFS_REPARSE, XAT_REPARSE, + xvap.xva_xoptattrs.xoa_hidden); + FLAG_CHANGE(UF_OFFLINE, ZFS_OFFLINE, XAT_OFFLINE, + xvap.xva_xoptattrs.xoa_offline); + FLAG_CHANGE(UF_SPARSE, ZFS_SPARSE, XAT_SPARSE, + xvap.xva_xoptattrs.xoa_sparse); #undef FLAG_CHANGE } return (zfs_setattr(vp, (vattr_t *)&xvap, 0, cred, NULL)); *** src/sys/fs/msdosfs/msdosfs_denode.c.orig --- src/sys/fs/msdosfs/msdosfs_denode.c *************** *** 304,311 **** if ((dep->de_flag & DE_MODIFIED) == 0 && waitfor == 0) return (0); dep->de_flag &= ~DE_MODIFIED; ! if (dep->de_Attributes & ATTR_DIRECTORY) ! return (0); if (dep->de_refcnt <= 0) return (0); error = readde(dep, &bp, &dirp); --- 304,311 ---- if ((dep->de_flag & DE_MODIFIED) == 0 && waitfor == 0) return (0); dep->de_flag &= ~DE_MODIFIED; ! if (DETOV(dep)->v_vflag & VV_ROOT) ! return (EINVAL); if (dep->de_refcnt <= 0) return (0); error = readde(dep, &bp, &dirp); *** src/sys/fs/msdosfs/msdosfs_vnops.c.orig --- src/sys/fs/msdosfs/msdosfs_vnops.c *************** *** 172,179 **** if (error) goto bad; ! ndirent.de_Attributes = (ap->a_vap->va_mode & VWRITE) ? ! ATTR_ARCHIVE : ATTR_ARCHIVE | ATTR_READONLY; ndirent.de_LowerCase = 0; ndirent.de_StartCluster = 0; ndirent.de_FileSize = 0; --- 172,178 ---- if (error) goto bad; ! ndirent.de_Attributes = ATTR_ARCHIVE; ndirent.de_LowerCase = 0; ndirent.de_StartCluster = 0; ndirent.de_FileSize = 0; *************** *** 256,263 **** mode_t file_mode; accmode_t accmode = ap->a_accmode; ! file_mode = (S_IXUSR|S_IXGRP|S_IXOTH) | (S_IRUSR|S_IRGRP|S_IROTH) | ! ((dep->de_Attributes & ATTR_READONLY) ? 0 : (S_IWUSR|S_IWGRP|S_IWOTH)); file_mode &= (vp->v_type == VDIR ? pmp->pm_dirmask : pmp->pm_mask); /* --- 255,261 ---- mode_t file_mode; accmode_t accmode = ap->a_accmode; ! file_mode = S_IRWXU|S_IRWXG|S_IRWXO; file_mode &= (vp->v_type == VDIR ? pmp->pm_dirmask : pmp->pm_mask); /* *************** *** 266,273 **** */ if (accmode & VWRITE) { switch (vp->v_type) { case VDIR: - case VREG: if (vp->v_mount->mnt_flag & MNT_RDONLY) return (EROFS); break; --- 264,271 ---- */ if (accmode & VWRITE) { switch (vp->v_type) { + case VREG: case VDIR: if (vp->v_mount->mnt_flag & MNT_RDONLY) return (EROFS); break; *************** *** 322,331 **** else vap->va_fileid = (long)fileid; ! if ((dep->de_Attributes & ATTR_READONLY) == 0) ! mode = S_IRWXU|S_IRWXG|S_IRWXO; ! else ! mode = S_IRUSR|S_IXUSR|S_IRGRP|S_IXGRP|S_IROTH|S_IXOTH; vap->va_mode = mode & (ap->a_vp->v_type == VDIR ? pmp->pm_dirmask : pmp->pm_mask); vap->va_uid = pmp->pm_uid; --- 320,326 ---- else vap->va_fileid = (long)fileid; ! mode = S_IRWXU|S_IRWXG|S_IRWXO; vap->va_mode = mode & (ap->a_vp->v_type == VDIR ? pmp->pm_dirmask : pmp->pm_mask); vap->va_uid = pmp->pm_uid; *************** *** 345,352 **** vap->va_birthtime.tv_nsec = 0; } vap->va_flags = 0; ! if ((dep->de_Attributes & ATTR_ARCHIVE) == 0) ! vap->va_flags |= SF_ARCHIVED; vap->va_gen = 0; vap->va_blocksize = pmp->pm_bpcluster; vap->va_bytes = --- 340,353 ---- vap->va_birthtime.tv_nsec = 0; } vap->va_flags = 0; ! if (dep->de_Attributes & ATTR_ARCHIVE) ! vap->va_flags |= UF_ARCHIVE; ! if (dep->de_Attributes & ATTR_HIDDEN) ! vap->va_flags |= UF_HIDDEN; ! if (dep->de_Attributes & ATTR_READONLY) ! vap->va_flags |= UF_READONLY; ! if (dep->de_Attributes & ATTR_SYSTEM) ! vap->va_flags |= UF_SYSTEM; vap->va_gen = 0; vap->va_blocksize = pmp->pm_bpcluster; vap->va_bytes = *************** *** 395,400 **** --- 396,413 ---- #endif return (EINVAL); } + + /* + * We don't allow setting attributes on the root directory. + * The special case for the root directory is because before + * FAT32, the root directory didn't have an entry for itself + * (and was otherwise special). With FAT32, the root + * directory is not so special, but still doesn't have an + * entry for itself. + */ + if (vp->v_vflag & VV_ROOT) + return (EINVAL); + if (vap->va_flags != VNOVAL) { if (vp->v_mount->mnt_flag & MNT_RDONLY) return (EROFS); *************** *** 408,431 **** * attributes. We ignored the access time and the * read and execute bits. We were strict for the other * attributes. - * - * Here we are strict, stricter than ufs in not allowing - * users to attempt to set SF_SETTABLE bits or anyone to - * set unsupported bits. However, we ignore attempts to - * set ATTR_ARCHIVE for directories `cp -pr' from a more - * sensible filesystem attempts it a lot. */ ! if (vap->va_flags & SF_SETTABLE) { ! error = priv_check_cred(cred, PRIV_VFS_SYSFLAGS, 0); ! if (error) ! return (error); ! } ! if (vap->va_flags & ~SF_ARCHIVED) return EOPNOTSUPP; ! if (vap->va_flags & SF_ARCHIVED) dep->de_Attributes &= ~ATTR_ARCHIVE; ! else if (!(dep->de_Attributes & ATTR_DIRECTORY)) ! dep->de_Attributes |= ATTR_ARCHIVE; dep->de_flag |= DE_MODIFIED; } --- 421,449 ---- * attributes. We ignored the access time and the * read and execute bits. We were strict for the other * attributes. */ ! if (vap->va_flags & ~(UF_ARCHIVE | UF_HIDDEN | UF_READONLY | ! UF_SYSTEM)) return EOPNOTSUPP; ! if (vap->va_flags & UF_ARCHIVE) ! dep->de_Attributes |= ATTR_ARCHIVE; ! else dep->de_Attributes &= ~ATTR_ARCHIVE; ! if (vap->va_flags & UF_HIDDEN) ! dep->de_Attributes |= ATTR_HIDDEN; ! else ! dep->de_Attributes &= ~ATTR_HIDDEN; ! /* We don't allow changing the readonly bit on directories. */ ! if (vp->v_type != VDIR) { ! if (vap->va_flags & UF_READONLY) ! dep->de_Attributes |= ATTR_READONLY; ! else ! dep->de_Attributes &= ~ATTR_READONLY; ! } ! if (vap->va_flags & UF_SYSTEM) ! dep->de_Attributes |= ATTR_SYSTEM; ! else ! dep->de_Attributes &= ~ATTR_SYSTEM; dep->de_flag |= DE_MODIFIED; } *************** *** 489,509 **** error = VOP_ACCESS(vp, VWRITE, cred, td); } else error = VOP_ACCESS(vp, VADMIN, cred, td); ! if (vp->v_type != VDIR) { ! if ((pmp->pm_flags & MSDOSFSMNT_NOWIN95) == 0 && ! vap->va_atime.tv_sec != VNOVAL) { ! dep->de_flag &= ~DE_ACCESS; ! timespec2fattime(&vap->va_atime, 0, ! &dep->de_ADate, NULL, NULL); ! } ! if (vap->va_mtime.tv_sec != VNOVAL) { ! dep->de_flag &= ~DE_UPDATE; ! timespec2fattime(&vap->va_mtime, 0, ! &dep->de_MDate, &dep->de_MTime, NULL); ! } dep->de_Attributes |= ATTR_ARCHIVE; ! dep->de_flag |= DE_MODIFIED; ! } } /* * DOS files only have the ability to have their writability --- 507,530 ---- error = VOP_ACCESS(vp, VWRITE, cred, td); } else error = VOP_ACCESS(vp, VADMIN, cred, td); ! if ((pmp->pm_flags & MSDOSFSMNT_NOWIN95) == 0 && ! vap->va_atime.tv_sec != VNOVAL) { ! dep->de_flag &= ~DE_ACCESS; ! timespec2fattime(&vap->va_atime, 0, ! &dep->de_ADate, NULL, NULL); ! } ! if (vap->va_mtime.tv_sec != VNOVAL) { ! dep->de_flag &= ~DE_UPDATE; ! timespec2fattime(&vap->va_mtime, 0, ! &dep->de_MDate, &dep->de_MTime, NULL); ! } ! /* ! * We don't set the archive bit when modifying the time of ! * a directory to emulate the Windows/DOS behavior. ! */ ! if (vp->v_type != VDIR) dep->de_Attributes |= ATTR_ARCHIVE; ! dep->de_flag |= DE_MODIFIED; } /* * DOS files only have the ability to have their writability *** src/sys/fs/smbfs/smbfs_node.c.orig --- src/sys/fs/smbfs/smbfs_node.c *************** *** 370,379 **** if (diff > 2) /* XXX should be configurable */ return ENOENT; va->va_type = vp->v_type; /* vnode type (for create) */ if (vp->v_type == VREG) { va->va_mode = smp->sm_file_mode; /* files access mode and type */ ! if (np->n_dosattr & SMB_FA_RDONLY) va->va_mode &= ~(S_IWUSR|S_IWGRP|S_IWOTH); } else if (vp->v_type == VDIR) { va->va_mode = smp->sm_dir_mode; /* files access mode and type */ } else --- 370,382 ---- if (diff > 2) /* XXX should be configurable */ return ENOENT; va->va_type = vp->v_type; /* vnode type (for create) */ + va->va_flags = 0; /* flags defined for file */ if (vp->v_type == VREG) { va->va_mode = smp->sm_file_mode; /* files access mode and type */ ! if (np->n_dosattr & SMB_FA_RDONLY) { va->va_mode &= ~(S_IWUSR|S_IWGRP|S_IWOTH); + va->va_flags |= UF_READONLY; + } } else if (vp->v_type == VDIR) { va->va_mode = smp->sm_dir_mode; /* files access mode and type */ } else *************** *** 390,396 **** va->va_mtime = np->n_mtime; va->va_atime = va->va_ctime = va->va_mtime; /* time file changed */ va->va_gen = VNOVAL; /* generation number of file */ ! va->va_flags = 0; /* flags defined for file */ va->va_rdev = NODEV; /* device the special file represents */ va->va_bytes = va->va_size; /* bytes of disk space held by file */ va->va_filerev = 0; /* file modification number */ --- 393,407 ---- va->va_mtime = np->n_mtime; va->va_atime = va->va_ctime = va->va_mtime; /* time file changed */ va->va_gen = VNOVAL; /* generation number of file */ ! if (np->n_dosattr & SMB_FA_HIDDEN) ! va->va_flags |= UF_HIDDEN; ! if (np->n_dosattr & SMB_FA_SYSTEM) ! va->va_flags |= UF_SYSTEM; ! /* ! * We don't set the archive bit for directories. ! */ ! if ((vp->v_type != VDIR) && (np->n_dosattr & SMB_FA_ARCHIVE)) ! va->va_flags |= UF_ARCHIVE; va->va_rdev = NODEV; /* device the special file represents */ va->va_bytes = va->va_size; /* bytes of disk space held by file */ va->va_filerev = 0; /* file modification number */ *** src/sys/fs/smbfs/smbfs_vnops.c.orig --- src/sys/fs/smbfs/smbfs_vnops.c *************** *** 305,320 **** int old_n_dosattr; SMBVDEBUG("\n"); - if (vap->va_flags != VNOVAL) - return EOPNOTSUPP; isreadonly = (vp->v_mount->mnt_flag & MNT_RDONLY); /* * Disallow write attempts if the filesystem is mounted read-only. */ if ((vap->va_uid != (uid_t)VNOVAL || vap->va_gid != (gid_t)VNOVAL || vap->va_atime.tv_sec != VNOVAL || vap->va_mtime.tv_sec != VNOVAL || ! vap->va_mode != (mode_t)VNOVAL) && isreadonly) return EROFS; scred = smbfs_malloc_scred(); smb_makescred(scred, td, ap->a_cred); if (vap->va_size != VNOVAL) { --- 305,334 ---- int old_n_dosattr; SMBVDEBUG("\n"); isreadonly = (vp->v_mount->mnt_flag & MNT_RDONLY); /* * Disallow write attempts if the filesystem is mounted read-only. */ if ((vap->va_uid != (uid_t)VNOVAL || vap->va_gid != (gid_t)VNOVAL || vap->va_atime.tv_sec != VNOVAL || vap->va_mtime.tv_sec != VNOVAL || ! vap->va_mode != (mode_t)VNOVAL || vap->va_flags != VNOVAL) && ! isreadonly) return EROFS; + + /* + * We only support setting four flags. Don't allow setting others. + * + * We map UF_READONLY to SMB_FA_RDONLY, unlike the MacOS X version + * of this code, which maps both UF_IMMUTABLE AND SF_IMMUTABLE to + * SMB_FA_RDONLY. The immutable flags have different semantics + * than readonly, which is the reason for the difference. + */ + if (vap->va_flags != VNOVAL) { + if (vap->va_flags & ~(UF_HIDDEN|UF_SYSTEM|UF_ARCHIVE| + UF_READONLY)) + return EINVAL; + } + scred = smbfs_malloc_scred(); smb_makescred(scred, td, ap->a_cred); if (vap->va_size != VNOVAL) { *************** *** 353,364 **** goto out; } } ! if (vap->va_mode != (mode_t)VNOVAL) { old_n_dosattr = np->n_dosattr; ! if (vap->va_mode & S_IWUSR) ! np->n_dosattr &= ~SMB_FA_RDONLY; ! else ! np->n_dosattr |= SMB_FA_RDONLY; if (np->n_dosattr != old_n_dosattr) { error = smbfs_smb_setpattr(np, np->n_dosattr, NULL, scred); if (error) --- 367,413 ---- goto out; } } ! if ((vap->va_flags != VNOVAL) || (vap->va_mode != (mode_t)VNOVAL)) { old_n_dosattr = np->n_dosattr; ! ! if (vap->va_mode != (mode_t)VNOVAL) { ! if (vap->va_mode & S_IWUSR) ! np->n_dosattr &= ~SMB_FA_RDONLY; ! else ! np->n_dosattr |= SMB_FA_RDONLY; ! } ! ! if (vap->va_flags != VNOVAL) { ! if (vap->va_flags & UF_HIDDEN) ! np->n_dosattr |= SMB_FA_HIDDEN; ! else ! np->n_dosattr &= ~SMB_FA_HIDDEN; ! ! if (vap->va_flags & UF_SYSTEM) ! np->n_dosattr |= SMB_FA_SYSTEM; ! else ! np->n_dosattr &= ~SMB_FA_SYSTEM; ! ! if (vap->va_flags & UF_ARCHIVE) ! np->n_dosattr |= SMB_FA_ARCHIVE; ! else ! np->n_dosattr &= ~SMB_FA_ARCHIVE; ! ! /* ! * We only support setting the immutable / readonly ! * bit for regular files. According to comments in ! * the MacOS X version of this code, supporting the ! * readonly bit on directories doesn't do the same ! * thing in Windows as in Unix. ! */ ! if (vp->v_type == VREG) { ! if (vap->va_flags & UF_READONLY) ! np->n_dosattr |= SMB_FA_RDONLY; ! else ! np->n_dosattr &= ~SMB_FA_RDONLY; ! } ! } ! if (np->n_dosattr != old_n_dosattr) { error = smbfs_smb_setpattr(np, np->n_dosattr, NULL, scred); if (error) *** src/sys/sys/stat.h.orig --- src/sys/sys/stat.h *************** *** 265,272 **** #define UF_NODUMP 0x00000001 /* do not dump file */ #define UF_IMMUTABLE 0x00000002 /* file may not be changed */ #define UF_APPEND 0x00000004 /* writes to file may only append */ ! #define UF_OPAQUE 0x00000008 /* directory is opaque wrt. union */ ! #define UF_NOUNLINK 0x00000010 /* file may not be removed or renamed */ /* * Super-user changeable flags. */ --- 265,290 ---- #define UF_NODUMP 0x00000001 /* do not dump file */ #define UF_IMMUTABLE 0x00000002 /* file may not be changed */ #define UF_APPEND 0x00000004 /* writes to file may only append */ ! #define UF_OPAQUE 0x00000008 /* directory is opaque wrt. union */ ! #define UF_NOUNLINK 0x00000010 /* file may not be removed or renamed */ ! /* ! * These two bits are defined in MacOS X. They are not currently used in ! * FreeBSD. ! */ ! #if 0 ! #define UF_COMPRESSED 0x00000020 /* file is compressed */ ! #define UF_TRACKED 0x00000040 /* renames and deletes are tracked */ ! #endif ! ! #define UF_SYSTEM 0x00000080 /* Windows system file bit */ ! #define UF_SPARSE 0x00000100 /* sparse file */ ! #define UF_OFFLINE 0x00000200 /* file is offline */ ! #define UF_REPARSE 0x00000400 /* Windows reparse point file bit */ ! #define UF_ARCHIVE 0x00000800 /* file needs to be archived */ ! #define UF_READONLY 0x00001000 /* Windows readonly file bit */ ! /* This is the same as the MacOS X definition of UF_HIDDEN. */ ! #define UF_HIDDEN 0x00008000 /* file is hidden */ ! /* * Super-user changeable flags. */ *** src/sys/ufs/ufs/ufs_vnops.c.orig --- src/sys/ufs/ufs/ufs_vnops.c *************** *** 528,536 **** return (EINVAL); } if (vap->va_flags != VNOVAL) { ! if ((vap->va_flags & ~(UF_NODUMP | UF_IMMUTABLE | UF_APPEND | ! UF_OPAQUE | UF_NOUNLINK | SF_ARCHIVED | SF_IMMUTABLE | ! SF_APPEND | SF_NOUNLINK | SF_SNAPSHOT)) != 0) return (EOPNOTSUPP); if (vp->v_mount->mnt_flag & MNT_RDONLY) return (EROFS); --- 528,538 ---- return (EINVAL); } if (vap->va_flags != VNOVAL) { ! if ((vap->va_flags & ~(SF_APPEND | SF_ARCHIVED | SF_IMMUTABLE | ! SF_NOUNLINK | SF_SNAPSHOT | UF_APPEND | UF_ARCHIVE | ! UF_HIDDEN | UF_IMMUTABLE | UF_NODUMP | UF_NOUNLINK | ! UF_OFFLINE | UF_OPAQUE | UF_READONLY | UF_REPARSE | ! UF_SPARSE | UF_SYSTEM)) != 0) return (EOPNOTSUPP); if (vp->v_mount->mnt_flag & MNT_RDONLY) return (EROFS); --cNdxnHkX5QqsyA0e-- From owner-freebsd-arch@FreeBSD.ORG Tue Aug 20 03:12:20 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 A57FAB5B; Tue, 20 Aug 2013 03:12:20 +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 609762A4E; Tue, 20 Aug 2013 03:12:19 +0000 (UTC) Received: (from root@localhost) by monday.kientzle.com (8.14.4/8.14.4) id r7K3C8HB069721; Tue, 20 Aug 2013 03:12:08 GMT (envelope-from tim@kientzle.com) Received: from [192.168.2.123] (CiscoE3000 [192.168.1.65]) by kientzle.com with SMTP id werssuegyqbsei2hi3v76mdbzn; Tue, 20 Aug 2013 03:12:08 +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: <551C488B-D56A-4E9F-8617-17B96D3E7677@bsdimp.com> Date: Mon, 19 Aug 2013 20:12:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: 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> <71A92486-2213-421E-B3D2-E55816C18924@bsdimp.com> <551C488B-D56A-4E9F-8617-17B96D3E7677@bsdimp.com> To: Warner Losh X-Mailer: Apple Mail (2.1283) Cc: =?iso-8859-1?Q?Dag-Erling_Sm=F8rgrav?= , secteam@freebsd.org, Mark R V Murray , 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: Tue, 20 Aug 2013 03:12:20 -0000 On Aug 19, 2013, at 3:01 PM, Warner Losh wrote: >=20 > On Aug 19, 2013, at 1:31 AM, Mark R V Murray wrote: >=20 >>=20 >> On 19 Aug 2013, at 08:18, Warner Losh wrote: >>> If we're going to allow passthrough, we should require the kernel = config to explicitly do something to get pass through. >>>=20 >>> nodevice yarrow >>> device random_passthrough >>>=20 >>> would be my suggestion. >>=20 >> I don't think it will sell; folks are asking for GENERIC with a = run-time switch to flip between the raw HW generator output and a SW = mixer/conditioner. I've not heard anyone asking for a run-time switch in GENERIC. I would suggest making that a longer-term option and having the choice of mixer/conditioner (Yarrow, Fortuna, or HW passthrough) be a compile-time choice for now. >>> 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=85 >>=20 >> Won't sell. Folks are saying they want the choice of the raw output. = In GENERIC. I've not heard anyone asking for raw output in GENERIC. I've heard people ask for the ability to compile customized kernels with raw output. From owner-freebsd-arch@FreeBSD.ORG Tue Aug 20 07:14:44 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 9F47FADA; Tue, 20 Aug 2013 07:14:44 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 5BC662804; Tue, 20 Aug 2013 07:14:44 +0000 (UTC) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VBg9H-000O0U-UB; Tue, 20 Aug 2013 08:14:41 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_6ACAF6A4-0C52-4CB0-B00A-E1953DB22B11"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: Date: Tue, 20 Aug 2013 08:14:32 +0100 Message-Id: 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> <71A92486-2213-421E-B3D2-E55816C18924@bsdimp.com> <551C488B-D56A-4E9F-8617-17B96D3E7677@bsdimp.com> To: Tim Kientzle X-Mailer: Apple Mail (2.1508) X-SA-Score: -2.2 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: Tue, 20 Aug 2013 07:14:44 -0000 --Apple-Mail=_6ACAF6A4-0C52-4CB0-B00A-E1953DB22B11 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 20 Aug 2013, at 04:12, Tim Kientzle wrote: >=20 > I've not heard anyone asking for a run-time switch in > GENERIC. des@ is the main one, and its what we have right now in CURRENT. > I would suggest making that a longer-term option > and having the choice of mixer/conditioner > (Yarrow, Fortuna, or HW passthrough) be > a compile-time choice for now. Too late. :-) Questions needing answering now include "should Yarrow/Fortuna be = run-time choosable?", "there are more than two hardware RNGs (Ivy, = Nehemiah) in the system, how do we best make them available?", "if more = than one HW RNG is present, do we mix them, and how?", "if the requested = configuration does not give you a random number supply, does the system = block or panic?". >>>> 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=85 >>>=20 >>> Won't sell. Folks are saying they want the choice of the raw output. = In GENERIC. >=20 > I've not heard anyone asking for raw output in GENERIC. There have been a couple. Again des@ is the one I remember most clearly = off the top of my head. M --=20 Mark R V Murray --Apple-Mail=_6ACAF6A4-0C52-4CB0-B00A-E1953DB22B11 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhMXXt58vKOKE6LNAQpnVgP/SpHWG57QnGkwzVlIHAMIRPamtG5EUfn9 Cxyd9t8oIe/Wgmut7IIdBJhCc8TiuiP5fMR9W8qDeQaU4uKuW2GjQXaHnBRwDKE7 jxIx6nzkaOFDtfCRKRESbOO80Zv+4LteRZ1xvGwqEaigtZzVu2ZsevW2JCJ8OWOj VyIidYtffnU= =N0gm -----END PGP SIGNATURE----- --Apple-Mail=_6ACAF6A4-0C52-4CB0-B00A-E1953DB22B11-- From owner-freebsd-arch@FreeBSD.ORG Wed Aug 21 19:03:25 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 9F03AF05 for ; Wed, 21 Aug 2013 19:03:25 +0000 (UTC) (envelope-from 3-g4VUgwJDAMoxlvhgzdugA4jpdlo.frpiuhhevg-dufkiuhhevg.ruj@calendar-server.bounces.google.com) Received: from mail-lb0-x249.google.com (mail-lb0-x249.google.com [IPv6:2a00:1450:4010:c04::249]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 062B0228B for ; Wed, 21 Aug 2013 19:03:24 +0000 (UTC) Received: by mail-lb0-f201.google.com with SMTP id v1so77088lbd.0 for ; Wed, 21 Aug 2013 12:03:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:reply-to:sender:auto-submitted:message-id:date:subject :from:to:content-type; bh=glcXyYVgQ5JQgiRlSV9TKRAjciiIk/VX/F8VosHx+lk=; b=JV5+So9n58KlckTj5DOztl6tl2Isn25TPYje5B/TSY7Jrtp/VcgZQ/pUvF5f/+Hb8K hWPmzwMFdb4q7g7gcoAgJOr0LEKOmUSWWcvMkgAZt+rHe4qbUWbGzMIBS7RlKQNrjqGM JS4c+Uco4YfE/PPJ7SJhVIQJXhGgLw9X3uiSLVtfS4FIgrJuMMlS18QyMaqTWNb9w3SZ 3tupXyGKgWP+9JM+nRvTTSoj5a1CDU6nIuk8CpFsoc5ppwqIZdxjTjghVwI94nHB7Fxj X38IczbOoL2Dke1ei8b6Omc6KvWynp2dbRnbY+FbEa00BNBfUv7hbO419yAVJVCIM1Dh ho/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:sender:auto-submitted:message-id:date:subject :from:to:content-type; bh=glcXyYVgQ5JQgiRlSV9TKRAjciiIk/VX/F8VosHx+lk=; b=S435Zxp0k1LIG4UjSSD3aM9+xFnF7KgD3Bisgr+10UVsbB3/C1Jute+8n9UJHbh0Np /RjKJpgnc0mlqjd0gvzt8LSjTinmRtB3qDNMlThkk3Zd+VJ+ozRW36aluUnCqsOXy9MJ UR3criccdtGigOMUV/iQqIYSo0BPxPgE8x2PsBNeD92ZyblgBKiD5qgm26j6+EepcEmF 612yau8ZZOQfVbDIZ5j7BvcWQ+n9Z0+vKXVGNCk/5JnS3lE2LMyK6MfK5og5LqWE00hV jON/Nu4rj68wE2cpLuStw8NutHxzGg4ge6DHacDtBz5xe8dlOinwzeDfnUNTRP6IwVpr KdJQ== MIME-Version: 1.0 X-Received: by 10.15.41.206 with SMTP id s54mr289788eev.6.1377111802734; Wed, 21 Aug 2013 12:03:22 -0700 (PDT) Sender: Google Calendar Auto-Submitted: auto-generated Message-ID: <089e01681eb6d195b204e479d3b4@google.com> Date: Wed, 21 Aug 2013 19:03:22 +0000 Subject: Invitation: Business Proposal / Partnership Investment @ Wed Aug 21, 2013 3:30pm - 4:30pm (luisedward71@gmail.com) From: "Engr.Luis Edward" To: "freebsd-arch@FreeBSD.ORG" Content-Type: multipart/mixed; boundary=089e01681eb6d195a804e479d3b3 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: "Engr.Luis Edward" List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Aug 2013 19:03:25 -0000 --089e01681eb6d195a804e479d3b3 Content-Type: text/plain; charset=windows-1252; format=flowed; delsp=yes Content-Transfer-Encoding: base64 WW91IGhhdmUgYmVlbiBpbnZpdGVkIHRvIHRoZSBmb2xsb3dpbmcgZXZlbnQuDQoNClRpdGxlOiBC dXNpbmVzcyBQcm9wb3NhbCAvIFBhcnRuZXJzaGlwIEludmVzdG1lbnQNCkZPUiBZT1VSIEtJTkQg QVRURU5USU9OIE9OIElOVkVTVE1FTlQNCg0KQSkgIElOVFJPRFVDVElPTjpUaGlzIGlzIEVuZ2lu ZWVyIEx1aXMgRWR3YXJkIGEgcGV0cm9jaGVtaWNhbC9vaWwgIA0KZXhwbG9yYXRpb24gZW5naW5l ZXIgd2l0aCB0aGUgU3lyaWFuIFBldHJvbGV1bSBDb21wYW55IGxvY2F0ZWQgaW4gRGFtYXNjdXMu ICANCk15c2VsZiBhbmQgdHdvIG90aGVyICBlbmdpbmVlcnMgRW5nci4gQi5TIEJhYnUgYW4gSW5k aWFuIGFuZCBFbmdyLiBEYXZpZCAgDQpRdWlqYWRhIEZpc2NoZXIgZnJvbSBWZW5lenVlbGEgbmVl ZHMgeW91ciBwYXJ0bmVyc2hpcCB0byBpbnZlc3Rpbmcgc29tZSAgDQpmdW5kcyBpbiB5b3VyIGNv dW50cnkgaW4gdmlhYmxlIHByb2plY3RzIG9uIHlvdXIgaW5zdHJ1Y3Rpb25zLg0KDQpCKSBTT1VS Q0UgT0YgVEhFIEZVTkRTOiBUaGUgZnVuZHMgd2VyZSByYWlzZWQgZnJvbSB0aGUgc2FsZSBvZiBj cnVkZSBvaWwgIA0KZnJvbSB0aGUgU3lyaWFuIG9pbCBmaWVsZC5XZSBoYXZlIHNlY3VyZWQgdGhl IGZ1bmRzIGFuZCBuZWVkcyBhbiBpbnZlc3RvciAgDQp3aG8gaXMgY2FwYWJsZSAgYW5kIHJlYWR5 IHRvIGludmVzdCB0aGUgZnVuZHMgaW4gZ29vZCBwcm9qZWN0cyBhbmQgIA0KcHJvcGVydGllcy4N Cg0KQykgV0hZIFlPVSBBUkUgQ0hPU0VOOiBXZSBjaG9zZSB5b3UgdG8gYXNzaXN0IHVzIGludmVz dCB0aGUgZnVuZHMgZm9sbG93aW5nICANCnRoZSBmYWN0cyB0aGF0IHdlIGFyZSBjYXJlZXIgZW5n aW5lZXJzIGFuZCB3ZSBoYXZlIG5vIGtub3dsZWRnZSBvZiAgDQpjb21tZXJjaWFsICBpbnZlc3Rt ZW50cyBhbmQgZm9yIHRoYXQgcmVhc29uLCB3ZSBuZWVkIGFuIGV4cGVydCB0byBndWlkZSB1cyAg DQphbmQgdG8gaGFuZGxlIGludmVzdG1lbnQgZGlyZWN0bHkuIEFsc28gd2UgY2hvc2UgeW91IGlu IG9yZGVyIHRvIGludmVzdCB0aGUgIA0KZnVuZHMgaW4gYSBnb29kIGVjb25vbXkuDQoNCkQpIFNI QVJJTkcgUkFUSU8gQU5EIFBFUklPRCBPRiBJTlZFU1RNRU5UOiBNeXNlbGYgYW5kIHR3byBvdGhl ciBjb2xsZWFndWVzICANCmhhdmUgYWdyZWVkIHRvIGdpdmUgMjUlIG9mIHRoZSBmdW5kcyB0byB5 b3Ugd2hpbGUgeW91IHdpbGwgYXNzaXN0IHVzIGludmVzdCAgDQo3NSUgaW4geW91ciBjb3VudHJ5 IG9ubHkgb24gcHJvamVjdHMgeW91IHdpbGwgcGVyc29uYWxseSBkcmFmdCBmb3IgdXMuIFlvdSAg DQp3aWxsIGJlIHJlc3BvbnNpYmxlIHRvIGRyYXcgaW52ZXN0bWVudCBwbGFuIGFzIHdlIHdpbGwg bm90IGJlIGludm9sdmVkICANCmZvbGxvd2luZyBvdXIgcG9vciBrbm93bGVkZ2Ugb24gaW52ZXN0 bWVudHMuDQoNCkUpIEdFTkVSQUwgUkVNQVJLUzogVGhpcyBwcm9qZWN0IGlzIDEwMCUgcmlzayBm cmVlIGJ1dCBuZWVkcyAgDQpjb25maWRlbnRpYWxpdHkuIFdlIG5lZWQgYW4gaW52ZXN0b3Igd2hv IGlzIHRyYW5zcGFyZW50LGRpcmVjdCwgc2VyaW91cyBhbmQgIA0KZGVkaWNhdGVkLiB3ZSBuZWVk IGFuIGludmVzdG9yICAgd2hvIHdpbGwgcmVwcmVzZW50IHVzIGFueSB3aGVyZSBpbiB0aGlzICAN CnByb2plY3QuIFdlIHdpbGwgY2hhbmdlIGFsbCBkb2N1bWVudHMgb2YgZGVwb3NpdCBpbiB5b3Vy IG5hbWUgYXMgc29vbiBhcyAgDQp5b3UgYXJlIGNvbmZpcm1lZCBvdXIgcG90ZW50aWFsIGludmVz dG9yLiBJZiB5b3UgICBhcmUgcmVhZHkgYW5kIHdpbGxpbmcgdG8gIA0KYXNzaXN0IHVzIGludmVz dCB0aGUgZnVuZHMsIGRvIGNvbnRhY3QgbWUgZm9yIG1vcmUgZGV0YWlscy4gQm90aCBwYXJ0aWVz ICANCm11c3QgYmUgcmVhZHkgdG8gZXhjaGFuZ2UgaWRlbnRpdGllcyBpbiBvcmRlciB0byBrbm93 IGVhY2ggb3RoZXIuDQoNCllvdXIgUmVzcG9uc2UgaXMgZXhwZWN0ZWQuIHNlbmQgeW91ciByZXNw b25zZSB0byBteSBwcml2YXRlIGVtYWlsICANCihsdWlzZS5lZHdhcmRAYW9sLmZyKQ0KDQpFTkdS LiBMVUlTIEVEV0FSRA0KbHVpc2UuZWR3YXJkQGFvbC5mcg0KU1lSSUFOIFBFVFJPTEVVTSBDT01Q QU5ZIERBTUFTQ1VTDQoNCldoZW46IFdlZCBBdWcgMjEsIDIwMTMgMzozMHBtIJYgNDozMHBtIEVh c3Rlcm4gVGltZQ0KQ2FsZW5kYXI6IGx1aXNlZHdhcmQ3MUBnbWFpbC5jb20NCldobzoNCiAgICAg KEd1ZXN0IGxpc3QgaGFzIGJlZW4gaGlkZGVuIGF0IG9yZ2FuaXplcidzIHJlcXVlc3QpDQoNCkV2 ZW50IGRldGFpbHM6ICANCmh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vY2FsZW5kYXIvZXZlbnQ/YWN0 aW9uPVZJRVcmZWlkPWFHazFNMnBqY21JemN6QjJPSEZtZEhZemRYUTRkalJoTkRnZ1puSmxaV0p6 WkMxaGNtTm9RR1p5WldWaWMyUXViM0puJnRvaz1NaklqYkhWcGMyVmtkMkZ5WkRjeFFHZHRZV2xz TG1OdmJUZ3hZVEpsWldJd05tUm1aV0kyTmpCaU9UY3hZamRsTnpBMk56RXdOV0UxTXpCak4yVmxO akEmY3R6PUFtZXJpY2EvTmV3X1lvcmsmaGw9ZW4NCg0KSW52aXRhdGlvbiBmcm9tIEdvb2dsZSBD YWxlbmRhcjogaHR0cHM6Ly93d3cuZ29vZ2xlLmNvbS9jYWxlbmRhci8NCg0KWW91IGFyZSByZWNl aXZpbmcgdGhpcyBjb3VydGVzeSBlbWFpbCBhdCB0aGUgYWNjb3VudCAgDQpmcmVlYnNkLWFyY2hA ZnJlZWJzZC5vcmcgYmVjYXVzZSB5b3UgYXJlIGFuIGF0dGVuZGVlIG9mIHRoaXMgZXZlbnQuDQoN ClRvIHN0b3AgcmVjZWl2aW5nIGZ1dHVyZSBub3RpZmljYXRpb25zIGZvciB0aGlzIGV2ZW50LCBk ZWNsaW5lIHRoaXMgZXZlbnQuICANCkFsdGVybmF0aXZlbHkgeW91IGNhbiBzaWduIHVwIGZvciBh IEdvb2dsZSBhY2NvdW50IGF0ICANCmh0dHBzOi8vd3d3Lmdvb2dsZS5jb20vY2FsZW5kYXIvIGFu ZCBjb250cm9sIHlvdXIgbm90aWZpY2F0aW9uIHNldHRpbmdzIGZvciAgDQp5b3VyIGVudGlyZSBj YWxlbmRhci4NCg== --089e01681eb6d195a804e479d3b3-- From owner-freebsd-arch@FreeBSD.ORG Fri Aug 23 22:21:52 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 0450935C for ; Fri, 23 Aug 2013 22:21:52 +0000 (UTC) (envelope-from jilles@stack.nl) Received: from mx1.stack.nl (unknown [IPv6:2001:610:1108:5012::107]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 89B152865 for ; Fri, 23 Aug 2013 22:21:51 +0000 (UTC) Received: from snail.stack.nl (snail.stack.nl [IPv6:2001:610:1108:5010::131]) by mx1.stack.nl (Postfix) with ESMTP id 62858120139 for ; Sat, 24 Aug 2013 00:21:34 +0200 (CEST) Received: by snail.stack.nl (Postfix, from userid 1677) id 3679928494; Sat, 24 Aug 2013 00:21:34 +0200 (CEST) Date: Sat, 24 Aug 2013 00:21:34 +0200 From: Jilles Tjoelker To: freebsd-arch@freebsd.org Subject: Using sys_errlist from executables is not ABI-stable Message-ID: <20130823222133.GA36931@stack.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) 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, 23 Aug 2013 22:21:52 -0000 The following program crashes or produces unexpected output if compiled on stable/9 and run on head: #include #include int main(int argc, char *argv[]) { printf("Last error: %d: %s\n", sys_nerr, sys_errlist[sys_nerr - 1]); printf("Last error via strerror: %d: %s\n", sys_nerr, strerror(sys_nerr - 1)); return 0; } The problem is that ld reserves space for sys_errlist at link time. The executable accesses sys_errlist directly like its own global variables. When the executable is run, rtld copies the string pointers from libc.so.7 to the executable's global variable. It does not care that the symbol in libc.so.7 is bigger than the executable's space (due to added ENOTRECOVERABLE and EOWNERDEAD), but even if it did, it could not fix the problem anyway. Meanwhile, the value of sys_nerr reflecting the larger sys_errlist is copied unchanged. The strerror() function in libc also uses the executable's copy. In my setup, the first printf gets NULL and the strerror() call segfaults. If the executable is linked statically or compiled with -fPIE, there are no copy relocations and it does not crash. The below patch makes libc always use its own copy of sys_errlist and sys_nerr. This ensures strerror() and friends continue to work correctly when an executable imports sys_errlist, but does not fix the executable's use of sys_errlist. As a side effect, the access to sys_errlist and sys_nerr becomes slightly faster and needs less work from rtld. One way of fixing the executable's use of sys_errlist would be to export sys_nerr with the value it had in FreeBSD 7.0 (93), making __hidden_sys_nerr a separate variable with the true value (or even a #define). This ensures that no error strings will be accessed out of bounds, but only errors that were in FreeBSD 7.0 are available to applications that use this deprecated method of accessing error strings. A more "proper" method would be to symbol version sys_errlist but this still does not allow accessing error strings added after the program was linked. Also considering other problems with sys_errlist (removing it would allow storing the error messages in a way that does not create one relative relocation per error message), I don't think it is worth it. Index: lib/libc/include/errlst.h =================================================================== --- lib/libc/include/errlst.h (revision 0) +++ lib/libc/include/errlst.h (working copy) @@ -0,0 +1,37 @@ +/*- + * Copyright (c) 2013 Jilles Tjoelker + * All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF + * SUCH DAMAGE. + * + * $FreeBSD$ + */ + +#ifndef __ERRLST_H__ +#define __ERRLST_H__ + +#include + +extern const char *const __hidden_sys_errlist[] __hidden; +extern const int __hidden_sys_nerr __hidden; + +#endif /* __ERRLST_H__ */ Property changes on: lib/libc/include/errlst.h ___________________________________________________________________ Added: svn:eol-style ## -0,0 +1 ## +native \ No newline at end of property Added: svn:mime-type ## -0,0 +1 ## +text/plain \ No newline at end of property Added: svn:keywords ## -0,0 +1 ## +FreeBSD=%H \ No newline at end of property Index: lib/libc/gen/errlst.c =================================================================== --- lib/libc/gen/errlst.c (revision 254670) +++ lib/libc/gen/errlst.c (working copy) @@ -34,6 +34,7 @@ __FBSDID("$FreeBSD$"); #include +#include "errlst.h" const char *const sys_errlist[] = { "No error: 0", /* 0 - ENOERROR */ @@ -156,3 +157,6 @@ "Previous owner died", /* 96 - EOWNERDEAD */ }; const int sys_nerr = sizeof(sys_errlist) / sizeof(sys_errlist[0]); + +__strong_reference(sys_errlist, __hidden_sys_errlist); +__strong_reference(sys_nerr, __hidden_sys_nerr); Index: lib/libc/stdio/xprintf_errno.c =================================================================== --- lib/libc/stdio/xprintf_errno.c (revision 254670) +++ lib/libc/stdio/xprintf_errno.c (working copy) @@ -34,6 +34,7 @@ #include #include #include +#include "errlst.h" #include "printf.h" int @@ -54,7 +55,7 @@ ret = 0; error = *((const int *)arg[0]); - if (error >= 0 && error < sys_nerr) { + if (error >= 0 && error < __hidden_sys_nerr) { p = strerror(error); return (__printf_out(io, pi, p, strlen(p))); } Index: lib/libc/string/strerror.c =================================================================== --- lib/libc/string/strerror.c (revision 254670) +++ lib/libc/string/strerror.c (working copy) @@ -42,6 +42,8 @@ #include #include +#include "errlst.h" + #define UPREFIX "Unknown error" /* @@ -87,7 +89,7 @@ catd = catopen("libc", NL_CAT_LOCALE); #endif - if (errnum < 0 || errnum >= sys_nerr) { + if (errnum < 0 || errnum >= __hidden_sys_nerr) { errstr(errnum, #if defined(NLS) catgets(catd, 1, 0xffff, UPREFIX), @@ -99,9 +101,9 @@ } else { if (strlcpy(strerrbuf, #if defined(NLS) - catgets(catd, 1, errnum, sys_errlist[errnum]), + catgets(catd, 1, errnum, __hidden_sys_errlist[errnum]), #else - sys_errlist[errnum], + __hidden_sys_errlist[errnum], #endif buflen) >= buflen) retval = ERANGE; -- Jilles Tjoelker From owner-freebsd-arch@FreeBSD.ORG Fri Aug 23 23:18:12 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 5C4819C; Fri, 23 Aug 2013 23:18:12 +0000 (UTC) (envelope-from jmg@h2.funkthat.com) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 33F6C2B59; Fri, 23 Aug 2013 23:18:11 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id r7NNI9fq016202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Aug 2013 16:18:09 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id r7NNI8ZY016201; Fri, 23 Aug 2013 16:18:08 -0700 (PDT) (envelope-from jmg) Date: Fri, 23 Aug 2013 16:18:08 -0700 From: John-Mark Gurney To: Tim Kientzle Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Message-ID: <20130823231808.GT94127@funkthat.com> Mail-Followup-To: Tim Kientzle , Mark R V Murray , Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , secteam@freebsd.org, FreeBSD-arch Arch References: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <932AB5CA-778E-438D-8FD3-8C0F29F3D117@kientzle.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Fri, 23 Aug 2013 16:18:09 -0700 (PDT) Cc: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= , secteam@freebsd.org, Mark R V Murray , 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: Fri, 23 Aug 2013 23:18:12 -0000 Tim Kientzle wrote this message on Sun, Aug 18, 2013 at 12:27 -0700: > 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. Considering that the Ivy bridge's rdrand implementation already uses AES to condition the raw entropy source, using Yarrow/etc to additionally condition it seems excesive, hence why some people want to use it directly... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." From owner-freebsd-arch@FreeBSD.ORG Sat Aug 24 08:35:56 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 488A74E4; Sat, 24 Aug 2013 08:35:56 +0000 (UTC) (envelope-from mark@grondar.org) Received: from gromit.grondar.org (grandfather.grondar.org [IPv6:2a01:348:0:15:5d59:5c20:0:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 083D9226B; Sat, 24 Aug 2013 08:35:55 +0000 (UTC) Received: from [2001:470:9174:1:99e7:47d0:ed0e:f6f5] by gromit.grondar.org with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80.1 (FreeBSD)) (envelope-from ) id 1VD9Jw-0008Z6-1m; Sat, 24 Aug 2013 09:35:47 +0100 Subject: Re: random(4) plugin infrastructure for mulitple RNG in a modular fashion Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D9A85106-FADA-46ED-9AAC-B9935A71D3A6"; protocol="application/pgp-signature"; micalg=pgp-sha512 From: Mark R V Murray In-Reply-To: <20130823231808.GT94127@funkthat.com> Date: Sat, 24 Aug 2013 09:35:38 +0100 Message-Id: <0ABD5A7F-D647-4958-92DB-79D277C9AE7C@grondar.org> References: <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> <20130823231808.GT94127@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1508) X-SA-Score: -1.0 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: Sat, 24 Aug 2013 08:35:56 -0000 --Apple-Mail=_D9A85106-FADA-46ED-9AAC-B9935A71D3A6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 24 Aug 2013, at 00:18, John-Mark Gurney wrote: > Tim Kientzle wrote this message on Sun, Aug 18, 2013 at 12:27 -0700: >> 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 > Considering that the Ivy bridge's rdrand implementation already uses > AES to condition the raw entropy source, using Yarrow/etc to > additionally condition it seems excesive, hence why some people want > to use it directly=85 Nehemiah as well, using a Davies-meyer hash in software. However, what may be excessive for one person may be another's requirement. M --=20 Mark R V Murray --Apple-Mail=_D9A85106-FADA-46ED-9AAC-B9935A71D3A6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.20 (Darwin) Comment: GPGTools - http://gpgtools.org iQCVAwUBUhhwXt58vKOKE6LNAQpV2wQArVhVCiPmJijv53f34SznlHhPr3Uz4G4V htbUuHCuILD80UWjPr0/6Clr0YH29LVsVgu3hrP42fsidc7Uwnw6aHqqkV/3Dcku NssBuMEU7C9cvazBvl/u1vMue9hHdz4gaeb8wwXJeBUyJ611oI4AjZ1budJvfRQc fjTyib7efHc= =80Bz -----END PGP SIGNATURE----- --Apple-Mail=_D9A85106-FADA-46ED-9AAC-B9935A71D3A6-- From owner-freebsd-arch@FreeBSD.ORG Sat Aug 24 14:57:23 2013 Return-Path: Delivered-To: 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 5AE977C2 for ; Sat, 24 Aug 2013 14:57:23 +0000 (UTC) (envelope-from bounces+612829-ba58-arch=freebsd.org@sendgrid.info) Received: from o1.bn.sendgrid.net (o1.bn.sendgrid.net [75.126.253.211]) by mx1.freebsd.org (Postfix) with SMTP id 18E762232 for ; Sat, 24 Aug 2013 14:57:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sendgrid.me; h=from:to :subject:mime-version:content-type; s=smtpapi; bh=tzRVJZXeh1HqNS Ei1omxXrPV5hI=; b=EavUx+IOTp2bxks80T4HeN1B0QQjf8uvXkFL9F9RGJH2EZ yYsnaKI3vA1CuiO+2gtbZZZC/6IYiytKEpJW17DK8Rpxb02MESLFIYLySBlGpWOS l+8dqfaC/sYqDcpkkA4IswRZDkqbPH7VnKRBjKbfhDzkfGCxrSOPWite35/mQ= Received: by with SMTP id filter-141.21887.5218C85C3 Sat, 24 Aug 2013 14:51:08 +0000 (GMT) Received: from (ool-ad034738.dyn.optonline.net [173.3.71.56]) by ismtpd-017 (SG) with ESMTP id 140b0cea9b8.48ed.2c307 for ; Sat, 24 Aug 2013 14:51:08 +0000 (UTC) From: TheUrbanShopper To: Date: Sat, 24 Aug 2013 10:50:55 -0400 Subject: IN THIS ISSUE: Back to School Fashions for Grownups | Autism's Social Side | Susu Saving | Outdoor Party Recipes X-Mailer: TOL Mailer MIME-Version: 1.0 Content-Type: multipart/mixed; boundary=_0_.__.__TOL__Mailer__Part_Boundary_ Message-ID: <1377355868.7735269430301329@filter-141.sjc1.sendgrid.net> X-SG-EID: PYCKI43QWrQUfl7nqliIpR4qzPlu41Kt+60rv5InnxH0xy/1fOWadm660dIekt7CmXuv+/r9xaBMXITVEXbYHjEMEXOkHB9BtyqZqAsjymB9fD4/kXJYt0Ir8hjv5H7e X-Content-Filtered-By: Mailman/MimeDel 2.1.14 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: Sat, 24 Aug 2013 14:57:23 -0000 This is a multi-part message in MIME format. --_0_.__.__TOL__Mailer__Part_Boundary_ Content-Type: multipart/related; boundary=_1_.__.__TOL__Mailer__Part_Boundary_ --_1_.__.__TOL__Mailer__Part_Boundary_ Content-Type: text/plain Content-Transfer-Encoding: 7Bit Untitled Document
Having trouble reading this email? Click Here to go direct to TheUrbanShopper.com.
To ensure delivery, please add us@theurbanshopper.com to your Safe Sender List or Address Book.
TheUrbanShopper Newsletter
You have received this update as a subscriber to TheUrbanShopper.com. Ensure inbox delivery by adding us@theurbanshopper.com to your SAFE SENDER or email CONTACTS list. If you'd like to unsubscribe . For more information, please read our Privacy Policy . ©2013 All Rights Reserved
--_1_.__.__TOL__Mailer__Part_Boundary_-- --_0_.__.__TOL__Mailer__Part_Boundary_--