Hi all,
Let’s assume that legacy boot and UEFI boot provisioning are functioning fine. I have attempted to enable secure boot on several systems - Dell 7720 Laptop, HP Z8 Workstation, etc. These all provision wonderfully with plain UEFI, but when secureboot is enabled and the grub2 uefi secureboot pxe template is selected, they fail.
Thanks!
Ok so maybe I’ve found where I’m making all the right connections.
Under Create Host / Operating System…
What template does that ^^^^ refer to? I have no provisioning template on my system that mentions SecureBoot. I checked the community templates repo and there doesn’t seem to be any reference to such a template there either.
Is this what’s messed up? Do I need to manually make a new grub2 uefi template that connects to this menu entry?
When you provision the host, on the Operating System tab there’s a “PXE loader” option - choose Grub2 UEFI SecureBoot. It’s not a provisioning template itself, it’s just setting the name of the filename used by DHCP.
Aha! So, every time I need to provision a secureboot system, I need to change the boot loader in the dhcp config? I’m not managing dhcp with Foreman, unfortunately.
If you’re using ISC DHCP, you can configure it to specify the filename based on the kind of client, and you can detect if it’s an UEFI PXE boot. There’s an example DHCP config on https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/installation_guide/s1-netboot-pxe-config-efi, look at the pxeclients class.
Ok, so I have shim.efi as the boot file in dhcp already. I believe that’s the correct file, though it seems to work when not securebooting too if that matters.
Still, I get an untrusted error on a blue screen after showing the pxe download of shim.efi, but before the grub menu should present. That said, if I switch to grubx64.efi, the system doesn’t get that far before showing a different more bios like message saying that it’s not trusted.
I’m not sure what’s really the problem.
Ok more detail on the environment…
Foreman and tftpd is on a CentOS 7.5 VM. shim-x64 is installed. The shim.efi file in /var/lib/tftpboot/grub2 matches the md5sum of the same file /boot/efi/EFI/centos. According to pesign, the shim.efi file is signed by Microsoft Windows UEFI Driver Publisher.
Regarding the error conditions…
Attempting to provision an HP Z8 workstation (with whatever HP’s bios is), I have secureboot enabled. DHCP server provides grub2/shim.efi as the pxe filename. Boot the system, select F12 for network boot. I get a white BIOS screen with HP logo and two NICs to boot from, I select the correct one. Screen goes black I see the PXE process flash in white text and the full screen turns blue with a gray text message that says “ERROR Verification Failed: (15) Access Denied” and an OK button in the center of the screen.
The tftpd logs show RRQ for grub2/shim.efi and a 2nd RRQ for grub2/grubx64.efi and that’s it. There are no logs for downloading the grub-cfg- file.
Is your grubx64.efi the same one from /boot/EFI that comes with the grub2-efi-x64 package? At some point Foreman built it’s own with grub-mkimage which wasn’t signed, depending on the version of Foreman you have.
@stbenjam it seems to be as you say. The /boot/efi/EFI/centos/grubx64.efi file has a different checksum than what is deployed in /var/lib/tftboot/grub2. Also, according to pesign, the /boot version is signed by Red Hat, whereas the tftp version is not signed at all.
I have backed up the original and replaced it with the signed version and am now able to see the typical grub2 pxeboot menu.
Thank you for pointing that out. I should note that this particular foreman server was brand new as of April 2018, there shouldn’t be much cruft from old foreman versions lying around.
Great thanks for letting me know… that code was merged a while ago, https://github.com/theforeman/puppet-foreman_proxy/commit/3c11b38f76680f9363971b490cbc6cf2838a7aab - but I’ll take a look, maybe there’s something still hanging around that’s doing a mkimage.
RHEL 7.4 introduced a regression that broke PXE building with Grub2, and there was a workaround introduced that returned to using mkimage on 7.4 or later, which produces unsigned images.
I’ve opened a PR to fix that for 7.5 and later.
Great analysis, thanks for the fix Stephen!
It is worth mentioning that our SecureBoot support is Red Hat only, AFAIK Debian is still WIP: