Hi Felipe,
>I'll comment only on the init stuff, as I have no idea what rng-tools does.
that’s fair. Thanks anyway.
>It is difficult to comment on this without more details. Maybe it would be
>possible to configure socket activation here? If not, the best option is
AIUI socket activation is used when something actively communicates
with the service to be started (please correct me if I’m wrong).
Here, the part of “what rngd is” comes into play: it’s sitting in
the background, shoving bytes from an entropy source (usually via
/dev/hwrng but in this case remote) to the kernel. It’s not actively
addressed by any application.
But given what you wrote below, in the “remote source” case, I can
handle starting/stopping it manually, especially with the factored-out
script.
>> • according to some people, the /dev/hwrng device sometimes
>> was not online when rngd was started, so we need a way to
>> wait for that (the submitter suggested a systemd unit with
>> multiple delayed restart attempts, which is… too crude)
>>
>> • some people use a HWRNG that only comes online after some
>> activity (e.g. plugging in a USB device, or powering up
>> the WLAN chip), and so want it started from udev (but how
>> to stop in that case?)
>
>These two problems are actually the same (device being asynchronously
>ready), and starting from udev is the correct solution. However, you don't
>directly start it from udev, rather you tag with
>`SYSTEMD_WANTS=rng-tools.service`, and then it is just as if it was started
>at boot.
OK, so (to see if I understood that correctly), for the WLAN
chip user use case:
• I write a systemd unit that starts the service normally
• the user disables that service by default (using the
systemd equivalent for update-rc.d)
• the user then places SYSTEMD_WANTS=rng-tools-debian.service
into their udev rule
This much I (think I) understand. What I don’t get is the first
case. I admit I barely know anything about udev, and I have no
idea how I’d delay starting until /dev/hwrng “comes online”, or
how this could be measured for /dev/hwrng in the first place,
especially in the generic case.
Incidentally, the init script only starts rngd if “a” device
exists (testing for the chardev existence) and, unless the user
manually specifies a device, probes these in this order:
/dev/{,misc/}{hwrng,hw_random,hwrandom,intel_rng,i810_rng}
That being said, someone mentioned in the bugreport that a
modern system would only have /dev/hwrng out of these mentioned
in almost all cases.
(There’s also the case of not having it, of course, which
is probably a majority. In this case, not autostarting the
rngd dæmon and only issuing an informative message, not an
error, would probably be best.)
Right now, rng-tools-debian does not have any systemd integration,
so we’re looking at creating something here.
The init script currently does the following:
• if HRNGSELECT is set in /etc/defaults/rng-tools-debian
its contents is written to a file in sysfs that tells
the kernel which HWRNG to use if there are multiple or
if the detected one is not enabled by default (e.g. TPM)
• if HRNGDEVICE is not set in the defaults file, the
aforementioned devices are tested for existence, and
the first found one is put into that variable
• “rngd -r $HRNGDEVICE $RNGDOPTIONS” is started (there
is already a -f option which can be used to keep it
in the foreground for systemd), RNGDOPTIONS being the
third option from the defaults file
I’m not sure we need to replicate all this for the systemd
case, especially if this is done via udev, but, since I do
not use systemd myself, I don’t have all necessary under‐
standing to come up with “the correct” solution.
[ factor out a start script ]
>This is a good idea regardless of systemd units. Files in /etc/init.d are
>conffiles, and thus any logic is best shipped elsewhere. Due to conffile
Indeed. (Although, as I wrote above, I’m not sure we even
need that logic elsewhere.)
>> and document that this is the script to start from
>> one’s udev rules somewhere?
>
>As mentioned above, you can instruct udev to start a systemd service
>directly.
OK, but I’m a bit fuzzy about where to put things for the
“trivial standard” case, that is, /dev/hwrng is set up by
default and can be used as-is.
Incidentally, I don’t find a system where this is the case
among these I (co‑)manage. With “modprobe virtio-rng”, I
was able to get it on a VM though. Perhaps relevant info:
$ ls -ld /dev/hw*; grep . /sys/devices/virtual/misc/hw_random/*
crw------- 1 root root 10, 183 Nov 10 17:04 /dev/hwrng
/sys/devices/virtual/misc/hw_random/dev:10:183
grep: /sys/devices/virtual/misc/hw_random/power: Is a directory
/sys/devices/virtual/misc/hw_random/rng_current:none
/sys/devices/virtual/misc/hw_random/rng_selected:0
grep: /sys/devices/virtual/misc/hw_random/subsystem: Is a directory
/sys/devices/virtual/misc/hw_random/uevent:MAJOR=10
/sys/devices/virtual/misc/hw_random/uevent:MINOR=183
/sys/devices/virtual/misc/hw_random/uevent:DEVNAME=hwrng
(I use rngd on my machines with the stunnel wrapper to get entropy
from central systems with ekeyd.)
>I;m not clear on whether you want this only for systemd systems
>or everyone else too. In the latter case, you could probably add a RUN
>script that starts the init script when not running under systemd.
To be honest, I’m not clear on this either. I think we really
need input from rngd upstream on quite some points here, as to
how this is best used.
That being said, I have exactly *one* report from someone with
this, and they use systemd. Perhaps the faster and parallel
startup has something to do with that. (I have another report
where I *think* someone either doesn’t load the kernel module
or loads it too late, but it is currently moreinfo, also using
systemd.)
>> I also need information on how I can delay the rngd start
>> to occur after udev has set up /dev/hwrng but not if there
>> is nothing to set up for it, that is, no source, or already
>> set up earlier / built into the kernel.
>
>Starting via udev should be the best way then.
OK. If we figure out the how. So, no “normally started”
service? (I assume just drop the WantedBy=multi-user.target ?)
>Please don't do this. Init scripts killing random processes is not a good
>idea (what if I ran stop while the system is up?).
Right. I specifically changed the rc script in FreeWRT
to use autostart and autostop instead of start and stop
for system startup/shutdown so it could distinguish
between those and manual actions but LSB lacks that,
unfortunately. I’ll manage.
>> There’s also the question whether/how to stop the instances
>> started by udev.
>
>At least under systemd, via SYSTEMD_WANTS they get treated as a service
>just like any other. Thus, the ExecStop will be run for the service at
>shutdown at the appropriate time (according to dependencies).
OK, good.
>> The question of whether to allow multiple rngd processes
>> (see above) also comes into play.
Question for upstream.
Thanks,
//mirabilos
--
18:47⎜<mirabilos:#!/bin/mksh> well channels… you see, I see everything in the
same window anyway 18:48⎜<xpt:#!/bin/mksh> i know, you have some kind of
telnet with automatic pong 18:48⎜<mirabilos:#!/bin/mksh> haha, yes :D
18:49⎜<mirabilos:#!/bin/mksh> though that's more tinyirc – sirc is more comfy
