-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
shim-15.4 for Isoo (2022-02-05) #202
Comments
My previously accepted SHIM: |
Can the submission be reviewed |
The shim submitted this time uses patches provided by Debian and adds blacklist dbx. |
Can the submission be reviewed |
Still, I guess, as you provide vendor_dbx hashes, you also should have provided mentioned binaries as checklist requires... @haobinnan, IMHO it would be more convenient for reviewers if rebuild artifacts were exported from container or container remained undeleted for manual review. |
vendor_dbx binaries have been provided, and they can be found here: https://github.com/haobinnan/shim-review/tree/isoo-shim-20211012 |
@frozencemetery You added the incomplete tag a month ago without a comment, do you think this is complete now? |
Right, I added it because the checklist at the top was not filled out all the way. It looks like binaries may have been provided in #202 (comment) and the checklist just wasn't updated |
@frozencemetery I think it's more a case of vendor_db being empty and so they ignored the checkmark (the files were for vendor_dbx; which arguably matters less). |
May I know if my SHIM can be reviewed and accepted? |
May I know if my SHIM can be reviewed and accepted? |
Hello, would it be possible to review my shim? I found that there is something wrong with the shim submitted last time, so I submit a new one. Thank you very much! |
@haobinnan, do you mean you will change the submission when another "new one" is ready, or do you mean |
@realnickel |
You are welcome. By the way, while you are waiting for the review you might want to participate in submitters cross review as it was suggested several times before: #165 (comment) |
Thank you very much for your quick response. May I know if my shim can be reviewed and accepted now? |
The link provided above contained a recipe, but let me put a direct link to the manual here: Using this guidelines you may provide a preliminary review to any of the open submissions (https://github.com/rhboot/shim-review/issues) not marked as "accepted" the way I provided it for yours before: #202 (comment) You are expected to check step-by-step and post your results as a comment to the reviewed submission. Many of us are waiting here for more than 2 or 3 months and I guess only active cross-reviewing may help to reduce the growing queue as review-board members seem to be overwhelmed. |
Can the submission be reviewed |
Link in #c0 is not a tag. Furthermore, no tags have been provided in comments. There have been many tags in that repo; I'm going to assume you mean isoo-shim-20211012 but please be clear about this in the future. Dockerfile calls an external shell script. It would be nicer not to do this. But can you explain what "AtomLinux" is? There's also a fair amount of dead code it would be nice to prune. Nonetheless, I have verified the build reproduces. fix_arm64_rela_sections.patch: this resembles 34e3ef205c5d65139eacba8891fa773c03174679 but the Makefile changes do not match. Is this a mistake? Submission does not answer all questions in submission checklist, but this information is available. (Please fill out the checklist completely in the future.) Cert doesn't match submitting org - submission says "Qinhuangdao Yizhishu Software Development Co., Ltd." while cert says "Isoo Software Development Co., Ltd.". Can you clarify the relationship between these two entities? It is not clear to me what grub and kernel you are using. |
Thank you very much for the comments. #192 has problem, so I submit #202.
Kernel: |
I found that you removed the "question" tag. May I know if my submission can be accepted? |
Can the submission be reviewed |
Can the submission be reviewed |
So the only pending question I have is about access control (6), which I'll defer to those who have been around longer. |
@frozencemetery You wrote "Ceritifcate does not use HSM", but the submission says "They're in an HSM" |
Ah, yeah. I was reading from README.md where it says "My certificate is stored in a db created by pesign, which is stored on a separate computer that is only used for signing and only few trusted administrators can access it. Linux kernel, grubia32.efi and grubx64.efi are signed using this certificate." |
@haobinnan Please address the conflicting information. I vaguely recall something, but I don't remember really. |
We only embed out CA certificate. This CA is used to sign further signing certificates which are used for signing the binaries. No other hashes are [CertFile.cer] |
Do you still have any questions? Could you please specify the problem? |
shim reviews are intended to be collaboratively done amongst distro vendors. The idea is that we provide a check on each other to ensure quality. This is not a service that "you" pay "us" for: there is no separation between the two. Most of us are overworked, and badgering those who can find time to do reviews at all only punishes us for trying - without offering any assistance of your own. If you want your submission done sooner, the best thing to do is make sure it is of good quality, and to |
Make sure you have provided the following information:
https://github.com/haobinnan/shim-review/tree/isoo-shim-20220205
What organization or people are asking to have this signed:
What product or service is this for:
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.
What's the justification that this really does need to be signed for the whole world to be able to boot it:
How do you manage and protect the keys used in your SHIM?
Do you use EV certificates as embedded certificates in the SHIM?
If you use new vendor_db functionality, are any hashes allow-listed, and if yes: for what binaries ?
Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a Linux kernel ?
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 ?
"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
Were your old SHIM hashes provided to Microsoft ?
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 ?
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 ?
What is the origin and full version number of your bootloader (GRUB or other)?
If your SHIM launches any other components, please provide further details on what is launched
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
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.
How do the launched components prevent execution of unauthenticated code?
Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)?
What kernel are you using? Which patches does it includes to enforce Secure Boot?
What changes were made since your SHIM was last signed?
What is the SHA256 hash of your final SHIM binary?
The text was updated successfully, but these errors were encountered: