Installing OpenBSD 6.9 on a laptop

Lately, I've been looking into some old laptops which I could spend my upcoming college years with. I wanted something cheap, but also good enough that I could use it for basic university related work. Of couse I could just buy a new low-end Windows laptop and be happy, but that would be a waste of money. Instead, I searched through used market for an old ThinkPad, T500 in particular. If you are a bit confused or haven't heard of Lenovo's ThinkPads and why they have a special place among many, I recommend you check out this guide. There are many newer models than the 2009's T500, however T500 seems to be the last "Librebootable" 15" ThinkPad. Flashing Libreboot is something I would love to do as well, but currently don't have the right tools to complete the process documented on the Libreboot wiki here. After T500 there are still a couple of pretty decent ThinkPad models, altough it is not possible to install completely Libre firmware on them.

Downloading OpenBSD

Downloading OpenBSD is pretty straightforward, just prepare two USB drives – one which we will boot the installer from and the other for our encryption key.

Head over to the download page and click on minirootXX.img

If you have a 64-bit machine, which the T500 is, select amd64. This will be a minimal intallation and we will only download file sets that we want during the install. If you do not care about this, you can pick one with the file sets already included.

For those unfortunate people who still use Windows on their main machine like me, you may use utility like Rufus to burn the image to a USB. Just pick the file and drive, make sure to choose the right one, this will overwrite all data on the USB drive.

Once we have the USB ready, we can plug it into the T500, press F12 and choose to boot from it. We will be greeted by this screen:

[obrazek 

instalacky na zacatku]

 

Installing OpenBSD

Full disk encryption with key (FDE)

I'm using a laptop, so it would be advisable to implement some sort of encryption in case it gets lost or someone steals it. We will follow the official guide here (with a little modification) and setup FDE with a USB drive for convenience, so that we don't have to type the encryption password every time and instead rely on the possesion of the USB drive.

Jump out of the installer into the shell by typing S

Begin the proces by creating a device node. You may be familiar with the naming convetion from Linux. sd is essentially SCSI disk driver.

# cd /dev && sh MAKEDEV sd0

We may also want to write some random data to the device, this is a fairly time consuming process, so get some coffee and do some work while it does it's thing. The bigger the drive, the longer this will take. The computer's speed also plays a big role. Wait, what is rsd0c? Haven't we just typed in sd0? Why are we writing something to rsd0c? I had the same questions, but the explanation if quite simple. R in the beginning stands for raw, as it is a raw (character) device. sd0 was already explained above (first SCSI driver device), but why c at the end? According to disklabel(5) "The ‘c’ partition is reserved for the entire physical disk". So there we have it, rsd0c points to the whole raw first hdd handled by the SCSI driver, to which we are currently writing random data.

# dd if=/dev/urandom of=/dev/rsd0c bs=1m

Since we have a crap load of time before it finishes, let's dissect the command a little further. dd is a well known utility from the world of Linux and other UNIX-like operating systems. It can be used to copy standard input (stdin) to standard output (stdout). These two aforementioned terms usually mean "what you type" and "what you get" to/from the terminal. In this case we are using the if and of options of dd which replace stdin and stdout with files. Basically copying the contents of /dev/urandom to /dev/rsd0c. As you can tell by the fact that urandom resides in /dev, it is some kind of a device, but not a physical one. Together with random, urandom is a data source device which provides high quality pseudo-random data. Why is it called pseudo-random? Well, computers can't actually produce truly random data (but they can use realisitcally random sources), instead, the kernel utilizes all sorts of different things that are happeing at any given moment (system activity, network, hadware output) and through some programming and math trickery output seemingly random data. It is important to make sure that the same data cannot be generated again, because that could lead to security issues, since actions like generating SSH key pairs use these pseudo-random data sources. (Imagine you generate an SSH key pair and someone finds a way to get the same pseudo-random output that you got, which will result in the same SSH key pair being generated, even though I'm sure there are reasons why this isn't realistically possible). The last option bs specifies the block size (how large the blocks of data will be)

As far as I know, the T500 doesn't support UEFI, so we'll have to use MBR partitioning table. Use fdisk to initialize MBR.

• -i uses default MBR
and
• -y avoids unnecessary yes/no questions.

# fdisk -iy sd0

If you have an UEFI device, use this command:

# fdisk -iy -g -b 960 sd0

To create a partition layout, we need to enter disklabel's label editor with the -E option and name of the device we want to edit.

# disklabel -E sd0

In the Label editor, enter the following commands (// respresent comments, don't type that into the terminal)

#sd0> a a // "a" to add partition and name it "a"
offset: [64] // press enter
size: [488391056] * // "*" and enter
FS type: [4.2BSD] RAID // default is 4.2BSD, but we want to create RAID volume
sd0*> w // write changes to the disk
sd0> q // quit the editor
No label changes.

Let's stop for a moment and let me explain the naming and structure. The device that we are now working with is sd0. We have just created an a parition on sd0, which resulted in sd0a RAID type filesystem that spans across the entire disk. Now we will use RAID management interface called bioctl to create a CRYPTO volume on sd0a. This encrypted volume will appear as another device, but it's just an encryption layer on the same physical device. Afterwards we can create volumes and file systems how we want, just like with a regular OpenBSD install without encryption.

If you are using a regular passphrase, the new encrypted device will become sd1. However, since we want a keydrive, we have to account for the other USB drive. Connect the USB that you want to use to unlock your laptop/PC and note the assigned name. In my case, it got recognized as sd2. This is important, becuase now our encrypted volume won't be sd1, but sd3.

Assume the key drive is sd2 and our initial parition is still sd0.

• -c sets the RAID level, but we just want an encryption layer, so we will use "C" which stands for CRYPTO
• -k use key disk device sd2a
• -l create volume on sd0a with software raid

This part took me a long time, because I got stuck on the -r option which specifies number of iterations for the KDF algorithm. What got me thinking was this article, which goes in depth into the encryption of OpenBSD. What confused me the most is that according to the bioctl man page, the default number of rounds is 16, however the author of the article mentions "The interesting part is the number of iterations which directly impact the resistance to brute force attacks. On OpenBSD, it is set to the hard-coded value of 8192. As discussed previously, this may be changed using bioctl options." If we are talking about the same thing, why the man page mentions 16 and he says 8192? Also "On my home install, my LUKS volume is configured for about 400,000 iterations, which is significantly higher than the OpenBSD default.". His closing thoughts are "If using OpenBSD on a recent computer, bump up the number of PBKDF2 iterations when creating the volume." What does bump up mean in this case? More than 10 000? 100 000? Anyway, take what you want from this, I will try 50 000 and see what happens.

# bioctl -c C -r 50000 -k sd2a -l sd0a softraid0

Well, this happened.

bioctl: could not open sd2a: No such file or directory

Of course, we don't have any sd2x devices in /dev, which we can confirm by ls /dev/. Correct that by issuing

cd /dev
sh MAKEDEV sd2

Aaaand, again we fail because:

bioctl: could not open sd2a: Device not configured

Sure, even though our key drive showed up as sd2, we haven't touched it with fdisk like we did with our sd0. If I could read, I would know since the guide clearly mentions it "Initialize your keydisk with fdisk(8), then use disklabel(8) to create a 1 MB RAID partition for the key data"

I grouped all the commands we need into the following block:

# dd if=/dev/urandom of=/dev/rsd2c bs=1m // rsd2c - our raw sd2 key drive
# fdisk -iy sd2
# disklabel -E sd2
sd2> a a // create "a" partition
offset: [64] // accept default with enter
size: [7984241] 1M // we only need a small 1M partition
FS type: [4.2BSD] RAID // again, create RAID type partition

// we can confirm that everything is ok
> p
#      size  offset  fstype [fsize bsize   cpg]
a:    16001      64    RAID
c:  7987200       0  unused

sd2*> w // write changes
sd2*> q // quit

Now we can run bioctl again

# bioctl -c C -r 50000 -k sd2a -l sd0a softraid0

You should see similar output:

Please note the volume which was created, in this case sd3, you will need it later!

This is everything we had to do in order to setup encryption. What follows is only the installation process described bellow.

Installation script

Type I to begin the installer

You can pick a different keyboard layout, but I will stick with the default one

Pick a hostname that you like

We are using a minimal image file, therefore we will need internet connection to download all required file sets, so it makes sense to configure network interface. I will just connect cable to the on board LAN (em0) and let DHCP give it lease. Unless you want to configure IPv6 stick to default none

This isn't going to be a server, so type no to SSH

I personally had some troubles with xenodm, but they mostly came down to me being incopetent. Using xenodm is a recommended security practice, instead of starting with startx. Not entirely sure why it's not default

Setup a user, name of the user

Timezone

Now make sure you install into the right volume

MBR

OpenBSD partitioning is something we will leave for another time. This time I'm going with the default which is surprisingly sane.