Bug 954126

I created the thread and was about to file the bug right now. If you need more information just let me know.

I tried with (all secure boot on):
-13.2 and worked ok
-41.2 and failed.
-13.2 updating to 41.2 and failed.

As the description says, secure boot disabled runs ok.

For 41.2 I mean 42.1, sorry ^_^U.

I had a similar problem today, though with a slight difference.

For me, I cannot do anything with secure-boot enabled, unless I use "shim.efi" from opensuse 13.2.  This is due to bug 950569

Booting with secure-boot enabled works if I use:
 shim.efi, grub.efi, MokManager.efi all from 13.2, with the other files from 42.1

It does not work if I use:
 shim.efi from 13.2, but grub.efi, MokManager.efi from 42.1.  In this case, I get the same "Not supported image" message when I try to boot Windows (but booting opensuse is fine).

I also tested:
 shim.efi from 13.2; grub.efi, MokManager.efi both from Tumbleweed 20151110.  And that seems to work.

I'm going to flag this report as CONFIRMED.

Note that the files I have just mentioned are all found in
"/boot/efi/EFI/opensuse/".

I made a few more tests taking into account what Prof. Rickert posted above. I recovered the files from 13.2 and used a different mix of them to boot my system with secure boot enabled:

The files for 42.1 are the ones from the Leap installation in my system.

The files for 13.2 are:
-shim.efi and MokManager.efi from http://download.opensuse.org/repositories/openSUSE:/13.2/standard/x86_64/shim-0.7.318.81ee561d-3.4.1.x86_64.rpm
-grub.efi from http://download.opensuse.org/distribution/13.2/repo/oss/suse/x86_64/grub2-x86_64-efi-2.02~beta2-20.5.1.x86_64.rpm

shim.efi | grub.efi | MokManager.efi | Boot with secure boot
---------+----------+----------------+----------------------
42.1     | 42.1     | 42.1           | Fail
---------+----------+----------------+----------------------
13.2     | 13.2     | 13.2           | OK
---------+----------+----------------+----------------------
42.1     | 13.2     | 13.2           | OK
---------+----------+----------------+----------------------
42.1     | 13.2     | 42.1           | OK
---------+----------+----------------+----------------------

So I suppose the problem could be in the grub.efi file from 42.1.

Could someone please attach bootmgfw.efi or send me privately? I see where it fails but I need to verify why.

And yes, Leap and TW EFI chainloader are different.

OK, I found bootmgfw.efi, and it confirms it. The problem is in grub2-efi-chainload-harder.patch that adds check for valid PE32+ header; but this check is wrong.

  if (grub_memcmp (pe32->signature, "PE\0\0", 4) != 0

pe32 header is not located at fixed address. pe32 is of type grub_pe32_header and expects header at offset 0x80; but botomgfw.efi has header at offset 0xe0. See PE COFF specification. Code should fetch header address at fixed offset 0x3b.

Cc patch author.

Please test version with patch disabled (sorry, bug number is wrong, typo).

zypper ar obs://home:arvidjaar:bnc:964126/standard boo954126
zypper refresh boo954126
zypper dup -r boo954126

You will need to import /usr/lib64/efi/grub.der after that using either mokutil or boot time MokManager.

I tried the suggested steps in Comment 7.  In SecureBoot mode I never get to GRUB, it just keeps booting.  It boots OK with SecureBoot off.

I'd like to help with testing, but firstly I need to  make sure I can keep a working system as I have only the one computer.

In Windows I'd normally need to use bcdedit to direct it to use GRUB. My concern is that If I do that, I need to be able to reverse it from within LEAP so I can get back into Windows. Please advise.

(In reply to Leo Davis from comment #8)
> I tried the suggested steps in Comment 7.  In SecureBoot mode I never get to
> GRUB, it just keeps booting.  It boots OK with SecureBoot off.

Did you enroll GRUB signing key? It is private build, so it is not signed by openSUSE key.

(In reply to Roger Luedecke from comment #9)
> I'd like to help with testing, but firstly I need to  make sure I can keep a
> working system as I have only the one computer.
> 

Sorry, I do not understand the question. If you already have dual boot, then nothing changes for you.

(In reply to Andrei Borzenkov from comment #7)
> Please test version with patch disabled (sorry, bug number is wrong, typo).
> 
> zypper ar obs://home:arvidjaar:bnc:964126/standard boo954126
> zypper refresh boo954126
> zypper dup -r boo954126
> 
> You will need to import /usr/lib64/efi/grub.der after that using either
> mokutil or boot time MokManager.

I made the update with zypper and installed the grub.der certificate into my system, but I am unable to boot using secure boot. During boot the following message is shown: "Verification failed: (15) Access Denied".

I don't really know if a made a mistake during the process because it's the first time I manually install a certificate to boot my system. However, the certificate seems to be installed because it's listed with the command "mokutil --list-enrolled" (actually it shows twice, so I suppose I installed it twice also).

I made a rollback so I am still able to use secure boot with the mix of 42.1 and 13.2 files.

(In reply to Enrique Garcia from comment #11)
> 
> I made the update with zypper and installed the grub.der certificate into my
> system, but I am unable to boot using secure boot. During boot the following
> message is shown: "Verification failed: (15) Access Denied".
> 

Did you enrolled certificate before or after installing my GRUB? Certificate comes with new package.

> I don't really know if a made a mistake during the process because it's the
> first time I manually install a certificate to boot my system. However, the
> certificate seems to be installed because it's listed with the command
> "mokutil --list-enrolled" (actually it shows twice, so I suppose I installed
> it twice also).
> 

Try using MokManager; copy certificate to ESP and start MokManager there. Just to be sure to eliminate mokutil problem.

(In reply to Andrei Borzenkov from comment #12)

> Did you enrolled certificate before or after installing my GRUB? Certificate
> comes with new package.
> 

After. The .cer file is in the path you mentioned and the sha1sum of the file is "ee4faab497e33c14b61d00354e8a2ec5e469821c"; the same sha1 fingerprint is shown by "mokutil -l".

> Try using MokManager; copy certificate to ESP and start MokManager there.
> Just to be sure to eliminate mokutil problem.

I installed using MokManager using grub2 boot menu. I repeated the process removing the certificate and installing it again. Same result as before: "Verification failed: (15) Access Denied". In addition, I didn't mention it before I get more messages as I hit enter "Could not install security protocol: (2) Invalid Parameter".

(In reply to Andrei Borzenkov from comment #10)
> (In reply to Leo Davis from comment #8)
> > I tried the suggested steps in Comment 7.  In SecureBoot mode I never get to
> > GRUB, it just keeps booting.  It boots OK with SecureBoot off.
> 
> Did you enroll GRUB signing key? It is private build, so it is not signed by
> openSUSE key.
> 

I did these steps:
zypper ar obs://home:arvidjaar:bnc:964126/standard boo954126
zypper refresh boo954126
zypper dup -r boo954126

Then:

mokutil --import /usr/lib64/efi/grub.der
entered a password twice.

I rebooted.  On reboot, I viewed the new key in MokManager signed by arvidjaar which looked like it matched the info in the newly installed /usr/lib64/efi/grub.der.  It asked me for the password, which I supplied.  I rebooted, enabled SecureBoot and got into a boot loop where I can't even get to GRUB.  After disabling SecureBoot, I was able to boot to GRUB and boot the system.

It actually looks like shim is simply ignoring any enrolled key. Leap shim is not able to load anything except grub.efi shipped with openSUSE, even though my key is claimed to be enrolled.

Same problem with Ubunut 14.04 shim BTW. Ubuntu has shim 0.8 and Leap shim 0.9. But with both of them I am not able to load anything signed by non-default key. I am able to load another shim which is signed by Microsoft though ...

This makes it rather hard to test anything. Gary, are there any known issues here? I try to test custom grub2 and shim cannot verify image although I enrolled my custom key (packaged with grub2) using MokManager.

Could the error be related to this?

https://github.com/rhinstaller/shim/issues/42

(In reply to Andrei Borzenkov from comment #15)
> It actually looks like shim is simply ignoring any enrolled key. Leap shim
> is not able to load anything except grub.efi shipped with openSUSE, even
> though my key is claimed to be enrolled.
> 
> Same problem with Ubunut 14.04 shim BTW. Ubuntu has shim 0.8 and Leap shim
> 0.9. But with both of them I am not able to load anything signed by
> non-default key. I am able to load another shim which is signed by Microsoft
> though ...
> 
> This makes it rather hard to test anything. Gary, are there any known issues
> here? I try to test custom grub2 and shim cannot verify image although I
> enrolled my custom key (packaged with grub2) using MokManager.

In case you're using the key from open build service. There is a known issue that the updated openssl(1.0.2d) in shim checks the key attributes more strictly. The open build service used to generate the self-signed key without the "key signing" attribute. It's accepted by openssl-0.9.8* but openssl-1.0.* treats it as an invalid key. The open build service already fixed the key attribute but the user has to do "osc signkey --extend" to update the key attribute and enroll the updated key.

(In reply to Andrei Borzenkov from comment #6)
> OK, I found bootmgfw.efi, and it confirms it. The problem is in
> grub2-efi-chainload-harder.patch that adds check for valid PE32+ header; but
> this check is wrong.
> 
>   if (grub_memcmp (pe32->signature, "PE\0\0", 4) != 0
> 
> pe32 header is not located at fixed address. pe32 is of type
> grub_pe32_header and expects header at offset 0x80; but botomgfw.efi has
> header at offset 0xe0. See PE COFF specification. Code should fetch header
> address at fixed offset 0x3b.

You're right, we should check msdos header from offset 0x3c for looking up file offset of pe header.

I was misguided by this comment in include/grub/efi/pe32.h so that I went straight to ignore the msdos header. And it happened to work well with my testing with xen.efi. :(

/* The MSDOS compatibility stub. This was copied from the output of
   objcopy, and it is not necessary to care about what this means.  */

I'm going to build a test package.

I have this bug and am willing to help test (time permitting).

HP 15t r100, Windows 10 (upgraded from 8.1)

I had fixed the patch to check msdos header to find pe header. It works for me with local build and could verify that windows and also xen boot works. But I have problem building it in the online build service as it constantly fails with.

could not retrieve ssl certificate: 400 remote error: problems making Certificate Request 

Usually issuing these command helps, but it wont work this time

 osc signkey --create 
 osc rebuild

Btw the project is hosted on

home:michael-chang:branches:openSUSE:Leap:42.1:Update/grub2.openSUSE_Leap_42.1_Update

I need to find out solution for the build service and test it.

Hi All,

The testing repo is published

http://download.opensuse.org/repositories/home:/michael-chang:/bsc954126/standard/

Here is step to test:

1. zypper ar --repo http://download.opensuse.org/repositories/home:/michael-chang:/bsc954126/standard/home:michael-chang:bsc954126.repo

2. zypper dup -r home_michael-chang_bsc954126

3. mokutil --import /usr/lib64/efi/grub.der

4. Input password to be used in MokManager for enrolling keys later

5. mokutil --list-new  # To check your enrolled key in step 3 is successful

6. Reboot

7. You should see MokManager UI (ncurses like) and from that selecting "Enroll MOK", type the password in step4 and system will reboot again.

8. Enable "Secure Boot"

9. Test

10. If it doe not work, boot to the system and run "mokutil --list-enrolled" to check that keys are enrolled correctly by step7.

PS. I also tested with shim 0.9, but did not have the verification problem issue in comment#15. I still like to know the result as my testing was done by a bootmgfw.efi downloaded from internet, not by a real shipped one. And some post processing like strip it's existing certificate which seems not work, and resign the image with self-signed certificate. 

Thanks.

(In reply to Michael Chang from comment #21)
> PS. I also tested with shim 0.9, but did not have the verification problem
> issue in comment#15.

The problem was in certificate that had been used, not in shim itself.

(In reply to Gary Ching-Pang Lin from comment #17)
> (In reply to Andrei Borzenkov from comment #15)

> In case you're using the key from open build service. There is a known issue
> that the updated openssl(1.0.2d) in shim checks the key attributes more
> strictly. The open build service used to generate the self-signed key
> without the "key signing" attribute. It's accepted by openssl-0.9.8* but
> openssl-1.0.* treats it as an invalid key. The open build service already
> fixed the key attribute but the user has to do "osc signkey --extend" to
> update the key attribute and enroll the updated key.

How to check that? Is it "Code Signing" from x509 output ? 

 $ openssl x509 -text -noout -inform der -in /usr/lib64/efi/grub.de
            ...
            X509v3 Extended Key Usage:
                Code Signing
            ...

(In reply to Andrei Borzenkov from comment #22)
> (In reply to Michael Chang from comment #21)

> The problem was in certificate that had been used, not in shim itself.

It's "shim 0.9(aka new openssl) + certificate problem", from your conversation with Gary it seems to me new shim is too picky on certificates in use, but mine just works that I do not know why.

(In reply to Michael Chang from comment #23)
> How to check that? Is it "Code Signing" from x509 output ? 

As I understand it should be "Certificate Sign"

            X509v3 Key Usage: critical
                Certificate Sign, CRL Sign

At least this was the only difference between old and new OBS certificates.

(In reply to Michael Chang from comment #21)
> Hi All,
> 
> The testing repo is published
> 
> http://download.opensuse.org/repositories/home:/michael-chang:/bsc954126/
> standard/
> 
> Here is step to test:
> 
> 1. zypper ar --repo
> http://download.opensuse.org/repositories/home:/michael-chang:/bsc954126/
> standard/home:michael-chang:bsc954126.repo
> 
> 2. zypper dup -r home_michael-chang_bsc954126
> 
> 3. mokutil --import /usr/lib64/efi/grub.der
> 
> 4. Input password to be used in MokManager for enrolling keys later
> 
> 5. mokutil --list-new  # To check your enrolled key in step 3 is successful
> 
> 6. Reboot
> 
> 7. You should see MokManager UI (ncurses like) and from that selecting
> "Enroll MOK", type the password in step4 and system will reboot again.
> 
> 8. Enable "Secure Boot"
> 
> 9. Test
> 
> 10. If it doe not work, boot to the system and run "mokutil --list-enrolled"
> to check that keys are enrolled correctly by step7.
> 
> PS. I also tested with shim 0.9, but did not have the verification problem
> issue in comment#15. I still like to know the result as my testing was done
> by a bootmgfw.efi downloaded from internet, not by a real shipped one. And
> some post processing like strip it's existing certificate which seems not
> work, and resign the image with self-signed certificate. 
> 
> Thanks.

I followed your instructions to test the patch. It worked like a charm.

The steps in Comment 21 worked for me as well.  However on the Thinkpad there's another step that I didn't do the first time around for Comment 8.  In the BIOS there's an additional BIOS setting that has to be set called "Reset to Setup Mode" before things will work.  Otherwise, it will boot in a loop.

(In reply to Leo Davis from comment #27)
> In the BIOS there's an additional BIOS setting that has to be set called
> "Reset to Setup Mode" before things will work.  Otherwise, it will boot in a
> loop.

Are you sure you tested it with Secure Boot still enabled? "Setup Mode" effectively disables Secure Boot.

(In reply to Andrei Borzenkov from comment #28)
> (In reply to Leo Davis from comment #27)
> > In the BIOS there's an additional BIOS setting that has to be set called
> > "Reset to Setup Mode" before things will work.  Otherwise, it will boot in a
> > loop.
> 
> Are you sure you tested it with Secure Boot still enabled? "Setup Mode"
> effectively disables Secure Boot.

I am sure it was still enabled when I booted.  But to double check, I disabled SecureBoot in the BIOS, booted to GRUB, restarted, enabled SecureBoot again, booted to GRUB, selected the Windows partition, and booted Windows OK.  It would require more investigation to see if SecureBoot is really on or not, but the BIOS said it was both times I booted.

(In reply to Leo Davis from comment #29)
>  It would require more investigation to see if SecureBoot is
> really on or not

In Linux you could use "mokutil --sb-state".

(In reply to Andrei Borzenkov from comment #30)
> (In reply to Leo Davis from comment #29)
> >  It would require more investigation to see if SecureBoot is
> > really on or not
> 
> In Linux you could use "mokutil --sb-state".

You were right, SecureBoot was not enabled.  When I re-enabled it I was not able to boot GRUB (booted in a loop).  I did a "mokutil --reset" and rebooted, did the reset in MokManager, rebooted, reran the sequence of steps from step 5 in comment 21.  I was not able to boot to GRUB after that either (booted in a loop).

(In reply to Leo Davis from comment #31)
> You were right, SecureBoot was not enabled.  When I re-enabled it I was not
> able to boot GRUB (booted in a loop).  I did a "mokutil --reset" and
> rebooted, did the reset in MokManager, rebooted, reran the sequence of steps
> from step 5 in comment 21.  I was not able to boot to GRUB after that either
> (booted in a loop).

Could you explain in more details what happens when you boot? Do you see any error message? Does GRUB menu appear?

Also could you boot with secure boot disabled and provide output of "efibootmgr -v"?

Created attachment 656808 [details]
The output from "efibootmgr -v"

Provided as info to comment 31.

(In reply to Andrei Borzenkov from comment #32)
> Could you explain in more details what happens when you boot?

When SecureBoot is enabled:  The fans in the laptop spin up, and the Lenovo BIOS boot screen is displayed.  Then the screen goes black and the fans spin down.  Then this process repeats.

When SecureBoot is disabled:  The fans in the laptop spin up, and the Lenovo BIOS boot screen is displayed.  The GRUB bootscreen is displayed and the fans spin down.  I can boot both Windows and openSUSE from GRUB.

> Do you see any error message?

No.

>Does GRUB menu appear?

No.

> Also could you boot with secure boot disabled and provide output of
> "efibootmgr -v"?

I've added this output as an attachment.

So I try to summarize. You had Leap installed and were able to boot openSUSE with Secure Boot enabled. Is it correct?

After update of grub2 to test version you can no more boot with Secure Boot enabled - system keeps rebooting silently without any errors. Is it correct?

(In reply to Andrei Borzenkov from comment #35)
> So I try to summarize. You had Leap installed and were able to boot openSUSE
> with Secure Boot enabled. Is it correct?

A short recap: 

I had opensuse 13.2 installed and was able to boot to GRUB, then Windows (or openSUSE) with SecureBoot enabled.  I upgraded to Leap 42.1 and was able to boot to GRUB, then to openSUSE, but not Windows with SecureBoot enabled.

I then updated to the first test version and I was not able to boot to GRUB with SecureBoot enabled.  No errors were visible, IIRC.  The system kept rebooting.

I then updated to the second test version and I was not able to boot to GRUB with SecureBoot enabled.  No errors are displayed.  The system kept rebooting.

> After update of grub2 to test version you can no more boot with Secure Boot
> enabled - system keeps rebooting silently without any errors. Is it correct?

With SecureBoot enabled, that is correct.  I cannot boot even to GRUB.

I'm not able to get back into my LEAP install. Using the  install media, it is not showing the good ol' "boot from hard drive" option.

I'm reluctant to do "bcdedit /set {bootmgr} path \EFI\opensuse\shim.efi" without knowing  if I'm going to seriously bork my system.

(In reply to Leo Davis from comment #36)
> (In reply to Andrei Borzenkov from comment #35)
> > So I try to summarize. You had Leap installed and were able to boot openSUSE
> > with Secure Boot enabled. Is it correct?

> > After update of grub2 to test version you can no more boot with Secure Boot
> > enabled - system keeps rebooting silently without any errors. Is it correct?
> 
> With SecureBoot enabled, that is correct.  I cannot boot even to GRUB.

I did not know why the changes would cause you the new troubles, as the changes were made in chainloader commad which won't be executed during start-up thus won't affect it at all.

Is it possible that you performed reset in setup mode that the preloaded Windows keys were cleared, thus can't really verify anything if secure boot enabled?

Please help to provide outputs for these commands?

  mokutil --pk
  mokutil --kek
  mokutil --db

Thanks.

(In reply to Roger Luedecke from comment #37)
> I'm not able to get back into my LEAP install. Using the  install media, it
> is not showing the good ol' "boot from hard drive" option.

As far as I know that option is not provided for UEFI but only legacy mode.

Created attachment 657194 [details]
output from invocations of mokutils

mokutils-pk.txt is the output from "mokutils --pk"
mokutils-kek.txt is the output from "mokutils --kek"
mokutils-db.txt is the output from "mokutils --db".  It also output "unknown hash type" on stderr.

(In reply to Michael Chang from comment #38)
> (In reply to Leo Davis from comment #36)
> > (In reply to Andrei Borzenkov from comment #35)
> > > So I try to summarize. You had Leap installed and were able to boot openSUSE
> > > with Secure Boot enabled. Is it correct?
> 
> > > After update of grub2 to test version you can no more boot with Secure Boot
> > > enabled - system keeps rebooting silently without any errors. Is it correct?
> > 
> > With SecureBoot enabled, that is correct.  I cannot boot even to GRUB.
> 
> I did not know why the changes would cause you the new troubles, as the
> changes were made in chainloader commad which won't be executed during
> start-up thus won't affect it at all.
> 
> Is it possible that you performed reset in setup mode that the preloaded
> Windows keys were cleared, thus can't really verify anything if secure boot
> enabled?
> 
> Please help to provide outputs for these commands?
> 
>   mokutil --pk
>   mokutil --kek
>   mokutil --db
> 
> Thanks.

I was unable to boot to GRUB with both the first fix and the second fix before I performed the reset (with SecureBoot enabled).  After the reset with the second fix I'm unable to boot to GRUB.  I'm unsure of what qualifies as "new".

(In reply to Leo Davis from comment #41)
> 
> I was unable to boot to GRUB with both the first fix and the second fix
> before I performed the reset (with SecureBoot enabled).  After the reset
> with the second fix I'm unable to boot to GRUB.  I'm unsure of what
> qualifies as "new".
You probably encountered boo#950569 which caused shim failed to load grub2.
Although I had the fix already, I'm still waiting for the new shim signature. You could replace shim.efi with the openSUSE 13.2 shim.efi as a temporary workaround.

(In reply to Gary Ching-Pang Lin from comment #42)
> (In reply to Leo Davis from comment #41)
> > 
> > I was unable to boot to GRUB with both the first fix and the second fix
> > before I performed the reset (with SecureBoot enabled).  After the reset
> > with the second fix I'm unable to boot to GRUB.  I'm unsure of what
> > qualifies as "new".
> You probably encountered boo#950569 which caused shim failed to load grub2.
> Although I had the fix already, I'm still waiting for the new shim
> signature. You could replace shim.efi with the openSUSE 13.2 shim.efi as a
> temporary workaround.

The symptoms of boo#950569 sound different, AIUI.  That bug from the reports I saw seems to hang on boot (with SecureBoot enabled).  After the I upgraded to Leap 42.1 could boot openSUSE (but not Windows).  The subsequent attempts to fix don't hang my laptop on boot, they immediately reboot (before GRUB), and reboot, and reboot...

I don't seem to get any artifacts like the blinking cursor they describe.  But then my display gets redrawn pretty quickly because of the reboot.  The shim.efi from openSUSE 13.2 would probably work.  It did before.

(In reply to Leo Davis from comment #43)
> The shim.efi from openSUSE 13.2 would probably work.  It did before.

It would really helpful if you tried it. We really need to separate two issues.

Also does reverting to original Leap 42.1 grub2 work?

(In reply to Andrei Borzenkov from comment #44)
> (In reply to Leo Davis from comment #43)
> > The shim.efi from openSUSE 13.2 would probably work.  It did before.
> 
> It would really helpful if you tried it. We really need to separate two
> issues.
> 

I tried new tests tonight with the old 13.2 shim.
shim-13.2 is shim.efi (shim-opensuse.efi) from shim-0.7.318.81ee561d-3.4.1.x86_64.rpm
shim is shim.efi from 42.1 shim-0.9-2.1.x86_64.rpm

So here's what we've determined from my laptop (SecureBoot is enabled on all these):

shim-42.1 + original 42.1 grub2
boots to GRUB, opensuse, Windows fails
This prompted the original bug report.

shim-42.1 + new grub2
reboots
What I've been talking about from comment 31 onwards.

shim-13.2 + new grub2
boots to GRUB, opensuse, Windows

shim-13.2 + original grub2 (2.02~beta2-68.2)
had the 42.1 shim after reinstall of grub2, so I recopied the 13.2 shim.efi
boots to GRUB, openSUSE, Windows fails

> Also does reverting to original Leap 42.1 grub2 work?

No.  The error screen and behavior look very similar if not identical to the original bug report.

The good news is that the new fixes in grub2 seem to work.  The bad news is that you can't seem to get to them with the (original) 42.1 shim installed.  Sorry this didn't seem to simplify anything.

(In reply to Leo Davis from comment #45)
> (In reply to Andrei Borzenkov from comment #44)
> > (In reply to Leo Davis from comment #43)

> The good news is that the new fixes in grub2 seem to work.  The bad news is
> that you can't seem to get to them with the (original) 42.1 shim installed. 
> Sorry this didn't seem to simplify anything.

Let's track shim as separate issue in boo#950569 and waiting for new signature update from Microsoft. For $subject, I think it's fixed and will be available as Leap maintenance update.

Thanks.

The original issue is still there on a freshly installed 42.1.

Will the shim from #950569 be released for 42.1 at some stage?

SUSE-SU-2015:2387-1: An update that solves one vulnerability and has 8 fixes is now available.

Category: security (important)
Bug References: 774666,917427,946148,952539,954126,954519,955493,955609,956631
CVE References: CVE-2015-8370
Sources used:
SUSE Linux Enterprise Server 12-SP1 (src):    grub2-2.02~beta2-73.3
SUSE Linux Enterprise Desktop 12-SP1 (src):    grub2-2.02~beta2-73.3

Hi Michael Chang,

the update still running for Leap. Please see: https://build.opensuse.org/project/show/openSUSE:Maintenance:4463

After reading this openSUSE G+ channel post <https://plus.google.com/u/0/+openSUSE/posts/Z1RGMVDddFW>, saying that this was fixed, I updated to shim-0.9-4.1.x86_64.  I also have grub2-2.02~beta2-73.1.x86_64, etc.  I made sure that the updated shim.efi (/usr/lib64/efi/shim-opensuse.efi) and MokManager.efi (/usr/lib64/efi/MokManager.efi) were in /boot/efi/EFI/opensuse by copying them there.  grub.efi seemed to be the right version there already probably from invoking the yast2-bootloader to rewrite the boot info just in case.

Anyway, after a couple of reboots trying to make sure the contents of /boot/efi/EFI/opensuse were what I thought they should be, I rebooted, enabled SecureBoot in the BIOS and rebooted.  I was able to get to GRUB (!).  I can boot openSUSE.  I cannot boot Windows -- I get the identical error message that I first reported.

REsponding to c#52

As I understand it, this is fixed in a technical sense, but we are still awaiting an update to Leap 42.1 which will provide the fix there.  I'm expecting it within the next few days.

If you know how to get them, then using "shim.efi" and "grub.efi" from Tumbleweed will provide a temporary fix (that's what I am doing).  Just copy those two files to "/boot/efi/EFI/opensuse".  I think we actually do already have the fixed "shim.efi" in 42.1 systems, so you probably only need the "grub.efi" from Tumbleweed.

(In reply to Neil Rickert from comment #53)
> REsponding to c#52
> 
> As I understand it, this is fixed in a technical sense, but we are still
> awaiting an update to Leap 42.1 which will provide the fix there.  I'm
> expecting it within the next few days.
> 
> If you know how to get them, then using "shim.efi" and "grub.efi" from
> Tumbleweed will provide a temporary fix (that's what I am doing).  Just copy
> those two files to "/boot/efi/EFI/opensuse".  I think we actually do already
> have the fixed "shim.efi" in 42.1 systems, so you probably only need the
> "grub.efi" from Tumbleweed.

I downloaded the current grub.efi from <http://download.opensuse.org/tumbleweed/repo/oss/EFI/BOOT/grub.efi> and copied it to /boot/efi/EFI/opensuse.  With that I was finally able to boot Windows with SecureBoot enabled, so for me at least it is now fixed.

Thanks to everyone who worked on this!

sudo mv grub.efi /boot/efi/EFI/opensuse
root's password:
mv: failed to preserve ownership for ‘/boot/efi/EFI/opensuse/grub.efi’: Operation not permitted


I am getting pretty peeved by this bug. I went and reinstalled openSUSE today thinking this problem was fixed... and now even the (finally) provided workaround doesn't work.

>mv: failed to preserve ownership for ‘/boot/efi/EFI/opensuse/grub.efi’: Operation not permitted

It should be okay to ignore that message.  It would have been better to use "cp" instead of "mv", and then you would not get the message.

What happened there, is that the EFI partition uses the FAT file system, which does not support the unix idea of file owner.

*** Bug 959066 has been marked as a duplicate of this bug. ***

openSUSE-SU-2016:0036-1: An update that solves one vulnerability and has 8 fixes is now available.

Category: security (important)
Bug References: 774666,917427,946148,952539,954126,954519,955493,955609,956631
CVE References: CVE-2015-8370
Sources used:
openSUSE Leap 42.1 (src):    grub2-2.02~beta2-76.1

Resolved fixed again according to comment#54.
Btw the Leap maintenance update for this problem has rolled out, please reopen if it did not work for you.

(In reply to Michael Chang from comment #59)
> Resolved fixed again according to comment#54.
> Btw the Leap maintenance update for this problem has rolled out, please
> reopen if it did not work for you.

Just by chance I stumbled over this bug, as I had a similar problem after installation on a Dell Laptop.
Once the update is applied to Leap, do you expect it to work out of the box, or is there a procedure to enable boot on Windows?

(In reply to Axel Braun from comment #60)
> Once the update is applied to Leap, do you expect it to work out of the box,
> or is there a procedure to enable boot on Windows?

It will work out of box, no any other special procedure required.
Thanks.

Responding to c#60

>Once the update is applied to Leap, do you expect it to work out of the box, or is there a procedure to enable boot on Windows?

I'm not quite sure what you are asking.

Once the update is applied, you will be able to boot Windows from the grub2 boot menu entry.  You don't have to do anything else.  If you had disabled secure-boot in your firmware, you might want to turn that on again.  The update won't do that -- you will have to get into firmware settings.

(In reply to Michael Chang from comment #59)
> Resolved fixed again according to comment#54.
> Btw the Leap maintenance update for this problem has rolled out, please
> reopen if it did not work for you.

I applied the Leap maintenance update, checked to make sure that /boot/efi/EFI/opensuse/grub.efi matched the update (AFAICT it did), and rebooted.  Both Leap and Windows boot with SecureBoot enabled.

Thanks again!