Error when using Shim (at least) 15.8 and DHCP Option 67 with non-Microsoft DHCP server

[MarkusSpier]

When attempting to boot Shim version 15.8 via DHCP and Option 67, an error occurs. In conjunction with a non-Microsoft DHCP server, the path is set incorrectly.

For example, if you set the path in Option 67 to: <some_directory>\shim_x64.efi so that it should look for grub2 in a subfolder, an error occurs. Grub2 is incorrectly requested directly from the root directory without the subfolder.

The error seems to occur because, with Option 67 set, the filename from the header is still used. If this is empty, subsequent requests are always made without the subfolder!

Since Microsoft DHCP apparently also sets the header by default when setting Option 67, this error is not observed here. However, if you use, for example, IPFire DHCP and only set Option 67 (here "option bootfile-name"), the header (here "filename") remains empty.

Actually, Shim should use the path set in Option 67 and not the one from the header in this scenario!

This error does not occur in an older version (15.4). It must have been introduced between 15.4 and 15.8.

Is this error known and will it be fixed in the next version?

Example in Microsoft DHCP:

Example in IPFire DHCP:

If you set here only the option 67, the error occurs. If you set also the header (filename) it works (like in this image)

[dennis-tseng99]

As you know, DHCP OFFER or ACK option 66 and 67 will provide the exact shim.efi location. To make sure IPFire DHCP server can generate the correct option 67, would you please capture and show the content of option 67 by using Wireshark(for example) when sending OFFER or ACK message out ?

Typically grub.efi located in the same directory where shim.efi resides.
Would you please list files under subfolder directory ?

[MarkusSpier]

@dennis-tseng99

The files in the subfolder are only the shim and the grub as you can see:

Here is wireshark:

The file that is requested is located in the subfolder, and in IPFire configured only as "option bootfile-name" WITH the subfolder. As soon as you also configure the "filename" the same as the "option bootfile-name", the request will be send including the subfolder.

Many of our customers with NON Microsoft DHCP servers have this problem after they updated to the new shim version. So we think, this is a common thing to NOT configure the filename option. But on Microsoft DHCP serves, as they set this option as default (as I mentiont in my first post) it works all fine.

[dennis-tseng99]

In your Wireshark, the Read Request(line 109) of TFTP reveals that the option 67 in OFFER message sent from IPFire server has successfully received and offered the subfolder \bblefi-x64\shim-x64.efi information. But after that, the firmware provides an incorrect virtual file system to the PXE. Hence, shim fallbacks to DEFAULT_LOADER(root directory) which is included in built time. Anyway, did you change the firmware version between shim-15.4 and 15.8 ? Is grub2_x64.efi accessible ?

[MarkusSpier]

No, the firmware is the same. Also, many of our customers run into this problem after updating to the new shim version and they using the same environment as before. Same hardware and so on.
If you use the old shim version, there is no problem. Also, if you set the "filname" in IP-Fire, there is no problem.

So, we think that this is a bug in shim and not a problem with firmware as "all" firmware seems to behaves like this. This is the case in VMs and on hardware.

[MarkusSpier]

@dennis-tseng99 Perhaps, I can clarify this by provide you this snippets.
So, as you can see here, the option 67 is set properly to the right filename BUT, the Bootfilename field is empty:

This is the offer, but it is the same behavior in ACK, the bootfilename field does not contain any value.

When the bootfilename is empty, as in the screenshot shown, the grub is requested in the wrong directory. It should be requested in the directory given in the option 67. When we set the bootfilename explicitly in the header with the same value as option 67, shim will request the grub correctly.

Can you confirm that this is a bug in the shim or by design?

[dennis-tseng99]

@MarkusSpier Some DHCP clients can work with opt-67 correctly, but some legal clients do NOT conform the DHCP standard who only read boot file name(BOOTP header) and skip option 67, specific in grub2:

https://github.com/rhboot/grub2/commit/93289dc67c7e213b21df0eb09afea5e3b00ad7df#diff-93cd75cf8712d66c15ae5885f7cac5dae3531aaef211a17ef9885eb443ecdb0b

For debug purpose, you could print ImagePath and PathName in read_image() to make sure shim can get the correct opt-67 to get grub.