Sign boot images #8206
Labels
C: builder
Qubes Builder
C: Xen
P: default
Priority: default. Default priority for new issues, to be replaced given sufficient information.
security
This issue pertains to the security of Qubes OS.
T: enhancement
Type: enhancement. A new feature that does not yet exist or improvement of existing functionality.
Comments
marmarek
added
T: enhancement
andrewdavidwong
added
the
security
I think this might be a typo. 😅 To help me (and others) better understand this issue, could we make the problem being addressed more explicit?
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).
|
|
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.
Is this necessary for secure boot to be meaningful? |
I don't think it's relevant in this ticket at all, especially since for systemd-boot you'd need unified binary too.
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 |
No Xen patch should be necessary: the command line to |
|
An attempt from today's laboratory session.
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
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:
(The
Unfortunately, the last point is where I got kind of lost. It seems like during this boot process, So I ran dmesgxl dmesgDid 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? |
marmarek
added a commit
to marmarek/qubes-core-admin-linux
that referenced
this issue
Nov 16, 2023
They don't have any secrets, and having them root-only breaks building initramfs as non-root. QubesOS/qubes-issues#8206
marmarek
added a commit
to marmarek/qubes-core-admin-linux
that referenced
this issue
Nov 24, 2023
They don't have any secrets (the file is publicly available in git repository and rpm package), and having them root-only breaks building initramfs as non-root. Add -P option to usbguard-daemon to skip config file permission check. QubesOS/qubes-issues#8206
fepitre
added a commit
to fepitre/qubes-core-agent-linux
that referenced
this issue
Dec 2, 2023
Related to QubesOS/qubes-issues#8206
|
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 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. |
fepitre
added a commit
to fepitre/qubes-builderv2
that referenced
this issue
Dec 10, 2023
Related to QubesOS/qubes-issues#8206
@marmarek could you be more precise about this? Did you download it as I did, or get it from dom0? I have no idea if this makes any difference. The same question about kernel and initramfs.
Better proof should be in
In my comment, I had this:
But I'm wrong here. The template is fedora-40-xfce. I'll try to reproduce your results and get back to you with confirmation. One correction: Together with @fepitre and @aronowski, we modified the initials, but honestly, I am trying to remember what and why. That shouldn't be a problem because we tested that together without taking initramfs, just xen.efi, but I wanted to let you know. |
I took them from dom0, but it should make no difference (and for kernel+initramfs, it didn't even reach that far in your case before). Xen is the exact same version as yours. |
|
I tried following: # remove previous experiments
rm -rf boot/ usr/
rm -rf initramfs-6.10.7-1.qubes.fc37.x86_64.img
# unpack kernel and hypervisor
rpm2cpio xen-hypervisor-4.17.4-5.fc37.x86_64.rpm |cpio -imd
rpm2cpio kernel-latest-6.10.7-1.qubes.fc37.x86_64.rpm |cpio -imd
# generate initramfs
dracut --no-hostonly --kver 6.10.7-1.qubes.fc37.x86_64 ./initramfs-6.10.7-1.qubes.fc37.x86_64.img
# generate UKI
./uki-generate ./boot/efi/EFI/qubes/xen-4.17.4.efi ./config ./boot/vmlinuz-6.10.7-1.qubes.fc37.x86_64 ./initramfs-6.10.7-1.qubes.fc37.x86_64.img xen-4.17.4.uki-unsigned.efi
# generate DB and PK
openssl req -new -x509 -newkey rsa:2048 -nodes -keyout DB.key -out DB.crt
openssl x509 -in DB.crt -out DB.cer -outform DER
openssl req -new -x509 -newkey rsa:2048 -nodes -keyout PK.key -out PK.crt
openssl x509 -in PK.crt -out PK.cer -outform DER
# make target dir
mkdir -p test-esp/EFI/BOOT
# sign
sbsign --key DB.key --cert DB.crt --output xen-4.17.4.uki.efi xen-4.17.4.uki-unsigned.efi
# copy artifacts
cp DB.cer PK.cer test-esp/
cp xen-4.17.4.uki.efi test-esp/EFI/BOOT/BOOTX64.efi
# prepare vars
cp /usr/share/OVMF/OVMF_VARS.secboot.fd .
# run QEMU
qemu-system-x86_64 -m 2G -M q35,kernel-irqchip=split -drive if=pflash,format=raw,readonly=on,file=/usr/share/edk2/ovmf/OVMF_CODE.secboot.fd -drive if=pflash,format=raw,file=OVMF_VARS.secboot.fd -net none -nographic -chardev file,path=debug.log,id=ovmf-debug -device isa-debugcon,iobase=0x402,chardev=ovmf-debug -drive file=fat:rw:$PWD/test-esp,media=disk,index=0,format=rawThis give me [Bds] Expand \EFI\BOOT\BOOTX64.EFI -> PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)/\EFI\BOOT\BOOTX64.EFI
[Security] 3rd party image[0] can be loaded after EndOfDxe: PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)/HD(1,MBR,0xBE1AFDFA,0x3F,0xFBFC1)/\EFI\BOOT\BOOTX64.EFI.
DxeImageVerificationLib: Image is not signed and SHA1 hash of image is not found in DB/DBX. |
|
Interesting, let me re-test this once more from clean start. |
marmarek
added a commit
to marmarek/qubes-vmm-xen
that referenced
this issue
Sep 24, 2024
|
I did the same steps and it works for me... |
|
@marmarek, I have the same result. Maybe we need a third party to check. Or something is broken in my environment that we don't consider necessary. How do we make sure we run the same stack? My Tcg2Protocol is not installed. - Not Found
None of Tcg2Protocol/CcMeasurementProtocol is installed.
InstallProtocolInterface: 5B1B31A1-9562-11D2-8E3F-00A0C969723B 7D4F0240
ConvertPages: failed to find range FFFF82D040000000 - FFFF82D0449FFFFF
Loading driver at 0x00072600000 EntryPoint=0x00072C32250 .efi <--- no filename
InstallProtocolInterface: BC62157E-3E33-4FEC-9920-2D3B36D750DF 7DA1EE98Some logs from me with sha256sum of artifacts: [user@builders qubes]$ rpm2cpio xen-hypervisor-4.17.4-5.1.fc37.x86_64.rpm |cpio -imd
100757 blocks
[user@builders qubes]$ sha256sum boot/
efi/ xen-4.17.4.config xen-4.17.4.gz
[user@builders qubes]$ sha256sum boot/
efi/ xen-4.17.4.config xen-4.17.4.gz
[user@builders qubes]$ sha256sum boot/efi/EFI/qubes/xen-4.17.4.efi
189f604d98d07ee62d6adb9c144c2a7cd82da9f2f907b68ac0030d17612ce130 boot/efi/EFI/qubes/xen-4.17.4.efi
[user@builders qubes]$ rpm2cpio kernel-latest-6.10.7-1.qubes.fc37.x86_64.rpm |cpio -imd
42864 blocks
[user@builders qubes]$ sha256sum ./config ./boot/vmlinuz-6.10.7-1.qubes.fc37.x86_64 ./initramfs-6.10.7-1.qubes.fc37.x86_64.img
6d316ad09be893e0cb05b912f1a80a9c8c8712e3083a9da32d1bdccbd85fd846 ./config
4de4a9c3a694cdf611bb77208a14700d6d042369add6a5be1c7191a64057620b ./boot/vmlinuz-6.10.7-1.qubes.fc37.x86_64
9b01deae3807b45c7834440c63cdf7aa30776c02e6cab78c4b4c0997e749fc75 ./initramfs-6.10.7-1.qubes.fc37.x86_64.img
[user@builders qubes]$ ./uki-generate ./boot/efi/EFI/qubes/xen-4.17.4.efi ./config ./boot/vmlinuz-6.10.7-1.qubes.fc37.x86_64 ./initramfs-6.10.7-1.qubes.fc37.x86_64.img xen-4.17.4.uki-unsigned.efi
[user@builders qubes]$ sha256sum ./xen-4.17.4.uki-unsigned.efi
6d3d47cb7d36d6bce81dbfe58fe286dde0c23d305fc58b228e93b3d19d90a247 ./xen-4.17.4.uki-unsigned.efiI'm unsure if [user@builders qubes]$ sbsign --key DB.key --cert DB.crt --output xen-4.17.4.uki.efi xen-4.17.4.uki-unsigned.efi
warning: data remaining[63525920 vs 63782155]: gaps between PE/COFF sections?
warning: data remaining[63525920 vs 63782160]: gaps between PE/COFF sections?
Signing Unsigned original imageThe result is still the same: BdsDxe: loading Boot0001 "UEFI QEMU HARDDISK QM00001 " from PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)
BdsDxe: starting Boot0001 "UEFI QEMU HARDDISK QM00001 " from PciRoot(0x0)/Pci(0x1F,0x2)/Sata(0x0,0xFFFF,0x0)
Xen 4.17.4 (c/s ) EFI loader
Using builtin config file
kernel: 0x0000000074a00000-0x00000000755ab200
ramdisk: 0x0000000075600000-0x0000000076ca3406
!!!! X64 Exception Type - 0D(#GP - General Protection) CPU Apic ID - 00000000 !!!!
ExceptionData - 0000000000000000
RIP - 00000000728278E9, CS - 0000000000000038, RFLAGS - 0000000000000006
RAX - 0000000072E15638, RCX - 000000007EEE7FFF, RDX - 33553D83BB26C4C3
RBX - 0000000072C66CC8, RSP - 000000007EEE47B8, RBP - 000000007EEE4850
RSI - 000000000040B953, RDI - 0000000072E15638
R8 - 0000000000000001, R9 - 0000000072E58380, R10 - BAAAD00000000000
R11 - 00000000FFFFFFFB, R12 - 000000007EEE4808, R13 - 0000000072A21F37
R14 - 0000000000000000, R15 - 0000000072E15638
DS - 0000000000000030, ES - 0000000000000030, FS - 0000000000000030
GS - 0000000000000030, SS - 0000000000000030
CR0 - 0000000080010033, CR2 - 33553D83BB26C4C3, CR3 - 000000007E801000
CR4 - 0000000000000668, CR8 - 0000000000000000
DR0 - 0000000000000000, DR1 - 0000000000000000, DR2 - 0000000000000000
DR3 - 0000000000000000, DR6 - 00000000FFFF0FF0, DR7 - 0000000000000400
GDTR - 000000007E5E1000 0000000000000047, LDTR - 0000000000000000
IDTR - 000000007DF98018 0000000000000FFF, TR - 0000000000000000
FXSAVE_STATE - 000000007EEE4410
!!!! Find image based on IP(0x728278E9) (ImageBase=0000000072600000, EntryPoint=0000000072C32250) !!!!
|
|
Are you sure you have copied the new signed xen.efi to test-esp/EFI/BOOT/BOOTX64.efi? (easy to forget...) |
|
Full debug.log from successful start: https://gist.github.com/marmarek/2c9f5cc4dbcd7838f1e6fb07af453db9 |
|
Are you sure you have copied the new signed xen.efi to test-esp/EFI/BOOT/BOOTX64.efi? (easy to forget...) [user@builders qubes]$ sha256sum test-esp/EFI/BOOT/BOOTX64.efi xen-4.17.4.uki.efi
295e2a120f93c8e8f350a7680f29231e63038a7dfdbdd6e932128fa32ae030cb test-esp/EFI/BOOT/BOOTX64.efi
295e2a120f93c8e8f350a7680f29231e63038a7dfdbdd6e932128fa32ae030cb xen-4.17.4.uki.efi |
There are only a few differences. Definitely, in your case, there is much more reading before kicking xen.efi from OVMF. For example, you would have a bigger xen.efi. Can you send me the DER cert and Xen.efi so that I can check its behavior? How big is your UKI? [user@builders qubes]$ du xen-4.17.4.uki.efi
62292 xen-4.17.4.uki.efi |
I'll send the file privately, as it's too big for github upload... |
|
@marmarek, your UKI works (no #GP), so I need to do something differently. I removed the signature and added mine using |
|
The size difference is probably attributed to initramfs. At this early stage, its content shouldn't matter (it's Linux parsing it, but it crashes before Linux even starts). But its size may change things (memory layout etc). |
|
You can also compare sections of the two files ( |
|
Config does not change anything. Diff of yours (good) and my (bad) xen uki objdump: --- good_objdump 2024-09-24 21:14:52.992079963 +0200
+++ bad_objdump 2024-09-24 21:14:37.893078778 +0200
@@ -17,29 +17,29 @@
CONTENTS, ALLOC, LOAD, DATA
6 .bss 001743a0 ffff82d040817000 ffff82d040817000 00000000 2**4
ALLOC
- 7 .reloc 000015c8 ffff82d04098b3a0 ffff82d04098b3a0 0024fc60 2**2
+ 7 .reloc 000015bc ffff82d04098b3a0 ffff82d04098b3a0 0024fc60 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
- 8 .debug_a 0009781e ffff82d04098c968 ffff82d04098c968 00251240 2**0
+ 8 .debug_a 0009781f ffff82d04098c95c ffff82d04098c95c 00251220 2**0
CONTENTS, READONLY, DEBUGGING
- 9 .debug_i 00c7a2b3 ffff82d040a24186 ffff82d040a24186 002e8a60 2**0
+ 9 .debug_i 00c7a413 ffff82d040a2417b ffff82d040a2417b 002e8a40 2**0
CONTENTS, READONLY, DEBUGGING
- 10 .debug_s 00583682 ffff82d04169e439 ffff82d04169e439 00f62d20 2**0
+ 10 .debug_s 00583798 ffff82d04169e58e ffff82d04169e58e 00f62e60 2**0
CONTENTS, READONLY, DEBUGGING
- 11 .debug_l 001fd8c9 ffff82d041c21abb ffff82d041c21abb 014e63c0 2**0
+ 11 .debug_l 001fd8d7 ffff82d041c21d26 ffff82d041c21d26 014e6600 2**0
CONTENTS, READONLY, DEBUGGING
- 12 .debug_l 0004c3ac ffff82d041e1f384 ffff82d041e1f384 016e3ca0 2**0
+ 12 .debug_l 0004c3ac ffff82d041e1f5fd ffff82d041e1f5fd 016e3ee0 2**0
CONTENTS, READONLY, DEBUGGING
- 13 .debug_f 0003ff10 ffff82d041e6b730 ffff82d041e6b730 01730060 2**0
+ 13 .debug_f 0003ff14 ffff82d041e6b9ac ffff82d041e6b9ac 017302a0 2**0
CONTENTS, READONLY, DEBUGGING
- 14 .debug_l 00263b32 ffff82d041eab640 ffff82d041eab640 0176ff80 2**0
+ 14 .debug_l 00263b40 ffff82d041eab8c0 ffff82d041eab8c0 017701c0 2**0
CONTENTS, READONLY, DEBUGGING
- 15 .debug_r 0006bf82 ffff82d04210f178 ffff82d04210f178 019d3ac0 2**0
+ 15 .debug_r 0006bf82 ffff82d04210f400 ffff82d04210f400 019d3d00 2**0
CONTENTS, READONLY, DEBUGGING
- 16 .debug_a 00006ef0 ffff82d04217b100 ffff82d04217b100 01a3fa60 2**0
+ 16 .debug_a 00006ef8 ffff82d04217b388 ffff82d04217b388 01a3fca0 2**0
CONTENTS, READONLY, DEBUGGING
- 17 .config 00000068 ffff82d042200000 ffff82d042200000 01a46960 2**2
+ 17 .config 00000257 ffff82d042200000 ffff82d042200000 01a46ba0 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
- 18 .kernel 00bab200 ffff82d042400000 ffff82d042400000 01a469e0 2**2
+ 18 .kernel 00bab200 ffff82d042400000 ffff82d042400000 01a46e00 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
- 19 .ramdisk 0192e9a1 ffff82d043000000 ffff82d043000000 025f1be0 2**2
+ 19 .ramdisk 016a3406 ffff82d043000000 ffff82d043000000 025f2000 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATAIIUC except reloc there are no meaningful difference between your and mine binary. |
|
Reloc difference is due to the PrintErrMesg fix - mine was plain R4.2 xen.efi without that fix. And yet, it worked... Honestly, I'm out of ideas at this point. |
|
AFAIR during the summit we hit the |
|
Here's an observation. This means that we're after the use of |
|
Progress: this seems to be crashing on printk after (failed) So, two tracks now:
|
|
Small note, In other code paths, the serial is used for this purpose. At least it will be possible to get the I would also print the entire I would also reset the memory pointed at Why instead of deleting entries from |
But that is crashing here, no?
That's a very good question. And git blame says I should know the answer... |
Not that early on boot it wont. You're ahead of |
I was not precise enough. In
Reading the commit message there, I cannot see the explanation for the In theory, if PS: Found at https://uefi.org/specs/UEFI/2.9_A/02_Overview.html, after calling |
Ah, I see. Let me try something like this.
The weird part is that it ( As for @pietrushnic can you share console log from successful boot with my binary? It should include memory map. But also, can you share the broken binary? |
|
I got the binary, and reproduced the issue. With some extra debug "prints", I got SetVirtualAddressMap returns 3 (EFI_UNSUPPORTED), which according to the UEFI spec means:
So, I looked at the config, and indeed there is |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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
module2command.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.
The text was updated successfully, but these errors were encountered: