Forum Replies Created

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • in reply to: TrueRNG problem on gentoo #941

    neoaeon
    Member

    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 4 years, 2 months ago by  neoaeon. Reason: p.p.s
    in reply to: TrueRNG problem on gentoo #933

    neoaeon
    Member

    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 '{}' \;
    
    in reply to: TrueRNG problem on gentoo #930

    neoaeon
    Member

    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

    in reply to: udev changes, throughput and entropy questions #923

    neoaeon
    Member

    Instead of removing the SYMLINK you can simply add a %n to it to have udev create TrueRNGn devices. i.e. TrueRNG0 and TrueRNG1.

    Be aware, with a single device TrueRNG will become TrueRNG0.

    I have my v1 and v2 running as TrueRNG0 and TrueRNG1. AFAIK n is passed through from the ttyACMn. As such you may end up w/ TrueRNG0 and TrueRNG2 if you have another ttyACM device already, or other such unpredictable numbering.

    # ubld.it TrueRNG
    #
    # This rule creates a symlin to newly attached CDC-ACM device 
    # Also includes fix for wrong termios settings on some linux kernels
    # New! includes ignore for modemmanger
    # (Thanks neoaeon)
    SUBSYSTEM=="tty", ATTRS{product}=="TrueRNG", SYMLINK+="TrueRNG%n", RUN+="/bin/stty raw -echo -ixoff -F /dev/%k speed 3000000"
    ATTRS{idVendor}=="04d8", ATTRS{idProduct}=="f5fe", ENV{ID_MM_DEVICE_IGNORE}="1"
    • This reply was modified 4 years, 2 months ago by  neoaeon. Reason: udev formatting
    in reply to: TrueRNG v2 Info? #812

    neoaeon
    Member

    Apologies, this should have been called v1.01 info as described here (Post #806). As hinted, the below command should list the version.

    # lsusb -v -d 04d8:f5fe | grep bcdDevice
      bcdDevice            1.00

    v1.00 – Original
    v1.01 – Whitener update
    v2.00 – TBD

    in reply to: udev changes, throughput and entropy questions #783

    neoaeon
    Member

    You can also check out csprngd https://code.google.com/p/csrng/. It has it’s own mix function, built-in additional RNGs (HAVEGE) and PRNGs, has a built-in whitener, and can read from/combine multiple sources.

    If you’re looking for faster random than the ~10kbps you’re getting you can use csprngd to achieve ~1 megabyte per second.

    • This reply was modified 4 years, 3 months ago by  neoaeon.
    • This reply was modified 4 years, 3 months ago by  neoaeon. Reason: removed incorrect information
    in reply to: udev changes, throughput and entropy questions #782

    neoaeon
    Member
     $ while sleep 1; do cat /proc/sys/kernel/random/entropy_avail | tr '\n' ' '; done;
    34 40 59 25 35 44 17 34 29 12 21 30 39 48 56 6 44 61 14 23 

    This causes ‘cat’ to run for each read, 8 bits of entropy are used for each evocation of cat. You have to open the file and re-read it. http://www.gossamer-threads.com/lists/linux/kernel/1210167

    you can read it w/ a single “bash” instead of cat with the below;

    
    while true; do
    exec 3< /proc/sys/kernel/random/entropy_avail
    read -u 3 a
    echo $a
    exec 3<&-
    done
    
    in reply to: RedHat/CentOS install #760

    neoaeon
    Member

    Reviewer jwoude pointed out an error in v2 on systemd devices. TrueRNG was selected as the output device not the source hwrng device.

    Review #628 by jwoude

    My sincere apologies to anyone affected.

    Simply re-running the install script should fix the error.

    script v3:

    
    #!/bin/bash
    #
    # Installer for TrueRNG udev rules
    # currently supports CentOS / RHEL and Fedora
    # Alpha Scientific Linux and Oracle Enterprise support
    #
    # Nick Crawford (npc) <nick@null.net>
    #
    # v1 -npc 7 Mar 2014
    # - intial version
    # v2 -npc 28 Mar 2014
    # - move to bash
    # - check for root
    # - case match of fedora, centos and redhat
    #  others untested; scientific (sl) and oracle (oraclelinux enterprise)
    # - strip alpha's from ver instead of print left 1
    # - F18+ (rhel7) no longer has /etc/sysconfig/rngd or /etc/init.d/rngd.
    # - future releases will depreicate service start for systemctl start, moved
    # - functions for chkconfig/systemctl, service/systemctl, udevcontrol/udevadm
    # v3 -npc 23 Jun 2014
    # - update rngd_systemd, fix from jwoude
    #  replace rngd call with proper -r option
    #  review 628 by jwoude:
    #  https://www.tindie.com/products/ubldit/truerng-hardware-random-number-generator/?#tab-product-reviews
    # - update rngd_sysconfig to support update of options via re-run
    #
    
    # check root
    if [ $UID -ne 0 -a $EUID -ne 0 ]; then echo "ERROR: need to run as root" 1>&2; exit 1; fi
    
    # determine redhat version and derivative type
    eval $(rpm -q --whatprovides /etc/redhat-release --queryformat "RHELTYPE=%{NAME}\nRHELVER=%{VERSION}\n")
    
    # check for pre-reqs
    if ! rpm -q wget &>/dev/null; then RPMS="${RPMS} wget"; fi
    if ! rpm -q unzip &>/dev/null; then RPMS="${RPMS} unzip"; fi
    if ! rpm -q rng-tools &>/dev/null; then RPMS="${RPMS} rng-tools"; fi
    
    # install pre-reqs
    if [ ! -z ${RPMS} ]; then yum -y install ${RPMS}; fi
    
    ## Install the udev rule
    # Grab the udev rules
    wget -nd http://ubld.it/wp-content/uploads/2014/02/TrueRNG-Linux-udev-rules.zip -O /tmp/TrueRNG-Linux-udev-rules.zip 
    # unzip the rules to /etc/udev/rules.d
    unzip /tmp/TrueRNG-Linux-udev-rules.zip -d /etc/udev/rules.d 
    # remove zip
    rm -fv /tmp/TrueRNG-Linux-udev-rules.zip 
    
    ## udev, rehash rules and trigger hot plug events
    # func old udevcontrol
    udev_control() {
      udevcontrol reload_rules
      udevtrigger
    }
    # func new udevadm
    udev_adm() {
      udevadm control --reload-rules 
      udevadm trigger 
    }
    
    ## add rng-device to rng config
    # func old sysconfig
    rngd_sysconfig() {
      sed -i~ -e 's/EXTRAOPTIONS=.*/EXTRAOPTIONS="--rng-device=\/dev\/TrueRNG"/' /etc/sysconfig/rngd 
    }
    # func new systemd
    rngd_systemd() {
      cp -p /usr/lib/systemd/system/rngd.service /etc/systemd/system/rngd.service
      sed -i~ -e 's/ExecStart=.*/ExecStart=\/sbin\/rngd -f -r \/dev\/TrueRNG/' /etc/systemd/system/rngd.service
      systemctl daemon-reload
    }
    
    ## start rngd and turn service on
    # func old chkconfig
    rngd_chkconfig() {
      chkconfig rngd on
      if ! service rngd status &>/dev/null; then service rngd start; else service rngd restart; fi
    }
    # func new systemctl
    rngd_systemctl() {
      systemctl enable rngd
      if ! systemctl status rngd &>/dev/null; then systemctl start rngd; else systemctl restart rngd; fi
    }
    
    # Process RHEL type and version, execute functions based on results
    case ${RHELTYPE} in
      redhat-* | centos-* | enterprise-* | oraclelinux-* | sl-*)
        if [ ${RHELVER//[!0-9]/} -le 5 ]; then
          udev_control
          rngd_sysconfig
          rngd_chkconfig
        elif [ ${RHELVER//[!0-9]/} -gt 5 -a ${RHELVER//[!0-9]/} -lt 7 ]; then
          udev_adm
          rngd_sysconfig
          rngd_chkconfig
        elif [ ${RHELVER//[!0-9]/} -ge 7 ]; then
          udev_adm
          rngd_systemd
          rngd_systemctl
        else
          udev_adm
          rngd_systemd
          rngd_systemctl
        fi
      ;;
      fedora*)
        if [ ${RHELVER//[!0-9]/} -le 8 ]; then
          udev_control
          rngd_sysconfig
          rngd_chkconfig
        elif [ ${RHELVER//[!0-9]/} -gt 8 -a ${RHELVER//[!0-9]/} -lt 18 ]; then
          udev_adm
          rngd_sysconfig
          rngd_chkconfig
        elif [ ${RHELVER//[!0-9]/} -ge 18 ]; then
          udev_adm
          rngd_systemd
          rngd_systemctl
        else
          udev_adm
          rngd_systemd
          rngd_systemctl
        fi
      ;;
      *)
        echo "ERROR: Unknown RedHat derivative ${RHELTYPE} ${RHELVER}." 1>&2
        echo "WARNING: Could not install services." 1>&2
        exit 1
      ;;
    esac
    

    diff:

    *** truerng-install.sh.orig	2014-06-23 17:07:25.152096057 -0400
    --- truerng-install.sh	2014-06-23 17:06:51.345818466 -0400
    ***************
    *** 17,22 ****
    --- 17,28 ----
      # - F18+ (rhel7) no longer has /etc/sysconfig/rngd or /etc/init.d/rngd.
      # - future releases will depreicate service start for systemctl start, moved
      # - functions for chkconfig/systemctl, service/systemctl, udevcontrol/udevadm
    + # v3 -npc 23 Jun 2014
    + # - update rngd_systemd, fix from jwoude
    + #  replace rngd call with proper -r option
    + #  review 628 by jwoude:
    + #  https://www.tindie.com/products/ubldit/truerng-hardware-random-number-generator/?#tab-product-reviews
    + # - update rngd_sysconfig to support update of options via re-run
      #
      
      # check root
    ***************
    *** 56,67 ****
      ## add rng-device to rng config
      # func old sysconfig
      rngd_sysconfig() {
    !   sed -i~ -e 's/EXTRAOPTIONS=""/EXTRAOPTIONS="--rng-device=\/dev\/TrueRNG"/' /etc/sysconfig/rngd 
      }
      # func new systemd
      rngd_systemd() {
        cp -p /usr/lib/systemd/system/rngd.service /etc/systemd/system/rngd.service
    !   sed -i~ -e 's/ExecStart=.*/ExecStart=\/sbin\/rngd -f -o \/dev\/TrueRNG/' /etc/systemd/system/rngd.service
        systemctl daemon-reload
      }
      
    --- 62,73 ----
      ## add rng-device to rng config
      # func old sysconfig
      rngd_sysconfig() {
    !   sed -i~ -e 's/EXTRAOPTIONS=.*/EXTRAOPTIONS="--rng-device=\/dev\/TrueRNG"/' /etc/sysconfig/rngd 
      }
      # func new systemd
      rngd_systemd() {
        cp -p /usr/lib/systemd/system/rngd.service /etc/systemd/system/rngd.service
    !   sed -i~ -e 's/ExecStart=.*/ExecStart=\/sbin\/rngd -f -r \/dev\/TrueRNG/' /etc/systemd/system/rngd.service
        systemctl daemon-reload
      }
      
    
    • This reply was modified 4 years, 4 months ago by  neoaeon.
    • This reply was modified 4 years, 4 months ago by  neoaeon. Reason: label script
    in reply to: RedHat/CentOS install #596

    neoaeon
    Member

    I wanted to give TrueRNG a shot on Fedora 20, so I rebuilt the script to support newer versions.
    Tested on CentOS 6 and Fedora 20.

    Should support CentOS, Red Hat Enterprise Linux, and Fedora. Untested support for Scientific Linux and Oracle Enterprise Linux.

    
    #!/bin/bash
    #
    # Installer for TrueRNG udev rules
    # currently supports CentOS / RHEL and Fedora
    # Alpha Scientific Linux and Oracle Enterprise support
    #
    # Nick Crawford (npc) <nick@null.net>
    #
    # v1 -npc 7 Mar 2014
    # - intial version
    # v2 -npc 28 Mar 2014
    # - move to bash
    # - check for root
    # - case match of fedora, centos and redhat
    #  others untested; scientific (sl) and oracle (oraclelinux enterprise)
    # - strip alpha's from ver instead of print left 1
    # - F18+ (rhel7) no longer has /etc/sysconfig/rngd or /etc/init.d/rngd.
    # - future releases will depreicate service start for systemctl start, moved
    # - functions for chkconfig/systemctl, service/systemctl, udevcontrol/udevadm
    #
    
    # check root
    if [ $UID -ne 0 -a $EUID -ne 0 ]; then echo "ERROR: need to run as root" 1>&2; exit 1; fi
    
    # determine redhat version and derivative type
    eval $(rpm -q --whatprovides /etc/redhat-release --queryformat "RHELTYPE=%{NAME}\nRHELVER=%{VERSION}\n")
    
    # check for pre-reqs
    if ! rpm -q wget &>/dev/null; then RPMS="${RPMS} wget"; fi
    if ! rpm -q unzip &>/dev/null; then RPMS="${RPMS} unzip"; fi
    if ! rpm -q rng-tools &>/dev/null; then RPMS="${RPMS} rng-tools"; fi
    
    # install pre-reqs
    if [ ! -z ${RPMS} ]; then yum -y install ${RPMS}; fi
    
    ## Install the udev rule
    # Grab the udev rules
    wget -nd http://ubld.it/wp-content/uploads/2014/02/TrueRNG-Linux-udev-rules.zip -O /tmp/TrueRNG-Linux-udev-rules.zip 
    # unzip the rules to /etc/udev/rules.d
    unzip /tmp/TrueRNG-Linux-udev-rules.zip -d /etc/udev/rules.d 
    # remove zip
    rm -fv /tmp/TrueRNG-Linux-udev-rules.zip 
    
    ## udev, rehash rules and trigger hot plug events
    # func old udevcontrol
    udev_control() {
      udevcontrol reload_rules
      udevtrigger
    }
    # func new udevadm
    udev_adm() {
      udevadm control --reload-rules 
      udevadm trigger 
    }
    
    ## add rng-device to rng config
    # func old sysconfig
    rngd_sysconfig() {
      sed -i~ -e 's/EXTRAOPTIONS=""/EXTRAOPTIONS="--rng-device=\/dev\/TrueRNG"/' /etc/sysconfig/rngd 
    }
    # func new systemd
    rngd_systemd() {
      cp -p /usr/lib/systemd/system/rngd.service /etc/systemd/system/rngd.service
      sed -i~ -e 's/ExecStart=.*/ExecStart=\/sbin\/rngd -f -o \/dev\/TrueRNG/' /etc/systemd/system/rngd.service
      systemctl daemon-reload
    }
    
    ## start rngd and turn service on
    # func old chkconfig
    rngd_chkconfig() {
      chkconfig rngd on
      if ! service rngd status &>/dev/null; then service rngd start; else service rngd restart; fi
    }
    # func new systemctl
    rngd_systemctl() {
      systemctl enable rngd
      if ! systemctl status rngd &>/dev/null; then systemctl start rngd; else systemctl restart rngd; fi
    }
    
    # Process RHEL type and version, execute functions based on results
    case ${RHELTYPE} in
      redhat-* | centos-* | enterprise-* | oraclelinux-* | sl-*)
        if [ ${RHELVER//[!0-9]/} -le 5 ]; then
          udev_control
          rngd_sysconfig
          rngd_chkconfig
        elif [ ${RHELVER//[!0-9]/} -gt 5 -a ${RHELVER//[!0-9]/} -lt 7 ]; then
          udev_adm
          rngd_sysconfig
          rngd_chkconfig
        elif [ ${RHELVER//[!0-9]/} -ge 7 ]; then
          udev_adm
          rngd_systemd
          rngd_systemctl
        else
          udev_adm
          rngd_systemd
          rngd_systemctl
        fi
      ;;
      fedora*)
        if [ ${RHELVER//[!0-9]/} -le 8 ]; then
          udev_control
          rngd_sysconfig
          rngd_chkconfig
        elif [ ${RHELVER//[!0-9]/} -gt 8 -a ${RHELVER//[!0-9]/} -lt 18 ]; then
          udev_adm
          rngd_sysconfig
          rngd_chkconfig
        elif [ ${RHELVER//[!0-9]/} -ge 18 ]; then
          udev_adm
          rngd_systemd
          rngd_systemctl
        else
          udev_adm
          rngd_systemd
          rngd_systemctl
        fi
      ;;
      *)
        echo "ERROR: Unknown RedHat derivative ${RHELTYPE} ${RHELVER}." 1>&2
        echo "WARNING: Could not install services." 1>&2
        exit 1
      ;;
    esac
    
    • This reply was modified 4 years, 7 months ago by  neoaeon. Reason: extra lf
    in reply to: Fix for rngd: read error #544

    neoaeon
    Member

    Based on your input I switched to stty -echoe -echok -F /dev/%k raw, which seems to be working better.

    Do you have any thoughts on -echoe -echok? I can’t tell if those apply to input or output. If applied to output then lacking them could create predictable patterns, if applied to input then having them flagged won’t hurt anything as there is no input.

    Thank you very much for the follow up.

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