On 31 July 2013 03:40, Philip Paeps <phi...@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 _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
