Add randomness source to FireSim environment

[dhand-galois]

Tracking issue for adding a source of randomness to FireSim-hosted processors.

[dhand-galois]

After working on the debug bridge for FireSim, I was better able to gauge the difficulty in adding new host<->target communication. A simple memory mapped register on both ends takes only a couple of lines of real code after all the boilerplate code.

With that information, I spent a few mins poking around the hw_random device drivers in the Linux kernel to find the simplest existing interface. st-rng.c fit the criteria nicely. It only uses two registers - one a small status register that indicates when random data is available and the second a 32-bit register that holds a different random value after every read.

On the host side, I'm opening /dev/urandom and transferring 32-bit chunks from there to the target FPGA. Open to feedback if there's a better/safer way to pull random numbers. Code here

I've checked in a HW module and bridge that will be compatible with this driver on the feature/randombridge branch. It's working in simulation - building an AFI now to confirm Linux will pick up the new device and use it.

This doesn't preclude implementing any of the other options from https://github.com/DARPA-SSITH-Demonstrators/BESSPIN-CloudGFE/issues/34#issuecomment-644388998, but was a quick enough addition that it made sense to add regardless.

[dhand-galois]

I've tested the RNG device on AWS with an updated build of debian to enable the ST driver and also include the rng-tools package. Everything seems to be working:

[  OK  ] Found device /dev/ttySIF0.
[  OK  ] Reached target System Initialization.
[  OK  ] Listening on D-Bus System Message Bus Socket.
[  OK  ] Reached target Sockets.
[  OK  ] Reached target Basic System.
         Starting LSB: Hardware ranb&tor entropy gatherer daemon...
         Starting Permit User Sessions...
         Starting OpenBSD Secure Shell server...
         Starting System Logging Service...
         Starting Login Service...
[  OK  ] Started D-Bus System Message Bus.
[  OK  ] Started System Logging Service.
[  OK  ] Started Permit User Sessions.
[  OK  ] Started Serial Getty on ttySIF0.
[  OK  ] Reached target Login Prompts.
[  141.550000] random: crng init done
[  141.550000] random: 7 urandom warning(s) missed due to ratelimiting
[  OK  ] Started LSB: Hardware randb&rator entropy gatherer daemon.
[  OK  ] Started Login Service.
[  OK  ] Started OpenBSD Secure Shell server.
[  OK  ] Reached target Multi-User System.

Debian GNU/Linux bullseye/sid besspin-fpga-3 ttySIF0

besspin-fpga-3 login: root
Password:
...
root@besspin-fpga-3:~# systemctl status ssh
b ssh.service - OpenBSD Secure Shell server
   Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enab
   Active: active (running) since Thu 2019-04-11 16:29:53 UTC; 1min 33s ago
     Docs: man:sshd(8)
           man:sshd_config(5)
  Process: 84 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
 Main PID: 96 (sshd)
   CGroup: /system.slice/ssh.service
           bb96 /usr/sbin/sshd -D

Apr 11 16:29:48 besspin-fpga-3 systemd[1]: Starting OpenBSD Secure Shell server.
Apr 11 16:29:53 besspin-fpga-3 sshd[96]: Server listening on 0.0.0.0 port 22.
Apr 11 16:29:53 besspin-fpga-3 systemd[1]: Started OpenBSD Secure Shell server.
root@besspin-fpga-3:~# cat /sys/class/misc/hw_random/rng_available 
63000000.ssithrng 
root@besspin-fpga-3:~# cat /sys/class/misc/hw_random/rng_current
63000000.ssithrng
root@besspin-fpga-3:~# dd if=/dev/hwrng of=/dev/null bs=1M count=5
5+0 records in
5+0 records out
5242880 bytes (5.2 MB, 5.0 MiB) copied, 3.72754 s, 1.4 MB/s

I'll get this merged in and start building all new P1/P2 FireSim AFIs including the RNG interface. I'll also add some documentation to use on non-Linux OSs.

[dhand-galois]

I should point out the data rate in Linux may be artificially limited by the ST driver. They make some assumptions about how long the ST HW RNG takes to actually produce 4 new 32-bit words (which we're obviously not limited by), so it may be waiting unnecessarily for new data. A bare-metal C program would be able to show the true transfer rates, but I'm hoping 1+MB/sec is plenty of throughput for what we need.

[kiniry]

1+MB/s is definitely good enough, as far as everything I know from all TA-1 teams.

[dhand-galois]

Resolved with #114