Oracle Linux 7.9 shim-15.3-1.0.1.el7 20210325

[iokomin]

Make sure you have provided the following information:

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

What organization or people are asking to have this signed:

Oracle Corporation

What product or service is this for:

Oracle Linux
https://www.oracle.com/linux/index.html

Please create your shim binaries starting with the 15.3 shim release tar file:

https://github.com/rhboot/shim/releases/download/15.3/shim-15.3.tar.bz2

This matches https://github.com/rhboot/shim/releases/tag/15.3 and contains

the appropriate gnu-efi source.

Please confirm this as the origin your shim.

Upstream shim version 15.3
https://github.com/rhboot/shim/tree/shim-15.3

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

Oracle Linux is a popular enterprise Linux distribution with Secure Boot support.

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

Digicert SSM service hardware protected EV certificates

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

Yes

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

No hashes whitelisted

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

Yes

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

"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

We keep all upstream SBAT entries and also append Oracle specific.
Since most packages in Oracle Linux are based on RHEL we also keep RHEL specific entries.

Oracle specific additions to packages are

grub2 Oracle Linux 7:
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.02,https://www.gnu.org/software/grub/
grub.rhel7,1,Red Hat Enterprise Linux 7,grub2,@@Version@@,mail:[email protected]
grub.ol7,1,Oracle Linux 7,grub2,@@Version@@,mail:[email protected]

grub2 Oracle Linux 8:
sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.02,https://www.gnu.org/software/grub/
grub.rhel8,1,Red Hat Enterprise Linux 8,grub2,@@Version@@,mail:[email protected]
grub.ol8,1,Oracle Linux 8,grub2,@@Version@@,mail:[email protected]

shim Oracle Linux 7:
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.ol7,1,UEFI shim,shim,1,https://github.com/rhboot/shim

shim Oracle Linux 8:
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.ol8,1,UEFI shim,shim,1,https://github.com/rhboot/shim

All new UEFI binaries that are yet to be built with SBAT support will follow agreed SBAT variable pattern and we will add Oracle specific entry for them.

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 ?

Affected grub2 signing cert removed from shim, new signing EV certificate introduced.
New grub2 builds with CVE fix will be signed with new signing EV certificate.

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 ?

Downstream RHEL/Fedora/Debian/Canonical like implementation

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

grub2 v2.02-0.87.0.7.el7 - upstream plus number of patches from RedHat and Oracle

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

No

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

grub2 launches Linux kernel

How do the launched components prevent execution of unauthenticated code?

grub2 verifies signatures on booted kernels via shim

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.

Not applicable, grub2 leaf certificate rotated in Oracle Linux shim

How do the launched components prevent execution of unauthenticated code?

Oracle Linux has same UEFI verification shim framework as RHEL that verifies all launched UEFI binaries.
All modules built into the GRUB2 either use shim framework or disabled when secureboot is enabled.

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?

4.1.12 based kernel with lockdown patches
4.14 based kernel with lockdown patches
5.4 based kernel with lockdown patches
5.8 based kernel with lockdown patches

What changes were made since your SHIM was last signed?

Shim rebased to upstream version shim-15.3
Updated vendor_db certificates

What is the SHA256 hash of your final SHIM binary?

e3256f5470baea73956a6d2c543c827af18c8e787916e5e3bd68c216f392ba73 shimx64.efi
afe55596f9828992d27c802b79f1adaeddeae8083c03c47b8a8cccc9183fce0e shimia32.efi

Link to review tag: https://github.com/iokomin/shim-review/tree/oracle-shim-15.3-1.0.1.el7-x86_64-20210325

[julian-klode]

Everything is the same as in #135: answers are identical, hashes match (would have been cool if the binaries were the same as ol8 but unrealistic :/), sbat seems ok, have not checked grub delta against RH.

[iokomin]

@julian-klode thanks for review
One shim for all releases is in our future plans :)
Same answer for grub2 question - built on top of latest RHEL errata, latest srpm http://yum.oracle.com/repo/OracleLinux/OL7/latest/x86_64/getPackageSource/grub2-2.02-0.87.0.9.el7_9.2.src.rpm

[aburmash]

Here is the full list of Oracle patches on top of RHEL source:
Patch5000: bug18504756-use-different-title-for-UEK.patch
Patch5001: bug30138841-remove-upstream-references.patch
Patch5002: bug32069510-fix-multiboot2-regression.patch
Patch5003: bug32172943-10_linux-Ensure-similar-format-for-menu-entry.patch
Patch5004: bug32584717-xfs-Don-t-attempt-to-iterate-over-empty-directory.patch

the only patches that actually touch grub2 code are:
bug32584717-xfs-Don-t-attempt-to-iterate-over-empty-directory.patch, which is backport of upstream commit http://git.savannah.gnu.org/cgit/grub.git/commit/grub-core/fs/xfs.c?id=c42acc23ff91ea0170eab5f1e10499dcfc4e0c92

bug32069510-fix-multiboot2-regression.patch - small code patch for multiboot2, however it does not affect the review process, since upstream RHEL patch Patch0221: 0221-Make-any-of-the-loaders-that-link-in-efi-mode-honor-.patch
simply does not allow execution of multiboot* in Secureboot mode.

I can attach exact patches if needed.

[aburmash]

In fact i have double checked and we do not even include multiboot into grub EFI image that we sign.

So the only meaningful patch in delta is one string XFS backport from upstream.
I have attached a macros file you can check it for
GRUB_MODULES=
and
%global efi_modules
grub.zip

[aburmash]

Reference centos/RHEL git repos:
https://git.centos.org/rpms/grub2/tree/c7

[julian-klode]

grub2 delta looks ok to me too. I checked out the repo, checked out the previous version in there, diffed the spec from the SRPM against it, and then diffed the dir against the repo sources.

✔️

[steve-mcintyre]

Hey guys,

Do you not run fwupd or similar at all?

[aburmash]

@steve-mcintyre we do have fwupd, but as for now we ARE not issuing a new fwupd and have NOT yet signed it with any of the new certificates.
OLD fwupd will not be bootable because old shim that trusts it is blacklisted.
NEW one is not yet built.

As pretty much none of our customers have a need to use a new fwupd right away, we will have a gap before we release an updated fwupd, because we want to do some extensive testing of it, before actually releasing.
As i have stated, we will followagreed SBAT variable pattern and we will add Oracle specific entry for fwupd SBAT data at the moment of shipping it.

On top: since fwupd is a binary directly booted through shim, presence of SBAT data for fwupd is mandatory and we will have both SBAT data and Oracle specific entry in it when we release a new fwupd, signed by new certificate.

[steve-mcintyre]

builds reproduce fine, good

[steve-mcintyre]

do you have the EV certs for the vendor_db.esl file handy please?

[steve-mcintyre]

shim build looks great, trivial single patch

[steve-mcintyre]

grub2 looks good for me

[iokomin]

@steve-mcintyre please find vendor_db certs in updated https://github.com/iokomin/shim-review/tree/oracle-shim-15.3-1.0.1.el7-x86_64-20210325

[steve-mcintyre]

yay, you got longer expiry on your keys this time! :-)

[steve-mcintyre]

shim and certs look good together. All good here for me.

[steve-mcintyre]

minor nit -your SBAT vendor entries don't point to anything you own. I know it's just a comment, but...

[aburmash]

minor nit -your SBAT vendor entries don't point to anything you own. I know it's just a comment, but...

Thanks for this comment. We would definitely address it in any future releases.

[julian-klode]

Due to some further issues, 15.3 was not sufficient, hence removing accepted and adding wontfix.