Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 13 Jan 2001 13:10:54 -0800 (PST)
From:      Matt Dillon <dillon@earth.backplane.com>
To:        Mark Murray <mark@grondar.za>
Cc:        Robert Watson <rwatson@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/etc crontab rc src/etc/defaults rc.conf src/etc/mtree BSD.root.dist src/libexec Makefile src/libexec/save-entropy Makefile save-entropy.sh 
Message-ID:  <200101132110.f0DLAsp34762@earth.backplane.com>
References:  <200101131857.f0DIvQR33918@earth.backplane.com>  <200101132028.f0DKSrI21262@gratis.grondar.za>

next in thread | previous in thread | raw e-mail | index | archive | help

:
:> :<repeat iteration=$BIGNUM>
:> :When the high-rate harvesters go in (after the preemptive threading),
:> :the "off" --> "on" transition will happen within a couple of seconds,
:> :and will no longer be a problem.
:> :</repeat>
:> :
:> :M
:> :-- 
:> :Mark Murray
:> 
:>     This isn't good enough.  What if the devices the high-rate harvesters
:>     use aren't configured in the system?
:
:For this, I have agreed in another (more recent) conversation that
:converting the compile-time option that turns off block-at-boot
:into a sysctl that can be tweeked by the sysadmin is a good idea.
:
:Already coded, undergoing testing. Will commit soon.
:
:M
:-- 
:Mark Murray
:Warning: this .sig is umop ap!sdn

    The *DEFAULT* has to guarentee proper operation.   Rather then forcing
    sysadmins to turn on the option when things break, the option should
    be turned on by default and sysadmins who are paranoid about the
    random number generator can turn it off.

    Either that, or not have a sysctl at all and instead have the
    device *guarentee* that it will not block for an unreasonable period
    of time.

    All the commits to date have been to be utterly paranoid about the
    cryptographic security of the random number generator to the detriment
    of everyone who has ever had a major snafu related to the blocking,
    and everyone who ever might have a snafu because they are running a
    kernel configuration that doesn't happen to use the devices you decide
    to depend on in your auto-seeding.

    You have to make the the damn thing work for everyone else FIRST, and
    *then* worry about cryptographic security during boot.  Your priorities
    are reversed.

						-Matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200101132110.f0DLAsp34762>