Skip to content

Commit

Permalink
Review request of shim 15.4+dev8.ab30a4a for Endless OS
Browse files Browse the repository at this point in the history
  • Loading branch information
jprvita committed May 27, 2021
1 parent d2f40a4 commit ef1ae9e
Show file tree
Hide file tree
Showing 11 changed files with 2,322 additions and 53 deletions.
9 changes: 9 additions & 0 deletions BUILDING.txt
Original file line number Diff line number Diff line change
@@ -0,0 +1,9 @@
To reproduce the build in a container defined by the attached Dockerfile, run:

```
./build.sh
```

At the end of the process this will print the SHA256 checksum of the
shimx64.efi binary that was just built, as well as copy the file to the current
directory and verify its checksum against the attached shimx64.efi.sha256 file.
20 changes: 20 additions & 0 deletions Dockerfile
Original file line number Diff line number Diff line change
@@ -0,0 +1,20 @@
FROM debian:bullseye
ARG PKGVER="15.4+dev8.ab30a4a"
ADD --chown=root:root endless.origins /etc/dpkg/origins/endless
RUN apt update -y
RUN DEBIAN_FRONTEND=noninteractive apt install -y --no-install-recommends build-essential devscripts git
RUN git clone --recurse-submodules https://github.com/endlessm/shim.git shim-${PKGVER}
WORKDIR /shim-${PKGVER}
RUN git config user.email "[email protected]"
RUN git merge --allow-unrelated-histories -m "Import the packaging bits into master" origin/debian-master
RUN echo "1.0" > debian/source/format
RUN echo "--compression=gzip" > debian/source/options
RUN apt build-dep -y .
ENV DEBEMAIL="[email protected]"
RUN dch -v ${PKGVER} -D eos --force-distribution "Automatic release from git (${PKGVER})"
RUN rm -rf .git
RUN DEB_VENDOR=endless dpkg-buildpackage -us -uc
WORKDIR /
RUN dpkg-deb -x shim-efi-image_${PKGVER}_amd64.deb shim-efi-image
RUN cp shim-efi-image/boot/efi/EFI/endless/shimx64.efi .
RUN sha256sum shimx64.efi
107 changes: 76 additions & 31 deletions ISSUE_TEMPLATE.md
Original file line number Diff line number Diff line change
@@ -1,43 +1,64 @@
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
- [x] link to your code branch cloned from rhboot/shim-review in the form user/repo@tag
endlessm/shim-review@endless-shim-x64-20210526
- [x] completed README.md file with the necessary information
https://github.com/endlessm/shim-review/blob/endless-shim-x64-20210526/README.md
- [x] shim.efi to be signed
https://github.com/endlessm/shim-review/blob/endless-shim-x64-20210526/shimx64.efi
- [x] public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE)
https://github.com/endlessm/shim-review/blob/endless-shim-x64-20210526/endless-uefi-ca.der
- [x] binaries, for which hashes are added do vendor_db ( if you use vendor_db and have hashes allow-listed )
No hashes are added to vendor_db, we do not use this functionality
- [x] any extra patches to shim via your own git tree or as files
The last 4 commits on https://github.com/endlessm/shim/commits/master.
- [x] any extra patches to grub via your own git tree or as files
The grub source code we use can be found on the master branch of
https://github.com/endlessm/grub. We are based on tag grub-2.04 from
upstream, and Debian's package version 2.04-16.
- [x] build logs
https://github.com/endlessm/shim-review/blob/endless-shim-x64-20210526/logs.txt
- [x] a Dockerfile to reproduce the build of the provided shim EFI binaries
https://github.com/endlessm/shim-review/blob/endless-shim-x64-20210526/Dockerfile


###### What organization or people are asking to have this signed:
`[your text here]`
Endless OS Foundation LLC
https://endlessos.org/

###### What product or service is this for:
`[your text here]`
Endless OS.

###### 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]`

Yes, we are based on upstream commit `4068fd42`, which is 4 commits on top of tag `15.4`.

###### What's the justification that this really does need to be signed for the whole world to be able to boot it:
`[your text here]`
Endless OS is a Linux distribution available for download on
https://endlessos.com/download/ and also shipped with computers sold directly
by us and by our OEM partners like Asus and Acer.

###### How do you manage and protect the keys used in your SHIM?
`[your text here]`
We have generated our own secure boot CA private key which is stored offline
with physical security protection and only accessed to provision new signing
keys. The CA public key is the one embedded in the shim binary. The signing
keys which are used in our build servers to sign the bootloader and kernel are
stored in J3A081 80K smartcard HW encryption devices. This is based on the
procedure described at
https://fedoraproject.org/wiki/User:Pjones/SecureBootSmartCardDeployment

###### Do you use EV certificates as embedded certificates in the SHIM?
`[your text here]`
No.

###### If you use new vendor_db functionality, are any hashes allow-listed, and if yes: for what binaries ?
`[your text here]`
We do not use the vendor_db functionality.

###### Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a Linux kernel ?
`[your text here]`
Yes, https://github.com/endlessm/linux/commit/75b0cea7bf30

###### if SHIM is loading GRUB2 bootloader, are CVEs CVE-2020-14372,
###### CVE-2020-25632, CVE-2020-25647, CVE-2020-27749, CVE-2020-27779,
Expand All @@ -46,55 +67,79 @@ Make sure you have provided the following information:
###### ( 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]`
Yes.

###### "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 ?
Yes.

###### Please provide exact SBAT entries for all SBAT binaries you are booting or planning to boot directly through shim
`[your text here]`
GRUB2:
```
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.debian,1,Debian,grub2,2.04-16,https://tracker.debian.org/pkg/grub2
grub.endless,1,Endless OS Foundation LLC,grub2,2.04+dev245.7421863-28bem1,https://github.com/endlessm/grub
```

##### Were your old SHIM hashes provided to Microsoft ?
`[your text here]`
Yes.

##### 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]`
Yes, the signing certificate we use to sign GRUB2 and the linux kernel image
has been replaced, and the previous signing certificates were added to the new
shim's vendor_dbx.

##### 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]`
Downstream implementation from Debian.

###### What is the origin and full version number of your bootloader (GRUB or other)?
`[your text here]`
We use Debian's GRUB2 version 2.04-16 as base, including their downstream
changes.

The GRUB2 source code we use can be found at https://github.com/endlessm/grub,
on branches master (for code) and debian-master (for packaging). Our master
branch is based on tag grub-2.04 from upstream.

###### If your SHIM launches any other components, please provide further details on what is launched
`[your text here]`
Our shim does not launch any other components.

###### 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
`[your text here]`
Our GRUB2 does not launch any other components.

###### 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.
`[your text here]`
We are revoking the certificate associated with the key we used to sign UEFI
binaries via shim's vendor_dbx.

###### How do the launched components prevent execution of unauthenticated code?
`[your text here]`
N/A.

###### Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)?
`[your text here]`
No, the GRUB version we ship does not allow loading unsigned kernels under
secure boot. The `linux` loader in our grub EFI binary always hands-off loading
to the `linuxefi` module, which verifies the kernel via the shim protocol under
secure boot.

###### What kernel are you using? Which patches does it includes to enforce Secure Boot?
`[your text here]`
We are currently based on Linux 5.11, which includes the most recent fixes for
secure boot enforcement. We will likely rebase onto a newer kernel before
releasing the next version of Endless OS, which will be the first to include
this shim.

###### What changes were made since your SHIM was last signed?
`[your text here]`
Rebased on a newer upstream version. All signing certificates used to sign
previous versions of GRUB or the Linux kernel are being included in shim's
internal `vendor_dbx`, via the build-time macro `VENDOR_DBX_FILE`.

###### What is the SHA256 hash of your final SHIM binary?
`[your text here]`
440bce4126b96d1f2c3ad3a75f34d36b74fbf1dec6045645fcb4dbe0fb7dba91 shimx64.efi
90 changes: 68 additions & 22 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -20,33 +20,38 @@ Here's the template:
-------------------------------------------------------------------------------
What organization or people are asking to have this signed:
-------------------------------------------------------------------------------
[your text here]
Endless OS Foundation LLC
https://endlessos.org/

-------------------------------------------------------------------------------
What product or service is this for:
-------------------------------------------------------------------------------
[your text here]
Endless OS.

-------------------------------------------------------------------------------
What's the justification that this really does need to be signed for the whole world to be able to boot it:
-------------------------------------------------------------------------------
[your text here]
Endless OS is a Linux distribution available for anyone to download on
https://endlessos.com/download/ and also shipped with computers sold directly
by us and by our OEM partners like Asus and Acer.

-------------------------------------------------------------------------------
Who is the primary contact for security updates, etc.
-------------------------------------------------------------------------------
- Name:
- Position:
- Email address:
- Name: Robert McQueen
- Position: CEO
- Email address: [email protected]
- PGP key, signed by the other security contacts, and preferably also with signatures that are reasonably well known in the Linux community:
`F864269C9010B282EE51BD607F94998DE06F63B5`

-------------------------------------------------------------------------------
Who is the secondary contact for security updates, etc.
-------------------------------------------------------------------------------
- Name:
- Position:
- Email address:
- Name: Will Thompson
- Position: Director of OS
- Email address: [email protected]
- PGP key, signed by the other security contacts, and preferably also with signatures that are reasonably well known in the Linux community:
`1E68E58CF255888301645B563422DC0D7AD482A7`

-------------------------------------------------------------------------------
Please create your shim binaries starting with the 15.4 shim release tar file:
Expand All @@ -55,32 +60,49 @@ 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]

Yes, we are based on upstream commit `4068fd42`, which is 4 commits on top of tag `15.4`.

-------------------------------------------------------------------------------
URL for a repo that contains the exact code which was built to get this binary:
-------------------------------------------------------------------------------
[your url here]
https://github.com/endlessm/shim/, branch `master`, commit hash `ab30a4af`.

-------------------------------------------------------------------------------
What patches are being applied and why:
-------------------------------------------------------------------------------
[your text here]
We are applying 4 patches to the fallback program. No Endless-specific patches
change the shim binary.

This set of changes have fallback treat boot entries with the same label as
duplicates, and remove any entries that are a duplicte of the entry we are
about to create from the CSV file in the fallback path. This is necessary for
Endless OS because randomize the partition ids during the first boot, since the
partition layout is created by the server at image build time and the image in
simply dd'ed to the disk during installation.

The full list of commits, starting from upstream commit `4068fd42`, can be
found below:

- `f428985b fallback: Print info on GetNextVariableName errors`
- `f5e1d7f7 fallback: Use a dynamic buffer when list var names`
- `97f57410 Revert "fallback: work around the issue of boot option creation with AMI BIOS"`
- `ab30a4af fallback: Clean-up duplicate boot entries`

-------------------------------------------------------------------------------
If bootloader, shim loading is, GRUB2: is 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, and if you are shipping the shim_lock module CVE-2021-3418
-------------------------------------------------------------------------------
[your text here]

Our GRUB2 is based on Debian's GRUB2 2.04-16, where all CVEs from the list
above that affect that codebase were fixed. The shim_lock module is not used.

-------------------------------------------------------------------------------
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]
Downstream implementation from Debian.

-------------------------------------------------------------------------------
If bootloader, shim loading is, GRUB2, and previous shims were trusting affected
Expand All @@ -100,7 +122,9 @@ by CVE-2020-14372, CVE-2020-25632, CVE-2020-25647, CVE-2020-27749,
( July 2020 grub2 CVE list + March 2021 grub2 CVE list )
grub2 builds ?
-------------------------------------------------------------------------------
[your text here]
- Yes, old shim hashes were provided to Microsoft.
- Yes, the new chain of trust disallow booting all previous GRUB2 and kernel
binaries signed with our old key.

-------------------------------------------------------------------------------
If your boot chain of trust includes linux kernel, is
Expand All @@ -109,15 +133,18 @@ upstream commit 1957a85b0032a81e6482ca4aab883643b8dae06e applied ?
Is "ACPI: configfs: Disallow loading ACPI tables when locked down"
upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 applied ?
-------------------------------------------------------------------------------
[your text here]
Yes, our most recent kernel is based on an upstrem release that already includes
these commits:
https://github.com/endlessm/linux/commit/1957a85b0032
https://github.com/endlessm/linux/commit/75b0cea7bf30

-------------------------------------------------------------------------------
If you use vendor_db functionality of providing multiple certificates and/or
hashes please briefly describe your certificate setup. If there are allow-listed hashes
please provide exact binaries for which hashes are created via file sharing service,
available in public with anonymous access for verification
-------------------------------------------------------------------------------
[your text here]
We do not use the vendor_db functionality.

-------------------------------------------------------------------------------
If you are re-using a previously used (CA) certificate, you will need
Expand All @@ -126,20 +153,39 @@ 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.
-------------------------------------------------------------------------------
[your text here]
The signing certificate we use to sign GRUB2 and the linux kernel image has
been replaced, and the previous signing certificates were added to the new
shim's vendor_dbx.

-------------------------------------------------------------------------------
What OS and toolchain must we use to reproduce this build? Include where to find it, etc. We're going to try to reproduce your build as close as possible to verify that it's really a build of the source tree you tell us it is, so these need to be fairly thorough. At the very least include the specific versions of gcc, binutils, and gnu-efi which were used, and where to find those binaries.
If the shim binaries can't be reproduced using the provided Dockerfile, please explain why that's the case and the differences would be.
-------------------------------------------------------------------------------
[your text here]
This was manually built on Debian Bullseye, to make it possible to reproduce,
since we currently don't ship development tools on Endless OS. The versions of
gcc, binutils and gnu-efi are listed bellow.

- gcc: 10.2.1
- binutils: 2.35.2
- gnu-efi: the version that is included as a git submodule in shim's tree

We are providing a Dockerfile in this repo that can be used to reproduce the
build pulling all dependencies from the public Debian repositories --
instructions are availabled in BUILDING.txt.

-------------------------------------------------------------------------------
Which files in this repo are the logs for your build? This should include logs for creating the buildroots, applying patches, doing the build, creating the archives, etc.
-------------------------------------------------------------------------------
[your text here]
https://github.com/endlessm/shim-review/blob/endless-shim-x64-20210526/logs.txt

-------------------------------------------------------------------------------
Add any additional information you think we may need to validate this shim
-------------------------------------------------------------------------------
[your text here]
The `debian` directory with the package building recipes and scripts, vendor
certificate, vendor DBX contents etc, is available at
https://github.com/endlessm/shim/commits/debian-master, commit `22ed0e48`.

The downstream patches we are carrying here were also reviewed and approved in
our previous submissions. Our previous community review requests can be found
at https://github.com/rhboot/shim-review/issues/61 and
https://github.com/rhboot/shim-review/issues/105.
Loading

0 comments on commit ef1ae9e

Please sign in to comment.