similar to: [PULL] virtio-rng: add derating factor for use by hwrng core

The khwrngd thread is started when a hwrng device of sufficient quality is registered. The virtio-rng device is backed by the hypervisor, and we trust the hypervisor to provide real entropy. A malicious hypervisor is a scenario that's ruled out, so we are certain the quality of randomness we receive is perfectly trustworthy. Hence, we use 100% for the factor, indicating maximum confidence

The khwrngd thread is started when a hwrng device of sufficient quality is registered. The virtio-rng device is backed by the hypervisor, and we trust the hypervisor to provide real entropy. A malicious hypervisor is a scenario that's ruled out, so we are certain the quality of randomness we receive is perfectly trustworthy. Hence, we use 100% for the factor, indicating maximum confidence

On (Mon) 11 Aug 2014 [15:11:03], H. Peter Anvin wrote: > On 08/11/2014 11:49 AM, Amit Shah wrote: > > The khwrngd thread is started when a hwrng device of sufficient > > quality is registered. The virtio-rng device is backed by the > > hypervisor, and we trust the hypervisor to provide real entropy. A > > malicious hypervisor is a scenario that's ruled out, so we

On (Mon) 11 Aug 2014 [15:11:03], H. Peter Anvin wrote: > On 08/11/2014 11:49 AM, Amit Shah wrote: > > The khwrngd thread is started when a hwrng device of sufficient > > quality is registered. The virtio-rng device is backed by the > > hypervisor, and we trust the hypervisor to provide real entropy. A > > malicious hypervisor is a scenario that's ruled out, so we

The khwrngd thread is started when a hwrng device of sufficient quality is registered. The virtio-rng device is backed by the hypervisor, and we trust the hypervisor to provide real entropy. A malicious hypervisor is a scenario that's irrelevant -- such a setup is bound to cause all sorts of badness, and a compromised hwrng is not the biggest threat. Given this, we are certain the quality

The khwrngd thread is started when a hwrng device of sufficient quality is registered. The virtio-rng device is backed by the hypervisor, and we trust the hypervisor to provide real entropy. A malicious hypervisor is a scenario that's irrelevant -- such a setup is bound to cause all sorts of badness, and a compromised hwrng is not the biggest threat. Given this, we are certain the quality

On 08/07/2014 06:08 AM, Amit Shah wrote: > On KVM guests where the virtio-rng device is available, and set as the > current rng, this udev rule will start rngd which will feed in the > host-provided entropy to /dev/random. > > Signed-off-by: Amit Shah <amit.shah at redhat.com> > --- > 90-virtio-rng.rules | 1 + > 1 file changed, 1 insertion(+) > create mode

On 08/07/2014 06:08 AM, Amit Shah wrote: > On KVM guests where the virtio-rng device is available, and set as the > current rng, this udev rule will start rngd which will feed in the > host-provided entropy to /dev/random. > > Signed-off-by: Amit Shah <amit.shah at redhat.com> > --- > 90-virtio-rng.rules | 1 + > 1 file changed, 1 insertion(+) > create mode

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

v3: - Kees Cook pointed out a weird side-effect: devices which have ->init() registered get their randomness added to the system each time they're switched in, but devices that don't have the init callback don't contribute to system randomness more than once. The weirdness is resolved here by using the randomness each time hwrng_init() is attempted, irrespective of

v3: - Kees Cook pointed out a weird side-effect: devices which have ->init() registered get their randomness added to the system each time they're switched in, but devices that don't have the init callback don't contribute to system randomness more than once. The weirdness is resolved here by using the randomness each time hwrng_init() is attempted, irrespective of

v2: - update patch 3 to store the hwrng_register_done bool per-device rather than global - add patch 2 that re-arranges struct elems for better packing. Hi, This series enables virtio-rng to service the early randomness requests made by the hwrng core (patch 3), with Herbert's idea of using the scan routine. Patch 4 reverts the previous restriction, which no longer applies, to not send

v2: - update patch 3 to store the hwrng_register_done bool per-device rather than global - add patch 2 that re-arranges struct elems for better packing. Hi, This series enables virtio-rng to service the early randomness requests made by the hwrng core (patch 3), with Herbert's idea of using the scan routine. Patch 4 reverts the previous restriction, which no longer applies, to not send

Current hwrng core supports to register multiple hwrng devices, and there is only one device really works in the same time. QEMU alsu supports to have multiple virtio-rng backends. This patch changes virtio-rng driver to support multiple virtio-rng devices. ]# cat /sys/class/misc/hw_random/rng_available virtio_rng.0 virtio_rng.1 ]# cat /sys/class/misc/hw_random/rng_current virtio_rng.0 ]# echo

Current hwrng core supports to register multiple hwrng devices, and there is only one device really works in the same time. QEMU alsu supports to have multiple virtio-rng backends. This patch changes virtio-rng driver to support multiple virtio-rng devices. ]# cat /sys/class/misc/hw_random/rng_available virtio_rng.0 virtio_rng.1 ]# cat /sys/class/misc/hw_random/rng_current virtio_rng.0 ]# echo

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

Instead of calling hwrng_register() in the probe routing, call it in the scan routine. This ensures that when hwrng_register() is successful, and it requests a few random bytes to seed the kernel's pool at init, we're ready to service that request. This will also enable us to remove the workaround added previously to check whether probe was completed, and only then ask for data from the

Instead of calling hwrng_register() in the probe routing, call it in the scan routine. This ensures that when hwrng_register() is successful, and it requests a few random bytes to seed the kernel's pool at init, we're ready to service that request. This will also enable us to remove the workaround added previously to check whether probe was completed, and only then ask for data from the