fedora-shim-20210414

[vathpela]

Make sure you have provided the following information:

• link to your code branch cloned from rhboot/shim-review in the form user/repo@tag
• completed README.md file with the necessary information
• shim.efi to be signed
• public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE)
• binaries, for which hashes are added do vendor_db ( if you use vendor_db and have hashes allow-listed )
• any extra patches to shim via your own git tree or as files
• any extra patches to grub via your own git tree or as files
• build logs

Note: this build differs from those in issue #146 only in the following ways:

• fixed shim package revision in .sbat data (cosmetic only)
• several minor bugfixes as listed in the patch list in https://github.com/vathpela/shim-review/blob/fedora-shim-20210414/README.md

What organization or people are asking to have this signed:

The Fedora Project

What product or service is this for:

Fedora Linux

Please create your shim binaries starting with the 15.4 shim release tar file: https://github.com/rhboot/shim/releases/download/15.4/shim-15.4.tar.bz2 . This matches https://github.com/rhboot/shim/releases/tag/15.4 and contains the appropriate gnu-efi source. Please confirm this as the origin your shim.

This starts with the shim 15.4 release tarball.
Here is the review repo: vathpela/shim-review@fedora-shim-20210414, which includes README.md, both shim EFI binaries, fedora-ca-20200709.cer, and the build logs root.log and build.log.

What's the justification that this really does need to be signed for the whole world to be able to boot it:

We're a major bigtime OS vendor

How do you manage and protect the keys used in your SHIM?

They're stored in an HSM.

Do you use EV certificates as embedded certificates in the SHIM?

No.

If you use new vendor_db functionality, are any hashes allow-listed, and if yes: for what binaries ?

We don't use vendor_db in this build.

Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a Linux kernel ?

All of the following commits are present:

475fb4e8b2f4444d1d7b406ff3a7d21bc89a1e6f
1957a85b0032a81e6482ca4aab883643b8dae06e
612bd01fc6e04c3ce9eb59587b4a7e4ebd6aff35
75b0cea7bf307f362057cc778efe89af4c615354
435d1a471598752446a72ad1201b3c980526d869

And the configuration setting CONFIG_EFI_CUSTOM_SSDT_OVERLAYS is disabled.

if SHIM is loading GRUB2 bootloader, are CVEs CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233, CVE-2020-10713, CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705, ( July 2020 grub2 CVE list + March 2021 grub2 CVE list ) and if you are shipping the shim_lock module CVE-2021-3418 fixed ?

Yes, these are all fixed

"Please specifically confirm that you add a vendor specific SBAT entry for SBAT header in each binary that supports SBAT metadata ( grub2, fwupd, fwupdate, shim + all child shim binaries )" to shim review doc ? Please provide exact SBAT entries for all SBAT binaries you are booting or planning to boot directly through shim

On shim, we have:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
shim,1,UEFI shim,shim,1,https://github.com/rhboot/shim
shim.redhat,1,The Fedora Project,shim,15.4-5.fc33,https://src.fedoraproject.org/rpms/shim-unsigned-x64

On grub2, we have:

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.06~rc1,https//www.gnu.org/software/grub/
grub.fedora,1,The Fedora Project,grub2,2.06~rc1-3.fc34,https://src.fedoraproject.org/rpms/grub2

Were your old SHIM hashes provided to Microsoft ?

Yes.

Did you change your certificate strategy, so that affected by CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779, CVE-2021-20225, CVE-2021-20233, CVE-2020-10713, CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705 ( July 2020 grub2 CVE list + March 2021 grub2 CVE list ) grub2 bootloaders can not be verified ?

We revved the cert for the 2020 batch of CVEs; for this one we require .sbat and are revoking the shims that don't require it.

What exact implementation of Secureboot in grub2 ( if this is your bootloader ) you have ?

• Upstream grub2 shim_lock verifier or
• Downstream RHEL/Fedora/Debian/Canonical like implementation ?

It is a Fedora-like implementation in the grub 2.04 builds; a couple of those patches are still applicable on the 2.06 rc1 versions.

What is the origin and full version number of your bootloader (GRUB or other)?

It's grub with a little light patching ;)

If your SHIM launches any other components, please provide further details on what is launched

We also have fwupd, which will have similar .sbat provisions to grub2.

If your GRUB2 launches any other binaries that are not Linux kernel in SecureBoot mode, please provide further details on what is launched and how it enforces Secureboot lockdown

No, only linux.

If you are re-using a previously used (CA) certificate, you will need to add the hashes of the previous GRUB2 binaries exposed to the CVEs to vendor_dbx in shim in order to prevent GRUB2 from being able to chainload those older GRUB2 binaries. If you are changing to a new (CA) certificate, this does not apply. Please describe your strategy.

We're using a post-boothole certificat and dbxing the intermediate shims that didn't require sbat.

How do the launched components prevent execution of unauthenticated code?

Everything validates signatures using shim's protocol.

Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)?

No.

What kernel are you using? Which patches does it includes to enforce Secure Boot?

This supports kernels ranging from kernel-5.6.6-300.fc32 to kernel-5.12.0-0.rc5.180.fc35, which are all patched for the kernel boothole CVEs and have the CONFIG_EFI_CUSTOM_SSDT_OVERLAYS config option disabled.

What changes were made since your SHIM was last signed?

Only upstream changes.

What is the SHA256 hash of your final SHIM binary?

random:~/devel/github.com/shim-review/fedora-shim-20210414$ sha256sum shim*.efi
eec952884d52040fbea5440fa88ae688e60b6d6fbe19f171a012b55c805f82df  shimia32.efi
c0e6c6316015b79bbe895bab3f06040771607d467c2d21e242cbce0bb29451a3  shimx64.efi

These represent the following submission IDs:

• 14015897820361694 shimia32
• 14020966244622788 shimx64

[Doncuppjr]

If you revved the cert, why does it have such a historical start date?

[jsetje]

I bet that cert was created after the previous SB event. Depending on a specific org's policies, creating a new CA cert can be a bit of a ceremony. So I'm not surprised that they didn't re-create one just to get a newer start date.

[jsetje]

The additional patches are reasonable, all the other answers are good and the build reproduces for me.

[Doncuppjr]

@jsetje O.k. but they say they created a new cert, so why not make it current?

[martinezjavier]

@Doncuppjr it says that a post-boot hole cert was created, not a new one for this submission.

[realnickel]

FWIW, build reproduces for me.

But I have a question about justification of vendor specific name selection for fedora's shim:

shim.redhat,1,The Fedora Project,shim,15.4-5.fc33,https://src.fedoraproject.org/rpms/shim-unsigned-x64>

We see "shim.redhat" and "The Fedora Project" while "grub.fedora" and "The Fedora Project" is used for fedora's grub...

I checked the same for RHEL and there we see "shim.redhat" and "Red Hat" for shim.

So I'm slightly confused: why not to use "shim.fedora" and "The Fedora Project" or "shim.redhat" and "Red Hat"?
@vathpela, your explanation may help others having more than one product to select vendor specific name correctly.

[martinezjavier]

@realnickel I won't speak for @vathpela but I'll provide my take on this. Sorry that the answer is a little bit long...

What the <component_name,component_generation> tuple implies is that set of fixed vulnerabilities that a given binary provides.

Each line of the .sbat section could be considered a layer on top of the previous one. The reason why we use a SBAT vendor entry on top of the upstream SBAT entry, is that vendors could have downstream patch that may introduce vulnerabilities. By having this vendor entry a vulnerability in a downstream patch won't affect the upstream entry that all the other vendors are using.

If different distros are using the exact same source, then there's really no need to have a $component.$foo and $component.$bar entries. Since otherwise a vulnerability in the common codebase would require to have two different entries in the SbatLevelRT variable to revoke what is effectively the same component and generation.

The reason why grub.fedora and grub.rhel was used (in fact was grub.rhel7 and grub.rhel8 but I'll return to that point later), is because the GRUB package different significantly between Fedora and RHEL. So there could be a vulnerability that is present in one but not in the other. Using grub.rhel for all would mean that a vulnerability in one package would require to bump the generation also in the other.

But shim has a simpler codebase than GRUB and is easier to make all distros to use always the same codebase (in fact we try to just use vanilla upstream shim and do rebases when needed, rather than have an older version with patches on top). That's why a single shim.redhat was used for Fedora and RHEL shim binaries.

If there's ever a need to make a distinction between the two, then a shim.fedora and shim.rhel could be used.

This is also why we used grub.rhel7 and grub.rhel8, because the GRUB code differs significantly between RHEL7 and RHEL8. Since both will use the upstream grub,1 entry (because we didn't have one before), we thought that would make more sense to have different vendor entries instead of making one package to bump the generation of the other if would had used the same component name for both.

But in the future we would just use grub.rhel, since even when RHEL9 and RHEL10 will likely differ on the GRUB upstream release, their upstream grub,$gen entry will also differ.

[julian-klode]

Accepted. I'm happy with the reviews performed so far, also Fedora's grub is kind of the reference for most people, the answers seemed in order, and it also builds reproducibly for me.

[realnickel]

@realnickel I won't speak for @vathpela but I'll provide my take on this. Sorry that the answer is a little bit long...
[...]

@martinezjavier, thanks for your detailed answer. I guess it is worth being pinned for some time for newcomers or even referred in shim's SBAT.md.

[jsetje]

@jsetje O.k. but they say they created a new cert, so why not make it current?

@Doncuppjr Their reasons may differ, but most orgs can't just create a new CA cert on a whim. This may require a quorum of people, potentially involving tavel, or line up with a time-based unlock.

[Doncuppjr]

@jsetje I get that, so why if they did in fact rev the certificate, shouldn't it be current?? In other words, if they went through the trouble to change the cert, why not make it current as well?

[jsetje]

Then they would have to create another one, potentially introducing another 6 months of delay or so. I am not at all surprised that using the new one they have on the shelf right now is essentially required.

[Doncuppjr]

@jsetje @martinezjavier After reading through Ubuntu's key gen and signing process. I think I understand what they are doing now. Thank you for your patience and direction.