|
2 gadi atpakaļ | |
---|---|---|
resources | 2 gadi atpakaļ | |
README.md | 2 gadi atpakaļ | |
build.sh | 2 gadi atpakaļ | |
encryptboot.sh | 2 gadi atpakaļ |
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.
boot
grub.cfg
updatesData 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.
/dev/sdX
resources/serial-number.txt
mkpassword.sh
to generate a Grub2 passwordresources/background.jpg
. It must be a 1920*1080
JPG of size below 300KB.build.sh
as root and check that it completes successfullyIf build.sh
fails, stop here. It does not make any sense to proceed without a valid firmware image
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.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
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.