Bug ID 973745
Summary Shim chainloaded by grub2 fails to load kernel
Classification openSUSE
Product openSUSE Tumbleweed
Version Current
Hardware Other
OS Other
Status NEW
Severity Major
Priority P5 - None
Component Bootloader
Assignee mchang@suse.com
Reporter arvidjaar@gmail.com
QA Contact jsrain@suse.com
CC glin@suse.com, pjones@redhat.com
Found By ---
Blocker ---

This was discussed on opensuse mailing list, but user has troubles with
bugzilla account so I report it for him.

User tries to chainload Mint (Ubuntu) shim from TW grub2. This works and user
gets Mint grub2 menu, but attempt to load Mint kernel fails with

Bootloader has not verified image.
System is compromised

Chainloading in reverse direction (chainload TW shim from Mint grub2) works.

As far as I can tell, this is caused by this shim patch:

commit 7ad94952cdfbf417501d2053368d1e831097fea8
Author: Peter Jones <pjones@redhat.com>
Date:   Fri Jun 5 10:31:03 2015 -0400

    Ensure that apps launched by shim get correct BS->Exit() behavior

    Right now applications run by shim get our wrapper for Exit(), but it
    doesn't do as much cleanup as it should - shim itself also exits, but
    currently is not doing all the cleanup it should be doing.

    This changes it so all of shim's cleanup is also performed.

    Based on a patch and lots of review from Gary Lin.

and what happens is

shim(1) -> hooks systab and launches bootloader (no UEFI StartImage)
  bootloader(1) -> chainloads shim(2) (no UEFI StartImage)
    shim(2) -> hooks systab and launches bootloader(2) (no UEFI StartImage)
      bootloader(2) -> tries to call ExitBootServices and launch kernel

Now ExitBootServices call from bootloader(2) is intercepted by shim(2) which
restores previous ExitBootServices value ... which unfortunately now points to
shim(1) exit_boot_services(). So shim(2) calls exit_boot_services() from
shim(1) which is not aware that bootloader(2) has verified image and blocks
execution.

It seems this commit appeared in shim 0.9 which may explain why it works in
reverse direction (at least my Ubuntu 14.04 still has shim 0.8).

I think partial workaround is to make grub2 chainloader attempt to load and
start image using standard UEFI API first. This would succeed in this case
(because shim is supposed to be accepted by firmware) and make shim(1)
correctly unhook itself. Actually it probably will also make shim(1) to call
uninstall__shim_protocol() which is exactly what we want here as well.

But there is also something to think about in shim itself. @gary, @peter - any
ideas?


You are receiving this mail because: