Bug#928300: secure boot via removable media path unavailable
Dear Steve, I just upgraded shim-signed and shim-signed-common to version 1.39+15.7-1; but unfortunately, secure boot still fails with the same message. I also turned on shim debug. A recording of the debug output, which is only visible when disabling secure boot in the (UEFI) BIOS, is available here: https://www.van-roermund.nl/temp/boot_shim.mp4 (I hope the quality suffices.) Cheers, Timo
Bug#928300: secure boot via removable media path unavailable
Hey guys, Apologies for not getting back to you in better time... I've just uploaded new shim-signed binaries for all of buster, bullseye and unstable based on the latest upstream version (15.7). I can't *promise* that this will fix your issue, but it would be very helpful if you could try them and let me know please. The buster upload should be already available via security.debian.org; the bullseye version is in bullseye-proposed updates if you need to look. You'll need to grab the appropriate shim-signed and shim-signed-common packages together, then install by hand. If that still doesn't help, the next thing to try is turning on shim debug using: $ sudo mokutil --set-verbosity true This will produce a *lot* of output; if you can capture it via video or on a serial port, that may help diagnose what's happening. Thanks! -- Steve McIntyre, Cambridge, UK.st...@einval.com "C++ ate my sanity" -- Jon Rabone
Bug#928300: secure boot via removable media path unavailable
Dear Chris, Steve, Was there any further follow-up on this issue? It seems that I've got pretty much the same situation here on an Intel DB75EN motherboard. Regarding the keys, pretty much the same situation: - same keys/content in the secure boot signature store (db) - similar contents in the secure boot blacklist signature store (dbx) -- I have the same first entry, only the 2nd and 3rd are missing - same keys/content in the Key Exchange Key Signature database (KEK) - but I have no public Platform Key (PK) installed The (literal) output on the screen is: Image Authorization Fail. System can not boot to this device due to Security Violation. Press Enter key to continue. Thanks in advance, Timo
Bug#928300: secure boot via removable media path unavailable
Dear Steve, > It's odd that you have files in /boot/efi but on a separate filesystem > (the rootfs?), not within the ESP. yep, on the rootfs on /dev/sda2. Must have been done by the deb-installer. Now I removed the files from the root partition as ESP is mounted over them. As expected, no change. >> The exact error message during booting with SB on is: >> Image Autorization Fail. > *Exactly* that, including the missing "h" in Authorization ? Or is > that a typo on your part? Defintively, I made the typo, since no cut&paste on the boot screen... > So, I'm curious what keys your system claims to recognise then. The > mokutil tool can dump the public keys in each of the key lists on your > system, as listed in the man page: # mokutil --pk [key 1] SHA1 Fingerprint: 77:a8:28:ba:0c:72:b4:49:79:5c:c0:5a:47:10:cf:a7:29:1c:0f:79 Certificate: Data: Version: 3 (0x2) Serial Number: c3:1d:39:ca:ef:3d:8b:dd Signature Algorithm: sha256WithRSAEncryption Issuer: CN=Intel(R) Desktop Boards Validity Not Before: Feb 2 00:09:49 2013 GMT Not After : Jan 31 00:09:49 2023 GMT Subject: CN=Intel(R) Desktop Boards Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:e0:32:77:4d:a5:f3:31:41:5f:9f:36:39:d1:93: ce:b2:16:f8:45:7f:4e:65:c1:42:2c:65:d5:96:5e: 99:22:5d:8a:16:2d:89:52:e3:e6:15:23:c7:7d:b8: 1e:55:84:7b:ca:2a:27:5d:ee:a4:33:6a:52:ff:39: a9:d4:81:21:8f:c2:f5:b8:f8:3c:85:43:60:61:68: 23:72:f1:82:b1:6d:68:ad:69:0b:fb:d1:5a:ed:d2: cd:c1:c4:81:d3:d2:ba:6f:ce:6f:ad:58:25:6f:39: 32:c5:06:ff:57:80:52:d6:8b:63:90:ec:a7:4b:cf: 2a:b0:2e:f7:13:2e:fc:a7:5b:6c:79:86:0d:d2:b3: 04:13:75:18:6d:8b:7a:35:b8:9c:71:00:1c:19:72: a4:8c:24:d4:0d:d5:e9:ca:d0:3b:a0:36:c6:55:4b: 58:b3:f3:7d:58:2d:7b:92:f0:38:e3:3f:06:8d:aa: 79:32:2e:6e:50:dc:8c:1d:e1:f7:db:0f:4b:af:61: bc:bd:d2:ba:d6:5f:ec:8f:79:3e:b8:c8:37:dc:a9: 5a:4d:80:ec:5b:ce:eb:6c:54:68:74:2a:5c:aa:bc: 25:d2:69:e1:c1:51:5b:35:c5:fb:cf:a6:58:a9:6c: f8:73:33:c6:f5:a8:d2:0a:ef:eb:e2:1f:ec:f3:aa: 84:0b Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: D2:EE:76:04:80:00:C1:E6:56:D2:FE:D7:EF:8B:5A:D8:0C:3C:B1:39 X509v3 Authority Key Identifier: keyid:D2:EE:76:04:80:00:C1:E6:56:D2:FE:D7:EF:8B:5A:D8:0C:3C:B1:39 X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha256WithRSAEncryption 38:e7:c3:21:94:97:9a:0c:96:5b:2d:0e:8a:77:1d:91:da:95: 7f:c6:d2:bc:84:cc:9d:ec:84:7c:8c:09:36:27:2c:08:d2:90: 8a:32:39:3e:4e:46:d9:42:ec:2d:90:94:38:34:24:e6:10:d9: 2e:a5:f2:ce:b2:8e:c0:51:7f:1e:b0:79:17:8b:40:1e:2c:d5: 8d:cb:70:89:ea:f9:2e:63:b1:23:80:c9:41:49:de:d0:5f:5a: bf:86:30:33:c4:57:c6:4e:2f:1a:b3:e9:63:5d:69:90:0d:b9: 00:f6:b4:3e:89:d7:97:0f:d3:ee:2c:6e:ca:a8:cb:ba:d8:4a: 38:46:de:01:6f:e1:8d:2e:6d:fe:ed:e2:55:f8:1a:6f:c7:7a: b8:7d:db:db:34:7f:3e:9e:9e:37:f7:3b:81:0e:52:ef:45:ac: d4:0b:ce:8c:f8:3d:36:ff:2f:9b:f4:e5:bc:9f:5f:d7:6b:8d: 8b:fd:63:d4:b1:69:43:cb:ae:04:07:a1:1a:e8:ed:69:09:3a: 09:3d:d2:b0:e8:b2:b7:6f:25:2c:9c:3e:24:a5:8a:5e:b6:0d: c5:1a:10:90:3f:8b:83:33:7d:d3:37:42:80:cb:6e:23:f8:09: dd:57:16:59:df:e3:8b:b4:fa:f7:82:42:90:d8:b1:71:c6:fe: 16:79:1b:87 # mokutil --kek [key 1] SHA1 Fingerprint: 31:59:0b:fd:89:c9:d7:4e:d0:87:df:ac:66:33:4b:39:31:25:4b:30 Certificate: Data: Version: 3 (0x2) Serial Number: 61:0a:d1:88:00:00:00:00:00:03 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation Third Party Marketplace Root Validity Not Before: Jun 24 20:41:29 2011 GMT Not After : Jun 24 20:51:29 2026 GMT Subject: C=US, ST=Washington, L=Redmond, O=Microsoft Corporation, CN=Microsoft Corporation KEK CA 2011 Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public-Key: (2048 bit) Modulus: 00:c4:e8:b5:8a:bf:ad:57:26:b0:26:c3:ea:e7:fb: 57:7a:44:02:5d:07:0d:da:4a:e5:74:2a:e6:b0:0f: ec:6d:eb:ec:7f:b9:e3:5a:63:32:7c:11:17:4f:0e: e3:0b:a7:38:15:93:8e:c6:f5:e0:84:b1:9a:9b:2c: e7:f5:b7:91:d6:09:e1:e2:c0:04:a8:ac:30:1c:df: 48:f3:06:50:9a:64:a7:51:7f:c8:85
Bug#928300: secure boot via removable media path unavailable
Hi Chris, On Mon, Jul 01, 2019 at 06:36:40PM +0200, Chris Nospam wrote: > >I try to deliver missing informations. > >> Can you get in to the system? I'm guessing (hoping!) just by disabling >> SB for now. > >Fortunately, that is possible. Phew. :-) >> Then please do a listing of the EFi System Partition and >> show us what boot variables are set: > >> # ls -lR /boot/efi >/boot/efi: >insgesamt 4 >drwx-- 4 root root 4096 Mär 7 2016 EFI > >/boot/efi/EFI: >insgesamt 8 >drwx-- 2 root root 4096 Jul 1 18:04 BOOT >drwx-- 2 root root 4096 Jul 1 18:04 debian > >/boot/efi/EFI/BOOT: >insgesamt 3968 >-rwx-- 1 root root 1322936 Jul 1 18:04 BOOTX64.EFI >-rwx-- 1 root root 1206824 Jul 1 18:04 fbx64.efi >-rwx-- 1 root root 1529200 Jul 1 18:04 grubx64.efi > >/boot/efi/EFI/debian: >insgesamt 5208 >-rwx-- 1 root root 108 Jul 1 18:04 BOOTX64.CSV >-rwx-- 1 root root 1206824 Jul 1 18:04 fbx64.efi >-rwx-- 1 root root 126 Jul 1 18:04 grub.cfg >-rwx-- 1 root root 1529200 Jul 1 18:04 grubx64.efi >-rwx-- 1 root root 1261192 Jul 1 18:04 mmx64.efi >-rwx-- 1 root root 1322936 Jul 1 18:04 shimx64.efi OK, that's very similar to my own system. (I've got fwupdate-amd64-signed installed too, so a couple of extra files). >> # efibootmgr -v >BootCurrent: >Timeout: 1 seconds >BootOrder: ,0008,0009,000A >Boot* debian >HD(1,GPT,ce8d01bc-8e1e-4bab-bd3f-10a56a1346cd,0x800,0x10)/File(\EFI\debian\shimx64.efi) >Boot0008* UEFI : LAN : IP4 Intel(R) 82579V Gigabit Network Connection >PciRoot(0x0)/Pci(0x19,0x0)/MAC(4c72b926a1c7,0)/IPv4(0.0.0.00.0.0.0,0,0)AMBO >Boot0009* UEFI : LAN : IP6 Intel(R) 82579V Gigabit Network Connection >PciRoot(0x0)/Pci(0x19,0x0)/MAC(4c72b926a1c7,0)/IPv6([::]:<->[::]:,0,0)AMBO >Boot000A* UEFI : SATA : PORT 6G 0 : SAMSUNG SSD 830 Series : PART 0 : OS >Bootloader >PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/HD(1,GPT,ce8d01bc-8e1e-4bab-bd3f-10a56a1346cd,0x800,0x10)AMBO OK, they all look sane enough. ># umount /boot/efi (if that should be of interest) ># ls -lR /boot/efi >/boot/efi: >insgesamt 4 >drwxr-xr-x 4 root root 4096 Mär 7 2016 EFI > >/boot/efi/EFI: >insgesamt 8 >drwxr-xr-x 2 root root 4096 Feb 23 2018 BOOT >drwxr-xr-x 2 root root 4096 Feb 23 2018 debian > >/boot/efi/EFI/BOOT: >insgesamt 128 >-rwx-- 1 root root 131072 Jun 29 06:15 BOOTX64.EFI > >/boot/efi/EFI/debian: >insgesamt 128 >-rwx-- 1 root root 131072 Jun 29 06:15 grubx64.efi It's odd that you have files in /boot/efi but on a separate filesystem (the rootfs?), not within the ESP. But they shouldn't be seen by the UEFI firmware, so meh. >The exact error message during booting with SB on is: >Image Autorization Fail. *Exactly* that, including the missing "h" in Authorization ? Or is that a typo on your part? >System cannot boot to this device due to Security Violation. >Press Enter key to continue. > > >Booting the live image like >https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-xfce.iso >with SB on is also not possible (actually I teststed last week's build). Win >10 by installer DVD is (and long time ago an installed system on (another) HDD >was) no problem with SB on. OK, that's odd too. Exactly that image is booting fine in SB mode for me on other systems. I've just tried it now to be sure! >Note, I have not a dual boot system or something like that, solely Buster is >on my system. ACK. ># gdisk -l /dev/sda >GPT fdisk (gdisk) version 1.0.3 > >Partition table scan: > MBR: protective > BSD: not present > APM: not present > GPT: present > >Found valid GPT with protective MBR; using GPT. >Disk /dev/sda: 1000215216 sectors, 476.9 GiB >Model: SAMSUNG SSD 830 >Sector size (logical/physical): 512/512 bytes >Disk identifier (GUID): 1F83AB09-033C-4FA1-80CB-8DD29163E919 >Partition table holds up to 128 entries >Main partition table begins at sector 2 and ends at sector 33 >First usable sector is 34, last usable sector is 1000215182 >Partitions will be aligned on 2048-sector boundaries >Total free space is 2669 sectors (1.3 MiB) > >Number Start (sector)End (sector) Size Code Name > 12048 1050623 512.0 MiB EF00 > 2 1050624 933314559 444.5 GiB 8300 > 3 933314560 1000214527 31.9 GiB8200 ># sgdisk --info=1 /dev/sda >Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System) >Partition unique GUID: CE8D01BC-8E1E-4BAB-BD3F-10A56A1346CD >First sector: 2048 (at 1024.0 KiB) >Last sector: 1050623 (at 513.0 MiB) >Partition size: 1048576 sectors (512.0 MiB) >Attribute flags: >Partition name: '' So, I'm curious what keys your system claims to recognise then. The mokutil tool can dump the public keys in each of the key lists on your system, as listed in the man page: ... --pk List the keys in PK --kek List the keys in KEK -
Bug#928300: secure boot via removable media path unavailable
Dear Steve, I try to deliver missing informations. > Can you get in to the system? I'm guessing (hoping!) just by disabling > SB for now. Fortunately, that is possible. > Then please do a listing of the EFi System Partition and > show us what boot variables are set: > # ls -lR /boot/efi /boot/efi: insgesamt 4 drwx-- 4 root root 4096 Mär 7 2016 EFI /boot/efi/EFI: insgesamt 8 drwx-- 2 root root 4096 Jul 1 18:04 BOOT drwx-- 2 root root 4096 Jul 1 18:04 debian /boot/efi/EFI/BOOT: insgesamt 3968 -rwx-- 1 root root 1322936 Jul 1 18:04 BOOTX64.EFI -rwx-- 1 root root 1206824 Jul 1 18:04 fbx64.efi -rwx-- 1 root root 1529200 Jul 1 18:04 grubx64.efi /boot/efi/EFI/debian: insgesamt 5208 -rwx-- 1 root root 108 Jul 1 18:04 BOOTX64.CSV -rwx-- 1 root root 1206824 Jul 1 18:04 fbx64.efi -rwx-- 1 root root 126 Jul 1 18:04 grub.cfg -rwx-- 1 root root 1529200 Jul 1 18:04 grubx64.efi -rwx-- 1 root root 1261192 Jul 1 18:04 mmx64.efi -rwx-- 1 root root 1322936 Jul 1 18:04 shimx64.efi > # efibootmgr -v BootCurrent: Timeout: 1 seconds BootOrder: ,0008,0009,000A Boot* debian HD(1,GPT,ce8d01bc-8e1e-4bab-bd3f-10a56a1346cd,0x800,0x10)/File(\EFI\debian\shimx64.efi) Boot0008* UEFI : LAN : IP4 Intel(R) 82579V Gigabit Network Connection PciRoot(0x0)/Pci(0x19,0x0)/MAC(4c72b926a1c7,0)/IPv4(0.0.0.00.0.0.0,0,0)AMBO Boot0009* UEFI : LAN : IP6 Intel(R) 82579V Gigabit Network Connection PciRoot(0x0)/Pci(0x19,0x0)/MAC(4c72b926a1c7,0)/IPv6([::]:<->[::]:,0,0)AMBO Boot000A* UEFI : SATA : PORT 6G 0 : SAMSUNG SSD 830 Series : PART 0 : OS Bootloader PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0,65535,0)/HD(1,GPT,ce8d01bc-8e1e-4bab-bd3f-10a56a1346cd,0x800,0x10)AMBO # umount /boot/efi (if that should be of interest) # ls -lR /boot/efi /boot/efi: insgesamt 4 drwxr-xr-x 4 root root 4096 Mär 7 2016 EFI /boot/efi/EFI: insgesamt 8 drwxr-xr-x 2 root root 4096 Feb 23 2018 BOOT drwxr-xr-x 2 root root 4096 Feb 23 2018 debian /boot/efi/EFI/BOOT: insgesamt 128 -rwx-- 1 root root 131072 Jun 29 06:15 BOOTX64.EFI /boot/efi/EFI/debian: insgesamt 128 -rwx-- 1 root root 131072 Jun 29 06:15 grubx64.efi The exact error message during booting with SB on is: Image Autorization Fail. System cannot boot to this device due to Security Violation. Press Enter key to continue. Booting the live image like https://cdimage.debian.org/cdimage/weekly-live-builds/amd64/iso-hybrid/debian-live-testing-amd64-xfce.iso with SB on is also not possible (actually I teststed last week's build). Win 10 by installer DVD is (and long time ago an installed system on (another) HDD was) no problem with SB on. Note, I have not a dual boot system or something like that, solely Buster is on my system. # gdisk -l /dev/sda GPT fdisk (gdisk) version 1.0.3 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk /dev/sda: 1000215216 sectors, 476.9 GiB Model: SAMSUNG SSD 830 Sector size (logical/physical): 512/512 bytes Disk identifier (GUID): 1F83AB09-033C-4FA1-80CB-8DD29163E919 Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 34, last usable sector is 1000215182 Partitions will be aligned on 2048-sector boundaries Total free space is 2669 sectors (1.3 MiB) Number Start (sector)End (sector) Size Code Name 12048 1050623 512.0 MiB EF00 2 1050624 933314559 444.5 GiB 8300 3 933314560 1000214527 31.9 GiB8200 # sgdisk --info=1 /dev/sda Partition GUID code: C12A7328-F81F-11D2-BA4B-00A0C93EC93B (EFI System) Partition unique GUID: CE8D01BC-8E1E-4BAB-BD3F-10A56A1346CD First sector: 2048 (at 1024.0 KiB) Last sector: 1050623 (at 513.0 MiB) Partition size: 1048576 sectors (512.0 MiB) Attribute flags: Partition name: '' Thank you again for your interest and commitment! Chris
Bug#928300: secure boot via removable media path unavailable
Hi Chris! On Sat, Jun 29, 2019 at 06:44:06AM +0200, Chris Nospam wrote: > >I know that this bug is not closed yet, but maybe the following is of >interest for you. > >I noticed your report of bug #930531 which was recently fixed in >grub2 version 2.02+dfsg1-19. Thus, I decided to give secure boot >another try on my Intel DH77KC board. Meanwhile grub2 2.02+dfsg1-20 >was installed on my system. > >So what I did is >$ apt-get install shim-signed grub-efi-amd64-signed >(and automatically all deendencies). Then, to be sure, >$ update-grub2 >$ dpkg-reconfigure grub-efi-amd64 >of course with force_efi_extra_removable set to/left on true. >$ update-grub2 >$ shutdown -r now OK, that *sounds* correct. >Then I turned secure-boot on within the mainboard's UEFI >Firmware. However, the system then won't boot and shows an error >message about security violations. Pretty the same as with my first >tries, which led to the initial posting. (A Windows media can be >booted in secure mode.) Can you get in to the system? I'm guessing (hoping!) just by disabling SB for now. Then please do a listing of the EFi System Partition and show us what boot variables are set: # ls -lR /boot/efi # efibootmgr -v -- Steve McIntyre, Cambridge, UK.st...@einval.com Getting a SCSI chain working is perfectly simple if you remember that there must be exactly three terminations: one on one end of the cable, one on the far end, and the goat, terminated over the SCSI chain with a silver-handled knife whilst burning *black* candles. --- Anthony DeBoer
Bug#928300: secure boot via removable media path unavailable
Dear Steve, I know that this bug is not closed yet, but maybe the following is of interest for you. I noticed your report of bug #930531 which was recently fixed in grub2 version 2.02+dfsg1-19. Thus, I decided to give secure boot another try on my Intel DH77KC board. Meanwhile grub2 2.02+dfsg1-20 was installed on my system. So what I did is $ apt-get install shim-signed grub-efi-amd64-signed (and automatically all deendencies). Then, to be sure, $ update-grub2 $ dpkg-reconfigure grub-efi-amd64 of course with force_efi_extra_removable set to/left on true. $ update-grub2 $ shutdown -r now Then I turned secure-boot on within the mainboard's UEFI Firmware. However, the system then won't boot and shows an error message about security violations. Pretty the same as with my first tries, which led to the initial posting. (A Windows media can be booted in secure mode.) Chris
