Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Shim 15.4 for ThinPro 7 (HPI-shim-x64-20210603) #179

Closed
eniaczhp opened this issue Jun 4, 2021 · 10 comments
Closed

Shim 15.4 for ThinPro 7 (HPI-shim-x64-20210603) #179

eniaczhp opened this issue Jun 4, 2021 · 10 comments
Labels
accepted Submission is ready for sysdev

Comments

@eniaczhp
Copy link

eniaczhp commented Jun 4, 2021

Make sure you have provided the following information:

What organization or people are asking to have this signed:
HP Inc.
What product or service is this for:
ThinPro for PC (an Ubuntu based Linux variant).  This is not our first linux release.  The actual version is 7.1/7.2.
What is the origin and full version number of your shim?
https://github.com/rhboot/shim/tree/15
What's the justification that this really does need to be signed for the whole world to be able to boot it:
Previous ThinPro are only released with HP hardwares support.  The next ThinPro release is targeted for not just HP's machines, but also general PC from other vendors.  We need our bootloader to

be signed by MS UEFI key for it to be bootable there.

How do you manage and protect the keys used in your SHIM?
The cert and keys are protected by HP's signing infrastructure.  Developer doesn't have direct access to the key.
Do you use EV certificates as embedded certificates in the SHIM?
No
If you use new vendor_db functionality, are any hashes whitelisted, and if yes: for what binaries ?
N/A
Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a linux kernel ?
Yes
if SHIM is loading grub2 bootloader, is CVE CVE-2020-10713 fixed ?
Yes
Were your old SHIM hashes provided to Microsoft ?
Yes
Did you change your certificate strategy, so that affected by CVE CVE-2020-10713 grub2 bootloaders can not be verified ?
Yes
What is the origin and full version number of your bootloader (GRUB or other)?
Grub 2.04
If your SHIM launches any other components, please provide further details on what is launched
It launches grub2 and fwupd
How do the launched components prevent execution of unauthenticated code?
Full set of grub2 fixes, fwupd will not execute unauthenticated code.
Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)?
No, our shim and grub will not load any unsigned binary when the system boots under
secure boot mode.
What kernel are you using? Which patches does it includes to enforce Secure Boot?
5.6.8, maybe move to a newer kernel later this year.  it has all the secureboot lockdown patches.
What changes were made since your SHIM was last signed?
Update 13 to 15, plus shim-patches from photon branch
What is the hash of your final SHIM binary?

$ sha256sum shimx64.efi
c3615588e7ba3d9c52a60014d4b84eb440b86404b3213c6a650e273965268a8f shimx64.efi
$ sha1sum shimx64.efi
5f33fb7c60b5548e49abbc2bc5d0f9ddfab9aab2 shimx64.efi
@miray-tf
Copy link

miray-tf commented Jun 9, 2021

Could you please add the missing information from the current ISSUE Template?

At a quick glance at least the following sections are missing or incomplete:

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.

[your text here]

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 ?

[your text here]

"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

[your text here]

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 ?

[your text here]

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 ?

[your text here]

@miray-tf
Copy link

Shim

Shim is branch 15.4 with no additional patches

sha256 checksum c3615588e7ba3d9c52a60014d4b84eb440b86404b3213c6a650e273965268a8f of shim256
matches values in README.md and ISSUE

Rebuilds with supplied docker file

Grub

grub2_2.04-1ubuntu45 was accepted in review #167 so that looks good to me

SBat:

Shim sbat entry matches information in README.md

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.thinpro,1,HP,shim,15.4,https://www.hp.com/

shimx64.efi:     file format pei-x86-64

Contents of section .sbat:
 cf000 73626174 2c312c53 42415420 56657273  sbat,1,SBAT Vers
 cf010 696f6e2c 73626174 2c312c68 74747073  ion,sbat,1,https
 cf020 3a2f2f67 69746875 622e636f 6d2f7268  ://github.com/rh
 cf030 626f6f74 2f736869 6d2f626c 6f622f6d  boot/shim/blob/m
 cf040 61696e2f 53424154 2e6d640a 7368696d  ain/SBAT.md.shim
 cf050 2c312c55 45464920 7368696d 2c736869  ,1,UEFI shim,shi
 cf060 6d2c312c 68747470 733a2f2f 67697468  m,1,https://gith
 cf070 75622e63 6f6d2f72 68626f6f 742f7368  ub.com/rhboot/sh
 cf080 696d0a73 68696d2e 7468696e 70726f2c  im.shim.thinpro,
 cf090 312c4850 2c736869 6d2c3135 2e342c68  1,HP,shim,15.4,h
 cf0a0 74747073 3a2f2f77 77772e68 702e636f  ttps://www.hp.co
 cf0b0 6d2f0a                               m/.

Grub sbat entry information from README.md

sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md
grub,1,Free Software Foundation,grub,2.04,https://www.gnu.org/software/grub/
grub.thinpro,1,HP,grub2,2.04-1ubuntu45+hp1,https://www.hp.com/

looks sensible.
You claim that you are using grub2_2.04-1ubuntu45, so you probably should add

grub.ubuntu,1,Ubuntu,grub2,2.04-1ubuntu45,https://www.ubuntu.com/

to the Grub sbat section.

product name 'thinpro' looks unique: A quick web search for thinpro only returned HP ThinPro related hits.

Linux

Please validate that linux upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 is included in your kernel.
You claim to use 5.6.8, and the commit was merged in linux upstream 5.7.7

Summary

  • shim is from good upstream source, no additional patches, sbat looks good
  • Grub is based on good upstream source but check additional comment regarding sbat section
  • Certificate setup looks fine to me, but I'd like an opinion from one of the regular reviewers

Questions / Open Issues:

  • ISSUE information is incomplete (See my previous post)
  • See comment regarding ubuntu sbat line for Grub
  • Please check if linux upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 is included in your kernel.

Notes:

gnu-efi package is no longer necessary, so you can remove it from the docker file

@eniaczhp
Copy link
Author

eniaczhp commented Jun 22, 2021 via email

@steve-mcintyre
Copy link
Collaborator

I saw that your tag looks ok - thanks!

@steve-mcintyre
Copy link
Collaborator

  • everything reproduces ok here
  • SBAT looks good enough
  • shim is straight 15.4 from upstream
  • included CA cert looks fine
  • grub looks ok, based on ubuntu
  • good question from @miray-tf re Linux version - can you clarify please?

@steve-mcintyre steve-mcintyre added the question Reviewer(s) waiting on response label Jun 22, 2021
@eniaczhp
Copy link
Author

steve-mcintyre
@steve-mcintyre
hi @steve-mcintyre

EZ: we don't plan to support 32bit cpu, or ARM, or MAC so i am ok not including these patches. i could include rhboot/shim#361 only if it's causing real issues. i don't mind if all it does is an extra warning in dmesg.

this is the response for @miray-tf

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.

EZ: Correct. That's the upstream source we use.

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 ?

EZ: We uses https://launchpad.net/ubuntu/+source/grub2/2.04-1ubuntu45, it has all the grub2 patches needed as far as i can tell. We don't ship shim_lock modules with our signed grub binary.

"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

EZ: the only binary that carries SBAT today is grub2 and shim, their sbat are provided in the repo:
https://github.com/eniaczhp/ThinProShim/blob/HPI-shim-x64-20210603/grub.sbat
https://github.com/eniaczhp/ThinProShim/blob/HPI-shim-x64-20210603/sbat.csv

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 ?

EZ: we uses https://launchpad.net/ubuntu/+source/grub2/2.04-1ubuntu45, it has all the grub2 patches needed as far as i can tell.

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 ?

EZ: we uses https://launchpad.net/ubuntu/+source/grub2/2.04-1ubuntu45, it has all the grub2 patches needed as far as i can tell.

@eniaczhp
Copy link
Author

regarding kernel patches, yes we do have patch for CVE-2020-15780:
$ grep -r LOCKDOWN_ACPI_TABLES
patches/cves/CVE-2020-15780/CVE-2020-15780.patch:+ int ret = security_locked_down(LOCKDOWN_ACPI_TABLES);

here're all the kernel CVE patches we applied on top of 5.6.8:
$ ls patches/cves/
CVE-2020-10732 CVE-2020-10767 CVE-2020-12114.patch CVE-2020-12656 CVE-2020-14314 CVE-2020-16119 CVE-2020-25285
CVE-2020-10751.patch CVE-2020-10768 CVE-2020-12351 CVE-2020-12771 CVE-2020-14356.patch CVE-2020-16166.patch CVE-2020-25704
CVE-2020-10757 CVE-2020-10781 CVE-2020-12352 CVE-2020-12888 CVE-2020-14386 CVE-2020-24394 CVE-2020-26088
CVE-2020-10766 CVE-2020-11608.patch CVE-2020-12655 CVE-2020-13974 CVE-2020-15780 CVE-2020-25212.patch CVE-2020-28374

@miray-tf
Copy link

@steve-mcintyre
Upstream patch 75b0cea7bf307f362057cc778efe89af4c615354 is the fix for CVE-2020-15780. So this patch is included.
Missing answers from the ISSUE template were also answered.
So the two main points I raised are done.

@steve-mcintyre
Copy link
Collaborator

@eniaczhp thanks for answering the kernel question, I think all looks good now. Marking accepted

@steve-mcintyre steve-mcintyre added accepted Submission is ready for sysdev and removed question Reviewer(s) waiting on response labels Jun 28, 2021
@eniaczhp
Copy link
Author

thanks @steve-mcintyre

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
accepted Submission is ready for sysdev
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@miray-tf @eniaczhp @steve-mcintyre