On Tue, Jun 06, 2017 at 07:48:03PM +0200, Jason A. Donenfeld wrote: > This protocol uses lots of complex cryptography that relies on securely > generated random numbers. Thus, it's important that the RNG is actually > seeded before use. Fortuantely, it appears we're always operating in > process context (there are many GFP_KERNEL allocations and other > sleeping operations), and so we can simply demand that the RNG is seeded > before we use it. > > We take two strategies in this commit. The first is for the library code > that's called from other modules like hci or mgmt: here we just change > the call to get_random_bytes_wait, and return the result of the wait to > the caller, along with the other error codes of those functions like > usual. Then there's the SMP protocol handler itself, which makes many > many many calls to get_random_bytes during different phases. For this, > rather than have to change all the calls to get_random_bytes_wait and > propagate the error result, it's actually enough to just put a single > call to wait_for_random_bytes() at the beginning of the handler, to > ensure that all the subsequent invocations are safe, without having to > actually change them. Likewise, for the random address changing > function, we'd rather know early on in the function whether the RNG > initialization has been interrupted, rather than later, so we call > wait_for_random_bytes() at the top, so that later on the call to > get_random_bytes() is acceptable. Do we need to do all of this? Bluetooth folks, is it fair to assume that hci_power_on() has to be called before any bluetooth functions can be done? If so, adding a wait_for_random_bytes() in hci_power_on() might be all that is necessary. - Ted
