Hi Thomas and others, Your "genirq: Disable random call on preempt-rt" commit on Jul 21 2009 removes interrupt timings as a potential source of randomness for the kernel entropy pool, if CONFIG_PREEMPT_RT_FULL is set. I have no qualms with this change, per se; manipulating the entropy pool is clearly something that shouldn't be happening at IRQ priority. However: on an embedded linux-rt system with solid-state storage, add_input_randomness() ought to contribute no entropy at all, and add_disk_randomness() likely contributes a marginal amount of entropy, since SSD seek timings have little variance. That leaves ioctl(/dev/random, RNDADDENTROPY) as the only remaining entropy source. But no kernel drivers appear to use that, and few distributions have egd set up out-of-the-box. Thus, for a stock linux-rt kernel, it appears to be the case that **NOTHING POPULATES THE ENTROPY POOL**. I can readily reproduce this on a live linux-rt ARM system: after boot, /proc/sys/kernel/random/entropy_avail is 0, and stays there. This, to me, seems to be a severe problem. In particular, if the embedded RT system is responsible for generating its own RSA keys for e.g. SSH/SSL on first boot, then the lack of entropy leaves it susceptible to catastrophic factorization attacks as documented in "Ron was wrong, Whit is right", http://eprint.iacr.org/2012/064.pdf, which made the news 3 months or so ago. Do you agree with this analysis? How have other linux-rt users solved this sort of problem, besides userspace ioctl(RNDADDENTROPY) calls from an entropy gathering daemon? Would anybody (else) be interested in pursing a realtime-safe way to use interrupt timings as an entropy source? -- Richard Tollerton <richard.tollerton@xxxxxxxxx> -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
