-
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 ZeronsoftN #147
Comments
Accepted ubuntu's grub looks better. git source : https://github.com/zeronsoftn/grub2/tree/zeron/2.04-1zeron02 grub SBAT:
|
Step 10/20 : COPY [ "patches", "/tmp/patches" ] |
Also, a 1 year cert is very short. I would guess you have your EV certificate on the SafeNET token, but is your CA private key also on an HSM? |
Thanks @Doncuppjr Both the CA certificate and the Secure Boot certificate have the key on the HSM. The patches directory was empty, so it wasn't uploaded to git. Fixed it. New Review Branch: New Builder Tag: pesign:
review/hashs.txt (sha256sum):
|
I was able to confirm the hashes. I did run into the following issue. Successfully tagged zeron-shim-builder:latest Also, you didn't tag your shim-review, you branched it. I would have also liked to have the build scripts in the shim-review git, not a separate one. I'll let the approver caveat anything else. |
This issue has not been reproduced. The build script works fine. I tagged it instead of a branch. github workflow log: The hash changed because I modified the sbat hash:
pesign:
|
I still get the following error when running your script. aside from that, I get the following hashes I think your sbat entry shouldn't point to a tree, but rather be a point of contact, so maybe just https://github.com/zeronsoftn/shim-builder and not the exact tree, right now I get the following entry which does not match the submission. d0000 73626174 2c312c53 42415420 56657273 sbat,1,SBAT Vers |
The shim-builder repository is deprecated. In the last comment I said.
New sbat: The output.tar error seems to be due to your environment. The Dockerfile itself prints the hash. |
The builds are reproducible here for me - good |
You're using a plain 15.4 build, which is good. Except... :-( There are two patches since 15.4 that you're likely to want:
The first is important if your kernel includes https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7e1550b8f20 |
Looking at your grub next. Also: you're using the kernel from Alpine? What SB/lockdown patches do they have included? |
Cool, grub looks good. Obviously, you'll need to make a small tweak to the build to add your own SBAT data rather than Ubuntu's. |
SBAT section will be put in through grub2-mkstandalone. So don't have to touch the grub2 source tree. :) The following patch have been applied to the kernel version.
I applied the above two patches.
hashs:
pesign:
|
@steve-mcintyre Thanks for the advice. I also saw the issue. |
Bug #364 isn't a security bug, it stops machines with older EFI firmware (like older Macs) from booting. If that's not a worry for you, then you're probably good here. I'm happy, but I'd like to get a second reviewer to look too. I'll go and prod some people... |
I'm unable to run the docker build, did something change?
|
"build.sh" is a wrapper which sets variables for the docker build. Not ideal, but it worked for me. I think lots of people are not used to driving docker with just "docker build ." etc. :-/ |
Everybody loves a wrapper. |
Thanks! That script then runs _build_impl.sh which uses http://mirror.kakao.com/ubuntu/ is that an official ubuntu mirror? |
This is a very popular mirror in South Korea. |
Hmm, looking again... arm64 shim is being quite problematic for people at the moment. If you're not looking to actively use it immediately, then you might be better to hang back. (See issue #366 for more details) |
I also saw the issue. |
If you don't need the arm shim urgently today, I would like to urge you to drop the arm shim at this point. You can then submit another review when you are ready to use it and the arm builds are more mature and stable. It should be pretty simple to get a quick review that's essentially the same as a previously approved ia32/x64 one. |
FWIW, your ia32 and x64 builds do reproduce for me. |
Thank you. Please ignore arm64 in this review. We need shim very soon to get our new products to market. What else is needed for this review to be accepted? |
Marking accepted now |
Thanks to everyone in the review process. |
Make sure you have provided the following information:
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.
You can see at https://github.com/zeronsoftn/shim-builder/tree/zeron/15.4-1
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 ?
Details: https://github.com/zeronsoftn/grub2/blob/zeron/2.04-1zeron01/debian/changelog (Exactly matches Ubuntu's debian/2.04-1ubuntu26.9 commit)
"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
SHIM :
GRUB
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
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
None
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?
(None)
This is first submission.
What is the SHA256 hash of your final SHIM binary?
How to reproduce the build:
The text was updated successfully, but these errors were encountered: