lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 8 Aug 2014 14:37:15 +0530
From:	Amit Shah <>
To:	"H. Peter Anvin" <>
	Virtualization List <>,
	Amos Kong <>,
	Rusty Russell <>,,
	Ricardo Neri <>
Subject: Re: [PATCH 1/2] rngd: add udev rule to source from hwrng if
 virtio-rng present

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 <>
> > ---
> >  90-virtio-rng.rules | 1 +
> >  1 file changed, 1 insertion(+)
> >  create mode 100644 90-virtio-rng.rules
> > 
> > diff --git a/90-virtio-rng.rules b/90-virtio-rng.rules
> > new file mode 100644
> > index 0000000..07f2f9c
> > --- /dev/null
> > +++ b/90-virtio-rng.rules
> > @@ -0,0 +1 @@
> > +KERNEL=="hw_random", ATTR{rng_current}=="virtio*", RUN+="/sbin/rngd -r /dev/hwrng"
> > 
> I'm not sure this is really right.  rngd can receive input from a number
> of sources, and I suspect it would be better to rngd to be started much
> earlier and perhaps get sent a SIGHUP to reconfigure when a hw_random
> device appears ... not just the virtio one.

Right - yea.  Modern distros do start rngd by default (at least Fedora
and RHEL do), so this does make sense.

But as you note below, not all distros may start rngd...

> Currently rngd exits 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.

Currently the kernel can only have 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?


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists