search for: d9e7972619

On Sat, Jul 05, 2014 at 11:04:53AM +0530, Amit Shah wrote: > The hwrng core asks for random data in the hwrng_register() call itself > from commit d9e7972619. This doesn't play well with virtio -- the > DRIVER_OK bit is only set by virtio core on a successful probe, and > we're not yet out of our probe routine when this call is made. This > causes the host to not acknowledge any requests we put in the virtqueue, > and the insmod or...

On Sat, Jul 05, 2014 at 11:04:53AM +0530, Amit Shah wrote: > The hwrng core asks for random data in the hwrng_register() call itself > from commit d9e7972619. This doesn't play well with virtio -- the > DRIVER_OK bit is only set by virtio core on a successful probe, and > we're not yet out of our probe routine when this call is made. This > causes the host to not acknowledge any requests we put in the virtqueue, > and the insmod or...

On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: > The hwrng core asks for random data in the hwrng_register() call itself > from commit d9e7972619. This doesn't play well with virtio -- the > DRIVER_OK bit is only set by virtio core on a successful probe, and > we're not yet out of our probe routine when this call is made. This > causes the host to not acknowledge any requests we put in the virtqueue, > and the insmod or...

On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: > The hwrng core asks for random data in the hwrng_register() call itself > from commit d9e7972619. This doesn't play well with virtio -- the > DRIVER_OK bit is only set by virtio core on a successful probe, and > we're not yet out of our probe routine when this call is made. This > causes the host to not acknowledge any requests we put in the virtqueue, > and the insmod or...

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

...ah <amit.shah at redhat.com> wrote: > On (Sun) 06 Jul 2014 [21:38:36], Kees Cook wrote: >> On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: >> > The hwrng core asks for random data in the hwrng_register() call itself >> > from commit d9e7972619. This doesn't play well with virtio -- the >> > DRIVER_OK bit is only set by virtio core on a successful probe, and >> > we're not yet out of our probe routine when this call is made. This >> > causes the host to not acknowledge any requests we put in the virtqu...

...ah <amit.shah at redhat.com> wrote: > On (Sun) 06 Jul 2014 [21:38:36], Kees Cook wrote: >> On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: >> > The hwrng core asks for random data in the hwrng_register() call itself >> > from commit d9e7972619. This doesn't play well with virtio -- the >> > DRIVER_OK bit is only set by virtio core on a successful probe, and >> > we're not yet out of our probe routine when this call is made. This >> > causes the host to not acknowledge any requests we put in the virtqu...

The hwrng core asks for random data in the hwrng_register() call itself from commit d9e7972619. This doesn't play well with virtio -- the DRIVER_OK bit is only set by virtio core on a successful probe, and we're not yet out of our probe routine when this call is made. This causes the host to not acknowledge any requests we put in the virtqueue, and the insmod or kernel boot process...

...: > > > On (Sun) 06 Jul 2014 [21:38:36], Kees Cook wrote: > > >> On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: > > >> > The hwrng core asks for random data in the hwrng_register() call itself > > >> > from commit d9e7972619. This doesn't play well with virtio -- the > > >> > DRIVER_OK bit is only set by virtio core on a successful probe, and > > >> > we're not yet out of our probe routine when this call is made. This > > >> > causes the host to not acknowledge any...

...: > > > On (Sun) 06 Jul 2014 [21:38:36], Kees Cook wrote: > > >> On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: > > >> > The hwrng core asks for random data in the hwrng_register() call itself > > >> > from commit d9e7972619. This doesn't play well with virtio -- the > > >> > DRIVER_OK bit is only set by virtio core on a successful probe, and > > >> > we're not yet out of our probe routine when this call is made. This > > >> > causes the host to not acknowledge any...

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

On (Sun) 06 Jul 2014 [21:38:36], Kees Cook wrote: > On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: > > The hwrng core asks for random data in the hwrng_register() call itself > > from commit d9e7972619. This doesn't play well with virtio -- the > > DRIVER_OK bit is only set by virtio core on a successful probe, and > > we're not yet out of our probe routine when this call is made. This > > causes the host to not acknowledge any requests we put in the virtqueue, > &g...

...redhat.com> wrote: > > On (Sun) 06 Jul 2014 [21:38:36], Kees Cook wrote: > >> On Fri, Jul 4, 2014 at 10:34 PM, Amit Shah <amit.shah at redhat.com> wrote: > >> > The hwrng core asks for random data in the hwrng_register() call itself > >> > from commit d9e7972619. This doesn't play well with virtio -- the > >> > DRIVER_OK bit is only set by virtio core on a successful probe, and > >> > we're not yet out of our probe routine when this call is made. This > >> > causes the host to not acknowledge any requests we pu...

On Wed, Jul 09, 2014 at 12:18:36PM -0400, Jason Cooper wrote: > On Sat, Jul 05, 2014 at 11:04:53AM +0530, Amit Shah wrote: > > The hwrng core asks for random data in the hwrng_register() call itself > > from commit d9e7972619. This doesn't play well with virtio -- the > > DRIVER_OK bit is only set by virtio core on a successful probe, and > > we're not yet out of our probe routine when this call is made. This > > causes the host to not acknowledge any requests we put in the virtqueue, > &g...

...@@ -69,13 +68,6 @@ static int virtio_read(struct hwrng *rng, void *buf, size_t size, bool wait) int ret; struct virtrng_info *vi = (struct virtrng_info *)rng->priv; - /* - * Don't ask host for data till we're setup. This call can - * happen during hwrng_register(), after commit d9e7972619. - */ - if (unlikely(!probe_done)) - return 0; - if (!vi->busy) { vi->busy = true; init_completion(&vi->have_data); @@ -137,7 +129,6 @@ static int probe_common(struct virtio_device *vdev) return err; } - probe_done = true; return 0; } -- 1.9.3

...recv_done(struct virtqueue *vq) { struct virtrng_info *vi = vq->vdev->priv; @@ -73,7 +72,7 @@ static int virtio_read(struct hwrng *rng, void *buf, size_t size, bool wait) * Don't ask host for data till we're setup. This call can * happen during hwrng_register(), after commit d9e7972619. */ - if (unlikely(!probe_done)) + if (unlikely(!vi->probe_done)) return 0; if (!vi->busy) { @@ -146,7 +145,7 @@ static int probe_common(struct virtio_device *vdev) return err; } - probe_done = true; + vi->probe_done = true; return 0; } -- 1.9.3

...recv_done(struct virtqueue *vq) { struct virtrng_info *vi = vq->vdev->priv; @@ -73,7 +72,7 @@ static int virtio_read(struct hwrng *rng, void *buf, size_t size, bool wait) * Don't ask host for data till we're setup. This call can * happen during hwrng_register(), after commit d9e7972619. */ - if (unlikely(!probe_done)) + if (unlikely(!vi->probe_done)) return 0; if (!vi->busy) { @@ -146,7 +145,7 @@ static int probe_common(struct virtio_device *vdev) return err; } - probe_done = true; + vi->probe_done = true; return 0; } -- 1.9.3

...rtqueue *vq) { struct virtrng_info *vi = vq->vdev->priv; @@ -73,7 +72,7 @@ static int virtio_read(struct hwrng *rng, void *buf, -size_t size, bool wait) * Don't ask host for data till we're setup. This call can * happen during hwrng_register(), after commit d9e7972619. */ - if (unlikely(!probe_done)) + if (unlikely(!vi->probe_done)) return 0; if (!vi->busy) { @@ -146,7 +145,7 @@ static int probe_common(struct virtio_device *vdev) return err; } - probe_done = true; + vi-&gt...