http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c2 --- Comment #2 from Enrique Garcia --- For 41.2 I mean 42.1, sorry ^_^U. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 bill morgart changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wsm@morgart.org -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c4 --- Comment #4 from Enrique Garcia --- 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/shi... -grub.efi from http://download.opensuse.org/distribution/13.2/repo/oss/suse/x86_64/grub2-x8... 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c6 Andrei Borzenkov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rw@suse.com --- Comment #6 from Andrei Borzenkov --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c8 --- Comment #8 from Leo Davis --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c9 Roger Luedecke changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |roger.luedecke@gmail.com --- Comment #9 from Roger Luedecke --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c11 --- Comment #11 from Enrique Garcia --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c13 --- Comment #13 from Enrique Garcia --- (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". -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c15 Andrei Borzenkov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |glin@suse.com Flags| |needinfo?(glin@suse.com) --- Comment #15 from Andrei Borzenkov --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c17 Gary Ching-Pang Lin changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(glin@suse.com) | --- Comment #17 from Gary Ching-Pang Lin --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c18 --- Comment #18 from Michael Chang --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c19 Christopher Cimiluca changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ccimiluca@gmail.com --- Comment #19 from Christopher Cimiluca --- I have this bug and am willing to help test (time permitting). HP 15t r100, Windows 10 (upgraded from 8.1) -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 Raul Malea changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |raulmalea@yahoo.co.uk -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c22 --- Comment #22 from Andrei Borzenkov --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c24 --- Comment #24 from Michael Chang --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c26 --- Comment #26 from Enrique Garcia --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c28 --- Comment #28 from Andrei Borzenkov --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c30 --- Comment #30 from Andrei Borzenkov --- (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 are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c32 Andrei Borzenkov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ldav1s@yahoo.com Flags| |needinfo?(ldav1s@yahoo.com) --- Comment #32 from Andrei Borzenkov --- (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"? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c34 --- Comment #34 from Leo Davis --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c36 Leo Davis changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ldav1s@yahoo.com) | --- Comment #36 from Leo Davis --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 Matthias Gensler changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gensler@gmx.de -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c38 Michael Chang changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo?(ldav1s@yahoo.com) --- Comment #38 from Michael Chang --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c40 Leo Davis changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(ldav1s@yahoo.com) | --- Comment #40 from Leo Davis --- Created attachment 657194 --> http://bugzilla.opensuse.org/attachment.cgi?id=657194&action=edit 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c43 --- Comment #43 from Leo Davis --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c45 --- Comment #45 from Leo Davis --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c49 Marcus Furlong changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |furlongm@gmail.com --- Comment #49 from Marcus Furlong --- 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? -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c53 --- Comment #53 from Neil Rickert --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c55 --- Comment #55 from Roger Luedecke --- 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. -- You are receiving this mail because: You are on the CC list for the bug.

http://bugzilla.opensuse.org/show_bug.cgi?id=954126 http://bugzilla.opensuse.org/show_bug.cgi?id=954126#c62 --- Comment #62 from Neil Rickert --- 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. -- You are receiving this mail because: You are on the CC list for the bug.