Andrei Borzenkov changed bug 1175766
What Removed Added
Status NEW CONFIRMED
CC   arvidjaar@gmail.com

Comment # 5 on bug 1175766 from
(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: