Introduction
In this HOWTO, we’ll walk through installing FreeBSD 10.1-RELEASE as the sole operating system on a UEFI-enabled amd64/x86-64 PC to a single hard disk, with all except the /boot directory installed to a ZFS pool encrypted using geli(8).

The /boot directory will reside on an unencrypted UFS partition.

If you’re reading this for a later version of FreeBSD then it will probably work, but there may be a better and easier way of achieving the same goal. FreeBSD 10.1 was the latest release at time of writing.

Understanding technical limitations
UEFI support was added to FreeBSD in the 10.1 release for the amd64 architecture, but has some limitations:

• It only supports booting from a UFS partition (that is, not ZFS)
• It does not support UEFI Secure Boot.

PC manufacturers’ implementations of UEFI vary in quality. During the transition from legacy BIOS booting to UEFI, many manufacturers include a method of booting from both. This might be configurable or the firmware may decide which one to use based on the disk partitioning type (MBR or GPT) or presence of boot sector code. Even if your PC supports UEFI, implementation issues may prevent this method working for you.

The configuration described here is not compatible with the ZFS Boot Environment management utilities sysutils/beadm or manageBE, since both of these make assumptions about the filesystem layout that aren’t true here.

If you’re using an SSD, you should know that geli(8), which we are using here for encryption, doesn’t yet support TRIM, which will unfortunately have implications for your write performance.

A brief discussion on risk mitigation, disk encryption and GELI
This is not a HOWTO on different disk encryption techniques but you should understand what protection this configuration offers and what it doesn’t. When designing security, it is important to keep in mind whom you are defending against. In this configuration, I’m aiming to prevent someone reading my data if I lose the computer (all too common for laptops) or if it is stolen by a thief more interested in selling the hardware for cash than for any secrets on the hard disk. I am not looking to protect my data from espionage level attacks or from covert modification.

Encrypting information on a disk protects an attacker from accessing it “at rest”, that is, when the computer is powered off. It offers no protection at all against attacks while the computer is powered on and you have made that information available in its decrypted (plain text) form. This is true for all disk encryption. The configuration described here has further shortcomings. Secure Boot is disabled, the kernel and its modules are available in unencrypted form on the disk and I will be using GELI without enabling data authentication. This means that if someone sneaky wants to plant attack software on the machine, conduct an “evil maid” style attack or even modify the encrypted data so it decrypts to something different, they can and you won’t know about it.

If I had different requirements, I would consider putting my UEFI boot files and kernel on a removable disk that I kept with me, enabling data integrity verification for my GELI partition, encrypting with AES 256-bit keys rather than 128-bit, physically securing my PC and making it tamper evident, locking down the firmware configuration, rewriting the UEFI bootloader to support Secure Boot, using a PC with a TPM chip, reviewing the FreeBSD source code, never connecting my computer to the Internet, installing an alarm system in my office, training an attack dog to guard my computer… you get the idea. You can hire me for security consultancy or attack dog training at competitive rates but for now, let’s get on with the show.