Building a UKI on Qubes?

Noah-Raketic · January 30, 2026, 8:04pm

Currently, it’s not possible to boot past the GRUB for Qubes OS when Secure Boot is enabled in the UEFI, even with self-signed EFI entries or manually enrolling their hashes in the Authorized Signatures database. This means that for systems without the hardware for Qubes AEM, Qubes doesn’t support any bootloader verification.

A Unified Kernel Image would allow users to use Secure Boot, as well as securely unlocking their system using the TPM with a PIN (which otherwise can’t ensure boot integrity before releasing the key).

I heard that a Unified Kernel Image can be built for Qubes, but I could not find documentation about it anywhere. Does anyone know how this can be done?

ryrona · January 30, 2026, 8:08pm

You might want to follow this ticket, or maybe help contribute:

github.com/QubesOS/qubes-issues

Sign boot images

opened 03:19AM - 12 May 23 UTC

marmarek

C: builder C: Xen security P: default waiting for upstream

[How to file a helpful issue](https://www.qubes-os.org/doc/issue-tracking/) #…## The problem you're addressing (if any) "UEFI Secure Boot" support will require several changes in the system. This ticket is a subtask about changes to the packaging. ### The solution you'd like 1. Sign grubx64.efi with a dedicated key. 2. Build unified xen.efi using latest "xen-hypervisor" and "kernel" packages (make it a new package with a version being combination of both). Configure it the way to allow dom0 command line via xen.efi parameters (if this isn't supported mode, it will require a xen patch). 3. Sign resulting xen.efi too. 4. Make grub to load xen.efi and give it dom0 command line like it would do via separate `module2` command. Ship all of the above as separate package(s), alternative to default boot packages. They may conflict with standard ones (forcing replacing them), or co-exist under different file names. The latter is probably friendlier to the user. ### The value to a user, and who that user might be This ticket is **NOT** about full UEFI Secure Boot support (for that we have #4371). It is only about preparing initial build and configuration infrastructure for it.

I also found this one with a quick search on the bug tracker, may be relevant:

github.com/QubesOS/qubes-issues

xen-4.19.3.efi doesn't work with systemd-ukify

opened 06:06PM - 24 Dec 25 UTC

osresearch

C: Xen P: default needs diagnosis affects-4.3

### Qubes OS release Qubes OS 4.3 ### Brief summary The `xen-4.19.3.efi` file… has extra sections and it doesn't work with `systemd-ukify`. A clean build of xen 4.19 seems to work fine. ### Steps to reproduce 1. Try to `ukify` the qubes 4.3 kernel and ramdisk: ``` ukify build \ -o test.efi \ --stub xen-4.19.3.efi \ --section .config:@xen.cfg \ --section .kernel:@vmlinuz \ --section .ramdisk:@initrd.img ``` ### Expected behavior ``` Wrote unsigned test.efi ``` ### Actual behavior ``` Traceback (most recent call last): File "/home/hudson/xen-uki/./ukify", line 1752, in <module> main() ~~~~^^ File "/home/hudson/xen-uki/./ukify", line 1741, in main make_uki(opts) ~~~~~~~~^^^^^^ File "/home/hudson/xen-uki/./ukify", line 913, in make_uki pe_add_sections(uki, unsigned_output) ~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^ File "/home/hudson/xen-uki/./ukify", line 646, in pe_add_sections raise PEError(f'Not enough header space to add section {section.name}.') PEError: Not enough header space to add section .kernel. ``` ### Additional information There is another issue with `systemd-ukify` that it doesn't like one of the Xen sections that is marked W+X, so I had to comment out the "treat warnings as errors" to get past it. I'm trying to debug this in qemu as well as part of testing UEFI Secure Boot with the Qubes 4.3 release, but run into the e820 memory map overlap error with OVMF.

Bottom line is, Xen is complicating things, but work is being done in the direction of adding boot security, slowly.

ryrona · January 30, 2026, 8:10pm

As long as one is aware this is not secure against sophisticated attackers. Regular LUKS2 encryption with long passphrase as QubesOS has today is way more secure, even if less convenient.

Noah-Raketic · January 30, 2026, 8:13pm

Whether a TPM’s key storage is “not secure against sophisticated attackers” mostly depends on the TPM implementation.

Noah-Raketic · January 30, 2026, 8:14pm

I noticed that the first thread links to a uki-generate script. Does that suggest that building a UKI is possible currently?

ryrona · January 30, 2026, 8:19pm

And how long you intend to keep your data secure if your device is taken, as pretty much any TPM or other security chip will get all their security broken within 5 years from initial release. Whereas LUKS2 with long passphrase can keep your data secure for much longer than that.

Don’t know. I haven’t tried.

Noah-Raketic · February 5, 2026, 8:22pm

I tested the script. It turns out that it absolutely is possible to build a UKI, and I’m now able to boot Qubes with Secure Boot enabled via the self-signed EFI entry.

I plan to document how it was done, in case anybody else would like to use one themselves.