stalled shim reviews

[jsetje]

As a bystander that does not work for Microsoft, I would like to point out the following:

There are currently a couple of shim reviews pending that haven't moved along with the usual expediency.

At least on current hardware, dbx entries used to deny list revoked shims are a finite resource. Given the recent boothole event, and the amount of dbx space that deny listing all the shims capable of loading bad grub binaries consumed, there is a desperate need to limit the number of shims signed until we have an alternate revocation model in place within the shim.

Shim developers consider this an urgent issue.

[jsegitz]

thank you for informing us.

[julian-klode]

Regarding urgency wrt the BootHole dbx updates: To my knowledge, only Ubuntu has rolled out the update to machines, and that change has been reverted recently, such that any machines that did not receive it won't receive it. I'm not aware of other vendors applying the dbx update, or intending to do so in the short term for general purpose operating systems and computers.

This means that shim updates due to BootHole dbx revocations are less urgent than it looks.

[joseph-zeronsoftn]

I hope a good solution can be found.

@julian-klode However, new vendors have a desperate need for shims.
I am not urging you, but I would appreciate if your consideration for this as well.
Thank you.

[toolhouse-de]

joseph-zerosoftn's comment is also true for existing vendors - like us - whose embedded EV certificate has expired. This is blocking us from releasing new, security enhanced versions. This is leaving us in a desperate situation.

Please help! Thank you.

[jsetje]

For anyone wanting to track direction of the shim work needed to support revocations in a manner that don't result in dbx growth, the proposal is currently being worked on here:

https://github.com/rhboot/shim/blob/sbat/SBAT.md

[TBOpen]

glad Ubuntu pulled that, it left our customers with unbootable systems. as far as the dbx size and the issue at hand, I would presume the firmware has one method in place so any fix to reduce the size is going to require a firmware update? While compression can be used (and it can be a very small amount of code for the decompression (few to several hundred bytes)), for these type of special mass updates a date criteria based on the MS 3rd party CA may be better. But you run the risk of what Ubuntu did, invaliding existing shims before a new working shim in place. You could use a new scheme supporting dual signing in a way the old firmware picks up the old certificate and the new would would see that invalid but pick up the newer one. We could tell all customers ahead of time they need to update for coming firmware updates (that's somewhat reasonable). You could also make the dbx update smart, it would scan all files in the EFI System partition looking at the signatures and if it finds a match tell the user what it found and what it is (maybe MS allows to add a description and dbx update would have description) and ask user to update the software or allow user to skip that dbx update until they are ready (running again it would ignore items already applied and check for the ones not applied, if gone (user updated or removed software) it updates dbx, if not, repeats UI information to user). Just thrown ideas out-there that may make a light-bulb go off for someone...

Reading the link above for SBAT, I think I get #1, this would something like a company given GUID (or DWORD) with some additional meta data, one of which a version (maybe product as well if someone doesn't have a flexible shim for multiple products), when something needs to revoke, you do it based on a GUID revoke / version. That is a space saving method over time (or even one time because less size than full hashes). That would work for that purpose. Lots of new variables, be nice if MS updated API to get variable by index instead of having to know name or searching a full range say BOOT#### from 0000 to FFFF which is slow.

On #2, I didn't quite follow, since even if you have the single shim provider, it would need the customers hash (public key) which changes the hash, so you get a unique hash for each "common" shim. But maybe I'm not understanding it.

[Doncuppjr]

Now that 15.3 is tagged, will reviews resume?

[julian-klode]

I think soon signing will resume with the major Linux distros and afterwards for others. Though I'm not sure about the policies that will be there for others - there's a goal to not sign other shims but have a different approach such that one shim works for them all, but I have not followed progress closely recently. Assuming there are no critical issues appearing in the middle of that :-D

[TBOpen]

I'm waiting for the official shim release, I see shim-15.3-rc3, is that the "one" (and grub tag or release). I'll also probably still pull my grub from ubuntu because they fix a bunch of additional issues, even though MS mentioned the official repository, I told them I may use it, but do you know, are all the distro's going to submit all the fixes to the single location for GRUB. It be nice if they did and for us (and you) to have the "one" official grub build. I also sent a message to Peter to fix the patch of mine he applied differently (wrong) to shim years ago that allow booting 686 kernel on x64 uefi. The fix is in my patch also my patch has the ability to disable fallback (which I don't need) and moves the file to load to a shim.dat file instead of hard coding the name in the code. Patch is small but potent, check my patch at https://github.com/TBOpen/shim-review thanks.

[julian-klode]

No 15.3-rc3 is not the final 15.3, but it's fairly close

Upstreaming all those downstream grub patches is a long and hard effort and will probably take the better part of this decade.

[julian-klode]

15.3 is out now. We expect to start building and reviewing submissions from the involved major Linux distributions soon. We will post another update once we get back to normal reviewing, but it's possible to get a head start and rebase on 15.3 now.

You can find the release at https://github.com/rhboot/shim/releases/tag/15.3, please use the https://github.com/rhboot/shim/releases/download/15.3/shim-15.3.tar.bz2 tarball referenced there specifically to build from, the git version requires submodule magic.

[TBOpen]

The binary is a bit smaller than 15, I presume due to improvements linking or building? I have the shim built, the .gz version missing files in the efi-gnu folder, the .bz2 has the files. I'm waiting for ubuntu grub update I see grub going to release 2.06 (they are at RC version now), so I presume either they will update to that or have the needed patches for 2.02 (what they were using last time that had the original boothole fix).

[julian-klode]

Unfortunately the SBAT self-check in the 15.3 release was broken. There were also some issues on ARM targets. Please do not submit 15.3 shims anymore, use 15.4 instead - the templates have been updated accordingly.

[julian-klode]

We have almost finished reviewing all the major distros and people involved in the work, and 15.4 seems to be doing OK, so we can close the issue now.

Sadly it seems other people just drop in more shim reviews, and don't help reviewing other submissions, which does not seem to be a healthy model. If you submit a shim, review another shim (first). It helps you figure out the fine details, and it helps things move along faster.