Open marmarek opened 1 year ago
The problem you're addressing (if any)
R4.2
I think this might be a typo. :sweat_smile:
To help me (and others) better understand this issue, could we make the problem being addressed more explicit?
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.
This is useful to differentiate this issue from other issues, but it's still not entirely clear to me what the value prop is. My general guess is improved security, but I'm not entirely clear on exactly which forms of attack this is designed to mitigate (and which it is not), for example.
This is useful to differentiate this issue from other issues, but it's still not entirely clear to me what the value prop is. My general guess is improved security, but I'm not entirely clear on exactly which forms of attack this is designed to mitigate (and which it is not), for example.
This on its own, prevents modifications of grub, xen and linux kernel in /boot, as long as the attacker cannot modify UEFI (either the binary itself, or its settings to disable SecureBoot or add their own key). The parts not covered by this tickets are:
Specific steps in this ticket:
Why use GRUB instead of systemd-boot? GRUB has a history of security holes that it takes a long time to fix.
protection of xen/kernel parameters
Is this necessary for secure boot to be meaningful?
Why use GRUB instead of systemd-boot? GRUB has a history of security holes that it takes a long time to fix.
I don't think it's relevant in this ticket at all, especially since for systemd-boot you'd need unified binary too.
protection of xen/kernel parameters
Is this necessary for secure boot to be meaningful?
Depending on what you want to achieve. If just compliance with MS requirements, probably not. But if using UEFI SecureBoot to protect system boot against malicious modifications of boot process, then yes, otherwise one could sneak for example spec-ctrl=no
to xen cmdline or add similarly harmful Linux parameter. I anticipate you'd answer something along the lines of DRTM or TPM - yes, it is an alternative approach for similar issue, not part of this ticket.
(if this isn't supported mode, it will require a xen patch).
No Xen patch should be necessary: the command line to xen.efi
is treated as part of Xen’s own command line, and on x86 anything following --
is passed to dom0.
An attempt from today's laboratory session.
- Sign grubx64.efi with a dedicated key.
I left this out as of today, since to make our desired chain work as intended with UEFI Secure Boot, the shim_lock protocol has to be present. Otherwise the error message error: shim_lock protocol not found
will show up.
- 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).
I initially tried to handcraft a unified image with @DemiMarie's uki-generate script to make sure it works fine before diving deeper into creating the whole infrastructure for a build process.
Here's a brief description of what I did:
[global]
default=qubes-aronowski
[qubes-aronowski]
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 pv-l1tf=false
noexitboot=1
mapbs=1
kernel=vmlinuz-6.1.43-1.qubes.fc37.x86_64 placeholder root=/dev/mapper/qubes_dom0-root ro rd.luks.uuid=luks-a262c494-924c-4a44-a28e-fdf253f4cc51 rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap plymouth.ignore-serial-consoles rd.driver.pre=btrfs rhgb qubes.enable_insecure_pv_passthrough
ramdisk=initramfs-6.1.43-1.qubes.fc37.x86_64.img
(The pv-l1tf=false
and qubes.enable_insecure_pv_passthrough
arguments are here, so the system works in my VirtualBox 7.0 laboratory environment, where nested virtualization is not possible - not to be used on production.)
/boot/efi/EFI/qubes/xen-uki.efi
sbsign
, using my db.key
and db.crt
filesUnfortunately, the last point is where I got kind of lost. It seems like during this boot process, efivarfs
does not get mounted and I can't mount it manually - running the mount -t efivarfs efivarfs /sys/firmware/efi/efivars/
command as root results in an error message:
mount: /sys/firmware/efi/efivars/: mount(2) system call failed: Operation not supported.
dmesg(1) may have more information after failed mount system call.
So I ran dmesg
and xl dmesg
and got the following logs:
Did I do something wrong? Maybe this approach is incorrect and I should have prepared the chain in the form of a shim binary with an embedded CA, then signed the GRUB2 and the Xen UKI binaries with the keys related to that CA?
Last week I did some work regarding shim-unsigned for Qubes OS, so GRUB2 works fine with the shim_lock protocol. Please fork my qubes-shim-unsigned repository, add the Qubes CA certificate there (I named it qubes-ca.cer
in the specfile), commit it, tag it and push these.
I've checked with a laboratory certificate and the building process should work - I've checked with my fork of qubes-builderv2.
I'm not creating a PR yet, as I suppose the qubes-shim-unsigned repo as a source of truth will be coming from QubesOS/qubes-shim-unsigned, rather than from my GitHub account. Once it's there, then I'll change the reference in the .yml file and request a PR.
How to file a helpful issue
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
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.