TrenchBoot support for UEFI boot mode in GRUB2 for Intel hardware and AMD hardware

[BeataZdunczyk]

Brief summary

This task focuses on expanding TrenchBoot support for UEFI boot mode with DRTM in Xen and GRUB2, targeting both Intel and AMD hardware. This task ensures that DRTM works with UEFI boot mode on Intel and AMD processors in GRUB2.

[krystian-hebel]

TrenchBoot/grub#25 - PR with initial rebase to GRUB used by Qubes as of now. No UEFI implementation yet.

[philipanda]

Testing AEM on HP t630 with UEFI boot so far:

• The anti-evil-maid-install still has to be run on the /boot partition, not /boot/efi, that didn't change.

  • Fails on /boot/efi:
  • Succeeds on /boot:

• Launching AEM grub entry results in an error

  • Enabling slaunch ...
    Loading Xen aem-xen-4.17.5.efi ...
    Loading SINIT module skl.bin ...
    Xen 4.17.5 (c/s ) Efi Loader ...
    Couldn't obtain the File System Protocol Interface : ErrCode 0x8000000000000003
    

  • The error appears for a fraction of a second. It disappears so quickly that sometimes it seems it is not even printed completely. The output above was collected visually by retrying multiple times.
  • A similar message sometimes appears and stays for much longer allowing to record it

• The normal QubesOS boot entry will fail to boot if the AEM entry was selected before. Grub will log loading Xen, loading the kernel, and then everything freezes on Loading initial ramdisk

  • To boot QubesOS normally a reboot is then required.

• The first time grub appears the resolution is lower and the boot menu is not centered. After failing to boot AEM the resolution in grub increases significantly.

  • Initially:
  • After booting AEM fails:

• I have had some issues with packages not being installed properly on QubesOS. A reboot and provisioning the AEM repo key to yum again helped with that.

• As suggested by @krystian-hebel I've tried launching the AEM boot entry with slaunch and slaunch_module /skl.bin removed. This changed nothing (apart from the changes in echo I've added to check if the modified entry is run)

  • The unchanged AEM boot entry:
  • The modified one:
  • The output is disappearing really quickly again. I've managed to catch it using a slow-mo camera
  • According to @krystian-hebel the error might be appearing because loading an initramfs seems to be missing in this bootentry

[BeataZdunczyk]

@SergiiDmytruk cc

[SergiiDmytruk]

• The anti-evil-maid-install still has to be run on the /boot partition, not /boot/efi, that didn't change.

I don't know if it was expected to change, but it didn't for two reasons:

• grub.cfg next to grubx86.efi redirects to /boot/grub2/grub.cfg so there is a common config for legacy and EFI located in /boot
• AEM setup assumes ext filesystem as can be seen from its error messages, although this should be easy to change

Couldn't obtain the File System Protocol Interface : ErrCode 0x8000000000000003

Same as on AMD Supermicro. Xen.efi unlike Multiboot EFI needs this filesystem protocol to find its configuration file. I just realized why it can't really work: /boot is ext filesystem and proprietary BIOSes don't know how to read it, hence no filesystem protocol. Xen, its config, Linux and initrd will have to be on ESP which is how I did it initially but $prefix was getting in the way if I remember correctly (can probably be worked around).

The normal QubesOS boot entry will fail to boot if the AEM entry was selected before. Grub will log loading Xen, loading the kernel, and then everything freezes on Loading initial ramdisk

That has always been the case because Slaunch status is stored in a global variable which is never reset. Maybe GRUB's "boot" command should switch Slaunch off on failure.

The first time grub appears the resolution is lower and the boot menu is not centered. After failing to boot AEM the resolution in grub increases significantly.

Xen.efi initializes video output, but it doesn't return it to previous state on failure.

[BeataZdunczyk]

@SergiiDmytruk Okay, so we will wait for your changes before proceeding with retesting.

[krystian-hebel]

/boot is ext filesystem and proprietary BIOSes don't know how to read it

Yes, because this isn't part of UEFI spec.

---

By going chainloader way, we introduced multiple unknowns, which should be tested before implementation:

• Xen must be able to boot using this protocol. AFAICT Xen was only tested to boot as first stage, not after GRUB.
• Qubes must be able to boot on standard UEFI using this protocol, which on top of the above means it must be able to load kernel and initramfs, together with getting info where to load it from.

Only if those two are proven to work without any modifications, we can begin work on AEM. Otherwise we have no idea which part breaks the booting.

[philipanda]

With the latest fix from https://github.com/TrenchBoot/qubes-antievilmaid/actions/runs/12897606455 AEM seems to work. I have reinstalled the package and ran anti-evil-maid-install again.

When booting AEM I get this output:

Then after a while a loading screen with QubesOS logo appears briefly.

At this moment a prompt to enter the prompt to unlock the TPM should appear, but the screen turns black (no signal, the monitor turns off). I have waited for it to return for approx. 5 minutes, which is much longer than ~10s it was taking on legacy boot.

I have tried entering the password blindly hoping that it's just visual. I have entered the SRK password after ~ 1 minute of no signal, and then the disk encryption password after another minute. After waiting yet another minute QubesOS actually boots!

So it works now, but there is possibly some bug related to video output?

[philipanda]

@SergiiDmytruk

@krystian-hebel Asked me to post the events listed by anti-evil-maid-dump-evt-log and to ask what is the entry number 4, and why it's name is empty:

[SergiiDmytruk]

@philipandag

So it works now, but there is possibly some bug related to video output?

Strange that video output works, but password prompt doesn't. Pressing Escape should hide plymouth's graphical screen with progress and show you console (likely with a prompt). It looks like AEM just thinks that plymouth isn't active. It's detected like this, so plymouth --ping can fail to check that plymouthd is running, but not sure why would it. Maybe console output will have an error if 2>/dev/null is removed from that file and AEM is reinstalled.

Is that on Qubes OS 4.2.3? Was legacy working on 4.2.3 as well? Seems like both should either work or not work. Password prompt works for me on AMD Supermicro with 4.2.0, although I didn't set SRK password.

@krystian-hebel Asked me to post the events listed by anti-evil-maid-dump-evt-log and to ask what is the entry number 4, and why it's name is empty

Same as before: it's MBI because early TPM code doesn't parse SLRT and passes an empty string for log entry's data.