svn commit: r253779 - in head: . share/man/man4 sys/amd64/conf sys/arm/conf sys/conf sys/dev/random sys/i386/conf sys/ia64/conf sys/mips/conf sys/modules sys/modules/random sys/pc98/conf sys/powerp...

[Philip Paeps]

On 2013-07-29 20:26:27 (+0000), David E. O'Brien <obrien at FreeBSD.org> wrote:
> Author: obrien
> Date: Mon Jul 29 20:26:27 2013
> New Revision: 253779
> URL: http://svnweb.freebsd.org/changeset/base/253779
> 
> Log:
>   Decouple yarrow from random(4) device.

As Dag-Erling already pointed out in relpy to r253789: please submit any
RNG changes to secteam@ to review before committing them.  That aside,
it would have been easier to review this if it were split into more than
two commits.

>   * Make Yarrow an optional kernel component -- enabled by "YARROW_RNG" option.
>     The files sha2.c, hash.c, randomdev_soft.c and yarrow.c comprise yarrow.

I would really prefer to see this logic reversed.  Of course, we expect
people to read UPDATING, but disabling functionality that has been
enabled by default "forever" without any warning, especially in a
security-related context is not cool.  Please change YARROW_RNG to
RNG_NO_YARROW or something similar and keep it in by default.  If you
think there's a really good reason to kick support out by default, there
are mailing lists to discuss this.

>   * Add random_adaptors.[ch] which is basically a store of random_adaptor's.
>     random_adaptor is basically an adapter that plugs in to random(4).

This is a good idea.  I've briefly read through the code (ie: not a
thorough review) and it looks okay at first glance.  It would have been
good if this were a separate commit and given a chance to be reviewed by
people familiar with the RNG code.

>     Unplugging random_adaptor from random(4) is not supported, and is probably a
>     bad idea anyway, due to potential loss of entropy pools.

I agree.

But what happens to the adaptors if you kldunload random?

>   * If the kernel doesn't have any random_adaptor adapters present then the
>     creation of /dev/random is postponed until next random_adaptor is kldload'ed.

This worries me.  A fast-booting system might want random numbers in
userland before a random_adaptor is loaded (and properly seeded?).  We
don't have particularly stellar support for early random numbers, but we
should be careful not to make it worse.

Also: what happens to in-kernel consumers of random (like TCP) before
the first random_adaptor is attached (and properly seeded)?

I'd really like to see this get some more review.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Ministry of Information