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: 0000
>Timeout: 1 seconds
>BootOrder: 0000,0008,0009,000A
>Boot0000* debian HD(1,GPT,ce8d01bc-8e1e-4bab-bd3f-10a56a1346cd,0x800,0x100000)/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,0x100000)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
> 1 2048 1050623 512.0 MiB EF00
> 2 1050624 933314559 444.5 GiB 8300
> 3 933314560 1000214527 31.9 GiB 8200
># 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: 0000000000000000
>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
--db List the keys in db
--dbx List the keys in dbx
Could you grab those and share them too please? I'm wondering if your
system has maybe had some keys removed or revoked.
--
Steve McIntyre, Cambridge, UK. steve@einval.com
"... the premise [is] that privacy is about hiding a wrong. It's not.
Privacy is an inherent human right, and a requirement for maintaining
the human condition with dignity and respect."
-- Bruce Schneier
Reply to: