From owner-svn-src-all@freebsd.org Sat Jul 25 08:10:43 2015 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD0219AA873; Sat, 25 Jul 2015 08:10:43 +0000 (UTC) (envelope-from markm@FreeBSD.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)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 77E15944; Sat, 25 Jul 2015 08:10:43 +0000 (UTC) (envelope-from markm@FreeBSD.org) Received: from graveyard.grondar.org ([88.96.155.33] helo=gronkulator.grondar.org) by gromit.grondar.org with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.85 (FreeBSD)) (envelope-from ) id 1ZIuXV-000O8c-Tg; Sat, 25 Jul 2015 09:10:38 +0100 Subject: Re: svn commit: r284959 - in head: . share/man/man4 share/man/man9 sys/conf sys/dev/glxsb sys/dev/hifn sys/dev/random sys/dev/rndtest sys/dev/safe sys/dev/syscons sys/dev/ubsec sys/dev/virtio/random sy... Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2102\)) Content-Type: text/plain; charset=utf-8 From: Mark R V Murray In-Reply-To: <96EA33AB-7325-4DD2-83F4-B4FAF6F47CB5@yahoo.com> Date: Sat, 25 Jul 2015 09:10:31 +0100 Cc: src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <201506301700.t5UH0jPq001498@svn.freebsd.org> <20150724012519.GE78154@funkthat.com> <96EA33AB-7325-4DD2-83F4-B4FAF6F47CB5@yahoo.com> To: Scott Long X-Mailer: Apple Mail (2.2102) X-SA-Score: -1.0 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Jul 2015 08:10:43 -0000 > On 25 Jul 2015, at 06:06, Scott Long wrote: >=20 >> I=E2=80=99m working on a premise of =E2=80=9Ctools, not policy=E2=80=9D= . I=E2=80=99d like there to be >> enough harvesting points for the box owner to get the warm fuzzies. >> If they choose to use less, fine by me. >>=20 >=20 > Sure, and that=E2=80=99s not an unreasonable goal, but the devil is in = the details. Yes, indeed! > It=E2=80=99s an unfortunate fact of modern CPU architecture that even = something > as simple and innocent as a run-time control that checks a variable = can > cause significant performance problems, thanks to the penalty of cache > misses and bus contention between lots of CPU cores. Maybe these > =E2=80=9Cextended=E2=80=9D collection points should be controlled with = a compile-time > option? They can. I=E2=80=99ve coded it already, but not tested it properly, and = will commit in a week or two. :-) >=20 >>> Many of the issues that FreeBSD sees with lack of entropy at start = up >>> is more of a problem on how systems are installed and provisioned. = I >>> don't believe that we currently store any entropy from the install >>> process, yet this is one of the best places to get it, the user is >>> banging on keyboard selecting options, etc. If an image is designed >>> to be cloned (vm images or appliance images) we need to have a >>> mechanism to ensure that before we start, we get the entropy from >>> other sources, be it a hardware RNG or the console. >>=20 >> Getting an initial entropy bundle for first boot is high up on my >> TODO list. :-) Patches welcome! We need the usual /entropy (or >> /var/db/entropy/=E2=80=A6 or whatever) and crucially we need = /boot/entropy >> and the correct invocation in /boot/loader.conf. >>=20 >=20 > I agree that bootstrap entropy is a big deal, especially with the = increasing > prevalence of using virtual machine containers, cloned images, and > datacenter automation. Addressing that is an interesting problem, and > goes well beyond the scope of in-kernel entropy collection. I wish I = had > a simple answer or a patch for you ;-) The hard stuff has been done. We just need to write (e.g.) 4k of good numbers to /boot/entropy and job nearly done. This could be done by sysinstall or by the cloning system, for example. The embedded folks will still need a bit more careful etc/rc.d/* design. >> Well, sure, but what if you don=E2=80=99t have microphone? I want = lots >> of choices, in anticipation of only a subset being usable. >>=20 >=20 > I still think that for most use cases where you have a high likelyhood > of draining /dev/random of useful bits, you=E2=80=99re likely already = on a tight > budget for CPU cycles and you=E2=80=99ll probably just look to a = hardware > accelerator rather than sacrifice even more CPU cycles. At least, > that=E2=80=99s what the nice sale people at Cavium and Intel tell me = ;-) Sure, but I don=E2=80=99t trust them either. This is the professional = mistrust of crypto, not an assertion of incompetence or malice. ;-) They do, however, fulfil a need, but I don=E2=80=99t like the idea of trusting a = single source unless that source has been properly vetted. M --=20 Mark R V Murray