TrueRNG problem on gentoo

[trubicoidMember]

There is a slight problem with TrueRNG and openrc start scripts, it seems that the start script uses /dev/ttyACM0 automagically as a tty device and then no data flow to rngd. My workaround for now is to start rngd manually. Summary here:

https://forums.gentoo.org/viewtopic-t-992872-highlight-.html

[neoaeonMember]

Mine run w/ a a tty of ttyACM0 as well on CentOS 6, this doesn’t cause any problems and is likely an artifact of rngd tying itself to a tty.

Have you looked into cgroups, which openrc can automatically allocate, which may be preventing access? forums.gentoo.org appears down at the moment, but IIRC from reading earlier in the week, you’re getting an error similar to “device doesn’t exist”. Which leads me to think of the cgroups based process segmentation in openrc and it’s relation to kernel namespaces. Since it appears that you have sometime between the rc start and the rngd daemon dying, have you tried running strace on it to see whats happening? You’ll probably just catch an ENOENT, but may provide other interesting output.

Some sparse details here: http://wiki.gentoo.org/wiki/OpenRC/CGroups

You’re probably looking for a devices.allow option for the rngd service.

I’d try adding the below to /etc/conf.d/rngd to allow access to devices;

rc_cgroup_devices="
devices.allow a
"

or try the below to access just ttyACM0 (not sure of the syntax, may have to play with quoting);

rc_cgroup_devices="
devices.allow c 166:0 mr
"

Further reading:
https://github.com/OpenRC/openrc/blob/master/etc/rc.conf.Linux
https://www.kernel.org/doc/Documentation/cgroups/devices.txt
https://github.com/OpenRC/openrc/blob/master/sh/rc-cgroup.sh.in
http://gentooexperimental.org/~patrick/weblog/archives/2011-10.html
https://linuxcontainers.org/

-Nick

[trubicoidMember]

I think it is not a problem of accessing the device. I tried your fix and it does not help.

The problem is with

start-stop-daemon --start --exec /usr/sbin/rngd --pidfile /var/run/rngd.pid --wait 1000 -- --pid-file /var/run/rngd.pid --foreground --random-step 64 --fill-watermark 2048 --rng-device /dev/hwrng

While manually without start-stop-daemon it works

/usr/sbin/rngd --pid-file /var/run/rngd.pid --foreground --random-step 64 --fill-watermark 2048 --rng-device /dev/hwrng

The –foreground may be changed for –background.

Looks like start-stop-daemon sees in the arguments a tty device and automagically connects the process to that tty instead of leaving it unconnected.

Then no data from ttyACM0 go to rngd and it complains and stops

what version on openrc do you have on centos? mine is 0.12.4

BTW the forum is back again.

[neoaeonMember]

I don’t have openrc, just reading and trying to help out. I don’t have time at the moment to spin up a gentoo VM to test out.

Let see if we can exclude cgroups.

Can you start rngd with start-stop-daemon and run the following then paste the output?

pidof rngd; find /sys/fs/cgroup -name tasks -exec grep -il "$(pidof rngd)" '{}' \;

If that returns something you should be able to bind to that cgroup and check out some stuff.

bash
echo $$ > /{PATH TO THAT TASKS FILE}/tasks
cat /proc/self/cgroup
ls -l /dev/ttyACM0; dd iflag=fullblock if=/dev/ttypACM0 bs=64 count=1 | od
exit
find /sys/fs/cgroup -name devices.list -ls -exec cat '{}' \;

[trubicoidMember]

not sure what you mean, because the problem is that I can’t run rngd with start-stop-daemon, so the first command is not useful

let’s try to bind it to another cgroup started by openrc, I’ve chosen metalog and everything works:

echo $$ > /sys/fs/cgroup/openrc/metalog/tasks
# cat /proc/self/cgroup
7:blkio:/
6:freezer:/
5:devices:/
4:cpuacct:/
3:cpu:/
2:cpuset:/
1:name=openrc:/metalog
ls -l /dev/ttyACM0; dd iflag=fullblock if=/dev/ttyACM0 bs=64 count=1 | od
crw-rw---- 1 root uucp 166, 0 Sep  6 01:46 /dev/ttyACM0
0000000 027221 177664 037012 170766 104447 105175 105241 011203
0000020 005052 163532 120074 006217 016672 010742 160602 037067
0000040 004256 003130 027505 047334 171510 126767 056415 015250
0000060 026661 157325 104115 065264 153776 150571 014457 063023
0000100
1+0 records in
1+0 records out
64 bytes (64 B) copied, 0.0211215 s, 3.0 kB/s

and

# find /sys/fs/cgroup -name devices.list -ls -exec cat '{}' \;
    18    0 -r--r--r--   1 root     root            0 Sep 12 17:53 /sys/fs/cgroup/devices/openrc_rngd/devices.list
a *:* rwm
    10    0 -r--r--r--   1 root     root            0 Sep 12 17:53 /sys/fs/cgroup/devices/devices.list
a *:* rwm

where the rngd permissions come from your first solution

I can also disable rc_controller_cgroups=”NO” in /etc/rc.conf, but nothing changes.
I can even rebuild kernel without cgroups, but I believe the problem is not related to cgroups. It is in the way start-stop-daemon handels tty line parameters.

[neoaeonMember]

not sure what you mean, because the problem is that I can’t run rngd with start-stop-daemon, so the first command is not useful

Since you were able to get a ps of it running from start-stop-daemon and the message had repeated 99 times, I assumed you had “some time” before it actually terminated to interrogate the broken rngd. It looks like you can get it to run forever with –foreground but –background immediately (or eventually?) terminates. If –background is “eventually” then that’s more interesting because you’re likely to capture the process in the act of failing.

There are a couple tools you can look into to peer inside the running rngd.

lsof – list open files. this will describe which files/devices it has open. Looking for a successful open of ttyACM0.
lsof -p <PID OF RNGD>

strace – system call trace. this will show you exactly what it’s doing and hopefully why it’s not working. It’ll drop errors like ENOENT (doesn’t exist) ENOACCESS (some type of permission denied, file modes/attrs, SELinux, cgroups, etc) and other errors. Looking for a failed “open” or “read”.
strace -p <PID OF RNGD> &>/tmp/rngd-strace.out

If you can’t get it to run, even for a moment, you can try strace with the -f option to follow children. I’m not sure if this’ll work nor how to capture the output, you may have to play with quotes. This will follow start-stop-daemon all the way through to rngd and everything in between.
strace -f start-stop-daemon --start --exec /usr/sbin/rngd --pidfile /var/run/rngd.pid --wait 1000 -- --pid-file /var/run/rngd.pid --background --random-step 64 --fill-watermark 2048 --rng-device /dev/hwrng

WARNING: be careful with the strace output as it will capture keyboard input, file reads, fractional memory mapping, etc. and can, for example, reveal passwords. What we’re looking at shouldn’t, but if by some odd chance something goes awry you could capture things you don’t intend to. Sanitize it before posting. It’ll be huge.

Looks like start-stop-daemon sees in the arguments a tty device and automagically connects the process to that tty instead of leaving it unconnected.

The reason I’m looking elsewhere is because I’ve had rngd show as tied to ttyACM0 on my box. Which while curious caused no ill effect. However, I can’t reproduce it at the moment.

Further, start-stop-daemon says it’s passing the proper argument on to rngd, and Linux doesn’t usually have a problem with multiple processes reading from the same device simultaneously. Even if start-stop-daemon “stole” ttyACM0, rngd could still read from it simultaneously. You can prove this by running that dd | od command in multiple terminals simultaneously.
dd iflag=fullblock if=/dev/ttyACM0 bs=64 | od

Also, with openrc employing all sorts of “process segmentation” techniques it brings me back to some form of permission, setting or operating mode.

I can also disable rc_controller_cgroups=”NO” in /etc/rc.conf, but nothing changes.
I can even rebuild kernel without cgroups, but I believe the problem is not related to cgroups. It is in the way start-stop-daemon handels tty line parameters.

Your outputs above show that your cgroups have access to all devices, and in or out of cgroups the file modes are world readable. Related to cgroups is kernel namespaces which allow different virtual kernel views of particular subsystems per cgroup. Which is why openrc cgroups was my first thought.

If disabling cgroups didn’t fix it then we’re still looking elsewhere.

For example, running something as root directly and having it work is a common indicator of SELinux problems on RHEL 5/6. While the daemon like systemd (or openrc) runs in it’s own SELinux context, root runs as unconfined (no restrictions) and thus “blows through” access control measures. In the cgroups realm the daemon is inside of one with who-knows-what access controls on it, and root via an interactive shell usually doesn’t (or at the very least, one with almost no access control) and thus works as intended.

All together; it doesn’t make sense to me that start-stop-daemon using ttyACM0 as a TTY would really happen, and if it did how it would cause a problem as rngd would still be able to read ttyACM0. It does make sense that running it directly as root would bypass all sorts of security mechanisms.

I’m debugging this with the assumption that showing a tty of ttyACM0 is an anomaly in ps and can be ignored, while running it directly is bypassing all security measures and thus the real place to look.

-Nick

P.s. it’s entirely plausible I’m completely wrong and the read-only nature of ttyACM0 is breaking some function of openrc. The strace -f would likely find that as well.

P.p.s. It could also be another segmentation technology like an overlay filesystem, chroot, or bind mount that openrc is running rngd in. Another potential issue I saw in your stuff was the lack of finding a rngd.pid. I haven’t been able to find anything on the web about this type of segmentation in openrc yet. Again, strace -f should turn that up via an ENOENT of /var/run/rngd.pid from the start-stop-daemon process after an open/write/close of /var/run/rngd.pid in the rngd process.

• This reply was modified 9 years, 7 months ago by  neoaeon. Reason: p.p.s

[chrekhMember]

I’m also using Gentoo, and have the same problem.

As a temporary workoround I edited /etc/init.d/rngd
I changed –bacckground to -f in command_args, and added –background
to start_stop_daemon_args

(resulting command)

start-stop-daemon –start –exec /usr/sbin/rngd –pidfile /var/run/rngd.pid –wait 1000 –background — –pid-file /var/run/rngd.pid -f –random-step 64 –fill-watermark 2048 –rng-device /dev/TrueRNG

In other words, don’t let rngd background itself, and let
start-stop-daemon do it instead. It’s not the “right way”, but it works

–
Christer

• This reply was modified 9 years, 7 months ago by  chrekh.

[Author]

Posts