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 <timo.lindfors@iki.fi>  Sun, 04 Jul 2021 12:54:58 +0300
