FOG and Secure Boot

[jfernandz]

Hi everyone,

I’ve been trying to follow this awesome tutorial (thank you to @george1421, btw ) because it looks promising, and I’ve got my setup partially working as I’m able to boot iPXE and refind, I’m even able to take an image of my added host, I’m able even to boot Windows from the firmware boot menu… However… the default entry in refind (“Boot from hard disk”) is not working, not sure what’s actually running this entry, … but it’s not able to boot the actual hard disk. In fact it has a weird behavior … because apparently that entry is trying to load refind, but you can see in this video it’s not able to fetch refind.conf.

Anyway … I’m a little bit confused … because if I press s to get into de iPXE shell, and run manually

imgfetch http://<my-fog-ip>/fog/service/ipxe/refind.conf
chain -ar http://<my-fog-ip>/fog/service/ipxe/refind_x64.efi

It seems to work… but I have again the very same menu. So … some idea about what could be happening or how may I debug this behavior?

Thank you very much!

PS: I’d suggest some minor fixes for @george1421 tutorial, but it’s a closed topic … so not sure if those might be fixed

[george1421]

@jfernandz Looking at your video, can you confirm that 172.120.1.4 is your fog server?

From your post it looks like “time” solves the problem, because you can repeat the same steps after a few seconds and it works??

If this is the case, intuition is telling me spanning tree issue. One network switches using standard spanning tree it take about 27 seconds to start forwarding the data while the switch ports listens for a BPU packet. This timer starts every time the network port “winks”, and it will “wink” (go down and up quickly) as each kernel starts (ipxe firmware, ipxe.efi, and then bzImage. To test this idea, get a dumb/umanaged/cheap network switch, like one of those 5 port monoprice switches. These do not support (typically) spanning tree. Place this switch between the pxe booting computer and the building network switch. See if this fixes this refind issue. -OR- contact your network infrastructure team to verify that one of the fast spanning tree protocols are configured on the port (portfast, fast-STP, RSTP, MSTP, etc). At this point I don’t think your issue has anything to do with secureboot.

[jfernandz]

Hi @george1421! Thank you for your answer

Well, I think the very same, so not sure if I should repeat the whole process (including FOG initial deployment/install), but sure, this wouldn’t seem a SecureBoot problem if it weren’t because of this setting in the firmware

I can see your firmware hasn’t that Secure Boot submenu, so … not sure how this could be interfering … but I’m having this issue when I set this in Deployed Mode. However, Audit Mode works as I expect, and … according to the description in my screenshot I’d say the proper value for production is Deployed Mode, and this should work in a very similar way Audit Mode does.

So not sure if this has something to do with some kind of network misconfiguration.

The most important fixes I’d suggest to your tutorial are the following, btw:

• You actually don’t need to mv dbx.esl dbx-fog.esl as you are not generating any dbx.esl, you cannot even run that command successfully as dbx.esl file doesn’t exist
• Also the param chain tftp:/${fog-ip}/EnrollKeys.efi for fog.keyenroll should actually be chain tftp://${fog-ip}/EnrollKeys.efi

Aside this … the tutorial is so helpful so … congratulations @george1421 and thank you a lot for your answer again.

[george1421]

@jfernandz said in FOG and Secure Boot:

You actually don’t need to mv dbx.esl dbx-fog.esl as you are not generating any dbx.esl, you cannot even run that command successfully as dbx.esl file doesn’t exist

I can’t believe I wrote that article in 2021, man time goes by quickly. The dbx file is created for black listed certificates. It is kind of an optional for the vendors to include in the firmware. The idea is if a secure boot certificate gets compromised the vendor can add it to that database. So I can see if the database is empty on the target system then the file might not get created. I should add a note into the document explaining this, thank you for the catch here.

For reference my notes say that I referenced this document as I was writing my document: https://wiki.gentoo.org/wiki/User:Sakaki/Sakaki's_EFI_Install_Guide/Configuring_Secure_Boot_under_OpenRC

Also the param chain tftp:/${fog-ip}/EnrollKeys.efi for fog.keyenroll should actually be chain tftp://${fog-ip}/EnrollKeys.efi

Thank you I will fix that.

[jfernandz]

@george1421 well, after some tests … The problem is apparently I have to sign also the refind_x64.efi binary, not sure if refind.efi is actually loading refind_x64.efi … but I’d suggest also to include this point in your tutorial. In fact I’m guessing you should also sign refind_ia32.efi and refind_aa64.efi as your whole environment could include also another archs.

Not sure if you’ll edit your tutorial with my suggestions … but I’ll write a little document for myself also … I think the signing process (with sbsign) may be automated in a bash script with a for loop, but your tutorial is still very valuable and helpful. This would be just a minor improvement. However … I think I’m going to write some script to try to automate the whole process, I could send it to you if you are interested in

Thank you again @george1421 and I hope you find also useful my suggestions

[jfernandz]

@george1421 oh, sure, I know the purpose of dbx.esl file, and sure … I guess it’s optional because usually you won’t need/want to include any certificate in your custom dbx.esl so you’re not even generating it … But if you’re not generating it … I don’t see necessary to explicitly include that mv in the guide, at least … I’d write explicitly that step is optional and it depends on you have generated the dbx.esl

But again … it’s up to you

[george1421]

@jfernandz said in FOG and Secure Boot:

The problem is apparently I have to sign also the refind_x64.efi binary, not sure if refind.efi is actually loading refind_x64.efi … but I’d suggest also to include this point in your tutorial. In fact I’m guessing you should also sign refind_ia32.efi and refind_aa64.efi as your whole environment could include also another archs.

You are correct I really missed the refind files. I will update that info too. While I had 1.6k viewers of the file not many people have returned comments. I have that turned off in the tutorial because it makes the multipart tutorial a bit messy because of the way the forum works.

I think the signing process (with sbsign) may be automated in a bash script

Towards the bottom of the document there is a bash script easter egg. I initially wrote the bash script then broke it up to explain what each part did. For those that never made it to the bottom of the post, they missed out on the bash script. I intentionally did it that way so people knew how it worked before they simply cut and pasted the script.