Open osresearch opened 4 years ago
One idea is to bundle xen.elf
into a unified kernel image, which would allow the single Xen+Kernel+Initrd to be signed.
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.
Preliminary unified Xen support works with qemu in secure boot mode: https://github.com/osresearch/xen/commit/765f0feecc1e1ceed206ccd310941bef8eed822c
This allows the hypervisor to locate the sections bundled into the PE executable and boot from them instead of the files on the drive.
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
Qubes 4.1 can boot with the unified Xen 4.13.
And it works on real hardware. Update on the qubes issue:
https://github.com/QubesOS/qubes-issues/issues/4371#issuecomment-670577215
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
Latest xen-devel patch. Hopefully ready for merging: https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg01735.html
Also important for the secure drop project https://github.com/freedomofpress/securedrop-workstation/issues/602
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?
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:
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.
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.
v6 of the patches on the xen-devel list: https://lists.xenproject.org/archives/html/xen-devel/2020-09/msg01367.html
Hopefully reaching some sort of convergence soon and reaching a merge.
v7 posted https://lists.xenproject.org/archives/html/xen-devel/2020-09/msg02111.html and had some more comments... working on patch v8. Surely this time it will be merged.
3/4 of the patches have been pushed to staging! https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=8a71d50ed40bfa78c37722dc11995ac2563662c3
The only one left is a less critical fix that stops unified xen from parsing the command line if secure boot is enabled. It needs a minor tweak, and will hopefully be merged next week.
Hi, I've submitted PR with initial Qubes OS safeboot support based on examples from PRs. It helps to build Qubes R4.1 package with qubes-builder and generate keys and unified image. Did I miss smth already developed for the issue or this might be useful?
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:
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 anxen.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./etc
; I did it a while ago, but found it challenging to maintain my patches.