## Coreboot+Grub2 for Purism Librem 14 ### Purposes Currently [Purism](https://puri.sm) 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](https://docs.puri.sm/PureBoot.html) 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](https://puri.sm/products/librem-key/). Before getting the Librem 14 I used to run [Qubes OS](https://qubes-os.org) on an old [Thinkpad X220 with coreboot and with Grub2 as a payload](https://git.lsd.cat/g/thinkpad-coreboot-qubes). The idea of using Grub2 directly in order to gain real full disk encryption comes mostly from the [libreboot](https://libreboot.org) 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](https://forums.puri.sm/t/coreboot-with-grub-payload/) * [Qubes Forum Thread]()