From owner-cvs-src@FreeBSD.ORG Fri Aug 15 12:07:54 2003 Return-Path: Delivered-To: cvs-src@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 133E837B401; Fri, 15 Aug 2003 12:07:54 -0700 (PDT) Received: from ebb.errno.com (ebb.errno.com [66.127.85.87]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4D8B543FAF; Fri, 15 Aug 2003 12:07:53 -0700 (PDT) (envelope-from sam@errno.com) Received: from melange.errno.com (melange.errno.com [66.127.85.82]) (authenticated bits=0) by ebb.errno.com (8.12.9/8.12.9) with ESMTP id h7FJ7n7N099217 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 15 Aug 2003 12:07:52 -0700 (PDT) (envelope-from sam@errno.com) Date: Fri, 15 Aug 2003 12:07:51 -0700 From: Sam Leffler To: Mike Silbersack Message-ID: <87953260.1060949270@melange.errno.com> In-Reply-To: <20030815133943.I1565@odysseus.silby.com> References: <200308150634.h7F6Ylxw022089@repoman.freebsd.org> <76344918.1060937662@melange.errno.com> <20030815133943.I1565@odysseus.silby.com> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline cc: cvs-src@FreeBSD.org cc: src-committers@FreeBSD.org cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/libkern arc4random.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Aug 2003 19:07:54 -0000 > On Fri, 15 Aug 2003, Sam Leffler wrote: > >> > Lock down arc4random so it can be safely called w/o Giant. >> > >> > Minor code reorganization was required, but the only functional >> > change was that the first 1024 bytes of output are thrown out >> > after each reseed, rather than just the initial seed. >> >> How did you validate the this change? I strongly suggest that mods like >> this need review before commit. Subtle problems can go unnoticed for a >> long time. >> >> Sam > > I'm fairly confident that I did not add any bugs in this commit. I suggest that being fairly confident about your changes is very different from testing them. > However,I also have no way of knowing if arc4random was working correctly before > the commit either... If you didn't know how to verify things worked before or after why did you make these changes? Was there a specific problem you were trying to address? > How hard would it be to hook up the randomness > testing code you committed a few months back? If the testing code is in > userland, perhaps we could export a /dev/arandom like openbsd does for > simpler testing. > You could use the rndtest code directly in the kernel to gate the output of arc4random or you could extract the code and write a user-level test application. I don't know if Mark Murray has something already along these lines (presumably he had something from his work on /dev/random). Note that the data generated by arc4random needs to be exported to user apps for seeding crypto operations when operating in a chroot'd environment where /dev/random is not available. This is something openbsd identified and that we've not brought over yet (I've known about it for a while but the work's been pending). As such one should be very careful about futzing with the goodness of the data arc4random generates. Sam