Unable to boot unsigned kernel, boot freezes in shim call

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

Stéphane has reported that with the build of shim 0.4, the problem is worse: both signed and unsigned kernels now fail. This seems to fit if the bug is in shim's own image verification - between the raring version of shim and shim 0.4, upstream has changed to use its internal SB verification code exclusively, instead of trying the firmware's verification routine first and falling back to its implementation only on failure.

Stéphane, can you please give the attached shimx64.efi a go, and post the console output so we can see where it hangs? Binary signed with the same key as the other one for bug #1187233. Will need to iterate this a few times to get to the bottom, I expect.

Forgot to comment there (only did it in private on IRC). The binary above doesn't print anything to screen in my case, it's as if grub was somehow preventing the shim to render anything on screen.

My suggestion is to use a nvram variable accessible from the booted system and use that to store the debug output.
However be careful to only log a very minimal amount of data as my mention suffers from the UEFI garbage collection bug that bricks machines when more than 50% of the nvram variable space is used.

12:01 <stgraber> ok, so I've got a patched shim that can log into nvram variables, that should make tracking the hang down a bit easier
12:32 <stgraber> and debugged as far as I can without getting any real shim knowledge
12:32 <stgraber> that is, I tracked it down to the exact line where it's hanging
12:33 <stgraber> http://paste.ubuntu.com/5962449/ is what I've been working with
12:33 <stgraber> after boot, I'm getting:
12:33 <stgraber> verify_buffer: debug 1a
12:34 <stgraber> so it appears it actually hangs on the Print() call in the error case of that first check in verify_buffer
12:34 <stgraber> possibly because grub prevents it from printing anything (as we've seen with your other test build)
12:57 <stgraber> found the issue, though it's pretty scary
12:57 <stgraber> commenting the Print() call makes my laptop boot just fine
12:57 <stgraber> may be related to some console state change triggered by grub or as Colin suggested in #ubuntu-installer, a memory allocation bug in the firmware's implementation of Print()
12:58 <stgraber> anyway, patching the shim not to print stuff to the screen seems like our easiest fix for this mess

Attaching the shim binary (signed with the key from the other shim bug report) I've been using for that successful boot. It's basically a current saucy shim with a bunch of debug code added to write to nvram and the problematic Print() call commented.

This bug was fixed in the package shim - 0.4-0ubuntu3

---------------
shim (0.4-0ubuntu3) saucy; urgency=low

  [ Steve Langasek ]
  * Install MokManager.efi.signed in the package.
  * debian/patches/no-output-by-default.patch: Don't print any
    informational messages. Closes LP: #1074302.

  [ Stéphane Graber ]
  * debian/patches/no-print-on-unsigned: Don't print an error message when
    validating an unsigned binary as that tends to hang Lenovo machines.
    (LP: #1087501)
 -- Stephane Graber <email address hidden> Thu, 08 Aug 2013 17:12:12 +0200

This bug was fixed in the package shim - 0.4-0ubuntu4

---------------
shim (0.4-0ubuntu4) saucy; urgency=low

  * debian/patches/fix-tftp-prototype: pass the right arguments to
    EFI_PXE_BASE_CODE_TFTP_READ_FILE.
  * debian/patches/build-with-Werror: Build with -Werror to catch future
    prototype mismatches.
  * debian/patches/fix-compiler-warnings: Fix remaining compiler
    warnings in netboot.c.
  * debian/patches/tftp-proper-nul-termination: fix nul termination
    errors in filenames passed to tftp.
  * debian/patches/netboot-cleanup: roll-up of miscellaneous fixes to
    the netboot code.
 -- Steve Langasek <email address hidden> Mon, 23 Sep 2013 00:30:00 -0700