Bug#911043: On starting (and stopping) rngd

[Neil Horman]

I read over the bug, and I have a few thoughts here

First, regarding the rng-tools version looks rather out of date.  From what
I see, the latest version in the debian archives is 5-1, which is horribly
old (circa 2004).  The latest version is 6.10, and is almost a complete
re-write, containing a useable systemd unit file, and also should work with
sysv-init.  It also contains several entropy sources, including a jitter
source entropy generator to fall back on should other sources not be
available for whatever reason.  I'd strongly suggest updating to the latest
version to avoid some of the problems described in the bug

As for the question regarding starting rngd on multiple cores, I can't
recommend that.  rngd automatically detects the number of cores and starts
threads on each for certain entropy sources, affining the cpus properly to
generate maximum entropy without disrupting the system

As for having trouble with ordering (i.e. if /dev/hwrng isn't ready when
rngd starts), I'd use udev rules to trigger on the addition of an entropy
source to just restart the rngd service, that shouldn't be too hard.  That
said though, if you use the included rngd.service, its blocked on WantedBy
multi-user.target, so on a general boot it shouldn't start until all the
hardware drivers are loaded and initalized.  If you need it earlier than
that, you can use dracut to start it in the initramfs, and shut it down on
switch-root to get early entropy from the jitter source.

Let me know if you have other questions

Best
Neil


On Tue, Nov 10, 2020 at 3:09 PM Henrique de Moraes Holschuh <hmh at debian.org>
wrote:

>
>
> On Tue, Nov 10, 2020, at 16:05, Thorsten Glaser wrote:
> > So we additionally have the case where the character device
> > exists but is not usable… oh my.
>
> This was common enough that rngd should know about it and bail out with an
> error if it doesn't gey proper random numbers from its input during
> startup. At least I vaguely recall adding that logic, including a timeout.
>
> And it won't feed the entropy pool with obvious crap no matter what,
> although you can easily fool it of you want, a typical device malfunction
> (all zeroes, patterns with too much bias, all ones...) Won't get past it's
> simplistic fitness testing (the old fips one).
>
> So you'd start it and it will bail up sometime later because the entropy
> source is unfit for use.  On systemd you should watch that and don't
> restart it aggressively or you'll waste one cpu core worth of busywork in
> the worst case.  Best case it sleeps.
>
> --
>   Henrique de Moraes Holschuh <hmh at debian.org>
>


-- 
/***************************************************
 *Neil Horman
 *nhorman at gmail.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20201111/beea7c96/attachment.html>