Shim 15.7 for openSUSE Tumbleweed

[jsegitz]

Confirm the following are included in your repo, checking each box:

• 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 to 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

---

What is the link to your tag in a repo cloned from rhboot/shim-review?

---

https://github.com/jsegitz/shim-review/tree/SUSE-openSUSE_tumbleweed-shim-15.7-20230508

---

What is the SHA256 hash of your final SHIM binary?

---

x86_64:

• pesign:
  hash: 3016c9a9dc256cdfa6b46e475303771621fd65bd07e5987b2a5b2b084a34e323
• sha256sum:
  68f89f47ac03a1fb4428692fd95a86d46eaeee087e392725797e64605b804509

aarch64:

• pesign:
  hash: 615aa39cfd278313c8317ae8cadd908aae25ace3edb04d8700639ad7898a952e
• sha256sum:
  d47c2e2c3c28b27bbc9674a13d89818ba7455d127f0267e83cc6b0b5c3831ca2

******************************************************************************* ### What is the link to your previous shim review request (if any, otherwise N/A)?

---

#283
(and #329, see notes in the README)

[aronowski]

I can see you shim now supports NX. Great job!

When it comes to further NX support in your bootchain I hope the official reviewers as well as Microsoft won't mind that it's still in WIP state according to the official message from @julian-klode:

Hence please don't submit shims for review if you don't have working NX stack or at least prepped the shim for NX (I mean you can continue working on the rest in the meantime).

With the fwupd-sle entry I can see what happens (in the Add any additional information you think we may need to validate this shim. section). Hopefully it can stay this way so no additional humanpower needs to be utilized.

---

Almost everything's fine in this review apart from the one thing I must admit - the build does not reproduce. I tried both Podman and Docker and get the messages

$ podman build .
STEP 1/12: FROM opensuse/leap@sha256:f62e58ff202b95250b8c8f6664d8d4ceebf5d22bbfa244dee7fb129bc667b784
Resolved "opensuse/leap" as an alias (/etc/containers/registries.conf.d/000-shortnames.conf)
Trying to pull registry.opensuse.org/opensuse/leap@sha256:f62e58ff202b95250b8c8f6664d8d4ceebf5d22bbfa244dee7fb129bc667b784...
Error: error creating build container: initializing source docker://registry.opensuse.org/opensuse/leap@sha256:f62e58ff202b95250b8c8f6664d8d4ceebf5d22bbfa244dee7fb129bc667b784: reading manifest sha256:f62e58ff202b95250b8c8f6664d8d4ceebf5d22bbfa244dee7fb129bc667b784 in registry.opensuse.org/opensuse/leap: manifest unknown

$ sudo docker build .
Sending build context to Docker daemon  474.4MB
Step 1/12 : FROM opensuse/leap@sha256:f62e58ff202b95250b8c8f6664d8d4ceebf5d22bbfa244dee7fb129bc667b784
manifest for opensuse/leap@sha256:f62e58ff202b95250b8c8f6664d8d4ceebf5d22bbfa244dee7fb129bc667b784 not found: manifest unknown: manifest unknown

[jsegitz]

ouch, not exactly a small problem. I tried it yesterday and it worked for me. I'll check it out and will report back here. Thanks for your work!

[jsegitz]

The fixed version of the image in the Dockerfile caused this problem. I apparently still had it cached. I pushed a single line change and tested the build on a fresh Fedora VM. Can you please try again?

[aronowski]

Switched to the branch SUSE-openSUSE_tumbleweed-shim-15.7-devel and it works now. Now it's time to tag this change, push the tag, update it in this issue and wait for the official committee.

Great job and wish you all the best!

[jsegitz]

The tag was already updated. Thanks for your review, I appreciate the feedback!

[jsegitz]

I've added the aarch64 shim to this review request. For that I adjusted the Dockerfile to be arch independent, added the shim binary and build log and added the relevant hashes.

[jsegitz]

Is there anything I can do to speed up an official review for this issue?

[evilteq]

Reproduced the binary with latest repo version, the hashes matches the review.
Objdump showed the NX flag is set.
It includes the opensuse cert (Subject: CN = openSUSE Secure Boot CA, C = DE, L = Nuremberg, O = openSUSE Project, emailAddress = [email protected]) valid up to Jul 22 16:12:07 2035 GMT.

[jsegitz]

thanks. Can an official reviewer please approve the request? This is open for over two months. If there's anything to help this along please tell me what to do

[jsegitz]

Let me try again. Is there anything I can do to speed this along? If the project needs help openSUSE can support here, but every attempt to help out with reviews didn't work out AFAIK

[julian-klode]

So the thing is, when I submit a shim, then I review 2-3 other shims, but if nobody is submitting shims who can accept your shim, or accepts shims out of order, it doesn't matter how far up on the queues you are.

[aronowski]

Thanks for the clarification, Julian. In regard to this part of the answer:

if nobody is submitting shims who can accept your shim, or accepts shims out of order, it doesn't matter how far up on the queues you are

I can see there's one more thing that could be done to speed up the reviewing process, if peer reviews don't count (only helping out clearing some errors, if there are any) and some contributions take time to be brainstormed and integrated, like these ideas.

In regard to what you wrote circa 3 years ago, that is:

 If you submit something for review, it's useful if you review something else, even if you are not a committer to this repo, such that (a) you gain understanding of the review process and (b) reviews can possibly be sped up and trust can be learned.

I was surprised by being instantly recognizable when emailing some people about private things unrelated to the bootloader-related processes, so I suppose that some trust has indeed been earned throughout all this time.

So right now, considering the aforementioned trust, I suppose the only way to speed up the process is to become an official reviewer myself. Please, give me a hint on how to accomplish this—is there a procedure at Microsoft somewhere that I wasn't following, or should I do something else, like attend FOSDEM, CCCamp or other meeting and present in person in real time the experience with bootloader-related technical stuff and reviewing requests for signing shims?

I account for the possibility of this being allowed to only be talked about in private; therefore, both my work and private email addresses are out there (the latter being directly at my GitHub profile and throughout most contributions), and the public GPG keys are uploaded to keyserver.ubuntu.com.

[evilteq]

The peer reviews may help to get it in shape, but it doesn't really matter much if we never get the stamp of approval from an authorized reviewer.
The amount of reviews/reviewers is not enough. Unattended submissions pile up to the second page now. Can we apply to that position? I can see already @aronowski wrote faster and better than me in that direction, so I guess we could get a handful of reviewers more.

[Fabian-Gruenbichler]

Being in the same boat as @jsegitz and @aronowski , just having crossed the 5 month mark with no "official" response whatsoever on our shim-review issue, but seemingly also no progress on other review requests, no matter whether the new vendor actively reviewed other requests or not, I feel like there is some sort of impasse reached. I (or rather, my employer) would happily allocate a few hours for updating our own request and doing spot checks and asking dumb questions on others (dumb given my limited knowledge of RHEL-based distros, and most review requests being based on that or something custom entirely) - if there was some kind of indication that those hours were well spent and the result would help. Even some sort of clarification in the form of "if you want your shim implementation to get reviewed, you need to commit X hours of review time over a certain period of time", or "review X other requests for each one you submit", or some other form of ensuring the backlog cannot grow indefinitely and then following through on that would be helpful.

The backlog for new-vendor shims is now already almost 9 months (the last new vendor that got accepted was LUX 1.0, with the review started on Dec 16th last year, and acceptance in Feburary this year). I am grateful for all the time and energy people have spent and are spending on shim and secure boot related things for the FOSS world (and I know it's not a thankful job, I develop and maintain FOSS software both for a living and in Debian in my spare time ;)) - but it also seems to me that the process is (somewhat) broken at the moment, which is frustrating for both sides. This is not intended as a critique of the people involved, but rather of the current way the process works (or rather, does not). If Microsoft does not want to sign (Linux) bootloaders except via shim(-review), but shim-review makes no progress reviewing new vendors over a long period of time, this effectively means smaller or newer distros that came late(r) to the party are blocked from implementing (user-friendly/out-of-the-box) secure boot for the foreseeable future :-/

[julian-klode]

The submissions only mentions fwupd as an additional component (but also lists sbat for fwupdate?), but SUSE folks in Berlin today said that you started signing systemd-boot as well, can you confirm whether this applies to Tumbleweed or which other (open)SUSE flavours?

[jsegitz]

yes, that is true nowadays. This has been in the queue for so long that now that this isn't up to date anymore. Thanks for the hint, I'll adjust it in the repo.

This could apply to all openSUSE flavors, as we reuse the shim, although I think it's unlikely that this will be backported to anything besides Tumbleweed

[aronowski]

In regard to the recent comments, I'll perform another review as soon as possible, once I'm informed about the adjustments being right there in a fresh tag.

[jsegitz]

Thank you. I've updated the information and force-updated the tag

[aronowski]

A proper review shall arrive soon. It's tough for me to test out everything in certain conditions such as boarding a train, i.e. with an unstable Internet connection and timeouts.
Thanks for the patience.

For now let's focus on these:

• Can we all be sure the build environment won't change over time because of the Docker image used (opensuse/leap:15.4)? While this may not be an issue right now, I can't say what happens if someone else wants to reproduce the build in the far future.
• There are distinct email addresses used for different components. The SBAT-related listing mentions [email protected] as well as [email protected]. Not that it itself is wrong, as it may be an alias; it's just I'd rather ask if this was intentional than allow for it to slip through in case it wasn't intentional.
• Recently an update in regard to the application template has been made and there's now an additional question on an ephemeral key for signing kernel modules. I understand that it indeed took some time for the application to be reviewed, but I'd still add an answer to that question, so other reviewers can be sure everything's as intended.

[aronowski]

I tried to rebuild the binaries with podman build -t opensuse_shim:15.7 . as instructed and got the following output:

STEP 11/12: RUN pesign --hash --padding --in=$(find /shim -name shim-opensuse.efi -print -quit)
hash: 3016c9a9dc256cdfa6b46e475303771621fd65bd07e5987b2a5b2b084a34e323
[...]
STEP 12/12: RUN sha256sum $(find /shim -name shim-opensuse.efi -print -quit)
68f89f47ac03a1fb4428692fd95a86d46eaeee087e392725797e64605b804509  /shim/usr/lib64/efi/shim-opensuse.efi

AFAIK that hash should be the same as in the review application. The file build_log.x86_64 mentions May 8, 2023:

[   25s] suse-workstation finished "build shim.spec" at Mon May  8 13:13:15 UTC 2023.

So did the build environment change in the meantime, so the result (Authenticode hash) changed too, or is there a misunderstanding on my side?

[jsegitz]

thanks your for taking the time to look into this. As for the questions:

* Can we all be sure the build environment won't change over time because of the Docker image used (`opensuse/leap:15.4`)? While this may not be an issue right now, I can't say what happens if someone else wants to reproduce the build in the far future.

I used a fixed container image for a while but that actually caused some issues for me because the images vanish, so I reverted to this. I can change it for this submission, but in my experience the images will be not available after a relatively short time anyway and then the submission is "broken" even though it would properly build on a more recent image

* There are distinct email addresses used for different components. The SBAT-related listing mentions `[email protected]` as well as `[email protected]`. Not that it itself is wrong, as it may be an alias; it's just I'd rather ask if this was intentional than allow for it to slip through in case it wasn't intentional.

It's the same team behind those addresses

* Recently an update in regard to the application template has been made and there's now an additional question on an ephemeral key for signing kernel modules. I understand that it indeed took some time for the application to be reviewed, but I'd still add an answer to that question, so other reviewers can be sure everything's as intended.

I assume you mean:

Do you use an ephemeral key for signing kernel modules?

If not, please describe how you ensure that one kernel build does not load modules built for another kernel.

We don't use ephemeral keys for signing kernel modules and ATM don't have a mechanism to prevent them from being loaded by another kernel. That would also be unfortunate for our setup if this would be required

[jsegitz]

I'll look into the build issues you described. Last time I tried it worked for me, but unfortunately it can change with time, yes :(

[jsegitz]

So the hashes you get for x86_64 are the new, correct ones with the current state. Unfortunately the aarch64 emulation is very slow so I don't have the proper hashes there yet. I'm away until Wednesday and will then update the issue with the current values and tag you here

[aronowski]

Thanks for the feedback!

Please ping me once either everything has been fixed or I should help with some of the implementations.

---

Unfortunately the aarch64 emulation is very slow so I don't have the proper hashes there yet.

I know that feeling. ;-)

[jsegitz]

@aronowski so the long weekend (public holiday on Tuesday in Germany) helped with the awfully slow build process ;) I've updated our submission to have current build logs, hashes and a minor change in the shim package (just something in the packaging, doesn't change the resulting binary). Would be great if you could have a look again

[aronowski]

Apologies for the late reply.

Managed to reproduce the x86_64 build, the checksum does match. 👍

I'll perform a thorough review and verify the aarch64 build as well in near future - I'll try my best to do it this Friday or next Monday.

[jsegitz]

thank you very much :)

[aronowski]

Managed to reproduce the aarch64 build, the checksum does match. 👍

I'm just worried about the fact that the buildroot might change in the near future, so there'll be a need to update the checksums again. Maybe we could think of freezing the packages required to build such a crucial component, similarly to how Ctrl IQ did it?

Furthermore, the same feeling in regard to the ephemeral key used for signing kernel modules. I'd be happy to help out with implementing this feature into the compilation/build process, but there's the matter of arranging time and space to work on this. I'll be kind of tied up at least the next week.

Let's wait for another reviewer to take a look and suggest an optimal solution. Feel free to ping people out there for assistance.

[jsegitz]

Thank you for your review.

As for the stable repo: That would be quite a number of packages as the whole build toolchain would need to be included. The checksums are stable over months, so my hope would be that we get this review process to a speed so that changes on the distros side aren't as much of a problem.

[ClaudioGranatiero-10zig]

I'm not an authorized reviewer, I'm just trying to help and learn.
I've only tested the x86_64 version here.

---

sha256:

68f89f47ac03a1fb4428692fd95a86d46eaeee087e392725797e64605b804509  shim-opensuse.efi

Build is reproducible, sha256 is confirmed.

---

Obj Alignment:

shim-opensuse.efi

SectionAlignment	00001000
DllCharacteristics	00000100

Alignement is ok.

---

DllCharacteristics:

shim-opensuse.efi

            DllCharacteristics:        256         0x100  NX_COMPAT

NX_COMPAT is enabled.

---

Sections:

shim-opensuse.efi

=== SECTIONS ===

  NAME          RVA      VSZ   RAW_SZ  RAW_PTR  nREL  REL_PTR nLINE LINE_PTR     FLAGS
  "/4"         5000    1d66c    1d800      400     0        0     0        0  40000040  R-- IDATA
  .text       23000    5ed91    5ee00    1dc00     0        0     0        0  60000020  R-X CODE
  .reloc      82000        a      200    7ca00     0        0     0        0  42000040  R-- IDATA DISCARDABLE
  "/14"       83000       6b      200    7cc00     0        0     0        0  c0000040  RW- IDATA
  "/26"       84000       47      200    7ce00     0        0     0        0  40000040  R-- IDATA
  .data       85000    2cb58    2cc00    7d000     0        0     0        0  c0000040  RW- IDATA
  "/37"       b2000     188c     1a00    a9c00     0        0     0        0  40000040  R-- IDATA
  .dynamic    b4000      100      200    ab600     0        0     0        0  c0000040  RW- IDATA
  .rela       b5000    1b438    1b600    ab800     0        0     0        0  40000040  R-- IDATA
  .sbat       d1000       c8      200    c6e00     0        0     0        0  40000040  R-- IDATA

Code section is not writable: OK

---

SBAT:

shim-opensuse.efi

shim-opensuse.efi:     file format pei-x86-64

Contents of section .sbat:
 d1000 73626174 2c312c53 42415420 56657273  sbat,1,SBAT Vers
 d1010 696f6e2c 73626174 2c312c68 74747073  ion,sbat,1,https
 d1020 3a2f2f67 69746875 622e636f 6d2f7268  ://github.com/rh
 d1030 626f6f74 2f736869 6d2f626c 6f622f6d  boot/shim/blob/m
 d1040 61696e2f 53424154 2e6d640a 7368696d  ain/SBAT.md.shim
 d1050 2c332c55 45464920 7368696d 2c736869  ,3,UEFI shim,shi
 d1060 6d2c312c 68747470 733a2f2f 67697468  m,1,https://gith
 d1070 75622e63 6f6d2f72 68626f6f 742f7368  ub.com/rhboot/sh
 d1080 696d0a73 68696d2e 6f70656e 73757365  im.shim.opensuse
 d1090 2c312c54 6865206f 70656e53 55534520  ,1,The openSUSE 
 d10a0 70726f6a 6563742c 7368696d 2c31352e  project,shim,15.
 d10b0 372c6d61 696c3a73 65637572 69747940  7,mail:security@
 d10c0 73757365 2e64650a                    suse.de.        

shim-opensuse.efi:     file format pei-x86-64

Contents of section .sbatlevel:
 84000 00000000 08000000 22000000 73626174  ........"...sbat
 84010 2c312c32 30323230 35323430 300a6772  ,1,2022052400.gr
 84020 75622c32 0a007362 61742c31 2c323032  ub,2..sbat,1,202
 84030 32313131 3530300a 7368696d 2c320a67  2111500.shim,2.g
 84040 7275622c 330a00                      rub,3..         

SBAT seems ok to me.

---

Certificate:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 1 (0x1)
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C = DE, ST = Franconia, L = Nuremberg, O = SUSE Linux Products GmbH, OU = OPS Services, CN = SUSE Trust Root, emailAddress = [email protected]
        Validity
            Not Before: Dec  6 00:00:00 2011 GMT
            Not After : Dec  5 23:59:59 2041 GMT
        Subject: C = DE, ST = Franconia, L = Nuremberg, O = SUSE Linux Products GmbH, OU = OPS Services, CN = SUSE Trust Root, emailAddress = [email protected]
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (4096 bit)
                Modulus:
                    00:d7:72:57:79:11:33:30:39:71:09:d5:9b:dd:bc:
                    04:7f:de:e5:f8:36:3d:bf:09:dc:e5:13:e2:3d:2f:
                    80:76:70:de:87:10:8c:4b:3c:cb:d2:6f:d6:97:e4:
                    9a:09:7c:98:41:3b:aa:2d:c0:46:6f:b8:21:8c:32:
                    98:c1:30:df:8e:69:9c:a1:72:fc:3c:a0:2f:11:0c:
                    89:84:c0:0d:98:02:02:80:b0:90:72:da:8e:6d:c6:
                    fb:3d:32:57:f0:b8:7f:a0:5b:58:4e:63:8c:42:d4:
                    d8:c9:80:f0:9a:3d:c5:65:6a:1b:ab:4c:98:69:34:
                    c5:91:b8:52:f3:5e:b9:58:23:39:53:3b:90:17:23:
                    65:ca:10:09:35:86:92:a4:88:69:33:7a:58:83:0a:
 
            X509v3 Key Usage: 
                Digital Signature, Certificate Sign, CRL Sign
        X509v3 extensions:
            X509v3 Basic Constraints: critical
                CA:TRUE
            X509v3 Subject Key Identifier: 
                B0:8A:DB:61:36:34:E9:BD:79:1E:07:E9:41:81:D7:BB:6B:D2:AF:97

It's a CA, good
Certificate is ok.

============================================

[jsegitz]

thank you for the review.

Is there a chance that the official reviewers can approve this request? We have been without a fixed shim for a very, very long time now

[julian-klode]

We should not be approving this shim until the systemd-boot questions have been merged which will not be happening this year, as so far we do not accept shims that trust systemd-boot.

[Thaodan]

Without the update to the shim updating firmware with fwupd is broken when secure-boot is enabled. I think waiting with that for longer would hurt users experience more.

[ceggers-arri]

I think waiting with that for longer would hurt users experience more.

I am in a quite uncomfortable situation: On my company's laptop, I tried to install openSUSE Leap 15.5. After recognizing that this distro is far too old for my hardware, I switched to Tumbleweed.

As a result, I cannot enable secure boot anymore. This is because Tumbleweed ships an older version of shim, which had already been revoked by the previously installed Leap distro. In order to solve this, I would have to reinstall Leap 15.5 and remove the older shim from the list of revoked shim versions (the older shim in Tumbleweed is not able to do this). After some hours of work, I (probably) could re-enable secure boot, but having a bootloader which isn't really secure anymore.

I would be happy having a solution for this problem.

[dennis-tseng99]

@julian-klode Would you please point out the key point why this release is rejected ? Did you find something in shim.spec and changelog or anything else ? We will try to rectify them to let this release keeps going. Many thanks.

[julian-klode]

It's not rejected but we can't approve it yet because we haven't merged the questions to be asked yet for systemd-boot.

Yes you managed to backstab the process and secretly signed systemd-boot for the previous shim without approval but that doesn't mean we should just wave it through now without having the process in place to do this properly.

So once #357 has been merged, some time after the holiday breaks, mid January, you'll be able to answer those additional questions.

[Thaodan]

So much for this process than, if you take so long to review requests users have to downgrade their security to not further downgrade their experience and/or the security issues affected.

[jsegitz]

closing because we'll submit a 15.8 shortly