Messages in this thread | | | Date | Thu, 12 Sep 2013 17:07:17 -0400 | From | Jörn Engel <> | Subject | Re: [PATCH] /dev/random: Insufficient of entropy on many architectures |
| |
On Tue, 10 September 2013 20:50:47 -0400, Theodore Ts'o wrote: > > Yep. The worse case would probably a serial port running at 230400 > bps. Even with a 16550A UART with the 16-byte FIFO, we're talking > about close to 2,000 interrupts per second. A 16450 running at 115200 > bps would give us 11,520 interrupts per second....
I happen to have a real-world system with >100k interrupts per second and - surprise - add_interrupt_randomness() showed up prominently in the profiles. I was also told twice to just remove that call. I resisted both times and have done far more work to reduce overhead while still collecting entropy. Some others would have caved in.
My bottom line: we have to make add_interrupt_randomness() cheaper or else it will get removed in custom kernels. Quite likely it already has been removed in a number of places.
One option is to add the "input_pool.entropy_count > trickle_thresh" condition that all other entropy sources currently have. But instead I would rather rename fast_mix() to not_too_fast_mix() and implement a real fast_mix(). Essentially just xor the collected numbers into a pool and schedule something to shuffle the bits at a later point.
The point is to make collection of randomness as cheap as possible. The cheaper it is to collect, the more of it we will collect. And collecting lots of bad randomness really cheaply may be a better tradeoff than collecting a bit of good randomness with medium cost. Hashing will ensure that any real randomness will overcome all predictable data we may have collected alongside.
Jörn
-- Optimizations always bust things, because all optimizations are, in the long haul, a form of cheating, and cheaters eventually get caught. -- Larry Wall -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |