On Monday, my ThinkPad X230 arrived. One of my goals for the system is to run OpenBSD with an encrypted root filesystem. Fortunately, the support exists in softraid(4) but it wasn't immediately clear how to accomplish this and allow the system to boot properly. Through a bit of trial and error, I figured it out and it works very well.
I have used OpenBSD for almost 15 years now and have always enjoyed its simplicity, security, and robust feature set. I have also been a Mac user for even longer. Due to my work, I can't switch to OpenBSD entirely on the desktop but I can use it for much of what I do.
I came across a few different articles on the subject of encrypted softraid(4) for the root filesystem but all seemed to cover aspects that didn't entirely fit my goals. One softraid article has much of the information needed but does not encrypt the entire system, only one filesystem.
In my own personal, non-server systems, I rarely separate out all of the different directores into their own filesystems like /var, /usr, /home, etc. On my ThinkPad X230, this is further compounded by the fact that I am using a relatively small SLC SSD which means I really don't want to limit my options with unnecessary filesystem complexity.
My goal is simple. I want the entire root filesystem which encompasses everything on this system to be encrypted with softraid(4). I will have a very small swap partition on the SSD since swap is always encrypted in OpenBSD anyway.
Warning: I should also note that the process of creating an encrypted softraid(4) partition on your drive will destroy whatever data you have on there already so make sure you backup everything before starting this process in a way that you are prepared to restore from. Even better, buy a new SSD and start from scratch.
Choosing the SSD
In a future article, I will cover what configuration of ThinkPad X230 I purchased but for now I will just mention storage. Rather than pick the ridiculously overpriced storage available direct from Lenovo for the X230, I simply purchased the system with the cheapest storage available which was a 320GB 7200RPM 2.5-inch laptop drive. It wasn't spelled out clearly during the configuration stage but this is a 7mm 2.5-inch drive, not the typical 9.5mm 2.5-inch hard drive form factor that we have become accustomed to for laptops. This doesn't bother me at all since HGST and Seagate both make plenty of 7mm options now and SSDs are also readily available in the 7mm form factor.
The particular drive my X230 shipped with is a Seagate Momentus Thin 320GB 7200RPM 2.5-inch drive. As I have done with all my non-Apple system for a number of years, I had no intention of using the original drive at all and so without even booting up the system, I removed the 320GB drive and set about installing another storage device. As I've covered extensively in past articles on SSDs, I use SSDs exclusively for my main systems and only use actual hard drives for bulk media storage, backups, and server arrays.
SandForce is Out
When choosing an SSD for software encryption, a number of parameters change in how you should pick the best SSD for your system. First off, any SSD that uses a controller that does compression in order to achieve its performance is out of the question. This is because any software encryption solution causes the data written to disk to be essentially random in nature and completely unable to take advantage of any compression.
The major SSDs on the market using compression are using the LSI SandForce line of controllers. The list includes many of the popular SSDs and one of my favorites that I highly recommend, the Intel 520 SSD series. While I still use and recommend the Intel 520 SSD series as my laptop, desktop and workstation top choice, they are a poor choice for software encryption.
mSATA and 7mm 2.5-inch SSDs
There are a number of other good choices on the market now but one particular consideration stood out in my mind for this system. The ThinkPad X230 features a single 7mm 2.5-inch hard drive or SSD bay but also has a mini PCIe slot that also accepts mSATA SSDs. In some configurations, the mini PCIe slot is taken up by a 3G or 4G WWAN card such as the Gobi 3000 or Gobi 4000. For this system I elected against a built-in card for now until I have some time to test OpenBSD 4G LTE support.
My plan for the X230 has been to have two different SSDs installed, one in the 2.5-inch bay and another in the mSATA slot. One of the two would house an Arch, Gentoo, or Ubuntu install and the other SSD would contain my OpenBSD install. The 7mm restriction changed my plans somewhat and so far I am only using OpenBSD on my X230.
Since software encryption can be even more write-intensive than typical SSD use and cannot take advantage of compression to minimize write amplification I decided to look for an SLC SSD. The benefits of SLC over MLC flash have been extensively covered by many articles but for the sake of simplicity the major benefits of SLC are exponentially higher write endurance, lower power consumption, and increased speed in similar configurations. The final benefit has been reduced by more and more advanced controller configurations that have allowed MLC to meet or exceed the typical performance of SLC-based SSDs.
I started looking around at my mSATA SSD options and SLC options in general and only one contender emerged as my best choice. Intel has consistently made excellent and very stable SSDs since the beginning of readily available SSDs in the retail market. I have been extremely happy with the Intel 520 SSD series so it was only natural to start looking at the Intel 313 SSD series.
Intel 313 SSD Series
The 313 series is the successor to the 311 series and is designed as a cache SSD for the Intel Rapid Start Technology present in some Sandy Bridge and Ivy Bridge motherboard chipsets. As such, the 313 series uses SLC flash memory since any type of cache drive will see extensive writes. As expected, the 313 series offers relatively small capacities. Only two Intel 313 SSD capacities are available. The first is a 20GB model and the second is a 24GB model. Both capacities are available in both a 7mm 2.5-inch and an mSATA form factor.
This makes for a total of four different configurations available in the Intel 313 SSD series. Since I would prefer to have as much capacity as possible while still using SLC flash memory, I elected to purchase the 24GB mSATA model which, while not particularly large, is quite adequate for my OpenBSD use.
Installing any mSATA SSD in the X230 is a challenge but proved to be quite interesting and enjoyable. I will not cover the details in this article but I am glad to have it installed and will likely not touch it again. One major caveat is that nearly all mSATA slots are SATA 3Gb/s and not 6Gb/s. This means that the Intel 313 SSD's limitation of SATA 3Gb/s is really not a limitation at all.
The softraid(4) Install
In order to do your softraid(4) crypto install, the first step is to boot into the OpenBSD installer with bsd.rd and select the Shell option. Once in the shell, you need to create the softraid volume but first you need create some additional devices. I should make note that all of this is on OpenBSD/amd64 5.2-current. In the shell, run the following commands assuming your SSD shows up as sd0:
# cd /dev
# sh MAKEDEV sd1
# sh MAKEDEV sd2Now that you have some additional sd devices, it is time to create partition your SSD for maximum efficiency. In order to boot from any softraid(4) partition other than a RAID 1 on OpenBSD/amd64 5.2 or later, you need a small a partition to hold your kernels. Here are the needed steps to prepare your SSD.
# fdisk -iy sd0
This command initializes your MBR with an OpenBSD primary partition in preparation for disklabel(8). The next step allows you to create the needed partitions for OpenBSD.
# disklabel -E sd0
At this point using the built-in editor for disklabel(8), you should be able to add several partitions. The first, a, should be large enough to hold the three kernels typically used for any system, bsd, bsd.mp, and bsd.rd. I use 64M for the size of the a partition which ended up being rounded to about 70MB. I added a swap partition of about 32MB and then dedicated the rest of the SSD to the RAID parition. Here are the partitions for my SSD as viewed from disklabel(8):
# size offset fstype [fsize bsize cpg]
a: 144512 64 4.2BSD 2048 16384 1
b: 64257 144576 swap # none
c: 46905264 0 unused
d: 46684902 208833 RAID In order to have a softraid(4) crypto root filesystem work at bootup, you must use a keydisk. Unfortunately, there is no way to assemble the softraid volume by prompting for a password. To this end, I used an SDHC card I had lying around. It happened to be a 4GB Lexar Professional SDHC card but any card will do. I added a very small (1MB is fine) partition to it using disklabel(8). I used the rest of the SDHC card for an a partition. In this case, I used the d partition for the keydisk and created it at the beginning of the SDHC card. Here is the output of disklabel(8) for sd1, the device name of my SDHC card.
# size offset fstype [fsize bsize cpg]
a: 8032448 16096 4.2BSD 2048 16384 1
c: 8057856 0 unused
d: 16001 64 RAID Now that I have both a prepared SSD and a prepared keydisk, it is time to format the a parition on the SSD for the kernel, and create the softraid volume which will utilize the keydisk.
# newfs /dev/rsd0a
# bioctl -c C -l /dev/sd0d -k /dev/sd1d softraid0You should now see output on the screen something like this for your new SR CRYPTO volume.
sd2 at scsibus3 targ 1 lun 0: <OPENBSD, SR CRYPTO, 005> SCSI2 0/direct fixed
sd2: 22795MB, 512 bytes/sector, 46684374 sectorsAt this point you can also format the a volume of your SDHC card but you can always do that later. The next step is to continue with the OpenBSD installer.
# cd /
# installProceed through the whole process but use sd2, or whatever your SR CRYPTO volume shows up as, as the root disk. In my case, I only created an a partition on sd2 that encompasses the entire SR CRYPTO volume since I already have a small swap partition on the SSD itself. Once the install is completed, you have two final steps.
# mount /dev/sd0a /mnt2
# cp /mnt/bsd* /mnt2/
# /mnt/usr/mdec/installboot -v /mnt/boot /mnt/usr/mdec/biosboot sd2The installboot(8) command will generate output similar to the following:
boot: /boot proto: /usr/mdec/biosboot device: /dev/rsd2c
sd2: softraid volume with 2 disk(s)
sd2: installing boot loader on softraid volume
/boot is 3 blocks x 16384 bytes
sd0d: installing boot blocks on /dev/rsd0c, part offset 208913
master boot record (MBR) at sector 0
partition 3: type 0xA6 offset 64 size 46893671
/boot will be written at sector 64
sd2d: installing boot blocks on /dev/rsd2c, part offset 80
master boot record (MBR) at sector 0With those steps completed, your softraid(4) crypto install is done and you should be able to boot from your system as long as the keydisk is available. Remember that if you somehow do not have your keydisk, you cannot access your data. It is a good idea to backup your keydisk if possible as mentioned in an older OpenBSD Journal article. In my case I only backed up sd1d and not sd1c like the article suggested.
Final Thoughts
The whole process went rather smoothly once I discovered that a keydisk is required for a bootable softraid(4) crypto root filesystem. Normally, you would have to assemble the softraid volume which then asks for your password by just running the following after booting up your system:
# bioctl -c C -l /dev/sd0d softraid0
The keydisk is what makes all the difference for allowing a bootable encrypted root setup. My attempts without a keydisk always ended in a kernel panic. So far performance seems excellent although I haven't done any major testing. For my needs the system is extremely responsive and everything is encrypted.
I would recommend that you use the softdep and noatime flags in your fstab for your filesystem since softdep will increase your filesystem's performance and noatime will cut down on unnecessary writes to your SSD. For details of both options and how to use them, read the fstab(5) and mount(8) man pages.
I would caution anyone considering this type of setup to only use it with a machine where the processor supports AES-NI or your processor will have to work very, very hard to do the encryption on the fly. Any recent Core i5 or Core i7 does support AES-NI as do Xeon E3 chips and a few others as well. Celeron, Pentium, and Core i3 chips do not have support for AES-NI as an almost universal rule.
I am enjoying my ThinkPad X230 with OpenBSD so much that I will likely just keep it an OpenBSD-only system instead of the dual-SSD OpenBSD and Ubuntu system that I had originally planned.
Update: tedu@, one of the OpenBSD developers, provided some additional insight in a comment on Lobste.rs. He pointed out that for file sizes less than around 1GB, AES-NI hardware acceleration makes little difference. Essentially, normal desktop tasks without large file copies will not benefit very much from AES-NI. He also pointed out that the buffer cache is not encrypted so frequently used programs do not have to be decrypted each time they are used.