similar to: [PATCH v2 1/1] 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

Hi Linus, Sending directly to you with the commit log changes Ted Ts'o pointed out. Not sure if Rusty's back after his travel, but this already has his s-o-b. Please pull. The following changes since commit c9d26423e56ce1ab4d786f92aebecf859d419293: Merge tag 'pm+acpi-3.17-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm (2014-08-14 18:13:46 -0600) are

Hi Linus, Sending directly to you with the commit log changes Ted Ts'o pointed out. Not sure if Rusty's back after his travel, but this already has his s-o-b. Please pull. The following changes since commit c9d26423e56ce1ab4d786f92aebecf859d419293: Merge tag 'pm+acpi-3.17-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm (2014-08-14 18:13:46 -0600) are

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

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 are certain > the quality of randomness we receive is perfectly trustworthy.

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

On (Thu) 07 Aug 2014 [12:31:11], H. Peter Anvin wrote: > 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> > > ---

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

On Thu, Jan 19, 2023 at 07:43:47PM +0100, Babis Chalios wrote: > Implement the virtio-rng feature that allows a guest driver to request > from the device to perform certain operations in the event of an > "entropy leak", such as when taking a VM snapshot or restoring a VM from > a snapshot. The guest can request one of two operations: (i) fill a > buffer with random bytes,

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

This reverts commit e052dbf554610e2104c5a7518c4d8374bed701bb. Now that we use the virtio ->scan() function to register with the hwrng core, we will not get read requests till probe is successfully finished. So revert the workaround we had in place to refuse read requests while we were not yet setup completely. Signed-off-by: Amit Shah <amit.shah at redhat.com> Conflicts:

Hey Greg, Can you add these two patches to the 3.16 queue? Thanks, On (Tue) 12 Aug 2014 [13:23:45], Amit Shah wrote: > 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.

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

On Mon, Jul 21, 2014 at 05:15:51PM +0530, Amit Shah wrote: > 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