iPXE shim (new submission)

[mcb30]

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

UPDATED: see below at #319 (comment)

---

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]

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

[dennis-tseng99]

• 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 
[1/2] STEP 1/8: FROM docker.io/ipxe/shimbuilder:2b4a7c74c0b1c44d4da35bd73d079783d6e8e636-4138665917-1 AS build-only
Trying to pull docker.io/ipxe/shimbuilder:2b4a7c74c0b1c44d4da35bd73d079783d6e8e636-4138665917-1...
Getting image source signatures
Copying blob 7778c55b9bda done  
Copying blob 17bf1f429488 done  
Copying config 01b3509b1f done  
Writing manifest to image destination
Storing signatures
[1/2] STEP 2/8: ARG SHIM_TAG
--> 8a54efcf815
[1/2] STEP 3/8: RUN git clone --depth 1 --recurse-submodules --shallow-submodules     https://github.com/ipxe/shim --branch ${SHIM_TAG}
Cloning into 'shim'...
fatal: unable to access 'https://github.com/ipxe/shim/': Could not resolve host: github.com
Error: building at STEP "RUN git clone --depth 1 --recurse-submodules --shallow-submodules     https://github.com/ipxe/shim --branch ${SHIM_TAG}": while running runtime: exit status 128

• So, I built x64.efi & aarch64.efi step by step:

shim-review]# sha256sum /{built,submitted}/shim{x64,aa64}.efi | sort -t / -k 3
be492d53adff1720e130347a68fb1df3231b7bce824ef3d41cdb311b26d2e024  /built/shimaa64.efi
be492d53adff1720e130347a68fb1df3231b7bce824ef3d41cdb311b26d2e024  /submitted/shimaa64.efi
26ec898a8e801fceafec29577386286687efe55d68fa96dc068adb4f5f02060e  /built/shimx64.efi
26ec898a8e801fceafec29577386286687efe55d68fa96dc068adb4f5f02060e  /submitted/shimx64.efi

• sha256sum hash values are matched for shimx64.efi and shimaa64.efi respectively.
• x64 sbat section looks good:

 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 69707865 2c312c69  im.shim.ipxe,1,i
 d1090 5058452c 7368696d 2c312c68 74747073  PXE,shim,1,https
 d10a0 3a2f2f67 69746875 622e636f 6d2f6970  ://github.com/ip
 d10b0 78652f73 68696d0a                    xe/shim.

• x64 sbatlevel section looks good:

 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..

• aa64 sbat section looks good:

 d4010 696f6e2c 73626174 2c312c68 74747073  ion,sbat,1,https
 d4020 3a2f2f67 69746875 622e636f 6d2f7268  ://github.com/rh
 d4030 626f6f74 2f736869 6d2f626c 6f622f6d  boot/shim/blob/m
 d4040 61696e2f 53424154 2e6d640a 7368696d  ain/SBAT.md.shim
 d4050 2c332c55 45464920 7368696d 2c736869  ,3,UEFI shim,shi
 d4060 6d2c312c 68747470 733a2f2f 67697468  m,1,https://gith
 d4070 75622e63 6f6d2f72 68626f6f 742f7368  ub.com/rhboot/sh
 d4080 696d0a73 68696d2e 69707865 2c312c69  im.shim.ipxe,1,i
 d4090 5058452c 7368696d 2c312c68 74747073  PXE,shim,1,https
 d40a0 3a2f2f67 69746875 622e636f 6d2f6970  ://github.com/ip
 d40b0 78652f73 68696d0a                    xe/shim.

• aa64 sbatlevel section looks good:

 88000 00000000 08000000 22000000 73626174  ........"...sbat
 88010 2c312c32 30323230 35323430 300a6772  ,1,2022052400.gr
 88020 75622c32 0a007362 61742c31 2c323032  ub,2..sbat,1,202
 88030 32313131 3530300a 7368696d 2c320a67  2111500.shim,2.g
 88040 7275622c 330a00                      rub,3.. 

[mcb30]

• 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. 🙏

[mcb30]

@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]

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 rhboot/shim@7c76425 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]

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]

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]

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]

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]

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]

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]

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 🙂

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]

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]

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]

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]

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]

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]

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]

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:

• Yes, we accept signing a shim for the iPXE upstream project for default iPXE builds
• Other vendors should not be signing iPXE for use with their shim
• 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.
• Linux distros will continue implementing network boot use cases using grub.

[mcb30]

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

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?

[stappersg]

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

[uranus829]

@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]

Another attempt to get this issue on the agenda by partial qouting #319 (comment)

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

[kfortner]

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]

@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]

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.

[mcb30]

Looks good, accepting!

@steve-mcintyre Thank you very much for reviewing and accepting!

Niggles:

• There's plenty of discussion in the issue about the NX bit. The
  final statement here is that the NX bit is not set, but your
  README.md still says it is. Not a blocker, just raising this as a
  minor nit!

Oh dear. 😵‍💫 I'm sorry if I missed updating that. Where did you find it documented as still being set? In the tagged version of README.md at https://github.com/ipxe/shim-review/tree/ipxe-shim-x64-aa64-20240306?tab=readme-ov-file#do-you-have-the-nx-bit-set-in-your-shim-if-so-is-your-entire-boot-stack-nx-compatible-and-what-testing-have-you-done-to-ensure-such-compatibility I see:

No, the NX bit is not set.

While it is believed that the shim+iPXE boot stack is NX-compatible (and the iPXE binary is already built with the NX bit set),
we do not intend to set the NX bit in the shim until it is set by default in the shim release.

[steve-mcintyre]

Apologies - that's my mistake. I didn't have the latest update to the README.md from 24c6d6c.

All good then! 👍

[mcb30]

For anyone wanting to track progress: this has now been submitted to Microsoft for Secure Boot signing (with submission number 13887439201546611).

[raddirad]

Purely out of curiosity.
Does this acceptance mean that other project could use iPXE instead of Grub for things that Grub currently can't do?
As mentioned earlier for example wimboot or boot via HTTPS

[mcb30]

Purely out of curiosity. Does this acceptance mean that other project could use iPXE instead of Grub for things that Grub currently can't do? As mentioned earlier for example wimboot or boot via HTTPS

Once the shim is signed by Microsoft, then yes. The intention is to release the signed shim, and then to make regular releases of some standard builds of iPXE signed by the EV certificate in the shim.

[raddirad]

Once the shim is signed by Microsoft, then yes. The intention is to release the signed shim, and then to make regular releases of some standard builds of iPXE signed by the EV certificate in the shim.

The intention of me asking is for example create an own build of iPXE with an embedded CA, sign the kernel with this cert and boot it via HTTPS

[mcb30]

The intention of me asking is for example create an own build of iPXE with an embedded CA, sign the kernel with this cert and boot it via HTTPS

Two issues with that:

• You would not be able to create your own build of iPXE that would be signed by the EV certificate present in the public iPXE shim, since you do not have access to the iPXE project's EV certificate's private key. You would need to get your own iPXE shim signed by Microsoft.

• iPXE uses the UEFI firmware's LoadImage() call to load the kernel, and so your loaded kernel needs to independently satisfy your firmware's Secure Boot policy. (There is a separate capability in iPXE for using embedded CA certificates to verify CMS-signed files, but this exists independently of Secure Boot.)

The expected usage pattern is that a Linux boot will involve the following steps:

1. UEFI firmware downloads and executes the Microsoft-signed iPXE shim (i.e. the subject of this GitHub issue) as e.g. ipxe-shimx64.efi
2. The Microsoft-signed iPXE shim automatically downloads and execute the iPXE-signed published iPXE binary (e.g. ipxe.efi).
3. The user's iPXE script directs iPXE to download a distro kernel (vmlinuz), shim (shimx64.efi), and initramfs (initrd.img)
4. iPXE executes the distro kernel via the distro shim

[steve-mcintyre]

@mcb30 Argh, apologies - just noticed one thing I missed on my review (and clearly so did others :-( )...

You're embedding a PEM-encoded certificate in your build, which can't work. It needs to be DER-encoded.

Sorry, should have noticed this much earlier.

[steve-mcintyre]

@mcb30 I'm surprised you didn't see this in testing, tbh...

[mcb30]

@mcb30 Argh, apologies - just noticed one thing I missed on my review (and clearly so did others :-( )...

You're embedding a PEM-encoded certificate in your build, which can't work. It needs to be DER-encoded.

Sorry, should have noticed this much earlier.

Great catch, thank you for spotting that! This slipped through testing because the test environment, of course, was using test certificates rather than the real EV certificate, and the test certificate was correctly encoded as DER.

I'll update the submission now: give me 15 minutes for everything to propagate through...

[mcb30]

Updated submission (previously #319 (comment), fixed to use DER-encoded certificate and README.md updated as noted in #319 (comment)):

---

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

---

What is the SHA256 hash of your final SHIM binary?

---

shimx64.efi 636d581943f1872d4eb17af39b3b7e07ed8dfc5ec5e85779550fa2c01fa3aeae
shimaa64.efi 986978b520a3b159f74da9e16939aac6a986b8467f6f41929e4d94ef87863ad0

---

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]

@steve-mcintyre Everything updated. Sorry it took so long: it's a very manual process dealing with all of this automation. 🙃

Could you please recheck and re-add the "accepted" label? 🙏

[steve-mcintyre]

Cool, all looks good with that change. Accepted.

[mcb30]

Cool, all looks good with that change. Accepted.

Thank you. Resubmitted to Microsoft as UEFI signing submission 14306281433235827.

[stappersg]

What I understand from https://learn.microsoft.com/en-us/windows-hardware/drivers/dashboard/file-signing-manage#view-uefi-or-lsa-submission-details are some credentials needed to see the status.

Some one with such credentials, please update this issue with that status.

[steve-mcintyre]

Hey folks, did you get a signed shim here yet please?

[mcb30]

Discussions with Microsoft are still ongoing. Next meeting is currently scheduled for late June.

[steve-mcintyre]

Hey! Did you make any progress there?

[mcb30]

Yes, we had one meeting in late June and another today. The reception has been generally positive, we have clarified a lot of details about the usage policies for the iPXE shim, and we're hoping to get to a final green light within the next month or two.

[stappersg]

On Tue, Jul 16, 2024 at 02:15:04PM -0700, Michael Brown wrote: ... and we're hoping to get to a final green light within the next month or two.

Off by one, by now

[mcb30]

Still ongoing, just very slowly. The next call with Microsoft has been deferred multiple times due to availability constraints, and we're currently looking at October 31st.

[admvir2oz]

Still ongoing, just very slowly. The next call with Microsoft has been deferred multiple times due to availability constraints, and we're currently looking at October 31st.

Hi. Is there anything to please you with?

[mcb30]

As an update: we are still waiting on Microsoft. This seems to be a permanent state of affairs. 😞

[skyblaster]

As someone who has been following this for some time, I'm incredibly disappointed.
It's clearly possible to get the latest version signed as seen here: https://knowledge.broadcom.com/external/article/280113/updated-64bit-ipxeefi-ipxe-v1211+-binari.html

Is there anything we can do as a community to help escalate this issue?

[mcb30]

Is there anything we can do as a community to help escalate this issue?

Honestly, I don't know. Please feel free to reach out to Microsoft via any commercial support route that your company may have in place, to indicate that this is something you would like to see happen.

[admvir2oz]

Ok, it's a pity that Microsoft doesn't want to make contact yet. Is it possible to make a signed bootloader work with my configuration file? I'm trying to put autoexec.ipxe next to snponly.efi, but the configuration file is not picked up. чт, 21 нояб. 2024 г. в 03:29, Jason Berry ***@***.***>:

…

As someone who has been following this for some time, I'm incredibly disappointed. It's clearly possible to get the latest version signed as seen here: https://knowledge.broadcom.com/external/article/280113/updated-64bit-ipxeefi-ipxe-v1211+-binari.html Is there anything we can do as a community to help escalate this issue? — Reply to this email directly, view it on GitHub <#319 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQWQIO447T3YXU4FEDD6VX32BUZPHAVCNFSM6AAAAAAU73EWGCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIOBZHA3TQOBQHE> . You are receiving this because you commented.Message ID: ***@***.***>

[mcb30]

Ok, it's a pity that Microsoft doesn't want to make contact yet. Is it possible to make a signed bootloader work with my configuration file? I'm trying to put autoexec.ipxe next to snponly.efi, but the configuration file is not picked up.

Yes, the eventual idea is that a signed (or shim-signed) iPXE binary will pick up autoexec.ipxe so that you can customise behaviour without needing to create a new iPXE binary (which would necessarily not be signed).

If you are trying to use a signed iPXE binary provided by a third party such as Broadcom, then that is completely unsupported since we have no idea what went into their iPXE binary.