Saturday, April 26, 2014

#4: Qemu Tool Chain for the Beaglebone Black

So far my adventures with the Beaglebone Black left something to be desired, so I decided to make my own ARM tool chain and try to get Fedora 20 to run properly on it.

The easiest way to prepare code for the BBB is with Qemu.  This way, one can make a native ARM system for test and debug on a fast computer and then one can simply copy the resultant programs over to the slow little BBB.

Well, that is the idea anyway.

Qemu

On a Mac, installing Qemu is an adventure in and of itself, so I eventually called it quits and rather installed it on a Fedora 20 virtual machine on the Mac - a virtual machine inside a virtual machine.  It makes my head hurt just to think about the computing contortions required underneath it all, but if it works, it works - except when it doesn't wanna...

Therefore, start here: http://www.aeronetworks.ca/2014/01/fedora-20-on-virtualbox.html

Instaling Qemu on Fedora is super simple, since it is very well supported:
# yum install qemu -y

which will install the whole catastrophe with all the different processors that Qemu can emulate.

This one liner is quite a contrast with trying to make Qemu work on a Mac.

Fedora 20 ARM on Qemu

There is a good guide on the Fedora web site on this:
https://fedoraproject.org/wiki/Architectures/ARM/HowToQemu

So, let's plod through that and see what happens.  That guide describes various ways to do it, with and without libvirt, with or without a cross compiler and so on.  It is worth scanning through the whole thing once before you start.

As is usual with Linux, something is bound to screw up spectacularly somewhere along the line.

Debugging Qemu

Some more information:
http://qemu.weilnetz.de/qemu-doc.html
http://fedoraproject.org/wiki/How_to_debug_Virtualization_problems 
http://www.aurel32.net/info/debian_arm_qemu.php

Using Qemu with libvirt

If one can get this method to work, the advantage is easy access to NAT and DHCP utilities, so connecting to the virtual machine and managing it, is more convenient.

Details here: http://wiki.libvirt.org/page/QEMUSwitchToLibvirt

We need a few more goodies:
# yum groupinstall virtualization

If you installed all of Qemu above, then this will do nothing:
# yum install qemu-system-arm
  
Start her up:
# service libvirtd start

ARM Root File System
# cd /var/lib/libvirt/images

Get it:
http://cdot.senecac.on.ca/arm/arm1.xml \
http://cdot.senecac.on.ca/arm/arm1.img.gz

That takes a while - So far, so good!

Now unzippit:
# gunzip arm1.img.gz 
# restorecon * 
# virsh define arm1.xml
error: Failed to define domain from arm1.xml
error: unsupported configuration: Unknown architecture arm

Bah, humbug...

Something is amiss here in file arm1.xml:
<vcpu>1</vcpu>
  <os>
    <type arch='arm' machine='versatileab'>hvm</type>


The problem is that "arm" is not correct.  It should be "armv7l".  So let's edit the arm1.xml file and try again:
# virsh define arm1.xml
Domain arm1 defined from arm1.xml

Cool, now we are progressing again.

SELinux

We need to loosen the access control a little bit to allow Qemu to run:
# setsebool -P virt_use_execmem 1

That takes a few seconds.

Virtual Machine Manager

Try System Tools>Virtual Machine Manager on the LXDE menu.  It should ask for the root password and then start a simple GUI with one VM called arm1.

The initial root password for the ARM VM image is fedoraarm.

As soon as I try to run the VM however, I get a monitor error and none of the available monitor types work:
Error starting domain: internal error: process exited while connecting to monitor: Error: Cirrus VGA not available

Bah, Humbug #2...

The command virsh start arm1 gives the same error, while virt-viewer arm1 brings up a dialogue with the message "waiting for guest domain to start", which really doesn't help a lot now does it?

Looking at the XML file again, there is a VNC option left to try, but for that I need a VNC viewer - sigh...
# yum install tigervnc -y
So, let's try to run the VM with a VNC server:
# virsh vncdisplay arm1
error: Domain is not running


Bah humbug #3, that error message is extremely unhelpful.

To known the exact error, look in the guest log:
# less /var/log/libvirt/qemu/arm1.logError: Cirrus VGA not available
2014-04-26 12:16:04.790+0000: shutting down


So it is really just the same old problem.

After some more experimentation with the Virtual Machine Manager, I found that a combination of NIC=RTL8139Display=VNC and Video=Xen runs, but that combination is not exactly the BBB hardware.

Hmmm, maybe I spoke too soon, because the whole F20 virtual machine locked up and I had to restart it...

On a second try,  I could connect to it with TigerVNC localhost:5900 and log in as root with password fedoraarm.  So it can work, I just don't know for how long or why it died before.

Here is the proof!

So now what can I do with it?

Hmm, when I try to pause Qemu, VNC exits and the F20 virtual machine becomes unusable.  It still runs, but most things don't work and it needs to be reset.  

Cross Compiler

Normally, one would use a cross compiler to develop for an  embedded system, since compiling something on a dinky little ARM processor will chug along till the sun goes nova and few people have that much time on their hands.

A good Linux cross compiler system is available here:

In general, two versions are available using either glibc or uclibc.
However, I would like to compile natively inside Qemu just for fun.  Yes, it will be slow, but a modern umpteen Gigahertz computer should be plenty fast enough - I hope.
Anyhoo, this is supposed to be fun, for various values of pain...


Native Compiler

As with most things, this has been done before,  but not necessarily on Qemu.

Very good ARM support is available with Arch Linux:
http://archlinuxarm.org/platforms/armv7/ti/beaglebone-black

I'll probably have to abandon Fedora and work with Arch - sigh...

A whole lot more information can be had here:
This guide, while it is out of date, really explains a lot of things regarding making your own tool chain and is worth reading attentively:

To be continued!

H.

Wednesday, April 9, 2014

Heartbleed

This bug will probably be taught in Comp Sci classes in years to come and the poor student Robin Seggelmann from T-Systems International who wrote this buffer bounds beauty, earned instant infamy.

It is a terrible, terrible bug - you send a request to a supposedly secure server and it returns up to 64KB of data, which on a busy mail service like Yahoo, could contain multiple user names, passwords and keys in each and every request.

The bad thing is that the heartbeat feature was not necessary.

A thing should be as simple as possible, but no simpler.
-- A. Einstein

T-Systems violated that principle and we are all paying the price.

Keepass

Give the good IT folks a few days to fix things and then change ALL your passwords everywhere and to preserve your sanity, do install Keepass (Windows), KeepassX (Linux, Mac) or KeepassDroid (Android).

For those worried about Keepass, see this: http://www.ssi.gouv.fr/fr/produits-et-prestataires/produits-certifies-cspn/certificat_cspn_2010_07.html

Broken windows

The problem is actually not as widespread as feared.  According to Netcraft, while a good 70% of all servers use OpenSSL, about a quarter use Heartbeat, meaning that the total percentage of servers affected by Heartbleed, is under 20%, but for the next few days, you cannot trust anything.

Nevertheless, the broken windows fallacy means that some IT businesses will profit handsomely, especially the certificate vendors, at the expense of everyone else.

My site statistics graph shows that there are still many broken Windows out there too...
;)

Now that many people are starting to look critically at OpenSSL, they are bound to find many other issues.  The OpenBSD contributors already started to scratch at it.  So expect to see a slew of updates over the next few weeks as large numbers of bugs get fixed.  Thanks to the heartbeat bug, OpenSSL should end up being much more secure than it ever was.

Update: OpenBSD announced LibreSSL, their lean and mean fork of OpenSSL.
http://www.libressl.org/

Who Knew?

The big question is who knew?

In these matters the only certainty is that there is nothing certain. 
 -- Pliny the Elder

Did the NSA, GCHQ, CSE and others know about this bug for the past two years and happily collected logins and keys and does this explain why they could perform Man In The Middle attacks with such apparent ease?



Thursday, April 3, 2014

Fedora Linux eth0

Sometimes a change is not as good as a holiday.

I like the ethernet port zero to be named eth0 and not p2p1 or em1 or whatever the blazes the system decided to call it this time, since this stupidity breaks all my scripts.

To get the standard behaviour back on Fedora 22 or later, you now only need to do two things:

Add net.ifnames=0 to GRUB_CMDLINE_LINUX in /etc/default/grub immediately before the last quote.

Reconfigure: 
# grub2-mkconfig -o /boot/grub2/grub.cfg

Rename /etc/sysconfig/network-scripts/ifcfg-whatever to ifcfg-eth0
Change to NAME=eth0 inside file ifcfg-eth0.

Now you can reboot:
# reboot

And check things with ifconfig once the machine is up again.

Alternatively, you can call it quits and install Slackware.

La voila!