Home › Forums › TrueRNG Hardware random number generator › More TrueRNG and IPFire Questions
Tagged: IPFire TrueRNG udev
- This topic has 4 replies, 2 voices, and was last updated 10 years, 5 months ago by
Ubld.it Staff.
-
AuthorPosts
-
October 10, 2014 at 12:57 pm #958
trymes
MemberRedneckMother posted earlier that he had successfully configured a TrueRNG to work with rngd in an IPFire installation. I have done the same, but I am trying to resolve a few issues I have encountered.
First, this is the udev rule I have been using:
# TrueRNG (http://forum.ipfire.org/index.php?topic=11091.0) #SUBSYSTEM=="tty", ATTRS{product}=="TrueRNG", SYMLINK+="hwrng", RUN+="/bin/stty raw -echo -ixoff -F /dev/%k speed 3000000" ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="f5fe", ENV{ID_MM_DEVICE_IGNORE}="1" ACTION=="add|remove", KERNEL=="hw_random", RUN+="/etc/rc.d/init.d/rngd udev-event"
My understanding is that this should create a /dev/hwrng symlink, run stty to implement a workaround, disable modemmanager (if installed), and then run rngd when the device is inserted or removed.
Using this rule, I can get the device to work, though it does not autorun rngd when inserted. I have noticed that it will sometimes auto-start rngd correctly, though it does not seem to auto-stop, and I have not been able to reliably replicate that. I did try replacing “hw_random” with “ttyACM%n” and “ttyACM0” in the last line, but neither change seemed to make it work.
Further, I have two newer PCs that report
kernel: usb 2-1.4: new full-speed USB device number 5 using ehci-pci
when I insert the TrueRNG, and two older PCs that reportkernel: usb 2-1: new full-speed USB device number 3 using uhci_hcd
when I insert the TrueRNG. All four are running IPFire core 83. The newer devices have been working reliably for a few days now, while on the older devices rngd stops with an error after a fairly short (but variable) period of time. The error is as follows (though the “read error” messages vary in number before a failure is reported):rngd: read error rngd: read error rngd: read error rngd: read error rngd: read error rngd: too many FIPS failures, disabling entropy source rngd: No entropy sources working, exiting rngd
I removed the
, RUN+="/bin/stty raw -echo -ixoff -F /dev/%k speed 3000000"
from the end of the first line and reinserted the device this morning, and have had no problems since, but I cannot say why that should be.It would be nice if I could get rngd to reliably start/stop when I insert/remove the TrueRNG, and I am uncertain about whether removing the stty portion of the udev rule will cause unforeseen problems in the future. Can anyone more knowledgeable point me in the right direction?
October 13, 2014 at 3:02 pm #961Ubld.it Staff
ModeratorHey there,
Ok lets see what we can do. First off let me say that it really depends on the default port settings per operating system, they are different. The stty rule is needed to force the serial port into raw mode if the default is not already raw. It is possible you don’t need the stty command but if the port isn’t in raw mode it means that serial control characters like flow control and EOF are enabled. If these special control characters are enabled, they do not pass as raw binary bytes through the dev node, and the FIPS-140 test that rngd does can fail because it will see the data isn’t completely white.
I haven’t tested it, but it looks like you’re having issues having multiple RUN statements, since you want the rngd to run when udev enumerates the device, try combineng both with a semi colon instead of 2 RUN statements. Like RUN+=”/bin/stty raw -echo -ixoff -F /dev/%k speed 3000000; /etc/rc.d/init.d/rngd udev-event”
On the note of the rngd: read errors, this is exactly what type of thing can happen without stty. More info can be found on this thread.
And finally as for shutting down rngd when the device is pulled. You might try creating 2 udev rules instead of one that does ACTION=”add|remove” where the remove will shutdown rngd and the add will start it (after the sym link is created, then stty is run on it of course)
October 13, 2014 at 7:16 pm #962trymes
MemberThank you for the details. I started by removing all udev rules I had created. I then rebooted the system with the TrueRNG disconnected. After the system had booted, I ran
/bin/stty -F /dev/ttyACM0
, and got this:speed 9600 baud; line = 0; -brkint -imaxbel
Then, I re-added this for a rule:
SUBSYSTEM=="tty", ATTRS{product}=="TrueRNG", SYMLINK+="hwrng", RUN+="/bin/stty raw -echo -ixoff -F /dev/%k speed 3000000" ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="f5fe", ENV{ID_MM_DEVICE_IGNORE}="1"
Now, if I leave the TrueRNG connected and reboot, all comes up properly, including the stty settings and rngd (which is started during boot, not as part of the udev rule. However, if I boot up without it being plugged in, the symlink is created, but the stty settings are not modified. I don’t understand why, but that is how it is working. If I plug it in and then manually run the commands in the “RUN” directive, all works as it should. Removing the “RUN” directive from the “SUBSYSTEM” line and re-adding the “ACTION” line does not accomplish anything:
#SUBSYSTEM=="tty", ATTRS{product}=="TrueRNG", SYMLINK+="hwrng" #ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="f5fe", ENV{ID_MM_DEVICE_IGNORE}="1" #ACTION=="add|remove", KERNEL=="ttyACM%n", RUN+="/bin/stty raw -echo -ixoff -F /dev/%k speed 3000000; /etc/rc.d/init.d/rngd udev-event"
Perhaps I should just leave it at that, but it just seems to me that a USB device ought to properly function when hot-plugged.
October 13, 2014 at 7:17 pm #963trymes
Member…and just to be clear, I am laying the fault at the feet of my faulty configuration, not the TrueRNG!
October 17, 2014 at 2:37 pm #965Ubld.it Staff
ModeratorIt sounds like the udev daemon isn’t getting insert notification from the kernel and is only running on bootup, I’ve seen this happen when people switch to mdev (for more embedded environments) instead of udev. Hmm. Maybe I can get a hold of an ipfire virtual machine and poke at it to see whats going on.
-
AuthorPosts
- You must be logged in to reply to this topic.