Xen / Qubes support

[osresearch]

Qube's AEM tool was mentioned in #19. It's worth thinking about how Qubes could be supported - there are several issues that make it difficult:

• Xen's hypervisor is a multiboot image, not an EFI executable, and doesn't bundle the kernel+initrd. There is a guide for building Xen EFI, although it is not a straightforward process. Xen builds an xen.efi that can be booted by the boot manager.
• Verifying the payload is done with mjg59's shim. This is supposed to call into the UEFI image loader protocol and verify with the PK/KEK/db, but the shim itself is signed by Microsoft. Building and signing a separate shim is required. Unified image does not require the shim to be present.
• Dom0 is a Fedora system, not Ubuntu, so the Debian package won't install...
• Fedora uses Dracut; the initramfs-tools would likely need some porting.
• Read-only root in dom0 requires some hacking since Xen wants to write into /etc; I did it a while ago, but found it challenging to maintain my patches.
• ???

[osresearch]

One idea is to bundle xen.elf into a unified kernel image, which would allow the single Xen+Kernel+Initrd to be signed.

[osresearch]

The systemd-boot stub.c would need to be modified to add an additional Xen section, which would contain xen.efi. Xen's EFI startup code has enough logic to find the config file and kernel via LoadedImageProtocol, and then validate them with the shim (and calls blexit() if it fails to validate)

However, it assumes that the config file is always present and opens it in read_file(). But, it does not validate it with the shim protocol? That would allow someone to modify the file.

[osresearch]

Preliminary unified Xen support works with qemu in secure boot mode: osresearch/xen@765f0fe

This allows the hypervisor to locate the sections bundled into the PE executable and boot from them instead of the files on the drive.

[osresearch]

Qubes 4.0.2 is using Xen 4.8, and Qubes 4.1 is using Xen 4.13. The Xen must match the Qubes tools, so it is necessary to apply the patch to the older version to get it to work.

There is a bug in binutils that causes xen.efi to be corrupt, it can be hacked around as well. https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00217.html and https://sourceware.org/pipermail/binutils/2020-August/112746.html

[osresearch]

Qubes 4.1 can boot with the unified Xen 4.13.

[osresearch]

And it works on real hardware. Update on the qubes issue:
QubesOS/qubes-issues#4371 (comment)

[osresearch]

Xen mailing list discussion on the patch series: https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00215.html

And some followups: https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00483.html
https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00482.html

[osresearch]

Latest xen-devel patch. Hopefully ready for merging: https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg01735.html

[osresearch]

Also important for the secure drop project freedomofpress/securedrop-workstation#602

[strugee]

Someone now apparently has a working AEM-like solution on TPM2.0 and UEFI, or at least something upon which an AEM-like solution could be built: QubesOS/qubes-issues#6015

So maybe this is less urgent?

[osresearch]

TOTP handles only one important aspect of booting: the attestation from the system to the user. This is a vital part, since as Garret pointed out "how can you trust the dialog box asking for your password?".

However, tpm2-totp alone does not address several of important points:

• The disk key is derived solely from the user password, so offline attacks are possible, or if the user is not trustworthy, they can remove the disk and decrypt it in another machine
• grub does not measure the initrd, so it can be modified by an attacker without changing the totp
• grub does not by default lock down kernel parameters, and they are not included in the measurement
• Rollback to pre-boothole grub could potentially bypass some of these protections
• Automated reboots are not possible since it requires manual intervention to validate the totp
• Upgrades require knowledge of the secret (could be fixed with a signed PCR policy like safeboot uses)
• Rollback attacks to previous vulnerable versions with sealed secrets are possible (could be fixed with TPM counters like safbeoot uses)
• The Microsoft and vendor keys are still in the UEFI DB, allowing the system to be booted with untrusted software.

A larger issue is that the shim protocol does not validate signatures on the xen config, the kernel command line, the initrd, or the xen flask. This is similar to the design of Ubuntu and other Secure Boot-compatible Linux distributions - they want users to be able to change kernel parameters and rebuild the initrd without having access to Ubuntu's signing key. However, it leaves a very large hole for attackers to bypass many of the Secure Boot protections. This is briefly discussed in the FAQ: How is safeboot different from normal UEFI secure boot.

The patches are making their way through the Xen merge process and can be backported to the Qubes Xen without too much difficulty. These fixes, combined with tpm2-totp, will hopefully improve the overall security of the system for Qubes users who want to enroll their own platform keys.

[JarrahG]

Someone now apparently has a working AEM-like solution on TPM2.0 and UEFI, or at least something upon which an AEM-like solution could be built: QubesOS/qubes-issues#6015

Echoing the above comments, having TPM2-TOTP in QubesOS is a starting point more akin to "something upon which an AEM-like solution could be built". Once it is there I plan on documenting/writing code to solve some of the issues with it, but it is not a full, user facing solution like safeboot.