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-31 11:15:55 (-0700), Adrian Chadd <adrian at freebsd.org> wrote:
> 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.

I'm absolutely not against "removing bloat" in general.  This particular
change, however, potentially leaves anyone who builds a custom kernel
("to remove bloat") and doesn't have a hardware PRNG without any PRNG.
We don't make changes like that without warning people.

While everyone should read UPDATING, many people only read it when stuff
(visibly) breaks, which could cause this change to slip under the radar
for them.

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

Sure.  I agree.  I read through the random_adaptors code and I like the
design and couldn't see any immediate issues.  The reasons I wanted this
backed out for now, are firstly that we have a policy that changes
affecting random should be reviewed by secteam before being committed
and secondly that I don't feel we should potentially be leaving a large
group of people without any functional random.

As soon as secteam can do a more thorough review of the random_adaptors
code, it should definitely come back.  It's an architectural change in
the right direction.  I am a lot less sure about removing Yarrow by
default, but that's something we can discuss as a separate issue - it
doesn't block the architectural improvement as far as I'm concerned.

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

I think we are enthusiastically agreeing with each other for the most
part. :)  I also want the architectural improvement and I'm all in
favour of removing bloat.

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

Right.  And had you not seen this discussion, when would you have
noticed that Yarrow was gone?  How long would you have run with poor
random before you found the entry in UPDATING that told you that you
needed to add an option to your kernel configuration?

I agree that this change is generally good.  I just want to see it
more thoroughly reviewed by secteam, and a discussion about whether we
want Yarrow to be default, and if not, when we throw that switch.

Philip

-- 
Philip Paeps
Senior Reality Engineer
Ministry of Information