tboot for Debian --------------- Background ---------- Trusted computing is a broad and complex topic but here is a short summary on how tboot fits to the picture. There are two main ways of performing measured boot. In SRTM (Static Root of Trust Measurement) each component measures the subsequent component in the boot chain to the TPM chip. The TPM chip cannot stop the boot process but you can store secrets (e.g. disk encryption keys) to the TPM such that they can only be accessed if the TPM has observed unmodified measurements of the boot chain. In DRTM (Dynamic Root of Trust Measurement) a special CPU instruction (SENTER) is used to enter a measured launch environment that cannot be affected by the software that was running earlier during the boot process. Similarly to SRTM this environment is measured to the TPM. The main benefit of DRTM is that bugs in your BIOS or boot loader cannot be used to send fake measurements to the TPM. The main drawbacks are that it requires a CPU that supports the SENTER instruction and that it is vulnerable to malicious code running in SMM (System Management Mode) or ME (Management Engine). It is possible to combine SRTM and DRTM. It is also possible to use them together with Secure Boot to prevent loading untrusted code. Currently tboot does not support Secure Boot. The tpm.mod module in the Debian package grub-efi-amd64-bin can be used for SRTM. This package can be used for DRTM. AMD has its own instruction for DRTM, called SKINIT, but tboot does not support it at the moment. Getting started --------------- If you want to boot Linux with tboot you need a kernel built with CONFIG_INTEL_TXT=y and CONFIG_INTEL_IOMMU_DEFAULT_ON=y. Official Linux packages have had CONFIG_INTEL_TXT since Debian 11. CONFIG_INTEL_IOMMU_DEFAULT_ON is not currently set but you can workaround this by using the intel_iommu=on boot option. The boot firmware should provide the ACMs (authenticated code modules) needed for Intel TXT to function. If the boot firmware does not do this then it might still be possible to use TXT if tboot loads the ACM modules from the filesystem. These ACM modules are non-free and not recommended. For more information, see for example https://doc.coreboot.org/security/intel/acm.html Use with Debian 10 and older debian releases -------------------------------------------- If you want to use tboot on an older Debian release you need to rebuild the kernel. One way to do that is as follows: 1) $ sudo apt-get install devscripts 2) $ apt-get source linux 3) Edit debian/config/config and add CONFIG_INTEL_TXT=y 4) Edit debian/config/defines and add "+txt.1" to abiname. If you don't need real-time kernels and want to save build-time you can also set "enabled: false" for featureset-rt_base 5) $ dch -i 6) Add "+txt.1" to the version number and save the file. 7) $ sudo apt-get build-dep linux 8) $ env DEB_BUILD_OPTIONS="parallel=$(nproc)" dpkg-buildpackage -rfakeroot -us -uc 9) Run the previous command again since it intentionally fails on the first run. The build should take around 2-3 hours. Common misconfigurations ------------------------ This package does not provide a complete solution for e.g. TPM-based disk encryption. However, regardless of what solution you end up using you should make sure that it avoids at least the following common misconfigurations: 1) If you use a normal Debian initramfs you can easily get a root shell without affecting TPM measurements e.g. by disconnecting the hard disk during the boot process. One way to solve this issue is to use the boot parameter panic=86400. 2) If you use LVM inside your encrypted LUKS volume it is possible to trick LVM into activating an LVM PV from unencrypted media. If you provide your own /sbin/init on that media you can execute arbitrary code as root. One way to solve this to use e.g. filter = [ "a|/dev/mapper/md1_crypt|" ] in /etc/lvm/lvm.conf. 3) If you use an UUID or GUID to find the root partition an attacker can similarly trick the boot process into running their own /sbin/init. The default configuration in Debian with LVM on LUKS avoids this issue by specifying the boot parameter root=/dev/mapper/HOSTNAME--vg-root. 4) It is possible to trick systemd-gpt-auto-generator into activating an unencrypted swap device and mounting an unencrypted /srv partition. This can lead into arbitrary code execution. One way to solve this problem is to use the boot parameter systemd.gpt_auto=no. 5) An attacker can tamper with the files that are stored on the unencrypted /boot partition. If you support automatic updates with forward-sealing of data for new package versions there is a risk that you might seal data for tampered system files. A solution is to carefully verify the integrity of files used for measurements and to force any generated files to be regenerated. One way to implement this is to use the following commands: (cd / && grep -h " boot/" /var/lib/dpkg/info/*md5sums | md5sum -c) update-initramfs -k all -d update-initramfs -k all -c update-grub2 -- Timo Lindfors Sun, 04 Jul 2021 12:54:58 +0300