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

[Mark R V Murray]

> On 25 Jul 2015, at 06:06, Scott Long <scott4long at 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