>> [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 [email protected] / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
