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...

[Scott Long]

> On Jul 24, 2015, at 12:59 AM, Mark R V Murray <markm at FreeBSD.org> wrote:
> 
> 
>> On 24 Jul 2015, at 02:25, John-Mark Gurney <jmg at 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