ISSUE_TEMPLATE.md

Make sure you have provided the following information:

• link to your code branch cloned from rhboot/shim-review in the form user/repo@tag baramundisoftware/shim-review@master
• completed README.md file with the necessary information https://github.com/baramundisoftware/shim-review/blob/master/README.md
• shim.efi to be signed https://github.com/baramundisoftware/shim-review/blob/master/shim_x64.efi
• public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE) https://github.com/baramundisoftware/shim-review/blob/master/bsAG_EV_productive_2020.cer
• binaries, for which hashes are added do vendor_db ( if you use vendor_db and have hashes allow-listed ) not used
• any extra patches to shim via your own git tree or as files No extra patches
• any extra patches to grub via your own git tree or as files https://github.com/baramundisoftware/grub2
• build logs https://github.com/baramundisoftware/shim-review/blob/master/shim_x64_build.log
• a Dockerfile to reproduce the build of the provided shim EFI binaries https://github.com/baramundisoftware/shim-review/blob/master/Dockerfile

What organization or people are asking to have this signed:

baramundi software AG

What product or service is this for:

baramundi Management Suite

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.

Yes

What's the justification that this really does need to be signed for the whole world to be able to boot it:

The SHIM bootloader starts a grub2 which decides if it should boot the local installed windows operating system or netboot a windows PE image. This is necessary to support remote operating system installation on clients in the LAN. With a signed SHIM bootloader we are able to support clients with enabled secure boot feature.

How do you manage and protect the keys used in your SHIM?

Private key is stored in hardware module with controlled access.

Do you use EV certificates as embedded certificates in the SHIM?

Yes

If you use new vendor_db functionality, are any hashes allow-listed, and if yes: for what binaries ?

vendor_db not used, no hashes allow-listed

Is kernel upstream commit 75b0cea7bf307f362057cc778efe89af4c615354 present in your kernel, if you boot chain includes a Linux kernel ?

No Linux kernel is used

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 ?

Yes The grub2 sources we use have it's origin in the commit https://git.launchpad.net/ubuntu/+source/grub2/tag/?h=applied/2.04-1ubuntu44

"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: 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

grub: 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.baramundi,1,Baramundi,grub2,2.04-1ubuntu44.2-bblefi1,https://github.com/baramundisoftware/grub2

Were your old SHIM hashes provided to Microsoft ?

No. We changed the EV certificate embedded in the shim, so the old shim can only start grubs signed with the old ev certificate.

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 ?

We used a new EV certificate which is only used for the new grub 2.04 which origin is the commit https://git.launchpad.net/ubuntu/+source/grub2/tag/?h=applied/2.04-1ubuntu44

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 ?

Downstream RHEL/Fedora/Debian/Canonical like implementation see: https://github.com/baramundisoftware/grub2

What is the origin and full version number of your bootloader (GRUB or other)?

grub 2.04 (extended) see: https://github.com/baramundisoftware/grub2 The grub2 sources we use have it's origin in the commit https://git.launchpad.net/ubuntu/+source/grub2/tag/?h=applied/2.04-1ubuntu44

If your SHIM launches any other components, please provide further details on what is launched

Our shim only launches the mentioned grub 2.04

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

The SHIM bootloader starts a grub2 which decides if it should boot the local installed windows operating system or netboot a windows PE image. This is necessary to support remote operating system installation on clients in the LAN. With a signed SHIM bootloader we are able to support clients with enabled secure boot feature.

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.

No certificate got reused. The EV certificate used for the shim is new. No need for vendor_dbx entry.

How do the launched components prevent execution of unauthenticated code?

with standard grub 2.04 functionality, we prevent to start any unsigned bootloader

Does your SHIM load any loaders that support loading unsigned kernels (e.g. GRUB)?

No

What kernel are you using? Which patches does it includes to enforce Secure Boot?

We launch Windows and Windows PE loader and kernel

What changes were made since your SHIM was last signed?

no changes were made to the original shim

What is the SHA256 hash of your final SHIM binary?

shim_x64.efi MD5 Hash:

2AD3AD28458C81F210DD95150DDB8110