Secure boot support

[jasperweiss]

According the secure boot specification, users can enroll their own keys for secure boot. If the QOS bootloader were signed, users could manually enroll the signing key within the UEFI. That would be a better anti evil maid system since it doesn't require the use of potentially untrusted USB keys.

Since dom0 doesn't contain any 3rd party applications, we can enforce code signing on anything that runs within it.

This blog post mentions secure boot being problematic due to running CA's etc but providing the user with a public key they can enroll manually would be doable.

Edit: I'm aware the developers are generally not very fond of secure boot. Could anyone explain why? Alternatively a TPM could be used to unseal the drive encryption key.

Pre-OS firmware components are hashed (measured) Measurements are initiated by startup firmware (Static CRTM) Measurements are stored in a secure location (TPM PCRs) Secrets (encryption keys) are encrypted by the TPM and bounded to PCR measurements (sealed) Can only be decrypted (unsealed) with same PCR measurements stored in the TPM This chain guarantees that firmware hasn’t been tampered with

[marmarek]

See this message the further down the thread. In short: just signing bootloader and/or Xen isn't enough, and would result in something trivial to bypass (for example using kernel parameters).

[jasperweiss]

@marmarek so the bootloader should check the next piece in the boot-chain as well as as all the parameters. Wouldn't it be possible to enforce code signing throughout dom0 similar to Windows 10S?

[marmarek]

Parameters are different for each installation, so you need to sign them yourself. Read that thread.

And BTW just setting up SecureBoot as a protection against someone with physical access (replacing /boot etc) isn't enough. One can simply disable SecureBoot and you'll most likely not notice. On some systems it might be non-trivial without a BIOS password (re-flashing BIOS etc), but still very much doable with physical access. So, here SecureBoot guards only against very simple attacks. Note that SecureBoot makes much more sense on non-Qubes system, where compromising monolithic system is enough to replace boot files, without physical access.

On the other hand, AEM-like solution guard against this kind of attacks too, because it doesn't rely on BIOS to prevent the boot if something goes wrong. Instead, TPM will not release keys if you boot different binary. While there are different ways to bypass BIOS refusal to boot, you can't fake to the user data decryption if you don't have a key.

Anyway, those mechanisms are not excluding each other. Right now AEM is not compatible with UEFI, so getting either of them implemented would be an improvement.

[jasperweiss]

Indeed a TPM would be necessary to provide meaningful protection. It measures the UEFI firmware data, settings, secure boot state and provisioned signing keys prior to releasing (part of) the decryption key.

[marmarek]

Notes how kernel signing is done in Fedora build infrastructure: kernel build log:

+ '[' -f arch/x86_64/boot/zImage.stub ']'
+ _pesign_nssdir=/etc/pki/pesign
+ '[' 'Red Hat Test Certificate' = 'Red Hat Test Certificate' ']'
+ _pesign_nssdir=/etc/pki/pesign-rh-test
+ '[' -x /usr/bin/pesign ']'
+ '[' x86_64 == x86_64 -o x86_64 == aarch64 ']'
+ '[' 0 -ge 7 -a -f /usr/bin/rpm-sign ']'
++ id -un
++ uname -m
+ '[' 'Fedora Project' == 'Fedora Project' -a mockbuild == mockbuild -a x86_64 == x86_64 ']'
+ grep -q ID=fedora /etc/os-release
+ [[ bkernel04.phx2.fedoraproject.org =~ ^bkernel.* ]]
+ '[' -S /var/run/pesign/socket ']'
+ '[' -S /var/run/pesign/socket ']'
+ /usr/bin/pesign-client -t 'Fedora Signer (OpenSC Card)' -c '/CN=Fedora Secure Boot Signer' -i arch/x86/boot/bzImage -o vmlinuz.signed -s
+ '[' '!' -s -o vmlinuz.signed ']'
+ '[' '!' -s vmlinuz.signed ']'
+ mv vmlinuz.signed arch/x86/boot/bzImage

PESign tool (including pesign-client): https://github.com/vathpela/pesign Setup exposing pesign socket to kernel builders: https://infrastructure.fedoraproject.org/cgit/ansible.git/tree/roles/bkernel/tasks/main.yml?id=17198dadebf59d8090b7ed621bc8ab22152d2eb6 Mock config snippet mounting that socket inside build chroot:

# mount the pesign socket into the chroot
config_opts['plugin_conf']['bind_mount_opts']['dirs'].append(('/var/run/pesign', '/var/run/pesign' ))
config_opts['plugin_conf']['package_state_enable'] = False

In short: kernel build environment is given access to the signing key through a bind-mounted unix socket. It may be doable to replicate similar setup in our build infrastructure (with appropriate logging what gets signed).

[osresearch]

As part of adding Qubes support to safeboot, I have a preliminary patch for Xen to build a unified xen.efi + xen.cfg + bzImage + initrd (and optional xsm), which can be signed with sbsigntool (including support for using a Yubikey or other PKCS#11 token to store the private key). https://github.com/osresearch/xen/commit/765f0feecc1e1ceed206ccd310941bef8eed822c

With this modification there is no need for grub -- the UEFI firmware can validate the signature on the hypervisor bundle using the SecureBoot PK/KEK/db key chain and directly invoke it if-and-only-if the signature is valid. Although, as @marmarek pointed out in https://github.com/QubesOS/qubes-issues/issues/4371#issuecomment-427024165, it is also necessary to use a TPM sealed secret that includes the platform key and secure boot DB to be able to prevent a local attacker from reflashing with Secure Boot disabled. The tpm2-attest part of safeboot can likely be ported to dom0 for remotely attesting this, although I haven't gotten that far yet in the Qubes support.

[marmarek]

Thanks, this looks very promising!

I have two main issues with using xen.efi in general:

1. Other boot files (dom0 kernel, initrd) loading by xen.efi is very unreliable - depending how xen.efi got started and/or specific UEFI implementation the required File System Protocol Interface may be missing or unable to access those files (including limitations like supporting ESP only, which on ISO9660 is limited to 32MB - pretty tight for installation initrd). Bundling everything into xen.efi may help partially here.
2. It is quite cumbersome to modify anything about boot parameters (even things like "choose older kernel") without grub (or other bootloader with interactive menu). If you want to modify dom0 boot options, you need a file editor (grub at this point is not enough). This is especially painful if your system fails to boot - you need then external boot media to perform any kind of troubleshooting/recovery. Embedding boot files into xen.efi makes this process even harder. But you can have multiple files with different versions embedded (allows you to boot different version, but not modify boot parameters even if you temporarily disable SecureBoot).

Those two are UX and stability related issues, not necessary security related. But for anything to be considered into default installation, those are also very important. Although for non-default, for power-users only solution those are less critical.

As for security concerns mentioned earlier in this thread, I understand your approach requires each installation to use unique, user-owned keys to sign boot files and have them included into secure boot DB, right? With this assumption it should be fine. Just to be sure I haven't missed anything - there is no way to stretch this approach into something compatible with standard secure boot DB keys (MS-signed shim), right?

[osresearch]

Bundling definitely avoids having to figure out the file system APIs and also makes it possible to embed in a ROM firmware volume, if you're lucky enough to have that option.

Choosing between versions can be done with the UEFI boot manager, although this doesn't allow changing parameters.

Modifying the boot parameters is challenging, although that is somewhat intentional - since the kernel parameters and xen config are critical to security, allowing arbitrary changes by a local user/attacker is dangerous. On the (non-Qubes) safeboot systems, the configuration is to have separate EFI boot manager entries for linux, the signed+sealed+dmverity-protected system, and recovery, the signed kernel with write access, but without access to TPM sealed secrets. An administrator with access to the disk recovery key can boot into the recovery kernel, unlock with disk, install new packages, upgrade kernels, edit the linux command line, etc. Once the system has been repaired, they hash the filesystem and build a new unified Linux/initrd/etc and sign it with a hardware token. This single file goes into the ESP and replaces the existing linux target. They also pre-compute the hash of the unified image and sign a PCR policy that allows the TPM to unseal the disk encryption key when that kernel is booted.

This does require a bit more space on the ESP since the recovery and normal kernel can't share bzImage or initrd files, although that hasn't yet been a problem for the machines I've configured.

[osresearch]

For the general use case, it might be workable to have the install image signed with the distribution key and to have that key signed by Microsoft so that the installer can boot. If they don't change the defaults, they can continue to use the official kernel, initrd and config as signed by the Qubes key.

If they do want to use their own keys, perhaps during the setup the user could be prompted to setup a software or hardware key and point them towards the steps for enrolling these keys in their firmware. Then they would need to use to sign any new kernels or initrd images that they build for the dom0, as well as any xen upgrades. With safeboot it isn't seamless right now; you can boot into recovery, install updates, and then have to run a separate command to re-sign everything. This would likely only be beneficial for very

[marmarek]

Modifying the boot parameters is challenging, although that is somewhat intentional - since the kernel parameters and xen config are critical to security, allowing arbitrary changes by a local user/attacker is dangerous.

Yes, definitely. I'd imagine modifying those would change some measurement and require disk recovery key (in case TPM unseal is used later) or require disabling SB in the firmware. But still possible without external tools.

Primary + recovery boot images should solve most of it, I think. As long as the user have real option to choose which one to boot - note many UEFI do not expose such menu, notably default UEFI in Thinkpads do not have it. In that case, some extra boot manager is needed.

If they don't change the defaults, they can continue to use the official kernel, initrd and config as signed by the Qubes key.

This is a bit problematic, because dom0 kernel cmdline and initrd (currently) do contain system-specific configuration. At least UUID of LUKS partitions to unlock and where to look for root filesystem. Remember we (currently) allow quite a bit of flexibility in disk layout (lvm/btrfs etc) so we can't easily hardcode defaults and in some cases even runtime detection may be challenging and lead to not finding the right partition.

the signed+sealed+dmverity-protected system, and recovery, the signed kernel with write access, but without access to TPM sealed secrets

How would that work with distribution key? The distribution-signed blob can't possibly include sealed secrets for particular TPM and PCR values... Or perhaps the sealed keys are included in the signed part? How are they loaded then?

[osresearch]

My Thinkpad X1 (gen 5 and 6) and T490 offer EFI boot manager support -- hit F12 when the Lenovo screen is displayed to bring it up, or hit Enter and then select Boot Manager from the menu. I haven't looked deeply at other systems, so I'm not sure how common it is to have it hidden.

With safeboot we found it easier to use LVM volume names instead of UUID, which also makes it possible to sign the kernel + initrd externally and have it work on different machines. For Qubes it might make acceptable to say "default installs may use the Qubes distribution key" and have more advanced users enroll their own key (or turn off SecureBoot).

Handling the TPM sealed secrets in the distribution key case is a little trickier; the signed PCR technique wouldn't work since you don't know what the PCRs are supposed to be other than the unified xen file. There is a fall back technique of sealing based on the current PCRs and storing the sealed data in the TPM NVRAM, however, it would require the disk recovery key to be available for every update since the new xen/kernel/initrd will change the measurements. That's not wonderful from a user perspective since they will need both the UEFI key (hardware token) as well as the disk recovery key in order to do an update.

If dom0 is running without lockdown, then potentially the current key can be retrieved from the running kernel, although that opens up some other security concerns...

[marmarek]

easier to use LVM volume names instead of UUID

Qubes uses LVM names too. I'm referring to the LUKS partition UUID.

[osresearch]

As a proof of concept I have Qubes 4.1 booting with a unified Xen 4.13 on real hardware, where the hypervisor, vmlinuz, initrd, and configuration are signed with my own Yubikey. The xen.cfg file is hand-converted from the grub config (with some extra lockdown and iommu parameters)::

[global]
default=qubes-verbose

[qubes-verbose]
options=placeholder console=none dom0_mem=min:1024M dom0_mem=max:4096M ucode=scan smt=off gnttab_max_frames=2048 gnttab_max_maptrack_frames=4096 no-real-mode edd=off efi=attr=uc
noexitboot=1
mapbs=1
kernel=vmlinuz placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=luks-f03ca0fb-2c19-4f83-9ae7-88bf6c2faf19 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles rd.driver.pre=btrfs rhgb lockdown=confidentiality intel_iommu=on efi=disable_early_pci_dma
ramdisk=initrd.img

For the initial install I signed my own version of the DVD, which worked for the first phase, but the reboot to finalize the install failed since the xen it installed into the boot partition was not signed. So I turned off secure boot, booted into Qubes to finish the install, then rebooted into running Qubes, unified+signed the resulting kernel and initrd, and then turned secure boot back on.

Not the easiest workflow... I think it can be made doable for casual users if there is a way to not include the rd.luks.uuid= in the config file, and if the initrd can be pre-built. Does the resulting one after the dom0 install vary, or would it be possible to build a generic dom0 initrd that could be signed as part of the distribution?

[marmarek]

(with some extra lockdown and iommu parameters)

I don't think IOMMU parameters to the dom0 kernel makes any difference - IOMMU is managed by Xen. Also, noexitboot=1, mapbs=1 should not be needed anymore.

I think it can be made doable for casual users if there is a way to not include the rd.luks.uuid= in the config file

Theoretically we can configure installer to use constant UUID. But we risk collisions then...

Another thing that is installation-dependent (either on kernel cmdline, or built into initramfs) is the keyboard layout to use during LUKS passphrase prompt. There can be few more similar options.

Does the resulting one after the dom0 install vary

Currently yes (includes a bunch of configs from the target system), but I think it can be made generic quite easily (at least --no-hostonly, perhaps few other options too). But the issue with few configuration parameters remains. Is there any place we could use to store some extra parameters, that do not also give too much control over the system? Some place that could be parsed by a dedicated script inside initramfs and nothing else - perhaps patch xen.efi to save efi stub parameters (but do not parse as xen options)? Or some EFI variables?

For the initial install I signed my own version of the DVD

Have you booted it from real DVD, or USB stick? I guess the latter. The ISO9660 format has limitation of 32MB for EFI boot partition. Fitting Xen+Linux+initramfs there was a major PITA. Now we can use grub2-efi to load some of the files from other place. Can you confirm the unified efi binary will also work this way (with either signed grub2-efi or shim+grub2-efi)?

[osresearch]

I've only booted from a USB stick; haven't had a physical DVD in years... The EFI executable should work from grub, although I don't have an easy way to test that on my system.

The additional configuration could go into EFI variables if they are not sensitive (in either sense), with some well tested parsers in the initrd. For instance with the change to add signed PCR policy, safeboot stores the signature in a UEFI variable (https://github.com/osresearch/safeboot/pull/58). If an attacker changes it, the worst they can do is prevent the TPM from unsealing the disk key (the size is limited and the data is a raw binary signature). There are other things that are nice to have, like rollback protection, which required storing counters in the NVRAM (so that the secrets can be unsealed by newer signed images, but not by older ones) (https://github.com/osresearch/safeboot/pull/62).

If the configuration values are sensitive, putting sealed blobs into NVRAM variables and using the TPM to unseal them is another option, although that does add an additional hardware dependency into the mix.

[osresearch]

The unified Xen patches are making their way through the xen-devel mailing list after several revisions and comments from the developers. https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg01735.html

Backporting the fixes to the Xen used in Qubes 4.1 (and even 4.0) is quite easy since there isn't a huge amount of churn in the EFI boot path. Even if the Qubes distribution doesn't use the UEFI Secure Boot aspects, having the unified patches built into the mainline Qubes xen-vmm module would make it possible for advanced users to enable it for their own machines without having to rebuild the hypervisor.

Also, there was quite a bit of discussion about what Secure Boot compliance would mean for Xen overall. There are quite a few features that need to be turned off in order to avoid a local attacker from modifying the hypervisor. Andrew Cooper wrote in https://lists.xenproject.org/archives/html/xen-devel/2020-08/msg00290.html:

Things like LIVEPATCH and KEXEC need compiling out, until they can be taught to verify signatures. Beyond that, things like the GDB serial stub probably need a way of being able to be compiled out, and then being compiled out. (This is definitely not an exhaustive list.) Xen's secureboot requirements also extend to the dom0 kernel, due to the responsibility-sharing which currently exists. For a Linux dom0, Xen must ensure that lockdown mode is forced on (/dev/mem in dom0 still has a lot of system level power). At a minimum, this involves extending lockdown mode to prohibit the use of /{dev/proc}/xen/privcmd, which is still a trivial privilege escalation hole in PV Linux that noone seems to want to admit to and fix. I think it is great that work is being started in this direction, but there is a huge quantity of work to do before a downstream could plausibly put together a Xen system which honours the intent of SecureBoot. I know Safeboot has different goals/rules here, but whatever we put together called "Secure Boot support" will have to be compatible with Microsoft's model for it to be useful in the general case.

I think the Qubes audience doesn't need or want a strict Microsoft-definition of Secure Boot, and hope that with these patches plus some configuration updates it will be possible for users to better protect their systems.

[marmarek]

Backporting the fixes to the Xen used in Qubes 4.1 (and even 4.0) is quite easy since there isn't a huge amount of churn in the EFI boot path. Even if the Qubes distribution doesn't use the UEFI Secure Boot aspects, having the unified patches built into the mainline Qubes xen-vmm module would make it possible for advanced users to enable it for their own machines without having to rebuild the hypervisor.

Yes, if there are no major incompatibilities, we can definitely do that.

I think the Qubes audience doesn't need or want a strict Microsoft-definition of Secure Boot, and hope that with these patches plus some configuration updates it will be possible for users to better protect their systems.

Yes, exactly. While having Microsoft-signed boot binary (whether with shim or some other solution) would ease installing Qubes on UEFI-enabled systems, it doesn't much affect the security aspect compared to your own keys - in fact, using own keys may be even better option (for example without grub and trusting MS keys we avoid issues like BootHole).

[osresearch]

The unified Xen hypervisor patches have finally made it through the mailing list and have almost all been pushed to staging! https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=8a71d50ed40bfa78c37722dc11995ac2563662c3

For a backport, do you prefer the individual commits (there are six patches in total) or is a single squashed patch easier?

[marmarek]

Congratulation! Preferably as landed upstream (individual commits).

[osresearch]

There were a few modifications required to back port it due to Makefile changes, as well as a few extra patches related to const* fixes in the efi code. Draft PR is https://github.com/QubesOS/qubes-vmm-xen/pull/89

[tlaurion]

@osresearch @marmarek : When comparing two root snapshots per

[user@dom0 ~]$ cat /lib/systemd/system-shutdown/root-autosnap 
#!/bin/sh

#This permits wyng-backup to backup root-autosnap and root-autosnap-back, taken at each system shutdowns like any other QubesOS LVMs.
#This also permits to restore to different states of dom0 from Heads and compare dom0 between reboots

#TODO: backup /boot content into a LVM and apply same logic, corresponding to each dom0 snapshots
#https://github.com/tasket/wyng-backup/issues/63

#We delete the backup of last shutdown snapshot (last last shutdown)
/usr/sbin/lvremove --noudevsync --force -An qubes_dom0/root-autosnap-back || true
#We take a snapshot of root-autosnap into root-autosnap-back
/usr/sbin/lvcreate --noudevsync --ignoremonitoring -An -pr -s qubes_dom0/root-autosnap -n root-autosnap-back
#We remove root-autosnap
/usr/sbin/lvremove --noudevsync --force -An qubes_dom0/root-autosnap || true
#We create root-autosnap from root
/usr/sbin/lvcreate --noudevsync --ignoremonitoring -An -pr -s qubes_dom0/root -n root-autosnap

And then we compare the content of the filesystems, we see that:

• /etc/libvirt/libxl
• /etc/lvm
• /etc/xdg/adjtime
• /home
• /root
• /var

Would need to be out of root fs to be able to have a RO QubesOS dom0 with dmverity

[tlaurion]

@marmarek @osresearch input on https://github.com/QubesOS/qubes-issues/issues/4371#issuecomment-761863958 ?

[DemiMarie]

@marmarek @osresearch input on #4371 (comment) ?

Personally I would be fine with moving these off of the root filesystem.

[tlaurion]

@marmarek ?

[jevank]

I've submitted PR with initial Qubes OS support. Tested with Lenovo X1C6/C7

[grince]

Question: will the installer of Qubes also support secureboot? when I try to boot from an usb-stick (made with the iso-image of qubes-4.1) grub on the usb-stick doesn't get started; when I try it with a non-secureboot-laptop it starts fine. since I want to use it an a secureboot-laptop I'd very much interested in having this feature ;)

I am willing to test it too, so if you have a modified ISO I shall test I am happy to do this. I already installed Debian on that system which kernels (and apparently installer) are secure-boot able if you choose "Microsoft and 3rd party certificates" as parameter.

[pietrushnic]

I'm not sure if this is the correct issue for the question about signed binaries.

We integrated the new UEFI Secure Boot menu layout, according to @marmarta suggestions, in Dasharo. Documentation is here. It most likely will be part of Dasahro for FidelisGuard and NitroPC v1.1.3.

As we discussed during Qubes OS Summit 2023, we would like to include Qubes OS Certificates in the release when you are ready to deliver signed binaries. My point is to align the Dasharo release (I assume it will be something after v1.1.3) with the date when the Qubes OS Team will have provided a certificate, which we would be able to use for UEFI Secure Boot of Qubes on Dasharo-supported hardware.

Are there any known/planned dates when that may happen?

[adrelanos]

There are two ways to to frame Secure Boot:

• A) As a usability feature: It totally makes sense to make Qubes compatible to be able to boot while modern EFI firmware default settings which come with Secure Boot enabled by default. Qubes would have to use shim [2] to be compatible to boot with god emperor Microsoft's key. [3]
• B) As a security feature: This makes limited sense. measured boot [4] seems to replace it and being better in every way. This is also what systemd is working on. systemd also working on measured boot. It's part of this talk. Love or hate systemd, that's unrelated, however measured boot as a concept is much better than Secure Boot.

More videos on the topic of measured boot:

• https://www.youtube.com/watch?v=0RSH3JXqShE
• https://www.youtube.com/watch?v=Qc75hobVjbo
• https://www.youtube.com/watch?v=pL0AMLiwPj8

Secure Boot is trust anchored in the EFI firmware. User's adding custom keys cannot be automated unless hardware would be sold with Qubes' key added by default to the firmware. Measured Boot is trust anchored in the TPM. I don't specifically trust either chip.

Coreboot, TrustedGRUB, Evil Maid, TPM, Secure Boot, Boot Guard, Heads, Librem Key, PureBoot... Confused? Rightfully so. Check out this blog post which explains them all: https://tech.michaelaltfield.net/2023/02/16/evil-maid-heads-pureboot/

---

[1] BIOS replacement that comes by default nowadays. [2] Used by Debian, Fedora, and many other distributions. [3] As sad as that is, but it is what it is. [4] Which wasn't forced on Linux distributions by Microsoft as Secure Boot was.

[pietrushnic]

Measured boot with an SRTM chain is very complex and hard to prove; what is more, it is as good as the first measurement. Code-making, the first measurement, has to be trustworthy, maybe even immutable, and protected by some root of trust (Intel Boot Guard?). A measured boot with DRTM could be much better, but it also has some limitations.

Secure Boot is trust anchored in the EFI firmware. User's adding custom keys cannot be automated unless hardware would be sold with Qubes' key added by default to the firmware. Measured Boot is trust anchored in the TPM. I don't specifically trust either chip.

The mechanism of UEFI Secure Boot is implemented in UEFI BIOS, but if that mechanism is implemented correctly (Dasharo OSFV) can validate that, then the best use of UEFI Secure Boot is to give power to the users and give them tools to own their boot process by signing kernel and all relevant parts. Of course, that may be too complex for many, and we can make shortcuts like shipping hardware with Qubes OS keys. Or shipping hardware with keys allows the reprovision of UEFI Secure Boot from OS by the person who ordered hardware, which is probably available only for Qubes OS Certified Hardware.

https://tech.michaelaltfield.net/2023/02/16/evil-maid-heads-pureboot/

I like this article, but as you can read my comment, there are some misconceptions. I would love to discuss this issue more during Dasharo Developers vPub in March. CfP is here, so if anyone could help me drive the discussion I would appreciate that.

[pietrushnic]

My POV is from the perspective of an open-source firmware product development company founder regarding what is possible in UEFI, not how it is broken by those who implement it.

Meaningful secure boot requires a chain of verification from hardware where each firmware phase and all the privileged firmware are verified with downgrade protection against specific keys, not trusting a huge number of keys and all versions of firmware/software signed with those keys.

It is hard to disagree with that. The critical question is what factors cause we cannot achieve that in the computer industry. Also, there will be some IMHO valid arguments that the immutable root of trust in hardware without the ability to pass ownership (re-ownership) is a threat to some essential freedoms, but I don't want to diverge too much from the UEFI Secure Boot path.

x86 secure boot CAN often be configured to verify a specific key (this doesn't always work properly), but it lacks downgrade protection without doing key rotation each time a vulnerability which impacts verified boot security is fixed. It's missing a way to simply trigger downgrade protection kicking in after updates are successfully booted and working fine. On nearly any device, especially laptops and desktops, it's missing a proper chain of trust from hardware by having breaks in the chain of trust or privileged firmware that's not covered. The low-level secure boot on x86 rarely has verification of a specific key for the later stages of boot firmware and downgrade protection for it.

This paragraph is so complex and hard to digest that I want to see some paper about the claims mentioned here. There also is a mix of issues related to signing updates (UEFI Capsule Update) and UEFI Secure Boot database updates, or I misread that. Most attacks published about UEFI Secure Boot are unrelated to its design, as stated in the specification. Attacks are against incorrect implementations, misconfiguration, or bad certificate management. All those problems can be addressed by doing things better. Neglecting UEFI spec is neglecting reality, which was able to chase most OSes.

It's also almost always used in a way where only the kernel and kernel modules are verified, which doesn't offer real security properties to users. Verifying the kernel line, initramfs and enough of the core OS to provide meaningful security properties is a requirement for it to provide users with real security properties. For example, any fix for a filesystem bug in the kernel as @DemiMarie recently brought up. Data being encrypted does not remove it as attack surface for secure boot since the main threat model is attacker persistence after an exploit of some kind, not necessarily full control over the OS but enough to make changes to the OS including any part of it that's encrypted.

Something that follows a chain of trust after passing control from firmware to bootloader/OS is important to be present, but the lack of that property right now does not neglect the fact that the open-source community should leverage existing mechanisms, including UEFI Secure Boot. On the other side, I would like to highlight that the continuing chain of trust from hardware to OS includes many mechanisms because of the complexity of x86 (and any other more complex hardware, including Arm servers) supply chain. So typically, we have some immutable Root of Trust like Intel Boot Guard, then we have IBV tech following the SEC and PEI phase (maybe some IBG implementation can cover up to PEI), which handles the transition to DXE when UEFI Secure Boot starts to play a role, the transition to OS. So, we have four parties that can influence the chain of trust - the situation is different in the industrial, embedded environment.

Secure boot on x86 platforms provides no real protection against physical attacks and it's not part of what has been defined as the threat model for the main deployments of it. The threat model is only reducing where attackers can persist for remote attacks, not defending against physical attacks or putting up real barriers to privileged persistence. It's not implemented in a way that it can do either of those things by most devices or operating systems. ChromeOS has an implementation for the OS which actually verifies nearly all of the OS and has limited privileges for the persistent state. It provides meaningful security properties for ChromeOS. They don't treat physical attacks as a serious part of the threat model for it though. If the device is ever obtained by an attacker, that's treated as a lost cause beyond protecting data at rest.

Chrome OS uses coreboot vboot, which essentially relies on signature verification. We deal with it as an everyday job, and there are issues that prevent the flexible use of boots. Luckily, it is open-source, and we can fix it. UEFI Secure Boot implements the same thing - signature verification. From that POV, I don't see the difference. A threat model is also similar, but at least Chromebooks give you a physical screw that unlocks the device for development and modding purposes, so it respects your freedom much more than a typical laptop fused with Intel Boot Guard. If we can provide more freedom regarding the Intel Boot Guard, and a re-owning scheme is possible, we will get almost the same design properties. Of course, implementation is slightly different, but we can improve it if it is open.

Measured boot (attestation) is a distinct topic, even when it's integrated into encryption. It doesn't provide the same thing. It's something else that's also almost always implemented in a way that's meaningless, It's also usually extremely fragile and breaks when applying important firmware updates, although those updates are often not available or don't really treat these things as part of a real security model which also prevents it working as intended.

This is precisely what I meant when writing about SRTM.

The space surrounding x86 secure boot and attestation in particular is full of security theater and what cannot be considered anything other than scams due to selling products based on fake features. It's almost entirely performative. The blog post above is a perfect example of this merged together.

It would be great to have a live discussion to understand this claim better. I have already invited you to the Dasharo Community. Feel free to join our quarterly call and have a conversation. There can be interesting arguments for communities interested in low-level security.

[andrewdavidwong]

Friendly reminder to everyone that this issue tracker (qubes-issues) is not intended to serve as a discussion venue. Instead, we've created a designated forum for discussion and support. By contrast, this issue tracker is more of a technical tool intended to support our developers in their work. Comments on this issue (#4371), in particular, should be focused on actionable information regarding Secure Boot support in Qubes OS. Thank you for your understanding.

[pietrushnic]

I downloaded 4.2.3-rc1, moved the content to a *.img file, signed EFI/BOOT/BOOTX64.EFI with DB key, installed X.509 (RSA8192+SHA512; this crazy combination is supported, and I wouldn't be surprised if longer keys also, ECC not) cert through OVMF (based on edk2-stable202408) UEFI Secure Boot menu (among PK and KEK). Then, booted. It fails quickly:

error: shim_lock protocol not found.
error: you need to load the kernel first.
error: you need to load the kernel first.

Press any key to continue...

This is expected because there is no shim in the image. When I tried to use the Ubuntu one in hand, I noticed Shim could not correctly chain to Grub, stating a security violation despite DB having a key that signed Grub, and Grub loads directly without problems. I'm not an expert here, but the shim I'm using supports SBAT, but apparently, Qubes OS GRUB2 does not. Chainloading by Shim Grub from Ubuntu signed with my key works without issues. Of course, I'm stripping signatures first with pesign since double signing doesn't seem to work with Shim.

There are essentially two main issues:

• What is needed to successfully install Qubes OS in the presence of UEFI Secure Boot, assuming a power user? I mean a power user who can modify ISO/IMG, generate keys, configure UEFI Secure Boot, and get shim.
• How do you enable UEFI Secure Boot after Qubes OS is installed? - This is a safeboot scenario that was contributed here: https://github.com/osresearch/safeboot/pull/156. Some time ago, I tried that, and I could not compile the safeboot packages, but I see some patches referring to PR were introduced, so I'm happy to try that again unless this is a neglected path for some reason.

[marmarek]

The default installation loads multiboot2 binary (xen.gz) that doesn't support signing. There are some attempts to pack MB2 binary into PE binary to be signed, but that's not what we decided to do. Our current plan is to build an unified xen.efi binary and sign that (see https://github.com/QubesOS/qubes-issues/issues/8206). So, to (not really) answer your questions - currently there is no easy path from R4.2 installation to a one with secure boot (the way we want it). It requires using different boot binaries (and building them yourself first). We plan to include pre-built unified xen.efi in R4.3 (https://github.com/QubesOS/qubes-vmm-xen-unified).

[pietrushnic]

So, to (not really) answer your questions - currently there is no easy path from R4.2 installation to a one with secure boot (the way we want it). It requires using different boot binaries (and building them yourself first). We plan to include pre-built unified xen.efi in R4.3 (https://github.com/QubesOS/qubes-vmm-xen-unified).

I would be glad to experiment to deliver status at the summit and continue during the hackathon. I guess it is closely related to trying queso-builderv2. Would it be sufficient to build just that one package, or is there some dependency hell I cannot see right now?

The second question is still open. Does it make sense to return to open safeboot contribution, assuming I have installed Qubes OS with disabled UEFI Secure Boot and would like to convert it to enabled UEFI Secure Boot as Trammel did with 4.1?