From owner-freebsd-current@FreeBSD.ORG Thu Aug 5 16:03:15 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6C47816A4CE; Thu, 5 Aug 2004 16:03:15 +0000 (GMT) Received: from out010.verizon.net (out010pub.verizon.net [206.46.170.133]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0150443D45; Thu, 5 Aug 2004 16:03:15 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from [192.168.1.3] ([68.161.100.95]) by out010.verizon.net (InterMail vM.5.01.06.06 201-253-122-130-106-20030910) with ESMTP id <20040805160314.NGPA14383.out010.verizon.net@[192.168.1.3]>; Thu, 5 Aug 2004 11:03:14 -0500 Message-ID: <41125A3D.2040806@mac.com> Date: Thu, 05 Aug 2004 12:03:09 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.1) Gecko/20040707 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Robert Watson References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Authentication-Info: Submitted using SMTP AUTH at out010.verizon.net from [68.161.100.95] at Thu, 5 Aug 2004 11:03:13 -0500 cc: Sam Leffler cc: freebsd-current@FreeBSD.ORG cc: Mark Murray Subject: Re: So much entropy it's coming out of our ears? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Aug 2004 16:03:15 -0000 Robert Watson wrote: > On Thu, 5 Aug 2004, Mark Murray wrote: [ ...snip Sam's comments about push versus pull models of harvesting entropy... ] >> Yarrow is not conducive to "water-mark" type flow-control, but I'm >> looking at replacing Yarrow with Fortuna (code at an advanced stage). >> This should improve things all-round. > > Could we do the rate limiting on the sender side, then, by making a > guestimate at a maximum useful entropy rate? [ ... ] > I.e., add a "entropy_gathered" int that uses a unlocked read to test for > non-zero, and is decremented while holding one of the harvesting mutexes > if it's non-zero. Reset it in a callout a few times a second, and set it > to some small value, like 4. This will result in the gathering of some > entropy each second, but not so much that it seriously hits the packet > delivery path in higher workloads. For what it's worth, this sounds like a pretty good approach to me. Given that Yarrow maintains an estimate of the amount of entropy available, it ought to be easy to use that to decide whether "4" or some other value is appropriate. If the entropy pool is "full", leave entropy_gathered == 0, or perhaps set it to a small value as Robert suggests so that we're still churning a few random bits into the pool. If entropy is being used, set entropy_gathered equal to some bigger value which is appropriate for the how much new entropy the pool would like to get over the next interval. Furthermore, the code which does the entropy gathering might even choose to pay attention to how much entropy is desired and alter their sensitivity a bit (ie, how many of the least-significant bits from a timestamp based on the interval between when the last two packets were received are trusted to be "random"). [ This part is a good candidate for a sysctl, so those who are concerned about the purity of their entropy can choose that the entropy harvesting code be pessimistic, whereas others who just want /dev/random to output reasonably random stuff without much overhead can choose to get just that, instead. ] Perhaps change the name from entropy_gathered to entropy_wanted? That seems to best describe what it's being used for... -- -Chuck