Am Samstag, 23. April 2016, 22:03:23 schrieb Theodore Ts'o: Hi Theodore, > On Fri, Apr 22, 2016 at 06:27:48PM -0400, Sandy Harris wrote: > > I really like Stephan's idea of simplifying the interrupt handling, > > replacing the multiple entropy-gathering calls in the current driver > > with one routine called for all interrupts. See section 1.2 of his > > doc. That seems to me a much cleaner design, easier both to analyse > > and to optimise as a fast interrupt handler. > > The current /dev/random driver *already* has a fast interrupt handler, > and it was designed specifically to be very fast and very lightweight. I agree here. The only challenge with the current implementation is the time the fast_pool is to be mixed into an entropy pool. This requires a lock and quite some code afterwards. I tried hard to avoid such additional code paths in my LRNG. > > It's a fair argument that getting rid of add_disk_randomness() > probably makes sense. However, add_input_randomness() is useful > because it is also mixing in the HID input (e.g., the characters typed > or the mouse movements), and that is extremely valuable and I wouldn't > want to get rid of this. In addition to the request to remove the Jitter RNG, I also have added support for the add_input_randomness function into the LRNG. I will release the code shortly. When dropping the add_disk_randomness function in the legacy /dev/random, I would assume that without changes to add_input_randomness and add_interrupt_randomness, we become even more entropy-starved. The entropy heuristic for add_interrupt_randomness cannot be re-valued to a higher level because the time stamp for the HID is still processed as part of add_input_randomness -- i.e. there is still a high correlation between the processed values of add_interrupt_randomness and add_input_randomness. Thus, all events received for block devices are now valued at most with 1/64th bits of entropy when dropping add_disk_randomness (which partially used to be valued higher). Thus, I tried with the LRNG to implement add_input_randomness as follows: it only picks up the key numbers or mouse coordinates but no timestamp. Those are mixed into the entropy pool without crediting any entropy. The reason for not crediting any entropy is that an unprivileged user knows the keys he pressed. Thus the user is an observer and a potential attacker that has full knowledge of an input value into the entropy pool. As each HID event is also processed as an interrupt, the interrupt processing of the LRNG will credit close to one bit of entropy for each HID event due to the interrupt timing nonetheless. > > > In the current driver -- and I think in Stephan's, though I have not > > looked at his code in any detail, only his paper -- heavy use of > > /dev/urandom or the kernel get_random_bytes() call can deplete the > > entropy available to /dev/random. That can be a serious problem in > > some circumstances, but I think I have a fix. > > So /dev/urandom, or preferentially, the getrandom(2) system call, > which will block until the entropy pool is initialized, is designed to > be a CRNG. We use the entropy accounting for the urandom pool as a > hueristic to know how aggressively to pull the random pool and/or > things like hwrandom (since pulling entropy from the TPM does have > costs, for example power utilization for battery-powered devices). > > We already throttle back how much we pull from the input pool if it is > being used heavily, specifically to avoid this problem. Agreed. And this exact behavior I tried to replicate into the LRNG (the blocking of getrandom and the emergency entropy for /dev/random). The processing leaves an "emergency" level of entropy in the pool that is inaccessible to /dev/urandom. Furthermore, when a call to /dev/random drains the entropy pool completely, the emergency entropy is replenished first before /dev/urandom gets new entropy from the entropy pool. Ciao Stephan -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
