search for: lakedaemon

...is made. This > causes the host to not acknowledge any requests we put in the virtqueue, > and the insmod or kernel boot process just waits for data to arrive from > the host, which never happens. > > CC: Kees Cook <keescook at chromium.org> > CC: Jason Cooper <jason at lakedaemon.net> > CC: Herbert Xu <herbert at gondor.apana.org.au> > CC: <stable at vger.kernel.org> # For v3.15+ > Signed-off-by: Amit Shah <amit.shah at redhat.com> > --- > drivers/char/hw_random/core.c | 6 ++++++ > drivers/char/hw_random/virtio-rng.c | 10 ++++...

...is made. This > causes the host to not acknowledge any requests we put in the virtqueue, > and the insmod or kernel boot process just waits for data to arrive from > the host, which never happens. > > CC: Kees Cook <keescook at chromium.org> > CC: Jason Cooper <jason at lakedaemon.net> > CC: Herbert Xu <herbert at gondor.apana.org.au> > CC: <stable at vger.kernel.org> # For v3.15+ > Signed-off-by: Amit Shah <amit.shah at redhat.com> > --- > drivers/char/hw_random/core.c | 6 ++++++ > drivers/char/hw_random/virtio-rng.c | 10 ++++...

...cess just > > sits there doing nothing. > > > > [ jac: Modify the API to allow drivers to disable reading at probe, new > > patch, copied Amit's commit message. ] > > > > CC: Kees Cook <keescook at chromium.org> > > CC: Jason Cooper <jason at lakedaemon.net> > > CC: Herbert Xu <herbert at gondor.apana.org.au> > > CC: <stable at vger.kernel.org> # v3.15+ > > Signed-off-by: Amit Shah <amit.shah at redhat.com> > > Signed-off-by: Jason Cooper <jason at lakedaemon.net> > > --- > > drivers/...

...cess just > > sits there doing nothing. > > > > [ jac: Modify the API to allow drivers to disable reading at probe, new > > patch, copied Amit's commit message. ] > > > > CC: Kees Cook <keescook at chromium.org> > > CC: Jason Cooper <jason at lakedaemon.net> > > CC: Herbert Xu <herbert at gondor.apana.org.au> > > CC: <stable at vger.kernel.org> # v3.15+ > > Signed-off-by: Amit Shah <amit.shah at redhat.com> > > Signed-off-by: Jason Cooper <jason at lakedaemon.net> > > --- > > drivers/...

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

...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. > > CC: Kees Cook <keescook at chromium.org> > CC: Jason Cooper <jason at lakedaemon.net> > CC: Herbert Xu <herbert at gondor.apana.org.au> > CC: <stable at vger.kernel.org> # For v3.15+ > Signed-off-by: Amit Shah <amit.shah at redhat.com> > --- > drivers/char/hw_random/core.c | 31 +++++++++++++++++++++++++------ > 1 file changed, 25 inserti...

...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. > > CC: Kees Cook <keescook at chromium.org> > CC: Jason Cooper <jason at lakedaemon.net> > CC: Herbert Xu <herbert at gondor.apana.org.au> > CC: <stable at vger.kernel.org> # For v3.15+ > Signed-off-by: Amit Shah <amit.shah at redhat.com> > --- > drivers/char/hw_random/core.c | 31 +++++++++++++++++++++++++------ > 1 file changed, 25 inserti...

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

...res all communication from the guest, and the guest insmod or boot process just sits there doing nothing. [ jac: Modify the API to allow drivers to disable reading at probe, new patch, copied Amit's commit message. ] CC: Kees Cook <keescook at chromium.org> CC: Jason Cooper <jason at lakedaemon.net> CC: Herbert Xu <herbert at gondor.apana.org.au> CC: <stable at vger.kernel.org> # v3.15+ Signed-off-by: Amit Shah <amit.shah at redhat.com> Signed-off-by: Jason Cooper <jason at lakedaemon.net> --- drivers/char/hw_random/core.c | 8 +++++--- include/linux/hw_random....

On Wed, Jul 2, 2014 at 6:41 AM, Jason Cooper <jason at lakedaemon.net> wrote: > On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote: >> Hi Jason, >> >> On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: >> > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" >> > added a call to 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

Hello, This series introduces a way to allow devices to contribute to initial system randomness after a certain delay. Specifically, the virtio-rng device can contribute initial randomness only after a successful probe(). A delayed workqueue item is queued in the system queue to fetch this randomness if the device indicates it's capable of contributing only after a delay, via the new

Hello, This series introduces a way to allow devices to contribute to initial system randomness after a certain delay. Specifically, the virtio-rng device can contribute initial randomness only after a successful probe(). A delayed workqueue item is queued in the system queue to fetch this randomness if the device indicates it's capable of contributing only after a delay, via the new

...re doing nothing. > > 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 isn't made. > > CC: Kees Cook <keescook at chromium.org> > CC: Jason Cooper <jason at lakedaemon.net> > CC: Herbert Xu <herbert at gondor.apana.org.au> > CC: <stable at vger.kernel.org> # For 3.15 only # v3.15+ should be fine here. > Signed-off-by: Amit Shah <amit.shah at redhat.com> > --- > drivers/char/hw_random/core.c | 8 +++++--- > 1 file changed,...

...re doing nothing. > > 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 isn't made. > > CC: Kees Cook <keescook at chromium.org> > CC: Jason Cooper <jason at lakedaemon.net> > CC: Herbert Xu <herbert at gondor.apana.org.au> > CC: <stable at vger.kernel.org> # For 3.15 only # v3.15+ should be fine here. > Signed-off-by: Amit Shah <amit.shah at redhat.com> > --- > drivers/char/hw_random/core.c | 8 +++++--- > 1 file changed,...

....3_p2) Product: Portable OpenSSH Version: 4.3p2 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: bitbucket at mindrot.org ReportedBy: opensshbugs at lakedaemon.net I've been testing openssh-4.3_p2 on my gentoo systems for remote layer2 access to my home network. It works well (haven't tested latency sensitive traffic, eg voip, yet), but only when logging in as root. I've created a first draft patch against 4.3_p2 that compiles cleanly on...

http://bugzilla.mindrot.org/show_bug.cgi?id=1223 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|tun/tap capability only |tun/tap capability requires |works with root login |root privileges