Musings from kb8ojh.net

I just upgraded my Dell XPS 13 Developer Edition (AKA “Sputnik 3”) to Ubuntu 14.04, the newest LTS release, in order to hopefully clear up some remaining glitches and source some newer software more easily. So far it seems to have been a mostly painless process, although there were a few hiccoughs getting encrypted disks working to my liking. This is how it went.

mount /dev/mapper/root /mnt
mount /dev/mapper/home /mnt/home
mount /dev/sda1 /mnt/boot
for dir in /proc /sys /run /dev; do
    mount -o bind $dir /mnt/$dir
done

# fstab
/dev/mapper/root / ext4 errors=remount-ro,relatime 0 1
/dev/mapper/home /home ext4 relatime 0 2
/dev/mapper/cswap0 none swap sw 0 0

# crypttab
root /dev/vg0/root-crypt none luks,discard
home /dev/vg0/home-crypt none luks,discard
cswap0 /dev/sda2 none luks

update-initramfs -k all -u
update-grub

I've been using the Dell XPS 13 Developer Edition (AKA “Sputnik 3”) for about a week now, and it's time for a follow-up to my first impressions review. All in all, I think I hit on most of the critical points in that first review, but there are a few things worth clarifying or reiterating, and some new experiences to relate. That's what this post is.

This is basically a guide for setting up a LUKS-encrypted home directory on LVM in Ubuntu 12.04, with the added wrinkle of working around the Dell installer setup bugs detailed in a previous post. Most of these instructions should work on other Ubuntu systems — you just probably don't have to do it this way, because you can set up LVM and LUKS at install time in the Ubuntu installer. Or so I suppose, I haven't actually done it.

This procedure makes a number of implicit assumptions. I'm going to make them more explicit here, so that you can decide if it's appropriate for your use:

• My primary concern is protecting my data from loss/theft and prying eyes, not complete secrecy. In particular, this has implications on the configuration of LUKS and trim, and prepping the partition for storage. If you have greater privacy needs, there are other tutorials with information on how to mitigate some of the shortcomings here.
• I am assuming that all important information that is privacy-sensitive is stored under /home. In particular, I am not (as yet) encrypting /tmp or any of the system directories. This assumption is true to a first approximation for the system on which I am installing it. Your needs may differ.
• Hibernate is a desired feature for me. Since the keys for encrypted partitions are stored in memory, and thus flushed to disk at hibernation time, this necessitates encrypted swap. Encrypted swap is a good idea anyway, since some of my precious data might be in RAM, but failing to use encrypted swap with hibernate essentially provides a direct path to decrypting your entire disk.
• I am willing to wipe the entire machine to set this up. I just got this laptop a couple of days ago, and I have good backups already. If your situation is different, you might want to take a more staged approach, resize partitions, etc. That task may be easier or harder, depending on your existing configuration and how you go about it.

Repartitioning the disk and installing the system

I used the Dell recovery image, written to a USB flash drive, to repartition the disk. Hop through the prompts and tell it that you want to install only the Linux OS, that you want to do a fresh install, and that you want to set up the disks manually. I don't recall the exact prompt wordings, but if you're prepared to follow this guide you really shouldn't need them. If you get too confused at this point, abort — it doesn't get clearer from here on out.

Create three primary partitions. The first should be as large as you expect the system to be (I used 40 GB, which should provide about 20 GB of overhead). It's not going to be easy to expand this later, so be suitably generous. You can always store non-sensitive data there if you need to. The size of the second depends on the size of the third, which will be swap; it should be the remaining disk space minus about twice as much space as you have RAM. My XPS13 has 8 GB of RAM, so I used 16 GB of swap. Note that the recovery installer stupidly uses 1,000,000 byte megabytes, so you may want to do a little bit of math if you're compulsive like I am. Set this second partition to unused, we're going to format it later. The third partition is swap. Use the disk space you set aside in creating the previous partition, and mark it as swap. It won't be encrypted for now, but that's OK.

Let the installer do its thing. When it gets all done and wants to restart, though, don't restart just yet. As I discuss in my previous post, the Dell installer is buggy and doesn't flag the boot partition as bootable. Therefore, just before the reboot, hit Ctrl-Alt-F1 and run sudo fdisk /dev/sda. If you partitioned the same as I described above, your boot partition is /dev/sda1, so hit a to toggle the bootable flag, and select 1 to select the first partition. If you partitioned differently, you know what you're doing, so do it here. Press w to write the partition table to disk (it may tell you it couldn't be loaded by the running kernel and will require a reboot, that's fine). Press Ctrl-Alt-F7 to go back to the installer, and hit Reboot.

Installing necessary packages and obtaining a setup environment

At this point, we're going to need some packages not present in the base install, for LUKS and LVM. We're also going to want a setup environment that doesn't use /home. We'll achieve both of these in one step. Don't log in to X11; instead, hit Ctrl-Alt-F1 to get to a virtual console and log in there. Then issue these commands:

    cd /
    exec sudo -H -s
    apt-get install cryptsetup lvm2

This will get you a root shell that isn't using any files under /home and provide the functionality necessary for the rest of the setup. use this terminal (and its root shell) for the remainder of this procedure.

Configuring encrypted swap

The next step is encrypted swap, because we need encrypted hibernate before we set up an encrypted /home. There are instructions for encrypted swap on the Ubuntu community wiki, although I don't quite like how they handle some things. For one, you don't need to enable ecryptfs and muck with the Ubuntu encryption solutions to get started, so don't do that — it just makes headaches. The cryptsetup package installed in the previous section provides everything necessary. The only major difference is that you'll have to create your own /etc/crypttab. You're going to be doing that for /home anyway, so not a big deal.

Note that you can follow these encrypted swap instructions to set up encrypted swap with hibernation without doing basically anything else in this document. Be forewarned that a misstep in the partition setup process will result in lost data, however.

Skip everything in those instructions up through How to Set up Hibernation, and do this instead:

1. Run swapon -s and make note of the disk used by your swap device. If you partitioned as above, it will be /dev/sda3. The following will assume that device.

2. Run:

   swapoff -a
   cryptsetup --verify-passphrase luksFormat --hash=sha256 \
       --cipher=aes-cbc-essiv:sha256 --key-size=256 /dev/sda3
   

   You may or may not want to tweak the cipher options; the recommendation above is what I used, but it does not represent any sort of guarantee on my part that it's suitable for your purposes. You'll be prompted for a passphrase to encrypt the swap partition; this is very important. This passphrase will be used to generate the key used to encrypt your swap partition, so make sure it is good and make sure you can remember it. I recommend using something much longer than your typical login password. If you forget this passphrase, you'll have to set up your swap partition again following these instructions; you also won't be able to resume from hibernation if you hibernate and then can't remember the password. You have been warned.

3. Next, we need to mount that partition and set it up for swapping. Do that as follows:

   cryptsetup luksOpen /dev/sda3 cswap0
   mkswap -f /dev/mapper/cswap0
   

   It is important that you leave that partition mounted, and that we set it up for swapping during this session, so that the initramfs image created later knows what modules to include to mount it on boot. The name cswap0 is somewhat arbitrary, but it is important that it is consistent from here on out.

4. The system then has to be told about the new swap partition, and its encryption configuration. To do that, you're going to edit /etc/crypttab and /etc/fstab as follows. First, open /etc/crypttab and insert the following line, which tells the system that there is an encrypted swap partition on /dev/sda3, that it uses LUKS for configuration, and that the user should be prompted for the passphrase:

   cswap0 /dev/sda3 none luks
   

   Next, remove or comment out the old swap configuration line in /etc/fstab and replace it with this:

   /dev/mapper/cswap0 none swap sw 0 0
   

5. Run swapon -a and make sure your swap initializes correctly. If it doesn't figure out why not now, or you'll be sorry later.

Now that you've set up encrypted swap, follow the remainder of the instructions linked above to fix up the hibernation stuff. Skip generating the initial RAM disk, if you're going to go on to setting up an encrypted home partition, because you're just going to have to do it again later, anyway.

Configuring LVM and LUKS for encrypted /home

This part of the setup can likewise be followed without doing the reinstall or setting up encrypted swap, but as mentioned above it doesn't make a whole lot of sense to set up encrypted partitions and not encrypted swap if you plan to hibernate. If you don't plan to hibernate, you should be OK — but I make no guarantees.

Setting up an LVM disk, volume group, and logical volume is pretty straightforward and well-documented elsewhere, so I will include the commands here but not the rationale or detailed description. Red Hat offers a really fantastic LVM administration guide that should answer almost any questions that come up before the point that we start talking about encryption. So with that said, do this (again, this assumes the partitioning scheme set up earlier in this guide, adjust as necessary or lose data!):

pvcreate /dev/sda2
vgcreate vg0 /dev/sda2
lvcreate -Z n -L 100G -n home-crypt vg0

This should create a 100 GB logical volume called /dev/vg0/home-crypt. Feel free to adjust names and sizes as you wish, but names have to be consistent from here on out. Note that there are mechanisms for resizing LUKS volumes and filesystem sizes, so you can always fix things up later; I used 100 GB to leave room for additional volumes for virtual machines.

Setting up encryption for this volume is substantially similar to setting up encryption for the swap partition, but we don't have to jump through the hibernation hoops.

1. Run:

   cryptsetup --verify-passphrase luksFormat --hash=sha256 \
       --cipher=aes-cbc-essiv:sha256 --key-size=256 /dev/vg0/home-crypt
   

   The same caveats regarding encryption setup for the encrypted swap partition apply here. Please review them if you are not fully aware of the consequences.

2. Attach the encrypted volume and create the filesystem with:

   cryptsetup luksOpen /dev/vg0/home-crypt home
   mkfs.ext4 /dev/mapper/home
   

   You're going to want to leave this attached from here on out, too, so that update-initramfs can do its thing.

3. Update /etc/crypttab and /etc/fstab as follows, correcting for any differences in naming you may have chosen:

   /etc/crypttab:
   home /dev/vg0/home-crypt none luks,discard
   
   /etc/fstab:
   /dev/mapper/home /home ext4 relatime 0 1
   

   Note the discard option in the LUKS configuration above; this enables TRIM support and has security and privacy implications. In particular, it reveals which portions of the disk your filesystem is using. It may make certain forms of cryptanalysis easier, and will almost certainly leak information about how much data you are storing on the encrypted partition. I believe the tradeoffs are appropriate for my particular usage scenario, but you should understand the considerations before enabling it. Note that if you do not enable it, you may also need or want to take other steps not included in this document. There are various resources on the Internet discussing these tradeoffs, and I suggest you consult them if you have questions.

That completes setup for the partition that will hold your home directories. If you have data in /home already, you may want to mount /dev/mapper/home someplace and move it over now. You will almost certainly want to mount it and create a home directory for your user (remember to chown it appropriately!).

Creating an updated initial RAM disk and booting

The final critical step is creating an updated initial RAM disk that contains the modules and crypto configuration to boot your machine with the encrypted swap and filesystems in place. At this point you should double check your /etc/crypttab, /etc/fstab, and hibernation configurations, and make sure the swap partition and encrypted home partition are mapped (they don't necessarily have to be mounted). When you are sure that everything is in place, run this command:

update-initramfs -u -k all

It should complete without errors. When it does, your system is set up, and you can reboot. I recommend doing so now. Upon bootup, you will be prompted for the passphrase first for your swap partition, and then for your encrypted /home partition. The first prompt is pretty and nice and everything works normally. For the second prompt, for some reason there will be some on-screen glitches (at least, there are on my machine), but everything works normally anyway. Note that you will be prompted three times for each passphrase if you make a mistake on entry, and after the third time bootup will continue without the partition in question. Not having /home in particular is not going to lead to a nice day, so type carefully and remember those passphrases!

There are likely to be a lot of these XPS13 posts, so I've created a category for them. This is the first post in that category.

Wherein a reinstall is harder than it should be

So I decided to wipe and reinstall my XPS13 for a variety of reasons, most of which boil down to encrypted /home. I found that that process was somewhat more difficult than it could otherwise have been, mostly because a) the Sputnik 3 install image does not have networking support, b) the recovery process doesn't partition correctly, and c) nothing else has networking support, either.

The setup

Let's start with networking support. Apparently, the wifi adapter in the Sputnik 3 is about five and a half minutes old. You have to have a very new kernel, and very new firmware, to get it to work. I have read variously that Linux 3.10 and 3.12 are the requisite kernel versions, and several different comments on firmware blobs. I don't know for sure, I haven't gotten that far. The bottom line is that neither Debian 7 (wheezy) nor Debian testing (jessie) netinst images would work, even with extra non-free firmware packages. That's not entirely unsurprising, but what is surprising is that Dell's own recovery image doesn't appear to have the appropriate driver and/or firmware. This means that you can't install software to the recovery image system.

... Which is unfortunate for me, because the whole point of this exercise was to set up the drive using LVM and LUKS encrypted partitions. Ubuntu 12.04 supports both of these things just fine, just not on the Dell recovery image. Ugh.

Reinstall #1

I decided to do things the “hard” way, leave everything but /home unencrypted, and just set up the encrypted /home partition once the recovery image had done its thing. For this to work, I deleted the partitions I didn't want, created a / partition, a large unused space for LVM, and a swap partition, then installed. The recovery image appeared to be happy, and did its thing for a while. So far so good. Except ...

When the laptop rebooted, it said Operation system not found. Yeah, “Operation system“. The Chinese-to-English translator was sleeping on the job that day, apparently. I had left a small FAT partition on the drive that appeared at a glance to be for UEFI, so I thought maybe it required some updates to get things working. I was a bit confused, though, as the system was configured for legacy boot and I wasn't sure why it would want that partition, anyway. So, figuring I could just do a complete restore (restoring the UEFI and recovery partitions, as well as the Linux install) if things went too wrong, I took the nuclear option.

Reinstall #2, and resolution

I rebooted to the recovery image, wiped the UEFI partition as well, and reinstalled with only the Linux install and empty partition. Same as before, everything appeared to go fine, then reboot, and whoops, no dice.

So I said to myself, “surely it's not as simple as they installed grub to the OS partition and didn't mark it bootable!,” and I rebooted to that !*$@& recovery image AGAIN. I fired up fdisk, marked /dev/sda1 bootable, wrote, and rebooted — without even looking at their GUI. Presto, the annoying setup video played and I was off to the races.

Summary

I'm done jacking with this thing for tonight. We'll see how the rest of the saga goes tomorrow (and maybe I'll write it up). This situation doesn't really significantly damage my opinion of the hardware, as it's obviously still great, but it does give me some pause regarding Dell's commitment to the product. Ubuntu 12.04 is pretty old, there doesn't appear to be a way to install anything newer (at least, without doing some installer futzing) at the moment, and even the Dell installer doesn't really seem to be brought up to speed for the new hardware. It's almost like they shipped with the Sputnik 2 installer and some extra install-time packages.

The charitable part of me hopes that this is because this product is only a month old, and they're already prepping 14.04 for April. Any word on that, Dell?