Shim 15.4 for MIRACLE LINUX 8

[tSU-RooT]

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
• a Dockerfile to reproduce the build of the provided shim EFI binaries

Link to our code branch for review: miraclelinux/shim-review@ml8-shim-15.4-20210629

What organization or people are asking to have this signed:

Cybertrust Japan Co., Ltd.

What product or service is this for:

MIRACLE LINUX 8

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.

Source is starting from upstream 15.4 release, tarball matches with upstream release at level of sha256sum.
https://github.com/miraclelinux/shim-review/raw/ml8-shim-15.4-20210629/shim-15.4.tar.bz2

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

We have received request from our customer that they wants to enable SecureBoot for OEM computer without indivisual signature from hardware vendor specially.

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

Our private key is stored in HSM(Yubikey), this will be only available while speicific package build.(e.g. shim, grub2, kernel, fwupd)

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 ?

Not applied.
We don't use vendor_db functionality at present.

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

This commits(75b0cea7bf307f362057cc778efe89af4c615354) is included for 5.8 version.
Our kernel is based on linux kernel version 4.18.0.
Strictly speaking, 75b0cea7bf307f362057cc778efe89af4c615354 is not applied for this reason.
But nearly fixes are included for our kernel from origin of RHEL.

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 grub2 CVEs were 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

We are planning below SBAT entries.
For shim:

shim.ML,1,Cybertrust Japan,shim,15.4-4,ml-packager@miraclelinux.com

For grub2:

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.ML8,1,Cybertrust Japan,grub2,2.02-99.el8.ML.1,mail:ml-packager@miraclelinux.com

Were your old SHIM hashes provided to Microsoft ?

No, we haven't.

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 ?

Not applied.
Our previous submission had closed, so we have no old grub2 binary for SecureBoot.

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 ?

RHEL-like implementation, we are downstream.

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

GRUB2's upstream version is 2.02
https://git.savannah.gnu.org/gitweb/?p=grub.git;a=tag;h=refs/tags/grub-2.02
Full version number will 2.02-99.el8.ML.1.
This is derived from RHEL with our certfications and SBAT CSV.

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

No, only linux kernel.

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

Not applied.

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 re-using, we have re-newed certificate in this year March.

How do the launched components prevent execution of unauthenticated code?

By SecureBoot ways.
Shim, Grub2, Kernel will prevent unauthenticated code in SecureBoot enabled environment.

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?

Our kernel is derived from RHEL.

What changes were made since your SHIM was last signed?

Our previous submission had closed semi-automatic for BootHole vulnerability.
Therefore, we have no last signed SHIM.

What is the SHA256 hash of your final SHIM binary?

$ sha256sum shimia32.efi shimx64.efi
416f59378de5bc6f01ecbb992b4efe23b305711881f6bed9acc668656ee00128  shimia32.efi
7cbecc62764694c1ca279805ebd611b356a481e521561d97a6311aadb839d154  shimx64.efi

[julian-klode]

We have received request from our customer that they wants to enable SecureBoot for OEM computer without indivisual signature from hardware vendor specially.

Would have liked to hear something about who you are and what you are building.

[tSU-RooT]

Would have liked to hear something about who you are and what you are building.

Oh I didn't recognize it.

Who we are:
We are Cybertrust Japan, OS vendor in Japan focuses to Linux distributions.
https://www.cybertrust.co.jp/english/

For one example, we are sponsoring to CIP(Civil Platform Infrastructure) for long term support in OS area.
https://www.linuxfoundation.org/en/press-release/civil-infrastructure-platform-announces-collaboration-with-the-debian-lts-initiative-and-welcomes-cybertrust-as-a-new-member/

What we are building:
We are building RHEL-derivative distribution as MIRACLE LINUX(ex-Asianux) in Japan for 19 years.

Distrowatch(Sorry these information are very old):
https://distrowatch.com/table.php?distribution=miracle
https://distrowatch.com/table.php?distribution=Asianux

[miray-tf]

I think that 'ML' as product specifier in the SBAT entries is too short.
Those specifiers should be unique and some other vendor might also try to use that abbreviation in the future.

[tSU-RooT]

'miracle' or 'miraclelinux' is better for SBAT?
I can still turn back now.

[miray-tf]

Both names should be ok.
In my personal opinion 'miracle' is the better choice of these two.

[tSU-RooT]

Hi, I have changed SBAT entry, and rebuilded shim-unsigend-x64.
Pushed same branch miraclelinux/shim-review@ml8-shim-15.4-20210629.

New SHA256 hashes of SHIM binary are here.

$ sha256sum shimia32.efi shimx64.efi 
678c2e622dda72d348bf3e028434a11fb55df230d57d6fa74a4ad534b5191383  shimia32.efi
a3f048ea3efda6a18c40c1b79d52c6477a451d0c590d022fe3cd385ae92a1f26  shimx64.efi

New SBAT entries are here.

For shim:

shim.miracle,1,Cybertrust Japan,shim,15.4-4,ml-packager@miraclelinux.com

For grub2(planning):

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.miracle8,1,Cybertrust Japan,grub2,2.02-99.el8.ML.1,mail:ml-packager@miraclelinux.com

Anyone can confirm SBAT section in shim from actual binary following commands;

$ objcopy -O binary --only-section=.sbat ./shimx64.efi sbat.txt
$ cat sbat.txt 
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.miracle,1,Cybertrust Japan,shim,15.4-4.el8.ML.1,ml-packager@miraclelinux.com

[steve-mcintyre]

• everything reproduces ok here
• SBAT looks good now with the change to "miracle"
• the only patch you're using is fine, straight from upstream

Things to follow up on:

• cert looks to have a very long duration, I'll be honest
• You say you're using kernel 4.18. Please describe what lockdown patches you've added to that
• Your grub package is obviously based on one from RHEL. Can you point at the version you've derived from, or provide a diff please?
• There are quite a few more important patches that various distros are using on top of shim 15.4 - see [tracking] shim 15.4 critical regressions #165. Please confirm that you're sure you don't need any more of those.

[julian-klode]

Please also preserve the .rhel8 SBAT entries such that your rebuild does not need to be revoked separately when there is a bug in the RHEL8 patch set. This mostly applies to grub, because the rhel8 grub patch set is large enough to treat it as a separate upstream essentially.

[tSU-RooT]

@julian-klode

Please also preserve the .rhel8 SBAT entries such that your rebuild does not need to be revoked separately when there is a bug in the RHEL8 patch set.

OK, I have recognized this.

We will change SBAT section in grub2 source.
Is this good with the following content?

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,2.02-99.el8,mail:secalert@redhat.com
grub.miracle8,1,Cybertrust Japan,grub2,2.02-99.el8.ML.1,mail:ml-packager@miraclelinux.com

And one more thing, is this need for only grub2?
Should I restore .redhat, .rhel8 entries for other components(e.g. shim, fwupd)?

[tSU-RooT]

@steve-mcintyre
Hi, I will follow up your questions.

cert looks to have a very long duration, I'll be honest

Yes, very long.
There are two reasons for it:

• Our customor prones to use system for very long years. Even after normal support terms.
• We had referenced CentOS's cert one when we generated, that was configured to 7100 days.

You say you're using kernel 4.18. Please describe what lockdown patches you've added to that

I have putted actual SRPM of kernel. (SRPMS/kernel-4.18.0-305.el8.src.rpm.a*)
Please confirm contents of package.
sha256 checksum is:
502af547177128f893373c5cc15c7e9c6722b24c64c65debf0a36c7f3a07aa8a kernel-4.18.0-305.el8.src.rpm

Actually, this is same as RHEL8 in source-code level except debranding.

Your grub package is obviously based on one from RHEL. Can you point at the version you've derived from, or provide a diff please?

Derived from RHEL8's grub2-2.02-99.el8.
The differences are:

• Defined different package version for distinction.
• Replaced certificate files to ours.
• Modified some macros intentionally because we need to fit token name for our signing process.
• Avoid to double sign for binary(rhel8's grub2.macros do pesign at twice)

There are quite a few more important patches that various distros are using on top of shim 15.4 - see
[tracking] shim 15.4 critical regressions #165. Please confirm that you're sure you don't need any more of those.

OK.
I saw this issue and checked upstream commit and debian's patches in reference.
Found problems seems to reproducible on some specific machines("MacBookPro8,2", ThinkPad T490, Dell Optiplex 790) and aarch64 environment.
If we encounter these problems often on server machine, I should decide to port these patches to solve.
But we and users will see such cases at only rarely case I think.
So I think not to need backport patch individually at present.

[tSU-RooT]

I have updated SRPM of grub2 which includes new sbat.csv.in.

New grub2's SBAT content will be below:

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,1:2.02-99.el8,mail:secalert@redhat.com
grub.miracle8,1,Cybertrust Japan,grub2,1:2.02-99.el8.ML.2,mail:ml-packager@miraclelinux.com

Have I now answered all the questions that pointed out?

[tSU-RooT]

Hi, we are waiting to accept our shim.
Is there anything else to do get OK from the reviewer?

[tSU-RooT]

@julian-klode
Would you please take a moment to review our shim?

[julian-klode]

I have sent you emails with lists of words (different for each person) to validate the email addresses and GPG keys. Please paste the values here, or reply via email to prove control of both address and GPG key.

(I actually had to send each email twice as I accidentally sent the same list to both)

[julian-klode]

We'd prefer if we had a public docker image to start the build from, the tarball is somewhat problematic to review with.

[tSU-RooT]

@julian-klode

I have sent you emails with lists of words (different for each person) to validate the email addresses and GPG keys.

Thank you very much!

Please paste the values here, or reply via email to prove control of both address and GPG key.

webbasierten Talentes gewöhnlichen Flügeln abstreichenden erbringende
danebenliegendes geduldigen wiedergekehrten Wahlveranstaltungen

[Yasuhiro-Nakamura]

I recived your email.

Please paste the values here, or reply via email to prove control of both address and GPG key.

umrüstbarem schnorre Mitverursachern redefiniertem Flussdiagramms
Rückgabe kleidsamsten Polarfluges Spekulantenecke Weinernte

[tSU-RooT]

@julian-klode

We'd prefer if we had a public docker image to start the build from, the tarball is somewhat problematic to review with.

I see, I have changed strategy to start from CentOS's public docker image. miraclelinux@02e2678

shim reproducibility is also OK.

[julian-klode]

tSU-RooT verified.

Hey, @Yasuhiro-Nakamura I sent you a second email a few minutes after that one with other words, as I accidentally reused the same words, could you let me know those?

[julian-klode]

What was being reviewed? ml8-shim-15.4-20210629 currently points at the following commit:

commit 02e2678d04cb7739dd084282183a4b285a03d2b2 (HEAD -> ml8-shim-15.4-20210629, miraclelinux/ml8-shim-15.4-20210629)
Author: Haruki TSURUMOTO <haruki.tsurumoto@miraclelinux.com>
Date:   Mon Nov 15 20:01:39 2021 +0900

    Change start point to CentOS official public image
    
    To make easier verifying of layers.

E-Mail verification: One outstanding.
Reproducibility The docker build is reproducible

$ sha256sum  shim*.efi
678c2e622dda72d348bf3e028434a11fb55df230d57d6fa74a4ad534b5191383  shimia32.efi
a3f048ea3efda6a18c40c1b79d52c6477a451d0c590d022fe3cd385ae92a1f26  shimx64.efi

These hashes do not match the issue description which lists

07a4b39f712ffa4a71ca7c79edb6aec8b89612896e7f221fdf4cf2265e8c5669  shimx64.efi

But it does match the README.md

Source code+Patches: This looks OK. It misses a ton of patches from #165, but there are no security concerns.

Answers: OK

** Certificate **

⚠️ The embedded certificate does not seem to be a CA, and has too long an expiry.

            Not After : Apr  4 06:35:51 2041 GMT                    
           [...]
            X509v3 Basic Constraints: critical
                CA:FALSE  

** SBAT **

The SBAT component is .miracle, and .miracle8 for the grub.

Have any grubs been signed with the certificate that still had an SBAT component of .ML8? If so, what is done to ensure this shim is unable to boot them?

** grub, kernel ** RHEL rebuild.

**Conclusion **

⚠️ This submission is rejected due to the embedded certificate having a long duration while not being a CA.

Work is needed to either switch to a CA key, or a non-CA key with a usual expiry of 1-5 years. This will also address any concerns about whether this certificate accepts grubs with the "old" .ML8 SBAT component.

[Yasuhiro-Nakamura]

tSU-RooT verified.

Hey, @Yasuhiro-Nakamura I sent you a second email a few minutes after that one with other words, as I accidentally reused the same words, could you let me know those?

leidvolle prüderes großflächigeren höherwertigen angefasst Nebraska
mafiösere produzierbarem Hollywoods aufbegehrender

[julian-klode]

tSU-RooT verified.
Hey, @Yasuhiro-Nakamura I sent you a second email a few minutes after that one with other words, as I accidentally reused the same words, could you let me know those?

leidvolle prüderes großflächigeren höherwertigen angefasst Nebraska mafiösere produzierbarem Hollywoods aufbegehrender

Those look good. emails are all verified now.

Once the certificate issue is addressed, we can continue, but maybe we should close this one and open a new submission to keep the queue cleaner if that takes a while.

[frozencemetery]

Closing per #189 (comment) . Please reference this issue when you open a new submission (or reopen this one - I don't remember if github allows that).

[tSU-RooT]

We opened a new submission at #266 that solves certificate issue and update to shim-15.6.