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

[Adrian Chadd]

On 31 July 2013 03:40, Philip Paeps <philip at freebsd.org> wrote:

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

I'm 100% against this. I'm getting extremely fed up with the "default
is on" bloat that is everywhere in our sub-systems. David is actually
_tidying things up_ by making optional devices be standalone devices -
that way they show up as very simple to include and expand when making
modules of things. Otherwise you turn this into a single, monolithic
module that has compile options.. and that sucks.

David's way is clean, simple and architecturally well-designed. It's
how it should've been done in the first place.

I'd like to see people bite the bullet in 10.0 for this and other
devices / subsystems.

> But what happens to the adaptors if you kldunload random?

Things should be correctly refcounted so you can't actually do that if
any of the users of it are loaded.

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

We have an infrastructure for this - it's called /boot/loader.conf .

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

I'd like to see the architectural changes needed for a cleanup like
this take place, rather than getting lost in discussion.

For the MIPS boards I hack on/for, I don't have any guaranteed random
number generator. So it's Yarrow or bust. So we need to "properly
seed" things as best as we can before any hardware random number
generators are loaded. The same problem exists for i386/amd64 with
hardware PRNGs.. we should ensure yarrow is properly seeded here.

Tsk,



-adrian