librem14-coreboot-grub-qubes/README.md

Coreboot+Grub2 for Purism Librem 14

Purposes

Currently Purism offers two possible boot options, coreboot+SeaBIOS, which is comparable to a standard BIOS legacy boot process and coreboot+HEADS, modified and renamed as PureBoot which attempts to build a trust chain for the boot process and detect tampering if used in addition with the Librem Key.

Although PureBoot has evident benefits, it has also a lot of added complexity, still needs a /boot partition unencrypted (even if it not expected to contain sensitive data) and to be fully secure it needs external hardware, the Librem Key.

Before getting the Librem 14 I used to run Qubes OS on an old Thinkpad X220 with coreboot and with Grub2 as a payload. The idea of using Grub2 directly in order to gain real full disk encryption comes mostly from the libreboot project.

Security considerations

The Librem 14 ships with a "write protection" screw for the coreboot flash chip on the mainboard. Assuming that it can be trusted, and that additional anti tampering measures are in place once the coreboot+Grub2 firmware has been written, it should be unmodifiable. The /boot partition, which is normally unencrypted, is now inside the same LUKS volume as the root volume and thus has the same properties and is secure as your passphrase and LUKS can be.

The only physical attack vector, except for attack vectors such as a bootrom exploit, is the disassembly of the laptop, removal of the "write protection" and flash of a malicious firmware. In this scenario we using glitter on the screws to detect disassembly. PureBoot uses instead the Librem Key and that is definitely a more robust solution, as would be a TPM TOTP anti evil maid mechanism, which would be really a nice addition to Grub itself but is currently not supported.

By default, Grub2 will boot the default option (encrypted Qubes). Since sometimes updates may fail and the system can fail to boot and recovery would otherwise require either changes to the firmware or extracting the storage to mount the system to repair, USB boot is supported but protected by password. Any Grub2 console access, manual modification or action which is not the default boot option in its state also requires a password. The password is set in the grub.cfg hardcoded in the CBFS.

How does it work?

Coreboot is compiled as normally for the Librem 14, with Grub2 as a payload. The grub.conf file is modified prior to flashing and is generic enough not to need any edits under normal circumstances. Since the Qubes installer does not support partitioning encrypting /boot, it is necessary to manually edit the partition scheme after installation.

Pros

• Faster boot time
• Almost comparable security with Pureboot
• Encrypted boot
• Does not normally need grub.cfg updates

Cons

• Anti evil maid relies on glitter (lol)
• Need to unscrew the "write protection" to update firmware
• LUKS password has to be entered twice or a keyfile has to be added

Installation instructions

Warning

Data loss is extremely probable and firmware corruption is rare but not impossible. The first can be avoided doing a full dd backup of the involved disk or performing the operation on a new laptop/disk. The latter may result in having the laptop in a bricked state and recovery could require hardware flashing. Do not attempt the procedure if you have no mean of hardware unbricking. This setup is unsupported by both me and Purism. Use at your own risk.

Prerequisites

• Purism Librem 14
• USB drive for Qubes installation
• USB drive for live system (Fedora/PureOS)
• Screwdriver kit
• Nail polish glitter

Procedure

Install Qubes (Step 1)

• Install QubesOS from the USB drive on the target storage with LUKS and LVM
• Note down the target drive, /dev/sdX

Boot live distro (Step 2)

• Reboot into a Debian or Fedora based distro, such as PureOS or Fedora
• Connect to the internet
• Clone this repository
• Write down the Librem 14 serial in resources/serial-number.txt
• Run mkpassword.sh to generate a Grub2 password
• If desired, change the background image for grub in resources/background.jpg. It must be a 1920*1080 JPG of size below 300KB.

Build coreboot+Grub2 (Step 3)

• Run build.sh as root and check that it completes successfully

If build.sh fails, stop here. It does not make any sense to proceed without a valid firmware image

Encrypt /boot (Step 4)

• Run encryptboot.sh /dev/sdX as root. The parameter indicates the target device noted down at Step 1.

If encryptboot.sh fails stop here. It does not make any sense to flash coreboot+Grub2 if it is unable to properly boot.

Flash the firmware (Step 5)

• Run flash.sh as root.

If flash.sh fails, do not reboot or turn off your computer. If you believe the failure left your firmware in an unknown state, run recover.sh

Boot into Qubes and set update hooks (Step 6)

• Run the following command in dom0

  sudo qubes-dom0-update python3-dnf-plugin-post-transaction-actions

• Copy resources/00-kernel-xen-symlink.conf from this repository to dom0 /etc/dnf/plugins/post-transaction-actions.d/00-kernel-xen-symlink.conf

Since editing grub.cfg requires a re flash, that we would like to avoid, the supplied configuration files boots qubes using some symlinks:

• /boot/vmlinuz-latest
• /boot/initramfs-latest
• /boot/xen-latest-latest

Since those names are not standard, in order to be able to update Qubes Linux Kernel and Xen without manual intervention, the aforementioned procedure creates a post transaction hook for dnf that automatically updates those symlinks.

Tun on hardware write protection (Step 7)

Add glitter to screws and joints (Step 8)

Community

• Purism Forum Thread
• [Qubes Forum Thread]()