Booting Qubes 4.0 in EFI Mode With Grub

I understand Grub was unable to boot Xen until recently (Xen 4.9). I was wondering if anyone has had success booting Qubes 4.0.X from Grub in EFI mode? I am currently on kernel 5.6.16 and Xen 4.8.5-23.fc25 so I assume I will need to update Xen. Is this possible without jumping all the way to 4.1 or installing any seriously unstable updates? I have been trying to figure out how these patches work. I have tried some things and broken things and I just don’t think I can bring myself to reinstall Qubes again this year (fingers crossed.)
I have a multi-boot setup and the reason I am using EFI is that I need my Windows install secured for CAD software and ITAR for work. The Windows install is protected with Bitlocker, Secure Boot, the Microsoft Security Compliance Toolkit Baseline, and the Windows Restricted Traffic Limited Functionality Baseline. It is important that I keep that install secure to the extent possible although I would abandon EFI if there is a good option there (I patched the hole in the boot and I’m aware of the others.) Thank you in advance for any ideas!

I understand Grub was unable to boot Xen until recently (Xen 4.9). I was wondering if anyone has had success booting Qubes 4.0.X from Grub in EFI mode? I am currently on kernel 5.6.16 and Xen 4.8.5-23.fc25 so I assume I will need to update Xen. Is this possible without jumping all the way to 4.1 or installing any seriously unstable updates? I have been trying to figure out how these patches work. I have tried some things and broken things and I just don’t think I can bring myself to reinstall Qubes again this year (fingers crossed.)

A bunch of the core Qubes packages are also tied to the Xen version.
While I believe there was a 4.9 branch for a while, I wouldn’t expect
this to work particularly well.

I have a multi-boot setup and the reason I am using EFI is that I need my Windows install secured for CAD software and ITAR for work. The Windows install is protected with Bitlocker, Secure Boot, the Microsoft Security Compliance Toolkit Baseline, and the Windows Restricted Traffic Limited Functionality Baseline. It is important that I keep that install secure to the extent possible although I would abandon EFI if there is a good option there (I patched the hole in the boot and I’m aware of the others.) Thank you in advance for any ideas!

If this is required for compliance reasons, you may want to get some
advice on setting up Qubes on the machine at all. Generally these things
require the lockdown to be managed, and for much the same reasons that
Qubes does not recommend dual boot, your Windows lockdown may not be
secure.

https://www.qubes-os.org/doc/multiboot/

As for EFI boot in qubes, you wouldn’t get secureboot even with GRUB in
Qubes. What is the difference between EFI with or without GRUB for you?
If it’s just the boot menu, wouldn’t using the EFI boot menu be easier
than building a custom hypervisor for Qubes?

Thanks for the feedback Jarrah.

FYI I am not trying to secure the qubes boot chain although it would be nice to be able to encrypt the boot partition an only leave grub in the clear. I would think this is possible with qubes and grub. Really I would just prefer grub to my Asus MB EFI boot chooser,.

Blockquote

That is discouraging. Are you of the opinion that 4.9 would not effectively be backward compatible with 4.8.5?

Blockquote

I know Secure Boot is out of the question for Qubes. Something tells me that my pedigree of having almost coded a black jack game on my TI86 in high school does not position me to be the first to secure the Qubes boot chain.

As for thinking carefully, I would say I have. I only have the triple boot circus because I need to use Catia with full hardware acceleration. I have locked down the Windows 10 (Education, equivalent to enterprise but with much of the consumer spy net disabled by default) install using Local Group Policy, the Security Baseline scripts and the Limited functionality baseline, and turning on all the type 1 hypervisor protections. I also use a few policy based routing rules to limit internet access to the (4) necessary windows update endpints, the catia update server, and the kerberos server so I am not browsing the web there, Of course, it is always possible that windows comes preloaded with tools to rootkit Xen and Qubes. It is also possible that something I catch on qubes could break out of Zen. Still, to pose a risk to the Win machine someone would have to exercise a firmware exploit without physical access, exploit the boot chain like the recent boot hole bug, or break the bitlocker encryption. I am more worried about my non-neutered ME. Considering my threat model I feel ok with my setup.