TeraByte Shim 15.4 - Updated with Dockerfile

[TBOpen]

Make sure you have provided the following information:

• [x ] link to your code branch cloned from rhboot/shim-review in the form user/repo@tag
• [ x] completed README.md file with the necessary information
• [ x] shim.efi to be signed
• [ x] public portion of your certificate(s) embedded in shim (the file passed to VENDOR_CERT_FILE)
• [na ] binaries, for which hashes are added do vendor_db ( if you use vendor_db and have hashes allow-listed )
• [ x] any extra patches to shim via your own git tree or as files

What organization or people are asking to have this signed:

[TeraByte, Inc.]

What product or service is this for:

[TeraByte UEFI Boot based products]

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. https://github.com/rhboot/shim/releases/download/15.4/shim-15.4.tar.bz2]

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

[Popular commercial software with secure boot support]

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

[Placed on Hardware token with EV Certificates.]

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

'[No. Use self created for longer shelf life.]`

If you use new vendor_db functionality, are any hashes allow-listed, 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 5.10.x]

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, will be based on ubuntu version. Currently 2.04-1ubuntu26.11]

"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

[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.terabyte,1,TeraByte,UEFI shim,1,https://www.terabyteunlimited.com]
[ ubuntu grub2 build doesn't add it's own sbat so will be using: ]
[ sbat,1,SBAT Version,sbat,1,https://github.com/rhboot/shim/blob/main/SBAT.md ]
[ grub,2,Free Software Foundation,grub,2.04,https://www.gnu.org/software/grub/ ]
[ grub.ubuntu,2,Ubuntu,grub2,2.04-1ubuntu26.11,https://www.ubuntu.com/ ]
[ grub.terabyte,1,TeraByte,grub2,2.04-tbu-2021-0,https://www.terabyteunlimited.com/ ]
[IFU.TERABYTE,1,TeraByte,Image for UEFI,1,https://www.terabyteunlimited.com]
[BIU.TERABYTE,1,TeraByte,BootIt UEFI,1,https://www.terabyteunlimited.com]
[TBOSDT.TERABYTE,1,TeraByte,TBOSDT UEFI,1,https://www.terabyteunlimited.com]
[Kernel.TERABYTE,1,TeraByte,Image for Linux,1,https://www.terabyteunlimited.com]

Were your old SHIM hashes provided to Microsoft ?

[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 ?

[Yes, new certificate generated.]

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 ?

[Will be using ubuntu 20.04.2 version of GRUB2 2.04 watching https://ubuntu.com/security/cve?q=&package=grub2 ]
[ it's using grub2_2.04-1ubuntu26.11 ]

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

[it will be either 2.04 from Ubuntu 20.04.2 - watching https://ubuntu.com/security/cve?q=&package=grub2.]
[ it's building with grub2_2.04-1ubuntu26.11 ]

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

[Image for Linux Recovery Boot Disk: Shim->Grub2->Kernel (15.10.x current)]
[Image for UEFI Recovery Boot Disk: Shim->Image for UEFI ]
[TeraByte OS Deployment Tool Suite: Shim->TBOSDT -> Signed OS Loader.]
[BootIt UEFI: Shim->BootIt UEFI -> Signed OS Loader.]

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

[doesn't launch anything that doesn't have valid signature through shim protocol check]

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.

[New certificated generated]

How do the launched components prevent execution of unauthenticated code?

[Using Shim Protocol]

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

[No, in secure boot mode, nothing but signed kernels boot.]

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

[5.10.x - confirm the config option needed is LOCK_DOWN_KERNEL_FORCE_INTEGRITY]

What changes were made since your SHIM was last signed?

[updated to 15.4 from 14]

What is the SHA256 hash of your final SHIM binary?

[SHA-256: c2e688edc3e7c7eb17752650ca3fcd6fa0043e998592908ed738c104895c7c95]

[Location: https://github.com/TBOpen/shim-review ]

[aburmash]

• [should I add an additional entry to shim besides the default?]
  Yes, you should.
  Your shim may contain vulnerabilities related to your toolchain for example. Each vendor should add vendor specific entry for shim so that we do not have to revoke all shims in case only a single vendor if affected.

• If your SHIM launches any other components, please provide further details on what is launched
  [Image for Linux Recovery Boot Disk Image for UEFI Recovery Boot Disk TeraByte OS Deployment Tool Suite (UEFI Boot) BootIt UEFI]

Honestly this answer does not give any answer on what is actually launched. Is that grub2 ? Some custom UEFI binary ? Linux kernel ? Later you say that

[No, in secure boot mode, nothing but signed kernels boot.]

so i feel you just need to clarify the previous part i have quoted.

• I also can't find the link to the review tag which is the first question in the template

[x ] link to your code branch cloned from rhboot/shim-review in the form user/repo@tag

[julian-klode]

The SBAT entry names for the next stages are too short IMO, that could cause collisions, it would be sensible to go with something more unique

[TBOpen]

I'll rebuild the shim with adding a new SBAT and post back here when ready. I'll update the entry for what is launched as well.

On the other being too short, then I take it you're only going to look at the "component_name" and "component_generation". The "vendor_XXX" items will be ignored and for information only purposes, meaning we can change them without affecting the need to invalidate anything? Basing the field names I referenced from:

component_name | the name we're comparing
component_generation | the generation number for the comparison
vendor_name | human readable vendor name
vendor_package_name | human readable package name
vendor_version | human readable package version (maybe machine parseable too, not specified here)
vendor_url | url to look stuff up, contact, whatever.

[TBOpen]

Okay, I updated the shim patch to add the sbat entry and rebuilt it so it's ready again. Also updated the form above.

[TBOpen]

Updated to reflect 15.4.

[Doncuppjr]

You need a docker file for this.

[TBOpen]

what's a docker file? All you have to do is run the script to build under fedora 29 (instructions given at https://github.com/TBOpen/shim-review) and you get the same result (less time related items). If you need a "docker" file, please provide detailed instructions.

[Doncuppjr]

I am just another shim submitter, taking some time to help others. I have read most of the accepted submissions, and they use docker to create the build environment that will reproduce your build exactly. With docker, you don't have to ask me to install F29, the docker file will create an F29 container and run your build.

[Doncuppjr]

You might want to elaborate on your storage methods for all the certificates and keys. Are they FIPS 140-2 level 2?

[julian-klode]

• I'd like to hear more about the protected keys too. Also given that the cert was generated on a machine, did you make sure to securely erase the private key from that machine such that it can't be restored?
• You have provided a SHA1 hash when asked for a SHA256
• Please provide a Dockerfile such that we can just run podman build . (or docker build .) to verify
• It would be good to have a second security contact. You say it's a popular product, but I've not found any users, but if it's as popular and a real company, you should have more people than just a a President. Seems odd.
• You wrote Removes the x64 on x32 section which prevents the x32 on x64 from working., but x32 kernels cannot work reliably on x64, as the EFI tables might be outside the 32-bit address space, which is why the patch denies this in the first place. I feel like I want an extra ACK on this from @vathpela

[TBOpen]

• I'd like to hear more about the protected keys too. Also given that the cert was generated on a machine, did you make sure to securely erase the private key from that machine such that it can't be restored?

Actually in a VM, but yep, just like it would be created anywhere and deleted/overwritten anywhere and put on the same hardware token you get from Verisign, Symantec, now digicert for extended validation

• You have provided a SHA1 hash when asked for a SHA256

Fine. Since I have to do yet another build for "dockerfile" (I've found some information on how to do it, but might be good if it was provided with the download and and instructions to use it so it could be used as a template and modified as needed).

• Please provide a Dockerfile such that we can just run podman build . (or docker build .) to verify

Fine.

• It would be good to have a second security contact. You say it's a popular product, but I've not found any users, but if it's as popular and a real company, you should have more people than just a a President. Seems odd.

Correct, just the one contact.

• You wrote Removes the x64 on x32 section which prevents the x32 on x64 from working., but x32 kernels cannot work reliably on x64, as the EFI tables might be outside the 32-bit address space, which is why the patch denies this in the first place. I feel like I want an extra ACK on this from @vathpela

Just after releasing the patch I thought if the "system type" is actually the EFI environment (implementation) then there are some x64 system out there using x32 UEFI. But yes, that section still breaks running x686 kernel on x64 system using UEFI x64. The kernel runs fine on most system (been doing it for since UEFI existed), you however can't access UEFI x64 from the 686 kernel (trying to mount efivarfs won't work).

Also you haven't confirmed my question for the kernel, is "LOCK_DOWN_KERNEL_FORCE_INTEGRITY" is the kernel option you're looking for?

[Doncuppjr]

I don't know that LOCK_DOWN_KERNEL_FORCE_INTEGRITY is what the approver is looking for, but I think they will accept it. It sets all the other options that they want, like CONFIG_EFI_CUSTOM_SSDT_OVERLAYS disabled, KEXEC disabled.

Keep in mind that this is a peer review board. Make some friends.

[TBOpen]

The dockerfile method is now available https://www.github.com/TBOpen/shim-review

Also updated comment in patch.

[Doncuppjr]

Step 9/13 : COPY cert/shim.cer /shim-15.4
---> e48044839bab
Step 10/13 : COPY shim-15.4.patch /
---> a23baff747f2
Step 11/13 : COPY make_shim_15.4 /
---> af247d53af47
Step 12/13 : RUN ./make_shim_15.4
---> Running in a7ef7df7e077
/bin/sh: ./make_shim_15.4: Permission denied
The command '/bin/sh -c ./make_shim_15.4' returned a non-zero code: 126

[TBOpen]

Run as root.

[Doncuppjr]

It's in a container. It runs as root. I suspect you could add an instruction to your Dockerfile to change the perms on the file to executable.

[TBOpen]

I didn't have any problems running it under Fedora 29 as as root? It might be the attributes were lost since it went from Linux to SMB Share on Windows, to Windows where Tortoise GIT was used to upload? I would guess then it just needs chmod +x make_shim_14.5

[Doncuppjr]

That should fix it. Let me know, and I'll try again.

[TBOpen]

i updated it. thanks.

[Doncuppjr]

sha256sum did not match
6c5a39ff045ece7d8556852efafb05528a6a8e215d485d9466d85c9e1ae34063
sbat section looks good.

[TBOpen]

I created the sha256 in windows using "certutil -hashfile filename SHA256", I just did it again and it came up with 6c5a39ff045ece7d8556852efafb05528a6a8e215d485d9466d85c9e1ae34063 so updated file above. Now to figure out what happened, scripting "for %i in (.) do certutil -hashfile %i SHA256" in each subdir, I found it the old hash was for the shim.cer file.
I guess that's what happens when you juggle 5 different things at the same time. Thanks for finding it and pointing it out.

[Doncuppjr]

@TBOpen Don't be afraid to do a few reviews and help out with the peer review process.

[steve-mcintyre]

Hi @TBOpen, a few questions:

• can you elaborate some more on what your patch is doing please? Is your product using a 32-bit kernel on 64-bit systems?
• (minor nit) no need to add the sbat data in a patch, the build system will add it for you
• storage of private keys - how is that managed? (we'd expect you to use an HSM, and I think Microsoft ask for similar too)
• you're basing your grub on the ubuntu builds - are you applying any additional patches?

I can say that the build reproduces ok.
The SBAT vendor ID is a little short for comfort, as @julian-klode says

You may also want to check on the 15.4 issues list in #165 and be sure that you don't need any of the updates there also.

[TBOpen]

Hi @TBOpen, a few questions:

* can you elaborate some more on what your patch is doing please? Is your product using a 32-bit kernel on 64-bit systems?

The patch looks to a file to determine the name of what to load, otherwise defaulting back to the hard coded grubx64.efi name . Also fixes being able to boot 32bit kernel on 64bit systems, customers can choose either, the default is 64bit kernel because some new systems won't boot the 686 kernel without hanging, however 32bit still available for systems with issues using 64bit kernel (config options for what devices and drivers are loaded are different) and has 686 version has lower memory requirement.

* (minor nit) no need to add the sbat data in a patch, the build system will add it for you

That's where I saw to get in my own unique SBAT entry and easy enough.

* storage of private keys - how is that managed? (we'd expect you to use an HSM, and I think Microsoft ask for similar too)

Hardware Token, Dongle, HSM, whatever name is the in-thing, it's on there with the EV certificate (the USB device you get from Verisign, Symantec, Digicert).

* you're basing your grub on the ubuntu builds - are you applying any additional patches?

Yes, their build system does that, confirmed back in july 30 build they had already fixed boothole main issue and patch was already applied.

I can say that the build reproduces ok.
The SBAT vendor ID is a little short for comfort, as @julian-klode says

They are expanded with the .TB, I don't see any conflicts occurring.

You may also want to check on the 15.4 issues list in #165 and be sure that you don't need any of the updates there also.

so they recommend waiting until 15.5?

[TBOpen]

why is there an incomplete label on it?

[Doncuppjr]

You picked up that label when you were missing your dockerfile. While I helped you through that process, I can’t change labels.  Sent from Yahoo Mail for iPhone On Monday, April 26, 2021, 11:24 PM, TBOpen ***@***.***> wrote: why is there an incomplete label on it? — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

[steve-mcintyre]

Hi @TBOpen, a few questions:

* can you elaborate some more on what your patch is doing please? Is your product using a 32-bit kernel on 64-bit systems?

The patch looks to a file to determine the name of what to load, otherwise defaulting back to the hard coded grubx64.efi name . Also fixes being able to boot 32bit kernel on 64bit systems, customers can choose either, the default is 64bit kernel because some new systems won't boot the 686 kernel without hanging, however 32bit still available for systems with issues using 64bit kernel (config options for what devices and drivers are loaded are different) and has 686 version has lower memory requirement.

OK, thanks for explaining. We're quite sensitive about shim patches that haven't been discussed/reviewed by the wider community at this point

* (minor nit) no need to add the sbat data in a patch, the build system will add it for you

That's where I saw to get in my own unique SBAT entry and easy enough.

OK, I guess.

* storage of private keys - how is that managed? (we'd expect you to use an HSM, and I think Microsoft ask for similar too)

Hardware Token, Dongle, HSM, whatever name is the in-thing, it's on there with the EV certificate (the USB device you get from Verisign, Symantec, Digicert).

Cool.

* you're basing your grub on the ubuntu builds - are you applying any additional patches?

Yes, their build system does that, confirmed back in july 30 build they had already fixed boothole main issue and patch was already applied.

Sorry, I guess I wasn't totally clear - do you apply any extra patches on top of the Ubuntu sources?

I can say that the build reproduces ok.
The SBAT vendor ID is a little short for comfort, as @julian-klode says

They are expanded with the .TB, I don't see any conflicts occurring.

Sorry, two characters is too short for comfort - please expand to something longer (e.g. "terabyte"). The design here is that things should be totally clear and unambiguous, with no chance of clashes.

You may also want to check on the 15.4 issues list in #165 and be sure that you don't need any of the updates there also.

so they recommend waiting until 15.5?

15.5 might be a short while yet; what other people are doing at the moment is pulling in those patches directly in the meantime.

[TBOpen]

I asked if they would create a tag, but apparently that's not going to happen? I didn't see an easy way to get the patches off of here. I would definitely need the mac support as several customers use it on those.

[Thinstation]

https://github.com/rhboot/shim/commit/4068fd42c891ea6ebdec056f461babc6e4048844.patch \
https://github.com/rhboot/shim/commit/822d07ad4f07ef66fe447a130e1027c88d02a394.patch \
https://github.com/rhboot/shim/commit/8b59591775a0412863aab9596ab87bdd493a9c1e.patch \

[TBOpen]

Thanks, updated issue with latest information and uploaded new build which includes patches to 15.4.

Are we good to go now?

[TBOpen]

Someone had a question on ubuntu grub2, the patches we apply after its patches is at: https://github.com/TBOpen/shim-review/blob/master/grub2_fullpatch.patch

[steve-mcintyre]

• shim reproduces ok, good
• SBAT looks better, good
• small set of patches applied look OK to me

Marking as accepted now

[TBOpen]

thanks.