> On 25 Jul 2015, at 06:06, Scott Long <scott4l...@yahoo.com> wrote: > >> I’m working on a premise of “tools, not policy”. I’d 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. >> > > Sure, and that’s not an unreasonable goal, but the devil is in the details.
Yes, indeed! > It’s 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 > “extended” collection points should be controlled with a compile-time > option? They can. I’ve coded it already, but not tested it properly, and will commit in a week or two. :-) > >>> 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. >> >> 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/… or whatever) and crucially we need /boot/entropy >> and the correct invocation in /boot/loader.conf. >> > > 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’t have microphone? I want lots >> of choices, in anticipation of only a subset being usable. >> > > I still think that for most use cases where you have a high likelyhood > of draining /dev/random of useful bits, you’re likely already on a tight > budget for CPU cycles and you’ll probably just look to a hardware > accelerator rather than sacrifice even more CPU cycles. At least, > that’s what the nice sale people at Cavium and Intel tell me ;-) Sure, but I don’t 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’t like the idea of trusting a single source unless that source has been properly vetted. M -- Mark R V Murray _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
