Created attachment 1897919 [details]
ovmf varstore

This is a variable store with:
 (a) fedora secure boot ca certs enrolled, and 
 (b) microsoft keys removed, and
 (c) boot entry pointing to grubx64.efi

This can be used to reproduce the problem.  Grab a
fedora cloud image, try boot it in a virtual machine
with this varstore instead of
/usr/share/edk2/ovmf/OVMF_VARS.secboot.fd

I'm not sure what the problem you're reporting here is.  We ship shim.efi, so why isn't it present?

(In reply to Robbie Harwood from comment #2)
> I'm not sure what the problem you're reporting here is.  We ship shim.efi,
> so why isn't it present?

See comment 1.  The microsoft keys are not present, only the fedora keys.

Given that shim.efi is signed with the microsoft keys only (instead of both microsoft and fedora keys) I can't load it.
There also is no fedora-signed variant (unlike rhel which ships a shim-redhat.efi in addition to shim.efi).

So I tried to load grub directly.

Indeed, we expect shim to always be in the boot chain.  shim is what transitions from the hardware root of trust to the OS root of trust, and that's an operation that needs to happen.

If you'd like to discuss your use case, or a particular feature you'd like to have added, please open an RFE.

(In reply to Robbie Harwood from comment #5)
> Indeed, we expect shim to always be in the boot chain.

Ok.  Which implies booting a fedora machine without microsoft keys requires 
a shim.efi binary signed with the fedora distro keys.  Which we don't have.

> shim is what
> transitions from the hardware root of trust to the OS root of trust, and
> that's an operation that needs to happen.

That is a borderline misleading description of the situation.

The UEFI firmware allows to configure whom you want trust and whom you
don't want trust, by enrolling or removing keys from 'db'.  There is no
need to do a 'transition'.

The issue is that there is no standardized way to manage trust.  Every
firmware implements its own way to do so (and some don't).  And *that* is
problem shim + mokmanager are solving.  Ideally the functionality implemented
in mokmanager (allow the OS ask for keys being enrolled or removed, on next
boot ask the user to confirm that action, ...) would be provided by the
firmware.  We don't have that though 😒

So we ended up with two trust databases, 'db' managed by the firmware
and 'MokList' managed by mokmanager, and shim consulting both when
checking signatures of efi binaries.

You can go the extra mile and setup 'db' the way you want.  For example
remove the microsoft keys (because you don't want trust everything signed
with them) and add the fedora keys instead.  If you do so the reason for
shim to exist in the first place goes away.

> If you'd like to discuss your use case, or a particular feature you'd like
> to have added, please open an RFE.

See comment #3.  I want boot fedora in secure boot mode without the
microsoft keys enrolled.

So if you don't want support grub.efi working without shim.efi (to reduce
QA effort I guess) the only option left is signing shim.efi with the fedora
keys.  Either rhel-style, with a separate binary.  Or a single binary with
both microsoft and fedora signatures.  I think the later would be better
because that way it would not be needed to configure a non-default boot file,
and it would also worrk for boot media.

(In reply to Gerd Hoffmann from comment #6)

> Or a single binary with both microsoft and fedora signatures.

I could be totally wrong, but I seem to remember that this has been (or
should have been) the case for several years now? I've always thought
that the *intent* has been this, at least -- and now my most recent
impression from this BZ has been that only the signing details /
implementation went awry.

I think Peter had written up the whole signing process (connected to
Brew somehow) somewhere, but I don't remember that either :/

(In reply to Laszlo Ersek from comment #7)
> (In reply to Gerd Hoffmann from comment #6)
> 
> > Or a single binary with both microsoft and fedora signatures.
> 
> I could be totally wrong, but I seem to remember that this has been (or
> should have been) the case for several years now?

It's not the case.

$ pe-listsigs /boot/efi/EFI/fedora/shimx64.efi
# file: /boot/efi/EFI/fedora/shimx64.efi
[ ... ]
#    sigdata: 0x0e4cc0 +0x002558
#       signature: len 0x2558, type 0x2
#          certificate
#             subject CN: Microsoft Windows UEFI Driver Publisher
#             issuer  CN: Microsoft Corporation UEFI CA 2011
#          certificate
#             subject CN: Microsoft Corporation UEFI CA 2011
#             issuer  CN: Microsoft Corporation Third Party Marketplace Root

On RHEL we have:

$ pe-listsigs /boot/efi/EFI/redhat/shimx64*.efi
# file: /boot/efi/EFI/redhat/shimx64-redhat.efi
[ ... ]
#    sigdata: 0x12fb98 +0x000a28
#       signature: len 0xa28, type 0x2
#          certificate
#             subject CN: Red Hat Secure Boot Signing 501
#             issuer  CN: Red Hat Secure Boot CA 5
#          certificate
#             subject CN: Red Hat Secure Boot CA 5
#             issuer  CN: Red Hat Secure Boot CA 5
# file: /boot/efi/EFI/redhat/shimx64.efi
[ ... ]
#    sigdata: 0x12fb98 +0x002148
#       signature: len 0x2148, type 0x2
#          certificate
#             subject CN: Microsoft Windows UEFI Driver Publisher
#             issuer  CN: Microsoft Corporation UEFI CA 2011
#          certificate
#             subject CN: Microsoft Corporation UEFI CA 2011
#             issuer  CN: Microsoft Corporation Third Party Marketplace Root

That is slightly better, it is at least possible to boot,
but the split into two binaries makes it inconvenient to use.

(pe-listsigs comes with python3-virt-firmware.rpm, version 1.2+,
 which should be in fedora-updates-testing right now).