Experiments with Randomness

In software, the amount of randomness collected by an Operating System is called entropy. I have recently been messing about with entropy on my Linux boxes. This happened because I was fiddling with https (SSL/TLS) and cryptography relies on a good source of random numbers. The random numbers need to come from somewhere.

On most Linux machines, you can see how much entropy your system has by looking at the value in /proc/sys/kernel/random/entropy_avail.

If your machine runs low on entropy, it means that any cryptographic calculations will either have to use a weak source of random numbers (and therefore be less secure) or will block until there is more entropy (meaning that things on your system might appear to slow down).

So out of curiosity I decided to experiment with this. I took my CPU monitoring webserver and adapted it to watch the entropy available rather than the CPU use. If you're really interested, the code can be found on GitHub here.

NOTE: you probably won't want to install the entropy monitoring webserver on your machine, because you would not want to tell the outside world how much entropy your system has available. I am only using it for experimentation and learning.

But ... here are some experiments that I did:

  • Driver Activity

    On Linux, the system uses various sources of entropy. Some of the entropy comes from drivers - including the keyboard and mouse drivers. This is why a VM or perhaps even a 'headless' machine might struggle to generate good quality random numbers - because it is unlikey to see the same type of driver activity. The following experiment demonstrated the effect of mouse movements on the amount of entropy available in a VM:

    You can see the entropy increasing much more rapidly when the mouse moves.

  • Process Activity

    Starting a process on Linux consumes entropy. So you can try running some commands in a terminal window to see the impact on your entropy:

    It's interesting to see the entropy drop as I'm running simple commands. I believe that a new process consumes entropy because it will use random numbers for the Address Space Layout Randomization.

It was reasonably interesting to do those experiments. There is some useful further reading about random numbers and cryptography here. I also found some work that has been done locally here in Cambridge at this blog which was interesting ... and also involves the Raspberry Pi.

Using https with stunnel and ssl_wrapper

Whilst randomly wandering around GitHub a few weeks ago, I noticed ssl_wrapper, which I thought was interesting. Actually, I quite liked the idea of moving the https stuff into a seperate module. It means that any vulnerabilities found in the SSL/TLS stuff could be patched without having to do anything to the actual web server. I am also a fan of the philosophy of smaller pieces of code which can be well tested independently. I suppose this is just the Unix philosophy. But whatever you call it; I liked the idea.

So I had a bit of a play with ssl_wrapper, and even forked the repository to make the basic instructions a bit easier for me to follow, including the creation of a certificate for testing.

So I tried it out by running my own CPU Monitoring webserver over an https connection. However, in Chrome, I noticed that Google considers it to be using 'obsolete cryptography', like this:

I know that Chrome says this about a lot of existing sites, but I thought that it would be a good idea to try and make that message go away. But so far, I have not managed to do that with ssl_wrapper. In the meantime, I have logged an issue on GitHub.

UPDATE: this has now been fixed (but not by me, by the original authors). You can use ssl_wrapper and Chrome will say you're using 'modern cryptography'.

But since I was now interested in all this stuff, I decided to go and look and see if there are alternatives. Indeed there are, and a good one is stunnel. On my Ubuntu box installing it was a breeze, like this:

sudo apt-get install stunnel4

NOTE: I found that it is sometimes important to refer to stunnel4 with the '4' at the end, because your machine might already have an older version.

I was able to take the same certificate I was using with ssl_wrapper and set it up in stunnel. But straight away I found that Chrome was happier, and declared that I was using modern cryptography, like this.

Nice! Another advantage of stunnel is that there has been more recent activity on maintaining the code, which is somewhat comforting.

So, I am now setting up a seperate GitHub repository to help me to test stunnel on various Linux boxes (I have yet to try it on my Rasperry Pi, for example). It means I can be lazy and do this:

sudo apt-get install stunnel4
git clone https://github.com/davidsblog/stunnel4_config
cd stunnel4_config
sudo make

Which is a pretty painless way to test it out on different machines.

FSV, or "this is a Unix System... I know this"

In this months (June, issue 16) Linux Voice magazine, they mentioned that the 3D File System Visualizer like the one used in the original Jurassic Park movie has been ported to modern Linux machines. It was just too tempting, so I went and tried it out. I managed to get it running on my laptop, this is how it looked:

That video clip was recorded in realtime, so considering this was done on a 5 year old laptop I was quite impressed. I was doing that on Elementary OS (Freya) and these were the commands (I hope that I noted them all down correctly):

git clone https://github.com/mcuelenaere/fsv
sudo apt-get install autogen
sudo apt-get install autoconf
sudo apt-get install libtool
sudo apt-get update
sudo apt-get install libgtk2.0-dev libgl1-mesa-dev libgtkgl2.0-dev
sudo apt-get install libglu1-mesa-dev
cd fsv
./autogen.sh
./configure
make
sudo make install

Then you should find the fsv program in your /usr/local/bin directory. You just need to run it.

Although in the end, it was not really as exciting as I expected ... (perhaps that's because there weren't any Velociraptors) but it was a cool thing to do. Apparently, the version used in the Jurassic Park movie was called FSN and was made for IRIX systems.

Supracafe in Santa Cruz de La Palma

Well, it would not be unusual for me to mention a good place to get coffee in the Canary Islands. We've recently returned from the island of La Palma, which is a fantastic place. We were walking along the main street of the captial, Santa Cruz and noticed this place called 'Supracafe' (on Calle O'Daly, the main shopping street):

It looked tempting, and the views were pretty nice:

Anyway, we had coffee and cake ... and it was the best:

If you go there, then we'd recommend it. You can recognise the cafe by the mural on their wall:

Both the cake and the coffee were delicious. The coffee was like a mini Flat White or a large Cortado. The Chocolate cake contained a fantastic chocolate and hazelnut mousse and was not too heavy despite the fact that we were given a massive slice.

Apart from that, it was just nice to sit on the street, take a break and watch the world go by...

"Programming Projects In C..." book

It's good to see that some new C programming books still get published. These days they are quite rare, but it's great to see when one does appear. At the moment I am enjoying this one:

Programming Projects In C For Students Of Engineering, Science, and Mathematics.

I bought mine when I found a copy whilst browsing the Cambridge University Press bookshop. As I flipped through the book in the store I stumbled on the chapter about makefiles, and realised that it was going to be good there and then. I liked the iterative way that the makefiles were presented - as a series of layered enhancements.

It even motivated me to go away and improve some of my makefiles, which were already working fine ... but could be done even better. The advantage is that now I have more of a chance to reuse them on other projects.

But now, I've had an opportunity to read more of this book, and have really enjoyed it. There are lots of little gems tucked away which would be worth taking note of. I reckon that most C programmers would find something interesting in this book, not just developers working in the fields of science, mathematics and engineering.

The C programming language has been around for a long time now, I think that even the author admitted to using certain blocks of code for 30 years or so. But for me, that's part of the beauty of it. There are not many languages where you could have written a block of code decades ago and find that it's just as good today.

If you're doing C programming and are curious to see how somebody else uses the language then you'll probably enjoy reading this book.

Elementary OS upgrade

I've just upgraded my old laptop OS (it's a Toshiba Satellite T130, and must be about 5 years old). Previously, I had been running Elementary OS Luna which I found pretty impressive. It had a couple of niggles ... for example the file manager app always seemed to take ages to load. Now that the new version, Freya has come out, I decided to try it. I went for a complete wipe and reinstall.

I am quite pleased with the upgrade. The slow file manager startup time has even gone away, and the whole OS seems even more polished. However, I have had a problem with the pointer getting corrupted if I did drag and drop, which was annoying, I am currently trying this fix, hopefully that will make it go away. Anyway, I celebrated a successful reinstall by going off to the Nasa JPL Wallpapers site and grabbing myself a nice background, so here's a screenshot:

I think that it's still the most visually appealing Linux I have tried and I'm quite happy that I've upgraded to the latest version. It runs nice and fast on my old laptop, and it's nice to have something that looks good without eating all your CPU cycles.

Remote monitoring *VoCore* CPU use

So I really wrote my CPU monitoring webserver program to be able to monitor my Raspberry Pi, but hoped that the code should run on other Linux machines too. Indeed, I have also been testing it in a virtual box running Debian. The code is runnable from Xcode on my Mac, but unfortunately it's a simulation only for testing purposes, because /proc/stat does not exist on Mac OS. So, for the moment, it definitely won't work on the Mac.

But I did think that it would work on OpenWrt, so decided to try it on my VoCore. In anticipation I had already put the necessary stuff in the makefile, so all I needed to do was go to a box with OpenWrt cross compilation set up and do this:  make vocore.

Then I copied the resulting binary executable to my VoCore and it worked straight away. I even made a recording of the initial run for posterity:

Since all the resources (html and javascript files) are embedded in the executable it is really very simple to do, just copy and run a single file. The version compiled for the VoCore came out at 112 Kb in size. Hopefully that's not too bad. I could compress the resource files if space was really important, but I haven't felt the need to do that.

It's pretty good to see this running on a machine about the size of a postage stamp. Obviously I could make it just show a single graph when it runs on a single core machine. Perhaps I'll do that when I get some time.

Sinclair nostalgia

A while back, in a fit of 1980s nostalgia, I realised that my place of work is within walking distance of the old Sinclair building in Cambridge. So I decided to walk over there at lunchtime and see if I could still find it. This is how the building looked back in the 80s:

...which is a single frame taken from this YouTube clip, which gives a glimpse of the inside too:

Anyway, this is what I found when I walked over there recently:

I was quite pleased that there was still a small street sign bearing the name "Sinclair" at the entrance. The building looks like it's part of Anglia Ruskin University nowadays.

It's a shame that the big Sinclair logo was taken down. But the building is clearly recognisable, which is pretty cool.

Remote monitoring Raspberry Pi 2 CPUs

I wanted to visualise of all those CPU cores on my new Raspberry Pi 2, so I decided to build a remote CPU monitoring webserver. The idea is to serve a webpage showing the percentage use of the CPU cores in a nice scrolling graph. Another idea I wanted to try was to keep all the HTML and JavaScript files embedded in the executable. So you only need the single binary program file. It means you just run the program without having to worry about putting supporting files in a particular place.

I'm hopeful that because it's lightweight and written in C the program itself won't consume many of the Raspberry Pi's resources. If you wanted, you could probably run the program as a service when the machine starts and not notice any difference. The CPU data is sent from a minimal Web API, which is built into the webserver. It sends out the CPU percentages as an array in JSON format. This means that most of the work is done by the browser (all the plotting and scrolling) and on the server side we just need to send an array of numbers every second or so. And whilst I was at it, I also included the ability to monitor the core temperature (if it is running on a Raspberry Pi).

I have put the resulting project on GitHub, so if anybody wants to have the ability to monitor their CPU cores over their network they can try it. I expect it will work on other Linux machines too, it's not restricted to the Raspberry Pi. The number of graphs is dynamically updated, depending on the number of cores you have.

This is how it looks (in this case showing the graphs on a simulated iPhone 4s):

If you want to, you can try it out like this:

git clone https://github.com/davidsblog/rCPU
cd rCPU/rCPU
make
sudo ./rcpu 80

...which will only work if you're not running an existing webserver on the machine, otherwise substitute the 80 on the last line for a different port. When the server is running, simply point a browser at your machines IP address (and port if its different than 80) and enjoy.

I did notice that the graphs don't plot very nicely on the default browser included with Raspbian (although if you install an alternative like Chromium it should be OK). But since the purpose is to monitor the CPUs remotely this should not really be an issue.

Recovering a slightly broken Vocore

OK, I managed to mess up the network settings on my Vocore. Oh well, it happens. It's not too bad... the device was still booting up and running... but was not accessible by Wi-Fi or by plugging in a network cable. So it's back to a good old serial connection. This is what I have done:

I've used a USB to Serial 3.3v TTL cable that I already had, and then just poked some jumper wires into the right places. Surprisingly it seems good enough. Anyway, in case I need to do this again, I thought that it would be worth taking a photo. I'm using PuTTY on a Windows box as the terminal. The settings I'm using are:

  • Speed: 57600
  • Data bits: 8
  • Stop bits: 1
  • Parity: None
  • Flow control: XON/XOFF

I connected the USB-to-serial cable first, then opened the connection using PuTTY. You then have a blank terminal screen. Then I connect the power to the Vocore, and you get to see all the logging information as the device boots. After a couple of minutes I press enter in the terminal and end up with the usual OpenWrt startup screen. After that you can use the console like normal. Anyway, it's handy to have that written down somewhere, because I'll probably break it again at some point. But I can report that I was able to fix the network config and things are back to normal now. Phew.