by Joshua Branson — March 30, 2023
So I previously talked about my interest in OpenBSD. Well last week, I have been more and more impressed with OpenBSD, especially after watching Theo’s recent talk. I recently installed OpenBSD on my desktop, and I was satisfied. There are some things that I knew how to do on GNU Guix that I do not yet know how to do on OpenBSD. For example, there is a minor issue with the sound being a bit wonky but that is not a deal breaker.
A few days ago I switched to OpenBSD on my laptop. So now, with the exception of my PinePhone, all of my computing devices are using OpenBSD. The OpenBSD installer is getting support for autoencrypting your hard drive, but I wanted to document the manual set up process if I ever decide to set up a RAID+ecryption. I do not believe the installer will support RAID+encryption anytime soon.
The real problem was trying to get libreboot to even recognize the OpenBSD usb installer stick. The best method to boot OpenBSD on libreboot is to use the seaBIOS payload. I could NOT get this to work. I must have booted and rebooted 10+ times trying to get this to work. I even opened up a grub command line prompt, and it could not SEE the usb stick. Others have reported this problem.
In grub you can get a feel for what partitions are available via:
grub> ls
(hd0) (hd0,msdos1)
This seems to only show my GNU/Linux Guix System partition. That’s not a good
sign. There is another way to check. I can type out the following
set root=(hd0,msdos1)/
and then press TAB:
I was able to see /bin
, /boot
, /etc
, etc. Going into /var
, I saw
guix/
. So clearly hd0
is my current SSD that has GNU/Linux Guix System. And
grub and libreboot did NOT see the OpenBSD usb stick. I kept rebooting, tried
searching for the OpenBSD stick, and finally the grub console showed me
something other than (hd0,msdos1)
. I think I have to use the right-most usb
port. I think that is the secret.
Technically, grub can boot OpenBSD, at least grub as packaged by Libreboot, but that is NOT advisable. And grub's ability to boot OpenBSD may disappear at any moment. Seeing no other option, I typed in this command to boot OpenBSD via grub:
grub> kopenbsd (usb0)/7.2/amd64/bsd.rd
grub> boot
And OpenBSD started booting! Woo hoo! At the OpenBSD installer I typed in “s” to exit to the shell so that I could set up full disc encryption.
Before we get to the disc encryption, let me give a quick overview of how OpenBSD sets up partitions. OpenBSD supports both MBR and GPT partitions, which divide the physical disc into sections (MBR is old; GPT is the modern way to do it, and most people will want GPT on newer machines so for the rest of this blog post I will just talk about GPT). All operating systems recognize and use GPT partitions. Linux will install its filesystem partitions into seperate GPT partitions, which means that a "partition" in Linux means the GPT partition and the filesystem partion. Here's a handy graphic:
|--------------+------------+----------------|
| | Linux | |
|--------------+------------+----------------|
| GPT partiton | filesystem | mount location |
| | partition | |
|--------------+------------+----------------|
| /dev/sda1 | ext4 | / |
| /dev/sda2 | btrfs | /etc |
| /dev/sda3 | xfs | /boot |
| ... | ... | ... |
| /dev/sda128 | vfat | /boot/efi |
| | | |
| /dev/sdb1 | ext4 | /data |
|--------------+------------+----------------|
OpenBSD is a little different. It uses one big GPT partition, and then it
further splits up that one big GPT partition into filesystem partitions, which
can be examined via disklabel. So in
OpenBSD sd0
and sd1
refer to the first and second hard drive. /dev/sd0c
refers to the one big GPT partition and /dev/sd0a
by convention is the /
partition. /dev/sd0b
is swap by convention and d
through p
could refor to
any other arbitrary mount point. So "partition" in OpenBSD may refer to the GPT
partion or the filesystem partitions.
|--------------+-------------+----------------|
| | OpenBSD | |
|--------------+-------------+----------------|
| GPT partiton | filesystem | mount location |
| | partition | |
| | (FFS) | |
|--------------+-------------+----------------|
| /dev/sd01 | /dev/sd0a | / |
| /dev/sd01 | /dev/sd0b | swap |
| /dev/sd01 | /dev/sd0c | not mounted |
| /dev/sd01 | /dev/sd0d | /home |
| | ... | |
| /dev/sd01 | /dev/sd0e | /tmp |
| | | |
| /dev/sd11 | /dev/sd1i | /data |
|--------------+-------------+----------------|
I would highly recommend the OpenBSD faq page about this (as well as the disklabel man page), which will also act as a more official version of this blog post. Now on with the blog post!
Let’s figure out which drive is my usb stick, and which drive is my SSD with Guix on it. Please note that I did not write the output of this command down. Your output might look different.
sysctl hw.disknames
hw.disknames=sd0:ec557d42f5cbfa41,sd1:
I typed in the next two commands to try to get a feel for which drive was my SSD.
doas disklabel sd0
doas disklabel sd1
I forget what the above commands output-ed, but looking at the output I was able
to determine that sd0
was my GNU/Linux Guix System. Now it was time to set up a
full disc encryption.
cd /dev && sh MAKEDEV sd0
dd if=/dev/urandom of=/dev/rsd0c bs=1m
That second command took 8+ hours to complete. It wrote random data on the whole SSD. That way, if an attacker ever stole my hard drive, when they examined my hard drive, they would not see:
00000000EncryptedData0000000EncryptedData000000
Instead they would see
RandomDataRandomDataRandomDataRandomDataRandomDataRandomData
where only the 2nd and 5th =RandomData= are actually my encrypted files. Trying
to figure what is data and what is just random ones and zeros would be really
hard. However, I should probably ask on #openbsd
irc to make sure that I
wrote the right command. Is there a way to search your raw hard drive for a
section of disc that is just 10,000 zeros?
Anway, let’s partition the sd0
drive and format it as a RAID. Random encrypted
data will go to sd0
. OpenBSD will read files from the unencrypted sd1
,
which will be encrypted and stored on sd0
.
fdisk -iy sd0
sd0> *a* *a*
sd0>size: [ ... ] ***
sd0> FS type: *RAID*
sd0> *w*
sd0> *q*
This next command will ask you for a passphrase. If you use an alternative keyboard layout, then make your command use numbers and special characters on the 1-9 section. That way you can still type in the secret password on boot, because OpenBSD changes your keyboard layout after you unlock your encrypted volumes.
bioctl -c C -l sd0a softraid0
Now let’s set up sd1
.
cd /dev && sh MAKEDEV sd1
dd if=/dev/zero of=/dev/rsd1c bs=1m count=1
exit
This will return us to the main installer. When the installer asks you which
hard drive to install OpenBSD on, I said sd1
.
[...]
Available disks are: sd0 sd1.
Which disk is the root disk? ('?' for details) [sd0] *sd1*
And that was that! I did a few things to set up XFCE
, which I quickly
abandoned in favor of i3, and I was off to the races. Then I realized that my
full-disk decryption passphrase was pretty weak. Basically, because I use a
physical dvorak keyboard
layout, and OpenBSD uses
the standard qwerty layout when you type
in the password to decrypt the disk, my initial full disk encryption password
was just numbers. Now, I wanted to change it to my normal password.
Apparently you can do so while the encrypted volume is mounted! I made sure that I changed the keyboard layout to the standard qwerty, when I typed in the new passphase.
doas bioctl -P sd1 # I was using the dvorak layout here
In another terminal I typed in:
setxkbmap -layout us
Then I moved to the terminal that was asking me to change the full disk encryption password.
Old Passphrase: # I typed in the numbers
New Passphrase: # I typed in an awesome password
Confirm Passphrase: # I typed it in again.
Now let's get back to dvorak:
setxkbmap -layout dvorak
That's better. I did have a great time the next day. I was hoping to
automatically automount my usb stick on boot. So I added this beauty to my
/etc/fstab
.
sd2i /mnt/usb msdos rw 1 2
The next time I booted it threw me into a rescue shell with only /
mounted.
That was a wild ride to fix, bit I will explain how I fixed that next time!