> On Jul 24, 2015, at 12:59 AM, Mark R V Murray <ma...@freebsd.org> wrote: > > >> On 24 Jul 2015, at 02:25, John-Mark Gurney <j...@funkthat.com> wrote: >> >> I would like to point out that the goal of collecting large amounts >> is starting to fall out of favor, and I happen to agree with the likes >> of djb[1] that we don't need an infinite amount of entropy collected by >> the system. If the attacker can read out our RNG state, then we are >> already screwed due to many other vulns. > > 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. 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? >> 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 ;-) >> I would like to see us scale back the entropy collection, and replace >> it with something like scan the zone once an hour or something >> similar. Or do something dtrace style, where we nop/jmp the >> collection after we feel that the system has collected enough. > > Most of the current entropy gathering is just about invisible > anyway. I think the above goes too far, but may be a useful way > of enabling/disabling (say) UMA gathering on the fly. > >> Heck, piping in mic data to /dev/random is a good way to seed the >> rng on many machines. > > 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 ;-) Scott _______________________________________________ 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"
