shim fails to load MokManager (mmx64.efi) in the case of unsigned grub

[Mikhail Kshevetskiy]

[see debian bug #860716 as well]

I test shim-signed with qemu in secure boot environment. Here is the steps
to reproduce a problem:

1) install shim, shim-signed, qemu and ovmf packages

2) get EnrollDefaultKeys.efi from
   https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/os/Packages/e/edk2-ovmf-20170209git296153c5-3.fc27.noarch.rpm

3) create a efi_test directory with shim binaries, grub and EnrollDefaultKeys.efi files

   mkdir efi_test
   cp /usr/lib/shim/{shimx64,mmx64,fbx64}.efi.signed efi_test/
   rename 's/[.]signed$//' efi_test/*

   cp /boot/efi/EFI/debian/grubx64.efi efi_test/ [this step is significant]

   cp EnrollDefaultKeys.efi efi_test/ [see step (2)]

4) so we have in efi_test/

   LANG=C ls -la efi_test/

   drwxr-xr-x 2 kl kl 4096 Apr 19 12:10 .
   drwxr-xr-x 5 kl kl 4096 Apr 19 11:52 ..
   -rw-r--r-- 1 kl kl 20032 Apr 19 11:55 EnrollDefaultKeys.efi
   -rw-r--r-- 1 kl kl 72144 Apr 19 11:52 fbx64.efi
   -rwxr-xr-x 1 kl kl 121856 Apr 19 12:10 grubx64.efi
   -rw-r--r-- 1 kl kl 1168464 Apr 19 12:05 mmx64.efi
   -rw-r--r-- 1 kl kl 1169528 Apr 19 11:52 shimx64.efi

5) run qemu with ovmf firmware

   qemu-system-x86_64 -m 1024 -enable-kvm -machine q35,smm=on,accel=kvm \
                      -bios /usr/share/ovmf/OVMF.fd \
                      -drive media=disk,file=fat:rw:efi_test

6) import microsoft keys and enable secure boot (from EFI shell)

   Shell> fs0:
   FS0:\> EnrollDefaultKeys.efi
   info: SetupMode=1 SecureBoot=0 SecureBootEnabled=0 CustomMode=0 VendorKeys=1
   info: SetupMode=0 SecureBoot=1 SecureBootEnabled=1 CustomMode=0 VendorKeys=0
   info: success

7) reboot virtual machine (from EFI shell)

   FS0:\> reset

8) run shim (from EFI shell)

   Shell> fs0:
   FS0:\> shimx64.efi

9) expected result:

   MokManager (mmx64.efi) will be started

10) actual result:

    Verification failed: (15) Access Denied

    Failed to load image: Access Denied
    start_image() returned Access Denied
    start_image() returned Access Denied

    and we back to EFI shell.

    Thus it's not possible to install user keys or add user
    loader to trusted binary database.

------------------------------------------------------

The following upsteram patch will resolve a problem:

https://github.com/rhinstaller/shim/commit/9f2c83e60e0758c3db387eebaed3f306ad6214a8

[Mikhail Kshevetskiy (laska)]

This is a low priority bug for ubuntu, cause it has grub2-signed package. But in debian case it becomes problematic as debian has no grub2-signed package. Thus users must use self-compiled monolith grub2 package. Evidently this package is not signed with Debian key, and hence it can't be loaded.

[Steve Langasek (vorlon)]

On Mon, May 22, 2017 at 10:08:21PM -0000, Mikhail Kshevetskiy wrote:
> This is a low priority bug for ubuntu, cause it has grub2-signed
> package. But in debian case it becomes problematic as debian has no
> grub2-signed package.

It doesn't have one *yet*. This is planned.

[Mikhail Kshevetskiy (laska)]

> > This is a low priority bug for ubuntu, cause it has grub2-signed
> > package. But in debian case it becomes problematic as debian has no
> > grub2-signed package.
>
> It doesn't have one *yet*. This is planned.

Yeah, I know. That's why this bug is quite significant.

Currently we should do the following truck to boot debian in secure boot environment

1) built our own monolithic grub

2) eject hard drive from target system and connect it to the system with disabled secure boot

3) prepare boot media (on computer with disabled secure boot)
   a) copy /usr/lib/shim/shimx64.efi.signed to /boot/efi/EFI/boot/bootx64.efi
   b) copy /usr/lib/shim/mmx64.efi.signed to /boot/efi/EFI/boot/grubx64.efi
   c) put self-built monolithic grub to /boot/efi/EFI/boot/somename.efi

4) boot with prepared media on target system to add our self-built monolithic grub
   to the chain of trust using MokManager (see 3b and 3c)

5) eject hard drive from target system and connect it the system with disabled secure boot (again)

6) modify prepared media (on computer with disabled secure boot)
   a) rename /boot/efi/EFI/boot/grubx64.efi to /boot/efi/EFI/boot/mmx64.efi
   b) rename /boot/efi/EFI/boot/somename.efi to /boot/efi/EFI/boot/grubx64.efi

7) enjoy debian in secure boot environment

With the bug fixed we may skip step 5 and step 6.

[Steve Langasek (vorlon)]

On Tue, May 23, 2017 at 01:08:03AM -0000, Mikhail Kshevetskiy wrote:
> > > This is a low priority bug for ubuntu, cause it has grub2-signed
> > > package. But in debian case it becomes problematic as debian has no
> > > grub2-signed package.

> > It doesn't have one *yet*. This is planned.

> Yeah, I know. That's why this bug is quite significant.

For Debian, not for Ubuntu; and you're reporting this on the Ubuntu bug.

[Mikhail Kshevetskiy (laska)]

The sources are mostly same, so the problems are the same.
I submit this bug for debian as well.

Actually this bug present in ubuntu as well. Normally it is low priority, but it becomes critical if we are using our own grub or any other efi loader (like refind) with shim.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Bougron (francis-bougron)]

Hello
I installed refind by naming it grubx64.efi.
Shimx64 launches it very well in NON SECURE mode.
But, if I change the bios to switch to SECURE mode, SHIMX64 does not succeed in launching it. Which is normal. but it does not launch MMX64.EFI that would allow me to define this "grub" as secure.