My New Blog: Here it Comes

After having written a few articles irregularly on my home page using my own scripts, I have decided to try out WordPress.  It definitely looks better than my homegrown scripts which admittedly is not hard as I have not spent a lot of time on looks previously.  Now, let’s see how easy it is to use and how easy it will be to get out my posts if I ever decide to switch to a different blogging infrastructure.

In the following days (or weeks), I plan to upload my previous articles as blog entries here, so that people can comment etc.  Please be patient because I will have to familiarise myself with this new infrastructure and might make a mistake or two.

Posted in Miscellaneous | Leave a comment

Postprocessing Underwater Photos with ufraw

Today, we will look into how to make good dive photos. We will most look into getting the colors right. The focus being on how to use ufraw to get the white balance right. For how to choose your UW Photo Equipment and for shooting techniques, check out the excellent guides by Scott Gietler.

Continue reading

Posted in Photography, Underwater | Tagged , , , | Leave a comment

Getting the ADT to run on 64 bit Linux

Installation is mostly straight forward except that for some unexplicable reasons, somebody at Google thought that there is no need to compile the platform tools as 64 bit binaries. Hence, this article mostly serves me to recall which 32 bit libraries to install if I ever reinstall my box. Hopefully, until then a native 64 bit version is available, but I am not counting on it.

Installation

Installation of the Android SDK is fairly easy but there are a few things to do.

  1. Download the Android Developer Tools and unzip.
  2. Download and install a Java Runtime Environment. Possibly, you may want to download and install a JDK instead or as well.
  3. Create a link pointing from adt-bundle-linux-x86_64-$version/sdk/platform-tools to your jre directory.

Depending on your Ubuntu version, install the following 32 bit libraries. These libraries are needed for the SDK tools.

Ubuntu 12.04
$ sudo apt-get install ia32-libs
Ubuntu 13.04
$ sudo apt-get install libc6-i386 lib32stdc++6 lib32gcc1 lib32ncurses5
Ubuntu 13.10
$ sudo apt-get install libc6-i386 lib32stdc++6 lib32gcc1 lib32ncurses5 lib32z1 lib32tinfo5

Yes, lib32tinfo5 does not have to be explicitly specified, it will be pulled in as a dependency.

Finally, if you are using Java 8.0, you may want to remove the -XX:MaxPermSize=... options from adt-bundle-linux-x86_64-$version/eclipse/eclipse.ini. This option has been removed from java and generates a warning. In my version of the ADT, this option was included twice. The same applies to the --launcher.XXMaxPermSize 256m option which is split over two lines.

Subversion

ADT is based on Eclipse which is nice. Eclipse is even nicer if used with the Subversion integration provided by Subversive. The Subversive Update Site can be found at http://download.eclipse.org/technology/subversive/1.1/update-site/.

References

Posted in Linux, Technology | Tagged , , , | Leave a comment

NVIDIA Drivers on Ubuntu 13.10

Installing NVIDIA drivers on Ubuntu 13.10. This article is heavily based on memory and my previous article on accomplishing the same for Fedora from a year ago. The good news, things have gotten easier in the meantime.

Installing nvidia’s binary drivers for Linux

The following instructions guide you through the installation of the NVIDIA graphics drivers. As first step, go to the NVIDIA web site and download the NVIDIA binary drivers for your graphics card. The drivers are available at http://www.geforce.com/drivers. The driver package comes as a self-etracting setup binary, that needs to be made executable:

$ sudo chmod 755 NVIDIA-Linux-x86_64-310.32

Most likely you need to install gcc for the NVIDIA drivers to be linked against your current kernel. Do not worry, this will be all done by the driver installation. You may want to proceed without this step. If things fail you can do this step lateron too.

$ sudo apt-get install gcc

Next you want to ensure that you are running the latest version of the linux kernel. A simple apt-get update and apt-get upgrade should take care of this. If a new kernel was installed, you want to restart your system to ensure that the latest kernel version is actively running.

Most likely, you are using the nouveau graphics drivers. The easiest way to figure out is to invoke the NVIDIA setup. Only downside is, this setup needs to be invoked without the X server being running (i.e., best from the console). Swith to a console (Ctrl-Alt-F2), and turn off X. Simply stop the display manager using:

$ sudo service lightdm stop

You may have to login again, switch again to the directory where you downloaded the NVIDIA drivers to and issue:

$ sudo ./NVIDIA-Linux-x86_64-310.32.run

If it tells you you are using the nouveau drivers, confirm you want to deactivate them. That’s it, unlike with some Fedora distributions, there is no need to adapt any grub configuration files.

If the above fails due to missing kernel sources, you need to install the kernel-devel package and restart the setup.

Now everything should be installed and once you restart your system for a very last time (don’t forget to disable the nouveau drivers if you have chosen option one above), you should be using the NVIDIA drivers.

References

Posted in Linux, Technology | Tagged , , , | Leave a comment

Creating and Verifying Signatures with OpenSSL

Signatures are used to verify that a given person has signed a given sequence of bytes. We will be using openssl to generate signatures and see what the outcome looks like.

First, let us create a new key for this sample, using:

$ openssl genrsa -out mykey.key 2048

The constituents of the key such as modulus, exponent, etc., we can show using the following command:

$ openssl rsa -text <keyfile.key

Creating a Hash value

To sign a message, we need to create a hash value of the message that needs to be signed. This can be accomplished using the following command:

$ openssl dgst -sha256 <myfile
(stdin)= 06160430cd3d59a68fb4f4a5602ae8c8e2560e9645df2a618034d80ba6debad5

This displays the hash value in a human readable form which is fine for experiments but not the approach typically taken. Instead, we want to generate the hash value in binary form which can be generated with the -binary option:

$ openssl dgst -binary -sha256 <myfile >myfile.sha256
$ xxd myfile.sha256
0000000: 0616 0430 cd3d 59a6 8fb4 f4a5 602a e8c8  ...0.=Y.....`*..
0000010: e256 0e96 45df 2a61 8034 d80b a6de bad5  .V..E.*a.4......

As the hexdump shows it is the same hash, just in binary form.

Signing a Hash value

Once we have the binary hash value, we need to sign it. openssl provides two ways of doing this which we will have a look at:

$ openssl rsautl -sign -inkey mykey.key <myfile.sha256 >myfile.sha256.sig
$ openssl sha -sha256 -sign mykey.key <myfile >myfile.sig

Verifying a Signature

Both of the above signatures can be verified using the following command:

$ openssl rsautl -raw -verify -inkey mykey.key <signature | xxd

When we apply this command to the two signature files above, we will get different output (instead of using xxd, one can also add the -hexdump command line option to openssl):

$ openssl rsautl -raw -verify -inkey mykey.key <myfile.sha256.sig | xxd
0000000: 0001 ffff ffff ffff ffff ffff ffff ffff  ................
0000010: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000020: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000030: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000040: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000050: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000060: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000070: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000080: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000090: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000a0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000b0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000c0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000d0: ffff ffff ffff ffff ffff ffff ffff ff00  ................
00000e0: 0616 0430 cd3d 59a6 8fb4 f4a5 602a e8c8  ...0.=Y.....`*..
00000f0: e256 0e96 45df 2a61 8034 d80b a6de bad5  .V..E.*a.4......
$ openssl rsautl -raw -verify -inkey mykey.key <myfile.sig | xxd
0000000: 0001 ffff ffff ffff ffff ffff ffff ffff  ................
0000010: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000020: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000030: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000040: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000050: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000060: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000070: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000080: ffff ffff ffff ffff ffff ffff ffff ffff  ................
0000090: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000a0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000b0: ffff ffff ffff ffff ffff ffff ffff ffff  ................
00000c0: ffff ffff ffff ffff ffff ffff 0030 3130  .............010
00000d0: 0d06 0960 8648 0165 0304 0201 0500 0420  ...`.H.e....... 
00000e0: 0616 0430 cd3d 59a6 8fb4 f4a5 602a e8c8  ...0.=Y.....`*..
00000f0: e256 0e96 45df 2a61 8034 d80b a6de bad5  .V..E.*a.4......

By supplying the -raw command line option, we can also see the bytes with which the signature was padded before it has been encrypted.

The difference in the two output files comes from the fact that the first one does not encode the hash algorithm which was used to generate the hash value. One explanation is that the openssl rsautl function does not know it (also there is no command line option to supply this) whereas the second one supplies this information. More precisely, the second one encodes the algorithm and the hash value into an ASN.1 string. We can have a look at this using the following command:

$ openssl rsautl -verify -inkey mykey.key -asn1parse <myfile.sig
    0:d=0  hl=2 l=  49 cons: SEQUENCE          
    2:d=1  hl=2 l=  13 cons:  SEQUENCE          
    4:d=2  hl=2 l=   9 prim:   OBJECT            :sha256
   15:d=2  hl=2 l=   0 prim:   NULL              
   17:d=1  hl=2 l=  32 prim:  OCTET STRING      
      0000 - 06 16 04 30 cd 3d 59 a6-8f b4 f4 a5 60 2a e8 c8   ...0.=Y.....`*..
      0010 - e2 56 0e 96 45 df 2a 61-80 34 d8 0b a6 de ba d5   .V..E.*a.4......

Generally speaking, the second version should be preferred because otherwise clients do not know what precisely has been signed with the user’s private key.

A synonym for the second option is the following command:

openssl dgst -sha256 -sign mykey.key <myfile >myfile.sig
Posted in Technology | Tagged , , | 1 Comment

Building a UEFI Secure Boot Enabled Virtual Machine

In the following, we will show how to setup a QEMU Virtual Machine with a Secure Boot Enabled UEFI BIOS. This makes for a perfect UEFI Development Environment.
The instructions below have been tested on an UBuntu 13.10 installation. Instructions may have to be adapted for other systems. The instructions have been written down from memory and they may contain errors. Unless otherwise noted, no root priviledges are necessary, if everything is installed properly.

Installing QEMU

The easiest way to experiment with a UEFI BIOS is to use a QEMU virtual machine. An extra benefit is that we can also enable Secure Boot and enroll our own Platform Key to test any Secure Boot development we may be doing. First install QEMU simply by issuing:

$ sudo apt-get install qemu

You can run a simple virtual machine using the following commands. To create a 32 bit machine, issue:

$ qemu-system-i386

To create a 64 bit machine, issue:

$ qemu-system-x86_64

Building the UEFI BIOS

Most UEFI machines are 64 bit based and use a 64 bit UEFI BIOS. The following instructions assume this is what needs to be built, for 32 bit, please adapt the instructions.

QEMU virtual machines by default use a standard MBR BIOS. As the next step, we need to build a custom BIOS. How to build this BIOS using EDK2 (EFI Development Kit) is shown here. If you want to enable Secure Boot, look at the Secure Boot section at the end.

Once the BIOS has been built, create the following directory structure (the following assumes the current directory is empty and is where the machine should be run:

$ mkdir -p bios
$ cd bios
$ ln -sf ${EDK2_HOME}/Build/OvmfX64/${TOOL_CHAIN}/FV/OVMF.fd bios.bin
$ cd ..
$ mkdir hda
$ cp ${EDK2_HOME}/Build/MdeModule/${TOOL_CHAIN}/X64/HelloWorld.efi hda
$ qemu-system-x86_64 -L bios -hda fat:hda -m 1024

Command line options explained:

-L bios
Sets the directory where the BIOS is located. When the machine starts up, it will complain about a missing vgabios-cirrus.bin and pxe-rtl8139.rom. They don’t seem to be necessary with newer versions of EDK. For older versions, link vgabios-cirrus.bin to ${EDK2_HOME}/Build/OvmfX64/${TOOL_CHAIN}/FV/OvmfVideo.rom.fd. If you are perfectly unhappy, locate the two files in the standard QEMU distribution (locate vgabios-cirrus.bin) and link it from there.
-hda fat:hda
Instructs qemu to use the directory hda as hard drive. QEMU wil lbuild a virtual hard disk composed from the files in hda. This drive is read-only, making it read-write would most likely be more complex than beneficial.
-m 1024
allocate 1024MB for the virtual machine.

For more details, please refer to the manual pages.

If everything was built successfully, the machine should boot into its built-in EFI shell. Now you can execute HelloWorld.efi and it should display Hello World. Unless you need Secure Boot, you are done.

Enabling Secure Boot

If you have built the UEFI BIOS with Secure Boot enabled, start up a virtual machine as above, and exit the UEFI shell by typing EXIT. Now you should be in the BIOS menu. Select Device Manager and you should come to a screen that offers the menu option “Secure Boot Configuration”.

We need to configure several keys:

  • Platform Key (PK): Establishes a trust relationship between the platform owner and the platform firmware.
  • Key Exchange Key(s) (KEK)

For an explanation of those, please have a look at the UEFI specification.

Update (December 2014)

If you want to compile the Secure Boot enabled UEFI BIOS for Ubuntu 14.04, you should use GCC48 for the tool chain tag in the Conf/target.txt file.

Additionally, in order to invoke the virtual machine, you should also include the -bios command line option, which sets the filename for the BIOS, like so:

$ qemu-system-x86_64 -L bios -bios bios/bios.bin -hda fat:hda -m 1024

References

Posted in Technology | Tagged , , | 2 Comments

NVIDIA Driver Installation on Fedora

The following instructions guide you through the installation of NVIDIA’s graphics drivers on Fedora Linux. At the time of this writing, the latest driver version was 310.32. Should be needless to say, but all information provided comes with no warranty whatsoever. Instructions for other version or system configurations may differ.

As first step, go to the NVIDIA web site and download the NVIDIA binary drivers for your graphics card. The drivers are available at http://www.geforce.com/drivers. The driver package comes as a self-extracting setup binary. After downloading, ensure it is executable:

$ sudo chmod 755 NVIDIA-Linux-x86_64-310.32

Most likely you need to install gcc for the NVIDIA drivers. gcc is necessary to compile a small stub so that the drivers can be loaded by your current Linux kernel. Do not worry, once you have gcc, the driver installation takes care of the rest. If you are lucky you may be able to proceed without installing gcc and return later if installation fails.

$ sudo yum install gcc

Next, ensure that you are running the latest version of the Linux kernel. Issue the following command inside a terminal window.

$ sudo yum update kernel\* selinux-policy\*

Once you have downloaded the latest kernel, you want to restart your system to ensure it is running.

Chances are your current setup is usinf the nouveau graphics drivers. The easiest way to check is by invoking the NVIDIA setup. Only downside, this setup needs to be invoked without the X server running (i.e., best from the console). Swith to a console (Ctrl-Alt-F2), login and switch to a runlevel without X by issuing (remember if you restart your system and want to run the NVIDIA setup again, you need to repeat these steps):

$ sudo init 3

You may have to login again, switch again to the directory where you downloaded the NVIDIA drivers to and issue:

$ sudo ./NVIDIA-Linux-x86_64-310.32.run

If the setup tells you that you are using the nouveau drivers, confirm you want to deactivate them. However, Fedora already enables them as part of the initial ramdisk, and hence they need to be deactivated when the system starts. There are two options to accomplish this.

  1. Manually at each startup- When your system starts, at the grub prompt, select the kernel you want to use and type e to change the boot settings for this kernel. Scroll to the line containing the kernel command line options (starting with linux /vmlinuz-…) and append the following entry. This has to be repeated whenever your system boots, even after the NVIDIA drivers have been installed.
    rdblacklist=nouveau
  2. Permanently disable the nouveau driver. Edit your grub configuration file (/boot/grub2/grub.cfg) locate the entry starting your kernel and add the same kernel command line option as above.

Start the installation of the drivers:

$ sudo ./NVIDIA-Linux-x86_64-310.32.run

If the above fails due to missing kernel sources, you need to install the kernel-devel package by issuing (most likely, one could include them upfront in the above yum update command – haven’t checked):

$ sudo yum install kernel-devel

If the above fails, you need to fix the setup scrip of the NVIDIA drivers (this happened to me the first time, I think I had a different kernel running, the second time I ran through my HOWTO this wasn’t necessary). Unpack them as indicated below.

$ sudo ./NVIDIA-Linux-x86_64-310.32.run -x
$ sudo vi NVIDIA-Linux-x86_64-310.32/kernel/conftest.sh

Now change lines 1705ff as indicated below.

#                if [ -n "$PATCHLEVEL" -a $PATCHLEVEL -ge 6 \
#                        -a -n "$SUBLEVEL" -a $SUBLEVEL -le 5 ]; then
                    SELECTED_MAKEFILE=Makefile.kbuild
                    RET=0
#                fi

Now, change into the NVIDIA-Linux-x86_64-310.32 directory and invoke the extracted installer as follows:

$ sudo ./nvidia-installer

Now everything should be installed and once you restart your system for a very last time (don’t forget to disable the nouveau drivers if you have chosen option one above), you should be using the NVIDIA drivers.

Now you can enjoy the NVIDIA drivers.

Posted in Linux, Technology | Tagged , | Leave a comment