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

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

M
-- 
Mark R V Murray