search for: hwrngs

...read > from them. > > This commit makes the call to rng_get_data() depend on no init fn > pointer being registered by the device. If an init function is > registered, this call is made after device init. Thanks, this seems pretty reasonable. One side-effect is that cycling between hwrngs via sysfs (when they have init functions) will cause them to add more entropy. I don't think this is a problem, but it is kind of a weird side-effect. Reviewed-by: Kees Cook <keescook at chromium.org> -Kees > > CC: Kees Cook <keescook at chromium.org> > CC: Jason Cooper...

...read > from them. > > This commit makes the call to rng_get_data() depend on no init fn > pointer being registered by the device. If an init function is > registered, this call is made after device init. Thanks, this seems pretty reasonable. One side-effect is that cycling between hwrngs via sysfs (when they have init functions) will cause them to add more entropy. I don't think this is a problem, but it is kind of a weird side-effect. Reviewed-by: Kees Cook <keescook at chromium.org> -Kees > > CC: Kees Cook <keescook at chromium.org> > CC: Jason Cooper...

...; > + if (!(rng->flags & HWRNG_NO_READ_AT_PROBE)) { > > + bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1); > > + if (bytes_read > 0) > > + add_device_randomness(bytes, bytes_read); > > + } > > But this has the inverse problem: if there are two hwrngs in the > system, one will be initialized and probed. The other will not be > initialized, but still be probed. That's a problem outside the scope of this patch. You're basically saying the ->init() should be called unconditionally for each hwrng. If that's what driver autho...

...; > + if (!(rng->flags & HWRNG_NO_READ_AT_PROBE)) { > > + bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1); > > + if (bytes_read > 0) > > + add_device_randomness(bytes, bytes_read); > > + } > > But this has the inverse problem: if there are two hwrngs in the > system, one will be initialized and probed. The other will not be > initialized, but still be probed. That's a problem outside the scope of this patch. You're basically saying the ->init() should be called unconditionally for each hwrng. If that's what driver autho...

...the call to rng_get_data() depend on no init fn > > > pointer being registered by the device. If an init function is > > > registered, this call is made after device init. > > > > Thanks, this seems pretty reasonable. One side-effect is that cycling > > between hwrngs via sysfs (when they have init functions) will cause > > them to add more entropy. I don't think this is a problem, but it is > > kind of a weird side-effect. > > Yes, agreed. Having a per-device bool that indicates whether the > initial randomness is obtained is quite a...

...the call to rng_get_data() depend on no init fn > > > pointer being registered by the device. If an init function is > > > registered, this call is made after device init. > > > > Thanks, this seems pretty reasonable. One side-effect is that cycling > > between hwrngs via sysfs (when they have init functions) will cause > > them to add more entropy. I don't think this is a problem, but it is > > kind of a weird side-effect. > > Yes, agreed. Having a per-device bool that indicates whether the > initial randomness is obtained is quite a...

...but it doesn't fit the problem I'm trying to solve. Basically, average systems, not trying to be Ft Knox-secure, but needing to generate long-term keys at first boot. These systems won't have an hwrng installed, but should use one if available. eg virtio-rng, or any of the on-die SoC hwrngs. > There's also the option to use a delayed workqueue item, that will > succeed if probe has finished. This method doesn't have userspace > dependencies. Hmm, I like that idea better. No ABI change to maintain, no userspace changes... You obviously know virtio-rng better than...

...but it doesn't fit the problem I'm trying to solve. Basically, average systems, not trying to be Ft Knox-secure, but needing to generate long-term keys at first boot. These systems won't have an hwrng installed, but should use one if available. eg virtio-rng, or any of the on-die SoC hwrngs. > There's also the option to use a delayed workqueue item, that will > succeed if probe has finished. This method doesn't have userspace > dependencies. Hmm, I like that idea better. No ABI change to maintain, no userspace changes... You obviously know virtio-rng better than...

..._randomness(bytes, bytes_read); > + if (!(rng->flags & HWRNG_NO_READ_AT_PROBE)) { > + bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1); > + if (bytes_read > 0) > + add_device_randomness(bytes, bytes_read); > + } But this has the inverse problem: if there are two hwrngs in the system, one will be initialized and probed. The other will not be initialized, but still be probed. My version was more conservative while this one keeps the bug from the current kernels. Amit

...; > This commit makes the call to rng_get_data() depend on no init fn > > pointer being registered by the device. If an init function is > > registered, this call is made after device init. > > Thanks, this seems pretty reasonable. One side-effect is that cycling > between hwrngs via sysfs (when they have init functions) will cause > them to add more entropy. I don't think this is a problem, but it is > kind of a weird side-effect. Yes, agreed. Having a per-device bool that indicates whether the initial randomness is obtained is quite a heavy solution for this s...

...{ >> > + bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1); >> > + if (bytes_read > 0) >> > + add_device_randomness(bytes, bytes_read); >> > + } >> >> But this has the inverse problem: if there are two hwrngs in the >> system, one will be initialized and probed. The other will not be >> initialized, but still be probed. > > That's a problem outside the scope of this patch. You're basically > saying the ->init() should be called unconditionally for each hwrng. If > t...

...amp; HWRNG_NO_READ_AT_PROBE)) { > > > + bytes_read = rng_get_data(rng, bytes, sizeof(bytes), 1); > > > + if (bytes_read > 0) > > > + add_device_randomness(bytes, bytes_read); > > > + } > > > > But this has the inverse problem: if there are two hwrngs in the > > system, one will be initialized and probed. The other will not be > > initialized, but still be probed. > > That's a problem outside the scope of this patch. No, not really. What will happen in a 2 hwrng scenario is that the first one that calls hwrng_register()...

Commit d9e7972619334 "hwrng: add randomness to system from rng sources" added a call to rng_get_data() from the hwrng_register() function. However, some rng devices need initialization before data can be read from them. Also, the virtio-rng device does not behave properly when this call is made in its probe() routine - the virtio core sets the DRIVER_OK status bit only on a successful

Amit, Kees, On Wed, Jul 09, 2014 at 06:55:24PM +0530, Amit Shah wrote: > On (Wed) 09 Jul 2014 [09:17:37], Jason Cooper wrote: > > On Wed, Jul 09, 2014 at 06:38:22PM +0530, Amit Shah wrote: > > > On (Wed) 09 Jul 2014 [07:53:17], Jason Cooper wrote: > > > > On Sat, Jul 05, 2014 at 11:04:52AM +0530, Amit Shah wrote: > > > > > Commit d9e7972619334

Amit, Kees, On Wed, Jul 09, 2014 at 06:55:24PM +0530, Amit Shah wrote: > On (Wed) 09 Jul 2014 [09:17:37], Jason Cooper wrote: > > On Wed, Jul 09, 2014 at 06:38:22PM +0530, Amit Shah wrote: > > > On (Wed) 09 Jul 2014 [07:53:17], Jason Cooper wrote: > > > > On Sat, Jul 05, 2014 at 11:04:52AM +0530, Amit Shah wrote: > > > > > Commit d9e7972619334

Hi, When booting a recent kernel under KVM with the virtio-rng device enabled, the boot process was stalling. Bisect pointed to a commit made during the 3.15 window to fetch randomness from newly-registered devices in the hwrng core. The details are in the patches. I considered a couple of approaches, but basing on the init() function being registered, as is done in patch 1 here, seems like

Hi, When booting a recent kernel under KVM with the virtio-rng device enabled, the boot process was stalling. Bisect pointed to a commit made during the 3.15 window to fetch randomness from newly-registered devices in the hwrng core. The details are in the patches. I considered a couple of approaches, but basing on the init() function being registered, as is done in patch 1 here, seems like

v2: - this now separates both the patches; the virtio-rng fix is self-contained - re-work hwrng core to fetch randomness at device init time if ->init() is registered by the device, instead of not calling it at all. - virtio-rng: introduce a probe_done bool to ensure we don't ask host for data before successful probe Hi, When booting a recent kernel under KVM with the virtio-rng

v2: - this now separates both the patches; the virtio-rng fix is self-contained - re-work hwrng core to fetch randomness at device init time if ->init() is registered by the device, instead of not calling it at all. - virtio-rng: introduce a probe_done bool to ensure we don't ask host for data before successful probe Hi, When booting a recent kernel under KVM with the virtio-rng