search

rhboot / shim-review

Reviews of shim
67 stars 131 forks source link

iPXE shim (new submission) #319

Open mcb30 opened 1 year ago

mcb30 commented 1 year ago

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

UPDATED: see below at https://github.com/rhboot/shim-review/issues/319#issuecomment-2007813215

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

https://github.com/ipxe/shim-review/tree/ipxe-shim-x64-aa64-20230217

What is the SHA256 hash of your final SHIM binary?

shimx64.efi 26ec898a8e801fceafec29577386286687efe55d68fa96dc068adb4f5f02060e shimaa64.efi be492d53adff1720e130347a68fb1df3231b7bce824ef3d41cdb311b26d2e024

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

N/A

mcb30 commented 1 year ago

@steve-mcintyre This is the submission we discussed in person on Wednesday 15th - thank you for taking the time to talk!

dennis-tseng99 commented 1 year ago
mcb30 commented 1 year ago

  • I'm not a formal reviewer, but I'd like to contribute a little effort to speed up reviewing

    • I got a "SHIM_TAG" missing warning which results in building error when using podman to run Dockerfile
WARN[0000] missing "SHIM_TAG" build argument. Try adding "--build-arg SHIM_TAG=<VALUE>" to the command line

Strange. The SHIM_TAG is specified right there in line 2 of the Dockerfile:

ARG SHIM_TAG=ipxe-15.7

and I do not get any error when building with the command podman build . (using podman version 4.3.1).

Thank you for verifying the hash and sbat values. :pray:

mcb30 commented 1 year ago

@frozencemetery I see you added the contact verification needed label - should I have already received a PGP-encrypted email with some random words in it yet?

mcb30 commented 1 year ago

The shim-review instructions clearly state:

Please create your shim binaries starting with the 15.7 shim release tar file: https://github.com/rhboot/shim/releases/download/15.7/shim-15.7.tar.bz2

This matches https://github.com/rhboot/shim/releases/tag/15.7 and contains the appropriate gnu-efi source.

I have been been advised off-list that the shim-review instructions are incorrect and that it is necessary to either include commit https://github.com/rhboot/shim/commit/7c7642530fab73facaf3eac233cfbce29e10b0ef that is not part of the 15.7 release, or to work around its absence by running an extra ./post-process-pe -n after the build.

Could one of the reviewers please advise?

julian-klode commented 1 year ago

The instructions to start with the tarball do not preclude including other patches. The instructions are there because the tarball is built with submodules setup correctly whereas if you start from git it involves more work and you may get it wrong.

julian-klode commented 1 year ago

One thing I advise is not to use a custom docker image, because then we need to inspect the custom docker image and that adds a lot more friction than starting from a trusted vendor image in your dockerfile.

mcb30 commented 1 year ago

The instructions to start with the tarball do not preclude including other patches. The instructions are there because the tarball is built with submodules setup correctly whereas if you start from git it involves more work and you may get it wrong.

The instructions suggest that the intention is to base the submission on the most recent release (currently 15.7) rather than on the current main.

I am happy to rebase onto current shim main to pick up all of the relevant bugfixes since 15.7, if that is the preferred option?

mcb30 commented 1 year ago

One thing I advise is not to use a custom docker image, because then we need to inspect the custom docker image and that adds a lot more friction than starting from a trusted vendor image in your dockerfile.

The Docker image used is simply a static snapshot of upstream Fedora, in order to give a reproducible build environment as required to be able to verify the sha256sums. This is modelled on the most recent RHEL shim-review submission, which uses a similar approach.

I am happy to use any trusted vendor image that will also give a reproducible build (i.e. where all versions of all packages used are fixed). Could you please suggest a suitable trusted vendor image?

julian-klode commented 1 year ago

RHEL is a special case because it doesn't have public images so they gotta do something. I always end up rebuilding the RHEL submissions with the Dockerfiles changed to CentOS Steam to ensure the image is not funky.

If the image becomes unreproducible between submission and review you'll have to update the submission. A GitHub action building he shims and comparing them and a public registry might also be enough evidence for reviews, although only Ubuntu had GitHub actions so far, so um, not much prior art :)

I do not know how Fedora and co are structured. Our Ubuntu shims we build without the -updates pocket, so the set is reasonably fixed (unless there's toolchain updates in security).

julian-klode commented 1 year ago

I think what it comes down to for iPXE aside from the technical submissions bit is the question why this needs to be signed. When we last talked about iPXE, the general consensus was that it seems unnecessary and users can just use grub to achieve their goals.

If we sign this shim, what about other distros? Our stance so far has been that shims must only load a single boot loader, they should not be able to have two exploitable bits after them. Will there be other vendors trying to sign shims just for iPXE? Do we care at all? Does it still matter? With SBAT we can just revoke all iPXEs in the world when we want to, so it does not add as much attack surface as in the past when one could only revoke shims.

The submission is unclear about the motivation for this signing request too and contains conflicting statements: It both states that iPXE has not been signed so far but also that it has been signed directly.

What value does adding a shim provide if it can be signed directly? Wouldn't iPXE be better served by implementing SBAT and SBAT self-revocation itself and submitting iPXE binaries directly for signing to Microsoft rather than potentially wait months for shim submissions to be reviewed?

mcb30 commented 1 year ago

RHEL is a special case because it doesn't have public images so they gotta do something. I always end up rebuilding the RHEL submissions with the Dockerfiles changed to CentOS Steam to ensure the image is not funky.

If the image becomes unreproducible between submission and review you'll have to update the submission. A GitHub action building he shims and comparing them and a public registry might also be enough evidence for reviews, although only Ubuntu had GitHub actions so far, so um, not much prior art :)

OK, so the goal is to have an only temporarily reproducible build :slightly_smiling_face:

Is there any chance of having a standard "please use this container" for all shim review submissions? The toolchain required to build shim from source is fixed, so having a standard container that includes all of the tools (and that gets updated once per shim release) would make life simpler for everyone.

In the meantime, I'll update this submission to use a less strictly reproducible build environment as requested.

mcb30 commented 1 year ago

If we sign this shim, what about other distros? Our stance so far has been that shims must only load a single boot loader, they should not be able to have two exploitable bits after them. Will there be other vendors trying to sign shims just for iPXE? Do we care at all? Does it still matter? With SBAT we can just revoke all iPXEs in the world when we want to, so it does not add as much attack surface as in the past when one could only revoke shims.

I'm not sure what you're objecting to here, sorry. This shim will be used to just load a single boot loader: iPXE. I'm not planning to sign any subsequent bootloaders.

I'm not expecting any other vendors to want signed shims for iPXE. The motivation behind features such as iPXE's autoexec.ipxe script is to eliminate the need for embedded scripts and other custom iPXE builds, so that everyone can use the official iPXE binary directly.

Yes, iPXE includes SBAT metadata so the revocation mechanism is fairly straightforward.

The submission is unclear about the motivation for this signing request too and contains conflicting statements: It both states that iPXE has not been signed so far but also that it has been signed directly.

Distros have not signed iPXE using their shim-embedded certificates. MS has signed a few iPXE binaries after lengthy and expensive review.

What value does adding a shim provide if it can be signed directly? Wouldn't iPXE be better served by implementing SBAT and SBAT self-revocation itself and submitting iPXE binaries directly for signing to Microsoft rather than potentially wait months for shim submissions to be reviewed?

Sure: if you're happy to pay me the £30,000 it costs per submission to get the MS-required security review from IOActive for direct signing, then there would be no need for an iPXE shim.

julian-klode commented 1 year ago

Well our goal is to not have people submit shims that don't build large distributions, so um each distribution builds their own shim in their own distribution. Because we can't review all those tiny rescue disks and whatnot.

The old Google submission used

-# Current Fedora 35 hash
-FROM docker.io/fedora@sha256:36af84ba69e21c9ef86a0424a090674c433b2b80c2462e57503886f1d823abe8

which I guess is safe (I mean in GitHub it wouldn't be, because it dedups commits across repos, but um I guess docker doesn't have forks, or at least I'd hope).

julian-klode commented 1 year ago

I'm not expecting any other vendors to want signed shims for iPXE. The motivation behind features such as iPXE's autoexec.ipxe script is to eliminate the need for embedded scripts and other custom iPXE builds, so that everyone can use the official iPXE binary directly.

People have been asking various distributions to sign their iPXE builds, for example. People always want custom builds, they're people, sadly. We told them no, you can't sign iPXE with the chain trusted by your shim

mcb30 commented 1 year ago

People have been asking various distributions to sign their iPXE builds, for example. People always want custom builds, they're people, sadly. We told them no, you can't sign iPXE with the chain trusted by your shim

Where are you trying to get to with this line of argument?

If your goal is to end up saying "no, we don't want to allow shim to be used even for the iPXE project's own published iPXE binaries" then this is a total dead end, and I'll just push a strong message to customers that they will have to continue to disable Secure Boot for the foreseeable future. Is that your preferred outcome here?

mcb30 commented 1 year ago

People have been asking various distributions to sign their iPXE builds, for example. People always want custom builds, they're people, sadly. We told them no, you can't sign iPXE with the chain trusted by your shim

Where are you trying to get to with this line of argument?

If your goal is to end up saying "no, we don't want to allow shim to be used even for the iPXE project's own published iPXE binaries" then this is a total dead end, and I'll just push a strong message to customers that they will have to continue to disable Secure Boot for the foreseeable future. Is that your preferred outcome here?

Would it be possible to get some clarity on this? I'm very happy to put in the effort to change the Dockerfile, pick up patches not included in shim-15.7, etc, but I don't want to waste my time if the end result is just going to be "sorry, please don't try to support Secure Boot".

NiKiZe commented 1 year ago

I think what it comes down to for iPXE aside from the technical submissions bit is the question why this needs to be signed. When we last talked about iPXE, the general consensus was that it seems unnecessary and users can just use grub to achieve their goals.

Last I tried Grub as a user it was not able to run signed wimboot since it has no "run efi binary", it lackd http support, network drivers, and was not able to provide the logic required for many of the usecases that iPXE provides. As such I think the statement "users can just use grub to achieve their goals" is factually incorrect.

iPXE needs to be signed, and is signed, the only question is how we do so moving forward in a reasonable manner.

Only reading this thread, one might think that there is only one signed build of Grub, or that different standards is used, why would that be ok, but not ok to sign the default builds of ipxe.efi and snponly.efi (?)

julian-klode commented 1 year ago

There was supposed to be an update here yesterday, but it seems to have not have happened.

Yesterday, we discussed the issue of signing iPXE in our weekly (but paused for the past weeks) call.

Our summary was:

mcb30 commented 1 year ago
  • We do believe most use cases can be fulfilled with grub, it has a http, tftp support, network support (UEFI network stack, at least for the ones distros use). We have no knowledge about windows use cases like the wimboot stuff mentioned by @NiKiZe - people should consider contributing wim booting features into grub rather than building their own solution.

wimboot has been the de facto standard way to HTTP-boot Windows for over a decade and is delivered as a totally standard UEFI executable signed directly by Microsoft. If GRUB can't load it, that's on GRUB to fix.

Our summary was:

  • Yes, we accept signing a shim for the iPXE upstream project for default iPXE builds

Great news, thank you. How do we now actually move this forwards?

mcb30 commented 1 year ago

Our summary was:

  • Yes, we accept signing a shim for the iPXE upstream project for default iPXE builds

Great news, thank you. How do we now actually move this forwards?

I've gone through the assorted comments above, and it looks to me as though there are two substantive issues to be addressed:

@julian-klode Is there anything else that you are expecting to be done, or are the above two sufficient?

stappersg commented 1 year ago

Whom is waiting for whom? (Or any other update on this (currently) stalled issue.)

uranus829 commented 1 year ago

@julian-klode Hello, I am an ipxe user, is there any progress in signing? I have been paying attention to whether ipxe can support uefi boot, and then I found here, and saw that there has been no news for several months, so I asked here, thank you.

stappersg commented 1 year ago

Another attempt to get this issue on the agenda by partial qouting https://github.com/rhboot/shim-review/issues/319#issuecomment-1460667603

Yesterday, we discussed the issue of signing iPXE in our weekly call.

kfortner commented 1 year ago

Our summary was:

  • Yes, we accept signing a shim for the iPXE upstream project for default iPXE builds

Great news, thank you. How do we now actually move this forwards?

I've gone through the assorted comments above, and it looks to me as though there are two substantive issues to be addressed:

  • Convert the build to be non-reproducible by switching to an off-the-shelf distro container.
  • Rebase the submission on upstream shim main instead of 15.7 in order to pick up required upstream bugfixes that were not included in the 15.7 release.

@julian-klode Is there anything else that you are expecting to be done, or are the above two sufficient?

@mcb30 Is there anything that you need other than the answers to your 2 questions above to move forward?

mcb30 commented 1 year ago

@mcb30 Is there anything that you need other than the answers to your 2 questions above to move forward?

No, that's all I need: some kind of clear statement from @julian-klode (or another shim reviewer) to clarify what changes they want made.

kfortner commented 1 year ago

No, that's all I need: some kind of clear statement from @julian-klode (or another shim reviewer) to clarify what changes they want made.

Got it. There is a weekly meeting referenced in the thread by @julian-klode. If there is any additional input needed to validate the need for this shim, I could see if I could get something added by my employer.

stappersg commented 1 year ago

ICMP echo request a.k.a. ping

toddjames commented 11 months ago

Could @julian-klode (or any other reviewer) please take a moment to review and validate the information provided by @mcb30 (quoted below)? Your input would be greatly appreciated, from another iPXE user with Secure Boot currently disabled for our solution/use case (not supported by GRUB).

I've gone through the assorted comments above, and it looks to me as though there are two substantive issues to be addressed:

  • Convert the build to be non-reproducible by switching to an off-the-shelf distro container.
  • Rebase the submission on upstream shim main instead of 15.7 in order to pick up required upstream bugfixes that were not included in the 15.7 release.

@julian-klode Is there anything else that you are expecting to be done, or are the above two sufficient?

stappersg commented 8 months ago

Happy New Year

BurningC4 commented 8 months ago

@frozencemetery I see you added the contact verification needed label - should I have already received a PGP-encrypted email with some random words in it yet?

Yes, you should copy the words in this email to this issue. After that the label will be delete.

mcb30 commented 8 months ago

@frozencemetery I see you added the contact verification needed label - should I have already received a PGP-encrypted email with some random words in it yet?

Yes, you should copy the words in this email to this issue. After that the label will be delete.

Thank you. @frozencemetery I have not received any such email, or if I did back in February 2023 then it is long since lost. Could you please resend?

aronowski commented 8 months ago

I have not received any such email, or if I did back in February 2023 then it is long since lost. Could you please resend?

I'll take the initiative. I'll send emails with random words soon. Please, post the received words here, once the emails arrive.

aronowski commented 8 months ago

Verification emails sent.

mcb30 commented 8 months ago

I'll take the initiative. I'll send emails with random words soon. Please, post the received words here, once the emails arrive.

bacchanal deprogrammed majoring spectra humongous adhesion neon theoretical mappings frankness

stappersg commented 8 months ago 
gpg: quoted printable character in armor - probably a buggy MTA has been used

(now retrying (upon success shall I remove this))

stappersg commented 8 months ago

On Thu, Feb 15, 2024 at 11:40:10AM -0800, Geert Stappers wrote:

gpg: quoted printable character in armor - probably a buggy MTA has been used

Beyond that error

(now retrying (upon success shall I remove this))

Current too early to call it a success.

Regards Geert Stappers In an attempt to tell: "I got some strange email that I relate to this issue"

-- Silence is hard to parse

stappersg commented 8 months ago

Happy Birth Day. Yes, this submission is a year old.

stappersg commented 8 months ago 
$ base64 --decode part_of_multi_part_message_without_headers 
entity electroplating shakes Angara Humboldt funk amplbase64: invalid input
$
stappersg commented 8 months ago

Another attempt:

entity electroplating shakes Angara Humboldt funk amplifier Deirdre 
risers carefuller
aronowski commented 8 months ago

The words match! Thank you.

Notice: I'll review the application itself and may ask others for helping out with reviewing the application, but I have no skills in reviewing the intermediary binaries. Sincerely hope that some big shots here do have them, however, and can help.

mcb30 commented 8 months ago

@aronowski Thanks for doing the contact verification, and updating the labels. It's nice to see progress on this issue at last!

I'll update the submission to rebase onto the 15.8 release.

aronowski commented 8 months ago

I did take a look at the application as promised. Since Microsoft won't be signing shim 15.7 anymore, a new one shall be created (the current one can just be updated), that I'll review once it's right there with high priority, but I thought we can use this one as a base and see, what's there to be updated, rather than just saying: update the current one and only then something will happen.

The build reproduces and checksums match. OK.
Hint: mention the usage of other registries, as docker.io has been throttling connections for some time. I sometimes get an ERROR: failed to authorize: failed to fetch anonymous token message. Or how to deal with things like these, as other reviewers may not know - for me using proxy servers did the job.

The ipxe-15.7 tag is signed with the private part of the key provided in the application. Keep up with the great work!

While I'm not a C programmer and won't be able to verify the ipxe: Allow next loader path to be derived from shim path patch, or even iPXE's source code, there's the following mention in the extra info section

iPXE has previously been signed directly for Secure Boot and has therefore been subject to several security audits, the results of which have been shared with Microsoft.

, so I suppose Microsoft themselves are capable of auditing the current revision, once a Hardware Dev Center submission is posted.
(See the link below for more info)

Furthermore, an entry on Microsoft Tech Community Hub mentions the following

We discovered that code written by the main author is of superior quality [...]

as part of the official UEFI Signing Requirements about applications containing iPXE functionality.

I have a feeling that once a new (shim 15.8) is there, we can refer to the historical entries I just mentioned and let Microsoft audit the most critical parts of the code. Since the application is itself so custom and barely matches the template, I think all the awesome mentions and shout-outs can be added as part of the ### Add any additional information you think we may need to validate this shim. entry.
Furthermore, let's also add some notes about how security issues are handled quickly and the reputation in regard to security incidents. I can see a rolling-release model is being used, so security bugs should be fixed fairly quickly (understand the entry about the potential quarterly releases, though).

To sum it up, the application looks alright, and I'm looking forward to being amazed by the updated one for shim 15.8 - please, ping me ASAP once it's posted and I'll prioritize it.

steve-mcintyre commented 7 months ago

Hi @mcb30!

So, as I understand it, a signed iPXE shim is meant to work in the following way:

If that's correct, then there's a worry that current versions of shim may not work well here. Once you have a shim binary installed and it hooks the EFI entry points, trying to load another may behave very badly, with potential for crashes etc. I'm assuming you've tested this path on a range of machines? Have you seen any issues like this?

mcb30 commented 7 months ago

Hi @mcb30!

So, as I understand it, a signed iPXE shim is meant to work in the following way:

* The system has SB enabled

* The system boots via the network (or some other way), loading and executing that signed shim.

* The signed shim loads the signed iPXE binary and executes that.

* iPXE will then let the user load and execute a new shim/GRUB/kernel chain (e.g. those belonging to a Linux distribution)

If that's correct, then there's a worry that current versions of shim may not work well here. Once you have a shim binary installed and it hooks the EFI entry points, trying to load another may behave very badly, with potential for crashes etc. I'm assuming you've tested this path on a range of machines? Have you seen any issues like this?

I have verified that the execution path you describe does work (i.e. SecureBoot UEFI -> iPXE-shim -> iPXE -> distro-shim -> distro-kernel).

The second shim is loaded via StartImage(). It therefore gets given a completely separate EFI image handle upon which to install protocols, and the call to StartImage() causes the first shim to uninstall its modifications to the EFI system table before control is transferred to the second shim.

mcb30 commented 7 months ago

To sum it up, the application looks alright, and I'm looking forward to being amazed by the updated one for shim 15.8 - please, ping me ASAP once it's posted and I'll prioritize it.

@aronowski Thank you! I have completed the shim code updates to rebase onto the 15.8 tag (see https://github.com/ipxe/shim/releases/tag/ipxe-15.8). I am now in the process of updating the shim-review submission Dockerfile. I hope to have the new submission ready for review tomorrow.

Thanks for your help in finally moving this forward!

mcb30 commented 7 months ago

While I'm not a C programmer and won't be able to verify the ipxe: Allow next loader path to be derived from shim path patch

In the new version (rebased onto shim 15.8), I've made this patch easier to review. I've removed the portions that attempted to clean up shim's existing (and very messy) handling of relative paths, and instead created a patch that is minimally intrusive on the existing shim codebase so that it can be more easily reviewed as a standalone patch: https://github.com/ipxe/shim/commit/ba5d0f9c

mcb30 commented 7 months ago

Updated submission (rebase on shim-15.8, with all review comments addressed):

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/ipxe/shim-review/tree//ipxe-shim-x64-aa64-20240228

What is the SHA256 hash of your final SHIM binary?

shimx64.efi 909737489b19e1f95617ef24013e648656a2ff477fc8f9e163c253878f199234 shimaa64.efi 0c4eb9dedc34a0d62af67d21c2dc0f17cffeae5c3aff4ffe579b351138c88538

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

Continued in this issue, so as not to lose track of the fact that this submission has already been waiting over one year.

mcb30 commented 7 months ago

To sum it up, the application looks alright, and I'm looking forward to being amazed by the updated one for shim 15.8 - please, ping me ASAP once it's posted and I'll prioritize it.

@aronowski Thank you very much. Please find the updated submission above at https://github.com/rhboot/shim-review/issues/319#issuecomment-1967954690

aronowski commented 7 months ago

Reviewing with high priority as promised. Although had stuff going on in my life and was absent for about a week.

Good job writing the successes in the additional information section! :+1:
I hope it will allow the application to be approved faster, especially considering how long you've been waiting.

There's something weird - the README says that NX bit is set, but it actually isn't:

$ objdump -x shimx64.efi | grep DllCharacteristics
DllCharacteristics      00000000

I'd say that we should leave it not set and modify the README, as some bootloader chains may not be NX-compatible. For example when iPXE loads a shim without NX bit set.

Don't count on me here as the source of truth - better ask others as well.

Considering the updated patch, I have no competence in reviewing C code, but I do trust that it has been tested out thoroughly and that will be confirmed in another Microsoft Tech Community Hub entry.

Continued in this issue, so as not to lose track of the fact that this submission has already been waiting over one year.

:+1:

Although I wonder if it's possible to update the original post as well, so when new people come here, they will immediately be informed about the latest entry.