|Giulio 4f36d06f57 Readme.md syntax||10 months ago|
|resources||10 months ago|
|README.md||10 months ago|
|build.sh||10 months ago|
|encryptboot.sh||10 months ago|
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.
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.
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.
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.
mkpassword.shto generate a Grub2 password
resources/background.jpg. It must be a
1920*1080JPG of size below 300KB.
build.shas root and check that it completes successfully
build.sh fails, stop here. It does not make any sense to proceed without a valid firmware image
encryptboot.sh /dev/sdXas root. The parameter indicates the target device noted down at Step 1.
encryptboot.sh fails stop here. It does not make any sense to flash coreboot+Grub2 if it is unable to properly boot.
flash.sh fails, do not reboot or turn off your computer. If you believe the failure left your firmware in an unknown state, run
Run the following command in
sudo qubes-dom0-update python3-dnf-plugin-post-transaction-actions
resources/00-kernel-xen-symlink.conf from this repository to
grub.cfg requires a re flash, that we would like to avoid, the supplied configuration files boots qubes using some symlinks:
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.