Home Forums TrueRNG Hardware random number generator More TrueRNG and IPFire Questions

This topic contains 4 replies, has 2 voices, and was last updated by  Ubld.it Staff 9 years, 6 months ago.

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #958

    trymes
    Member

    RedneckMother 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 report kernel: 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?

    • This topic was modified 9 years, 6 months ago by  trymes.
    • This topic was modified 9 years, 6 months ago by  trymes.
    #961

    Ubld.it Staff
    Moderator

    Hey 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)

    #962

    trymes
    Member

    Thank 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.

    #963

    trymes
    Member

    …and just to be clear, I am laying the fault at the feet of my faulty configuration, not the TrueRNG!

    #965

    Ubld.it Staff
    Moderator

    It 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.

Viewing 5 posts - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.