baramundi-shim-20210203

[ghost]

Make sure you have provided the following information:

• link to your code branch cloned from rhboot/shim-review in the form user/repo@tag
  https://github.com/baramundisoftware/shim-review/releases/tag/baramundi-shim-20210203
• 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
  https://github.com/baramundisoftware/shim-review/blob/master/shim_x86.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 whitelisted )
  No vendor_db is used
• any extra patches to shim via your own git tree or as files
  N/A
• any extra patches to grub via your own git tree or as files
  N/A
• build logs
  https://github.com/baramundisoftware/shim-review/blob/master/grub2_x64_build.log
  https://github.com/baramundisoftware/shim-review/blob/master/grub2_x86_build.log

What organization or people are asking to have this signed:

baramundi software AG

What product or service is this for:

baramundi Management Suite

What is the origin and full version number of your shim?

https://github.com/baramundisoftware/shim/tree/baramundi-shim-08

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 whitelisted, and if yes: for what binaries ?

No

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, is CVE CVE-2020-10713 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-1ubuntu26.4

Did you change your certificate strategy, so that affected by CVE CVE-2020-10713 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-1ubuntu26.4

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

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

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

Our shim only launches the mentioned grub 2.04

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?

This is the first submission

What is the hash of your final SHIM binary?

• shim_x64 MD5 hash: c0a928af63609a4c9ada8a297f027028
• shim_x86 MD5 hash: 537899f7377ff2486bd0527bd0418230

[julian-klode]

I suggest you just use the pre-built grub from Ubuntu (since you're basing on that), there's no need here for having your own signing keys since you just chainload windows.

Note that in any case, signing is suspended at the moment until at least SBAT work is complete (#120)

[ghost]

Thank you for your remark.

We have implemented and integrated a grub module to be able to control the boot process from a central server. We compile the grub with all necessary modules into one binary, which includes our own module, therefore we cannot use the default ubuntu grub2 bootloader.

If you have further questions we are happy to answer them.

We are aware, that the signing is currently suspended, thank you.

[julian-klode]

Well, then, you have pointed at the unmodified Ubuntu source code tree. Point to the actual grub tree. Implying that you use unmodified ones and not pointing us at the real tree is bad taste.

[julian-klode]

FWIW, I don't understand the use of grub here, you have two things to chainload, it'd be far easier to write a custom EFI binary and get it signed by MS directly than to go a shim+grub approach.

[ghost]

Hello again and thanks for responding that fast.
You're right, our modifications on grub2 are marginal, but writing an own EFI binary now would cost us way more time for a similar result. Currently the source code for our modified grub2 bootloader isn't on github. We follow our policy and give it to anyone who requests it by CD or the like. According to your suggestion, we added a hint, that we extended the grub2.
Is it possible to provide the modified grub2 source code for you without publishing it on github?

[martinezjavier]

@baramundi-fsauer please update this request to use the shim 15.4 release. Or close this issue and file a new one based on that version.

[steve-mcintyre]

@baramundi-fsauer sorry you've had a bad experience here. Especially in the last few months we've had a massive amount of work to do on shim upstream. That has cumlminated in latest 15.4 release, and even then there are a few recommended patches on top (see #165). We're catching up on a lot of reviews now.

As others have said, builds based on older shim versions will not meet the requirements for signing any more so I'm afraid you'll have to move forwards to 15.4. I'm therefore closing this review now - please open a new one when you have a 15.4 build ready.

I'm trying to steer shim development discussions into being more open, and we have a mailing list now: https://lists.einval.com/cgi-bin/mailman/listinfo/efi