search for: khwrngd

On 08/08/2014 02:07 AM, Amit Shah wrote: > > >> To >> some degree the above is obsolete when we get khwrngd widely deployed, >> but that is a new-kernel-only kind of thing. > > Right - I'm wondering if any such changes as propsed here are now > obsolted already by khwrngd? > In this case, yes, khwrngd would be a better solution for current kernels. -hpa

On 08/08/2014 02:07 AM, Amit Shah wrote: > > >> To >> some degree the above is obsolete when we get khwrngd widely deployed, >> but that is a new-kernel-only kind of thing. > > Right - I'm wondering if any such changes as propsed here are now > obsolted already by khwrngd? > In this case, yes, khwrngd would be a better solution for current kernels. -hpa

...ts if there is no daemon. There are a few ways to deal with that: one is to run rngd on changes and leave a pid file around; the rngd can try to signal the old rngd or launch itself; another option would be to have a different rngd for each source. To some degree the above is obsolete when we get khwrngd widely deployed, but that is a new-kernel-only kind of thing. -hpa

...ts if there is no daemon. There are a few ways to deal with that: one is to run rngd on changes and leave a pid file around; the rngd can try to signal the old rngd or launch itself; another option would be to have a different rngd for each source. To some degree the above is obsolete when we get khwrngd widely deployed, but that is a new-kernel-only kind of thing. -hpa

On (Fri) 08 Aug 2014 [14:46:27], H. Peter Anvin wrote: > On 08/08/2014 02:07 AM, Amit Shah wrote: > > > > > >> To > >> some degree the above is obsolete when we get khwrngd widely deployed, > >> but that is a new-kernel-only kind of thing. > > > > Right - I'm wondering if any such changes as propsed here are now > > obsolted already by khwrngd? > > > > In this case, yes, khwrngd would be a better solution for current kerne...

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 p...

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 p...

...ave one rng_current, which is a pity. So in the current case, rngd only needs one instance -- and it'll always accept stuff from /dev/hwrng and it doesn't matter if the rng_current is changed as long as there's some rng there. > To > some degree the above is obsolete when we get khwrngd widely deployed, > but that is a new-kernel-only kind of thing. Right - I'm wondering if any such changes as propsed here are now obsolted already by khwrngd? Thanks, Amit

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 are certain > > t...

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 are certain > > t...

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 random...

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...

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

Il 07/08/2014 15:09, Amit Shah ha scritto: > +udevrules_DATA = 90-virtio-rng.rules If rng-tools is packaged with "make dist" you need this to be dist_udevrules_DATA = 90-virtio-rng.rules or alternatively EXTRA_DIST = 90-virtio-rng.rules udevrules_DATA = 90-virtio-rng.rules > +AC_ARG_WITH([udevrulesdir], > + AS_HELP_STRING([--with-udevrulesdir=DIR], [Directory for udev

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...

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

Il 07/08/2014 15:09, Amit Shah ha scritto: > +udevrules_DATA = 90-virtio-rng.rules If rng-tools is packaged with "make dist" you need this to be dist_udevrules_DATA = 90-virtio-rng.rules or alternatively EXTRA_DIST = 90-virtio-rng.rules udevrules_DATA = 90-virtio-rng.rules > +AC_ARG_WITH([udevrulesdir], > + AS_HELP_STRING([--with-udevrulesdir=DIR], [Directory for udev

Hello, I didn't find a mailing list for rng-tools, so CC'ing the kernel lists and the last few committers. The first patch in this series adds a udev rule to start rngd for guests that have a virtio-rng device available. The second patch attempts to add autoconf magic to install the udev rule in the system dirs. However, installing as non-root will obviously fail. Prefixes are also

Hello, I didn't find a mailing list for rng-tools, so CC'ing the kernel lists and the last few committers. The first patch in this series adds a udev rule to start rngd for guests that have a virtio-rng device available. The second patch attempts to add autoconf magic to install the udev rule in the system dirs. However, installing as non-root will obviously fail. Prefixes are also