Re: Patch: rework kernel random number subsystem

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> [I]f working hardware RNG get auto-detached whenever a 1-in-10000
>> test trips, long-lived systems _will_ lose their RNGs.
> 1) Hardware RNGs are statistically tested only once [per boot] [...]
>    So we are actually talking about a hardware RNG being incorrectly
>    detached once per 10,000 system boots.

Ah.  Yes, that's still not great, but probably better than risking
failed hardware going unnoticed.  (I'd _like_ to see some way to
control this, even if a kernel compile option, but it really doesn't
make all that much difference to me.)

Of course, it introduces a new risk, that of hardware failing in
service and the failure not being noticed until next boot (which may be
quite a while off; I've seen systems with well over a year of uptime).
However, hardware RNGs are probably one of the less fragile pieces on
systems that have them....

> 2) This is considerably gentler than what the relevant standard
>    requires, namely shutdown and restart of the entire cryptographic
>    module -- in other words, a panic.

Agreed.  It might be nice to have an option to behave that way, for
tick-list conformance if nothing else, but if whoever's doing it (you?)
doesn't want to bother implementing more than one reaction I'd prefer
the current way.

Again, it doesn't make a whole lot of difference to me.

> My thinking is that, again, with other sources of entropy for the
> pool (including entropy preserved across normal shutdown/restart
> cycles, which I will implement soon)

Hm.  Saving entropy across reboots makes me uneasy but I haven't been
able to come up with any specific example of something it gets wrong,
at least not assuming the entropy-in-the-pool value is set to 0 even if
entropy is loaded at boot, and the pool is stirred before being saved.

I assume it's disableable?

> it is better to detach the hardware RNG, emit a warning, and continue
> to run, than to reboot the whole system.  But perhaps this is wrong;
> after all, if the result is spurious, it should not happen again at
> the next boot -- and if it *does* happen repeatedly, perhaps most
> admins would prefer to *not* run the system without a hardware RNG in
> the long term.

Well, "continue to run" is a somewhat misleading phrasing if this
happens at hardware RNG attach time, since that will be boot time, not
after the system has been up for a while.

I also think that unconditionally panicking at boot time if the RNG
fails is possibly a bad idea; it makes it difficult-to-impossible to
boot manually and build a kernel with the RNG disabled.  Of course, not
all admins will want to do that, but some will.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B