Load via Grub?

[DocMAX]

My windows boots with grub (chainload bootmgfw.efi). Is it possible to load EfiGuard with grub? chainload efiguard and then bootmgfw doesnt work.

[Mattiwatti]

Hi,

Yes, it is possible to load EfiGuard with GRUB. However, note that for this to work, the Windows Boot Manager entry must be present in the boot options list in the BIOS so that EfiGuard can find it. The simplest setup is of course to put GRUB at no. 1 in the list (so it will be the default boot entry) and Windows Boot Manager at no. 2.

Here is a grub.cfg entry that works for me:

setparams 'EfiGuard (on /dev/nvme0n1p2)'

    insmod part_gpt
    insmod fat
    if [ x$feature_platform_search_hint = xy ]; then
      search --no-floppy --fs-uuid --set=root 36E9-0377
    else
      search --no-floppy --fs-uuid --set=root 36E9-0377
    fi
    chainloader /EFI/Boot/Loader.efi

Note 1: there is no set root='hdX,gptY' following the insmod statements. Note 2: the second if branch is completely the same as the first one, so I'm not sure why this entry was generated this way (Gentoo generated the entry for me). Presumably you could just use a single search instead.

Here, 36E9-0377 is the serial number of the FAT32 EFI System Partition. In Windows you can find this as follows:

C:\Users\Matti>mountvol X: /S
C:\Users\Matti>dir X:
  Volume in drive X has no label.
  Volume Serial Number is 36E9-0377
  <...>

[utoni]

For Debian based distros, you have to create a new script file in /etc/grub.d/ e.g. /etc/grub.d/40_winboot, which should basically look alike:

#!/bin/sh exec tail -n +3 $0 menuentry "Windows 10 UEFI/GPT" { insmod part_gpt insmod search_fs_uuid insmod chain search --fs-uuid --no-floppy --set=root XXXX-XXXX chainloader ($root)/EFI/MICROSOFT/BOOT/bootmgfw.efi } menuentry "Windows 10 EfiGuard" { insmod part_gpt insmod search_fs_uuid insmod chain search --fs-uuid --no-floppy --set=root XXXX-XXXX chainloader ($root)/EFI/Boot/Loader.efi }

where XXXX-XXXX is the Serial Number EFI partition. On Linux you can view these UUIDs/SNs/... via ls -l /dev/disk/by-uuid/. Run sudo update-grub2 and you're good to go.

[DocMAX]

My problem is that the loader is freezing. How can i debug this?

[Mattiwatti]

1. Are you sure it is the loader is freezing and not EfiGuardDxe (the driver)? The loader does not normally print anything unless an error occurred, so you may be looking at EfiGuardDxe freezing.

2. Does this happen only in combination with GRUB, or always? In the latter case I will need more information about your specific machine (and even then I may not be able to help). In the former case, please post your grub.cfg.

3. What happens if you try the second method listed in the README (loading the driver manually from the shell without using the loader)?

---

You can use the instructions at How to debug OVMF with QEMU using GDB as a guideline for debugging EfiGuard, skipping the OVMF-specific parts. Note that you will need to compile OVMF and EfiGuard yourself to do this, and you will want to do so in debug mode: build -a X64 -p EfiGuardPkg/EfiGuardPkg.dsc -b DEBUG -D EFI_DEBUG

Here is the QEMU configuration I use. Change the paths for drive 0 and 1 to your OVMF build output paths. efifat is a directory relative to the current that contains the emulated FAT32 filesystem. You should put Loader.efi and EfiGuardDxe.efi and any other EFI files you need (such as GRUB) in there, as well as Loader.debug and EfiGuardDxe.debug so you can load debug symbols in gdb. -s tells QEMU to listen for gdb at port 1234, and -S tells it not to start until told to do so by gdb.

qemu-system-x86_64 \
	-s \
	-S \
	-M q35,smm=on \
	-m 1024M \
	-drive unit=0,if=pflash,format=raw,readonly,file=/home/matti/efi/edk2/Build/OvmfX64/DEBUG_GCC5/FV/OVMF_CODE.fd \
	-drive unit=1,if=pflash,format=raw,file=/home/matti/efi/edk2/Build/OvmfX64/DEBUG_GCC5/FV/OVMF_VARS.fd \
	-drive unit=2,file=fat:efifat/,read-only=on,media=disk,if=virtio,format=raw \
	-global isa-debugcon.iobase=0x402
	-debugcon file:debug.log \
	-global ICH9-LPC.disable_s3=1

[DocMAX]

The driver is freezing (second method, "load EfiGuardDxe.efi"). Not loader.efi. This is where it freezes: Tried older versions and CSM module on/off - makes no difference.

[Mattiwatti]

This is a bit of a stab in the dark, but this looks similar to an issue I once had on a Gigabyte Z97 motherboard where the shell would hang while connecting controllers in ConnectAllEfi(). Can you try load -nc instead of load to see if this makes a difference?

[Mattiwatti]

Closing this issue as stale, but feel free to reopen if above suggestion did not work.