[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Patch: rework kernel random number subsystem
>> [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
Main Index |
Thread Index |