http://bugzilla.opensuse.org/show_bug.cgi?id=1175766 http://bugzilla.opensuse.org/show_bug.cgi?id=1175766#c5 Andrei Borzenkov <arvidjaar@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CONFIRMED CC| |arvidjaar@gmail.com --- Comment #5 from Andrei Borzenkov <arvidjaar@gmail.com> --- (In reply to Neil Rickert from comment #4)
The problem occurs in these circumstances:
1: Booting is being done with shim (not with grubx64.efi) 2: secure-boot is disabled 3: "/boot/grub2/grub.cfg" is using the "linux" command rather than the "linuxefi" command for booting.
This is a change with the new shim. It worked fine with the old shim.
It has nothing to do with shim. Current grub implements so called "file verifieres" which are filters invoked when file is opened. Verifier can deny access to file. Verifier can also skip verification but indicate that file must be verified by some other verifier. Secure boot verficiation is implemented as file verifier (shim_lock). For known file types (like linux kernel) it calls shim to verify signature. For grub modules it returns indication that they must be verified by some other means, e.g. using external pgp signature. In secure boot environment grub.efi is used. It has only one verifier - shim_lock - so attempt to load external grub module fails because on one hand shim_lock requested mandatory verification, on the other hand nothing provides additional verification. It worked earlier because linux.mod was implicitly included in grub.efi by dependency, so no verification was required. Recently dependency that caused linux.mod to be included was "fixed", which exposed this issue. This is patch 0002-cmdline-Provide-cmdline-functions-as-module.patch. This is not visible with linuxefi because it is built-in into grub.efi and so is not subject to verification. Trivial fix is to explicitly add linux.mod to grub.efi which restores previous configuration. Probably shim_lock should not return GRUB_VERIFY_FLAGS_DEFER_AUTH if secure boot is disabled, but that is really upstream issue. More challenging is implementing EFI signature for grub modules. When shim is not loaded, shim_lock does nothing so this problem does not occur.
I'll note that if secure-boot is enabled, then under the same conditions the attempt to boot silently does nothing.
Yes, this is SUSE patch which makes loading external grub module noop if secure boot is enabled, so grub never gets as far as calling verifiers.
It is supposed to be a feature of grub-2.04, that "linux" and "linuxefi" are interchangeable. But the new shim is being very fussy and insisting on using "linuxefi".
It is not shim, it is grub. -- You are receiving this mail because: You are on the CC list for the bug.