This guide demonstrates how to run Qubes OS alongside Windows with Secure Boot enabled.
IMPORTANT: This approach is specifically intended for users who require Secure Boot for their other operating systems (e.g., Windows with BitLocker). But note that Qubes OS images (Xen, Linux) are NOT verified.
While this guide focuses on Windows, the method should work for any OS that does not rely on shim/MOK for its own boot process.
Background
It is generally not recommended to dual-boot Qubes OS with other operating systems. Because Qubes does not natively support Secure Boot, unencrypted components—such as the EFI partition, /boot, and LUKS headers—could potentially be tampered with by a compromised secondary OS.
A solid countermeasure is this setup, which moves unencrypted data to a detached USB drive. You simply remove the drive when using the other OS.
However, things get messy when the secondary OS requires Secure Boot (e.g., for BitLocker compliance). Constantly toggling Secure Boot in the BIOS every time you switch between OSes is a significant friction point.
How-To
Essentially there are only three steps:
- Install and configure the shim EFI binary.
- Disable MOK validation:
mokutil --disable-validation - Enroll GRUB EFI binary (first time on boot)
I have successfully tested this using my refined USB setup, though it should theoretically work with the original detached-header setup as well.
How it works
- UEFI sees that Secure Boot is ON.
- Windows executes normally and reports that Secure Boot is active.
- Qubes OS boots via shim and grub. Since shim is signed, it is executed successfully by the UEFI. Because MOK validation is disabled, shim allows GRUB to load Xen and Linux kernels without signatures.
Security Implications
This configuration should be at least as secure as a standard Qubes setup using a detached USB.
If you are using my refined USB setup—where the Qubes /boot directory resides in an encrypted partition—there is further potential for hardening. For instance, one could embed the LUKS header inside the intermediate GRUB binary and sign/enroll it. If the GRUB binary is modified, the shim will detect it and ask you to explicitly enroll it. This might provide enough security to store these components on the internal disk rather than a detached USB, though that requires further testing. Note: this does not protect from evil maid.
For those seeking a fully verified boot chain, you can manually sign all related files. Excellent guides for that level of hardening already exist here on the forum.