Shim 15.8 for Freexian's Debian 10 ELTS (extended support by Freexian) #435
Comments
THS-on
added
new vendor
|
I couldn't find any public key matching the address If I may request, please edit the opening post, so that the link to your current application revision matches the text displayed (edit the visible text, which currently looks like a template one). I'll perform an application review soon. |
|
I've sent mail to [email protected], but the key for Emilio doesn't include a uid for [email protected]. Please fix... |
steve-mcintyre
added
the
bug
|
Identity confirmation email received:
|
I have added that UID. Please fetch the key again from keyring.debian.org
Fixed.
Thanks! |
steve-mcintyre
removed
the
bug
|
Contact verification mail sent to [email protected] now |
steve-mcintyre
added
contact verification pending
|
Identity verification:
|
|
Contatc verification complete |
steve-mcintyre
added
contacts verified OK
Questions/notes:
|
It's the same patches that were approved for Debian. If necessary, we could remove the arm patches, as we don't actually support SB there. However I'd prefer to keep it for this release (and drop it for the next) to avoid another round-trip.
Not really, the reason is that we inherited Debian's kernel which didn't support ephemeral keys. However, we've already backported the necessary changes and on our next kernel update we'll switch to ephemeral keys. |
review for freexian-shim-amd64-i386-20240801I am not an authorized reviewer, hope this helps anyway
|
|
Thank you for the patience. I wanted to review this application as thoroughly as possible, so I myself could also get introduced to the tooling used in the Debian family. That said, when there are some things I should be aware of, when doing this review, please let me know, what I missed - I'm here to learn as well. So first I'd like to comment on the things that didn't go right for me, or I'd like to learn about. Most importantly, I can't reproduce the build. Here are the logs, what happens on my end (Docker with the buildx plugin on Fedora 40). Note: the same happens when trying to rebuild from Do I need to use other tooling and/or on a different system? I couldn't find the I compared the GRUB2 modules used with the ones from the recent Debian 10 application: They seem fine, but just wondering, why the difference between the upstream-downstream relation. The upstream commits, about which the application form asks, (and especially the one fixed with Linux 5.19) should have been fixed as part of Debian-provided kernel 5.10.120-1, and yes - the code from eadb2f47a3ced5c64b23b90fd2a3463f63726066 is there. I downloaded the sources from https://deb.freexian.com/extended-lts/pool/main/l/linux-5.10/linux-5.10_5.10.218.orig.tar.xz and confirmed it.
I assume the air-gapped computers are also stored in a secure manner or had their storage securely wiped, so as to prevent the recovery of the private keys. OK.
And some final thoughts: Please also add some hints/links about the patches used, so it helps the people who are not that knowledgeable about the Debian systems family. I got lucky, as the patches have already been reviewed at #429 (comment). Also, when listing the SBAT entries, please surround these with three backticks (```), otherwise the rendering on GitHub makes it harder to read without resorting to reading in plaintext. |
|
I am not a docker expert. For me building with the included Dockerfile worked without problem for 64Bit (didn't tried 32 Bit). I don't used |
I'm not sure what's going on there. As @richterger mentioned, those out of memory errors look odd. That seems to be dpkg-source extracting the source package and applying the patch files. Can you attach a full build log? Also can you try to build directly with docker build, without the buildx plugin?
Yes. same for the i386 build. Do you want me to fix this and make a new tag and update the link in this issue?
Hmm, they should be the same, because we don't have any changes to grub. The grub build prints the modules that it's bundling. I have built grub2 2.06-3~deb10u4 on amd64 and it gave me this: The only difference with my previous list is the lack of tftp, which is only included in net binaries (e.g. grubnetx64.efi, but not in e.g. grubx64.efi)
Note that we have backported the ephemeral key patch set and when we start signing kernels those will have ephemeral keys.
Ack, will do. |
|
It looks like the Docker issue was something I managed to already fix on my end (unconfirmed, but might have been about to the I'd like to ask if you'd like to update the application for the |
Great!
I have fixed the build log filenames, improved the formatting for SBAT entries, and added a clarification for the kernel ephemeral keys. I think it was already explained that we don't have them yet because the Debian kernel didn't have them, and that we'll switch to it in the next update. However that update is already prepared and uploaded to our staging repository, so I have added a note for that. Let me know if there's anything that is not clear. |
|
Looks alright! Accepting! |
|
Thank you @aronowski @richterger @steve-mcintyre. I submitted the binaries to Microsoft last week. Since it was our first time, we got back a set of questions asking quite a few technical details about our submission. I asked them if we could skip some questions since the same SHIM has probably been reviewed dozen times by them but it looks like that's not an option. I'm thus wondering if we have somewhere canned responses for all the questions that requires submitters to describe the inner workings of the shim. If not, I'm willing to collate the answers and create that document and submit it somewhere (here in this repository?). FTR, here are the questions one gets:
It seems to me that questions 4 and 6 to15 are generic questions where one would always answer the same if you submit a shim since those questions ask details about the submitted product, hence shim. Then I assume that many Debian distributions support "fwupd" and/or "fwupdate" and that answers for questions 16.g could also be shared since AFAICT we sign binaries in those packages so that they can be chain-loaded by the shim too (to install firmware updates). |
With the input of some Debian people, here's a first draft in the hope that it can help others: https://gist.github.com/rhertzog/7efd1f78212e2708ba64d3dc3190095f Don't hesitate to review it and share some feedback if some explanations are incorrect or can be improved. |
|
The official Microsoft questions are mostly so generic, so that they cover products that are not UEFI shims too. I myself am not against an unofficial cheat-sheet with the answers, as long as it's, well, unofficial. I could add a link to the community-backed cheat-sheet, once it's ready, and give proper accreditation in my own unofficial guide, but I myself would rather not be directly involved with maintaining the cheat-sheet itself. You can also fork my own guide and add the appropriate entries. That is, on your responsibility, considering that I give no warranties as to the quality of the information in the guide, as well as my repository maintainability. ;-) I don't think the cheat-sheet should be in the shim-review repository for several reasons: First, it might look contradictory to have all these answers ready-made, if the point of the shim-review repository is to help vendors maintain their bootloader chains in a secure manner and correct potential errors (in shim-review submissions) so as to learn for the actual official questions being asked as part of Microsoft's Hardware Dev Center File Signing Services submission. They are separate, although some shim-related questions are the same. Second, the shim-review repository is nevertheless the venue required by Microsoft to be completed with the accepted label in a GitHub issue, so the answers posted in this repository's docs could well be considered by the File Signing Services reviewers as copied and pasted without some vendors knowing, what they are doing, only modifying the answers for some minor changes, like vendor name. Quoting @julian-klode,
Third, shim-review and Microsoft Hardware Dev Center File Signing Services are nevertheless separate entities and if the answers were to be posted as part of shim-review documentation, the committee would have to keep track of the current state of File Signing Services questions, since these may change unexpectedly. I would be against adding any more pressure for the committee, who are in most cases just volunteering to help with the actual applications (and overworked). |
|
Thanks @aronowski for your answers. I understand what you are saying and arguably the research I had to make improved my knowledge of the field. Instead of having a cheat-sheet, what would be even better is if the upstream documentation of each related project could have the explanations readily available but without being explicitly linked to the Microsoft questions... Thus I submitted the following issues: In the mean time we received the signed binaries from Microsoft, this ticket can be closed. Thank you. @epozuelo is not currently available, but eventually he will close this ticket if nobody else closes it before. |
|
Closing. Thanks everyone! |
Confirm the following are included in your repo, checking each box:
What is the link to your tag in a repo cloned from rhboot/shim-review?
https://github.com/freexian/shim-review/tree/freexian-shim-amd64-i386-20240906What is the SHA256 hash of your final SHIM binary?
9fd8ca20c5245a38b2a45c2b9c7b48d0ef8eeb0aa42a882b41a892eca3e8b72a shimx64.efi
ce30b60229ba5ce5a01d778a93ac2cb1d3600a3049a527d6916e243bc13e940a shimia32.efi
What is the link to your previous shim review request (if any, otherwise N/A)?
N/A
If no security contacts have changed since verification, what is the link to your request, where they've been verified (if any, otherwise N/A)?
N/A
The text was updated successfully, but these errors were encountered: