shim 15.6 for MIRACLE LINUX 8.6

[tSU-RooT]

Confirm the following are included in your repo, checking each box:

• 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 to 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

---

What is the link to your tag in a repo cloned from rhboot/shim-review?

---

https://github.com/miraclelinux/shim-review/tree/miraclelinux-shim-x64-20220803

---

What is the SHA256 hash of your final SHIM binary?

---

8b091c13daecd709c0d63d6195afa51a97e17259a219d140b67789b299fb4b3e  shimia32.efi
28d103d158eff69bc318ef41f78a7714a7cdc43c6ab0d860e7191fdc3e7b8640  shimx64.efi

[frozencemetery]

Not all boxes are checked.

[tSU-RooT]

I've marked vendor_db box. (I misunderstood about case of answer is 'not applied')
We updated repository to fix pointed issues at #264 .

New tag is: https://github.com/miraclelinux/shim-review/tree/miraclelinux-shim-x64-20220901

[steve-mcintyre]

Looking:

• shim builds reproduce here
• shim from upstream 15.6, no patches
• self-signed non-CA cert, expires 2027
• SBAT looks (mostly) ok, see below
• revocation story sounds ok
• kernel sounds (mostly) ok, seel below
• HSM for key management
• still looking at grub stuff

Issues / things to look at:

• Your shim SBAT data looks fine, but minor issue with the grub SBAT. You don't need to increase the grub.miracle8 SBAT level to 2 just because upstream grub has been increased.
• You said "no" to the question about kernel patch eadb2f47a3ced5c64b23b90fd2a3463f63726066. Are you sure you're not vulnerable here? (Please explain).

[steve-mcintyre]

contact verification mails sent

[tSU-RooT]

lied field pickers sol diminuendos erected catastrophic Aprils prefabricated alley

[tSU-RooT]

I received a message from secondary contact.
Keywords are:
unbelievable rustled Lippmann scullery moons embroidering recliner advocating supplied marabou

[tSU-RooT]

Your shim SBAT data looks fine, but minor issue with the grub SBAT. You don't need to increase the grub.miracle8 SBAT level to 2 just because upstream grub has been increased.

Hmm..., I had thought vendor must increase component_generation of own entry when important vulnerabilities are found(and fix), but is it means OK to do not bump number when it is increased by upstream side?

If yes, we must decrease number of grub.miracle8 to 1?

You said "no" to the question about kernel patch eadb2f47a3ced5c64b23b90fd2a3463f63726066. Are you sure you're not vulnerable here? (Please explain).

RHEL based kernels are set CONFIG_KDB_DEFAULT_ENABLE(kdb_cmd_enabled) as 0x0(=0=disable) in kernel-x86_64.config, kernel-x86_64-debug.config (aarch64 is exception, set as 0x1 but we have no plans for aarch64)
So I think CVE-2022-21499 is not vulnerable by default kernel config.

More detail about eadb2f47a3ced5c64b23b90fd2a3463f63726066:
Upstram commit added kdb_check_for_lockdown() to fix CVE-2022-21499
kdb_check_for_lockdown() does not change flag when kdb_cmd_enabled is 0.

[steve-mcintyre]

Your shim SBAT data looks fine, but minor issue with the grub SBAT. You don't need to increase the grub.miracle8 SBAT level to 2 just because upstream grub has been increased.

Hmm..., I had thought vendor must increase component_generation of own entry when important vulnerabilities are found(and fix), but is it means OK to do not bump number when it is increased by upstream side?

Yes, that's correct.

If yes, we must decrease number of grub.miracle8 to 1?

You said "no" to the question about kernel patch eadb2f47a3ced5c64b23b90fd2a3463f63726066. Are you sure you're not vulnerable here? (Please explain).

RHEL based kernels are set CONFIG_KDB_DEFAULT_ENABLE(kdb_cmd_enabled) as 0x0(=0=disable) in kernel-x86_64.config, kernel-x86_64-debug.config (aarch64 is exception, set as 0x1 but we have no plans for aarch64) So I think CVE-2022-21499 is not vulnerable by default kernel config.

That's fine. That's what I hoped you'd say, but it's much better to be
explicit here! :-)

[steve-mcintyre]

I'd like to have a look at your grub sources - can you share them please? In your README.md, you list the version but nothing more.

[tSU-RooT]

In your README.md, you list the version but nothing more.

OK, We will note more detail next time.

All sources of grub2 are checked-in grub2 dir: https://github.com/miraclelinux/shim-review/tree/miraclelinux-shim-x64-20220803/grub2
sbat.csv.in is: https://github.com/miraclelinux/shim-review/blob/miraclelinux-shim-x64-20220803/grub2/sbat.csv.in
Our change log in grub2.spec is : https://github.com/miraclelinux/shim-review/blob/miraclelinux-shim-x64-20220803/grub2/grub2.spec#L505
No local patch is added from 2.06-123.el8_6.8.

[frozencemetery]

So there's not a lot of information in your submission about what MIRACLE LINUX is, but wikipedia suggests it's an el8 rebuild. Is that the case? If so, could you just ship the signed shim+grub2+kernel from RHEL 8?

[tSU-RooT]

Sorry for late response.

but wikipedia suggests it's an el8 rebuild. Is that the case?

Yes.

If so, could you just ship the signed shim+grub2+kernel from RHEL 8?

Is it means that we(i.e.downstream) should attach these SRPMs GPG signed by RH for shim-review?
Rebuilded SRPMs are unpreferable?

I will close this issue since shim 15.6 is no longer passable by upstream's 15.7 release.
We are waiting new release from el8 for shim 15.7