Make grub-ipxe work under UEFI

Bug #1811496 reported by Alkis Georgopoulos on 2019-01-12
12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
ipxe (Debian)
New
Unknown
ipxe (Ubuntu)
Medium
Unassigned

Bug Description

Please update /etc/grub.d/20_ipxe so that:
1) It uses ipxe.efi under UEFI, so that it works under UEFI as well, and
2) It loads /boot/boot.ipxe as an initrd if the user provided a custom ipxe script there.

Snippets - to be ran from /boot/grub/grub.cfg, as it's possible to dynamically switch bios/uefi in firmware settings:

if [ "$grub_platform" = "efi" ]; then
  chainloader /boot/ipxe.efi
else
  linux16 /boot/ipxe.lkrn
  if [ -f /boot/boot.ipxe ]; then
    initrd16 /boot/boot.ipxe
  fi
fi

Andreas Hasenack (ahasenack) wrote :

Sounds reasonable. Subscribing foundations, since it involves grub.

tags: added: rls-dd-incoming
Alkis Georgopoulos (alkisg) wrote :

Attaching a 20_ipxe that does what I mentioned. I tried to keep the .diff minimal, by reusing the IPXEPATH variable:

22,29c22
< if [ "\$grub_platform" = "efi" ]; then
< chainloader ${IPXEPATH%.lkrn}.efi
< else
< linux16 $IPXEPATH
< if [ -f ${IPXEPATH%.lkrn}.ipxe ]; then
< initrd16 ${IPXEPATH%.lkrn}.ipxe
< fi
< fi
---
> linux16 $IPXEPATH

tags: added: patch
Robie Basak (racb) on 2019-01-17
Changed in ipxe (Ubuntu):
importance: Undecided → Medium
Steve Langasek (vorlon) wrote :

Andreas, /etc/grub.d/20_ipxe appears to be a file shipped by the grub-ipxe package built from ipxe source, which is maintained by the server team. I think it's for you to decide if this is what you want, not foundations.

I would add the caveat that /boot/ipxe.efi will not be bootable on SecureBoot-enabled systems and this is not something that will be changed.

Alkis Georgopoulos (alkisg) wrote :

Note that this grub entry already shows up in UEFI and is not working at all (since it's just linux16).
So making it work under UEFI, even with secure boot disabled, is definitely an improvement.

Additionally, four days ago, the developer of ipxe mentioned on IRC that:
> (02:44:57 πμ) mcb30: I finally managed to get my new UEFI Secure Boot key registered with Microsoft's new UI
> (02:46:52 πμ) mcb30: As I'm about to start submitting https://github.com/ipxe/ProxyLoaderPkg for signing, I discover that the whole Coverity Scan service went offline last week, so I have no static analysis results to show for the submission

I believe that secure boot support in iPXE may take some time, but it'll be available eventually.

On Sun, Jan 20, 2019 at 10:53:22AM -0000, Alkis Georgopoulos wrote:

> Additionally, four days ago, the developer of ipxe mentioned on IRC that:
> > (02:44:57 πμ) mcb30: I finally managed to get my new UEFI Secure Boot
> > key registered with Microsoft's new UI
> > (02:46:52 πμ) mcb30: As I'm about to start submitting
> > https://github.com/ipxe/ProxyLoaderPkg for signing, I discover that the
> > whole Coverity Scan service went offline last week, so I have no static
> > analysis results to show for the submission

> I believe that secure boot support in iPXE may take some time, but it'll
> be available eventually.

Unless they're also doing reproducible binary builds, this is not relevant,
since the binary signed by Microsoft would not match what's in the Ubuntu
archive.

Alkis Georgopoulos (alkisg) wrote :

> Steve Langasek (vorlon) wrote on 2019-01-20:
I would add the caveat that /boot/ipxe.efi will not be bootable on SecureBoot-enabled systems and this is not something that will be changed.

Why can't Ubuntu sign the ipxe.efi binary during its build process, using the same key that it's using to sign vmlinuz? Too much hassle?
What if enough users request it, proving it's popular?

Steve Langasek (vorlon) wrote :

As discussed on IRC, we are not going to sign multiple bootloader implementations with the key because this would increase the attack surface of UEFI Secure Boot (which is already quite large, but signing multiple competing bootloader implementations would be an unforced error).

If there are features missing from grub, that should be addressed as a bug in grub.

We do publish a signed grub image suitable for netbooting use.
http://archive.ubuntu.com/ubuntu/dists/disco/main/uefi/grub2-amd64/current/grubnetx64.efi.signed

Alkis Georgopoulos (alkisg) wrote :

> If there are features missing from grub, that should be addressed as a bug in grub.

This is a list of network cards that iPXE supports:
https://github.com/ipxe/ipxe/tree/master/src/drivers/net

I don't think Grub would ever accept a "bug report" to include all the iPXE drivers in order to be able to cope with e.g. the following scenario:

"My onboard NIC failed/wasn't gigabit/whatever and I replaced it.
Of course my firmware doesn't know how to netboot the new NIC, so I need iPXE."

> signing multiple competing bootloader implementations

I.e. I don't think they're competing (iPXE calls itself "firmware", not "bootloader"); they have very different focus and cover different and in many cases complementary needs.

Of course I can respect the policy not to sign anything other than grub, though.
I will document the need to disable secure boot in the installations that will require iPXE.

Thank you for all the input!

Alkis Georgopoulos (alkisg) wrote :

We talked a lot about secure boot, so let me clarify that the initial issue, that my included patch addresses, is unrelated to secure boot.

The current grub-ipxe package hangs the computer under UEFI (with secure boot disabled), as it does "linux16 ipxe.lkrn".

With the patch, it will boot ipxe.efi fine.

This change doesn't involve the grub2 source package at all; grub-ipxe comes from the ipxe source package.

Steve Langasek (vorlon) wrote :

On Mon, Feb 04, 2019 at 09:51:11PM -0000, Alkis Georgopoulos wrote:
> We talked a lot about secure boot, so let me clarify that the initial
> issue, that my included patch addresses, is unrelated to secure boot.

> The current grub-ipxe package hangs the computer under UEFI (with secure
> boot disabled), as it does "linux16 ipxe.lkrn".

> With the patch, it will boot ipxe.efi fine.

> This change doesn't involve the grub2 source package at all; grub-ipxe
> comes from the ipxe source package.

Right, and I am not objecting to making this change to the ipxe packaging,
I'm simply pointing out the limitations (we have no plans to sign the
binary because it's redundant with our standard boot stack, so it won't work
on SecureBoot systems).

UEFI also has a built-in network stack and I've yet to encounter a UEFI
system with a network card that didn't have a UEFI driver, so I am doubtful
that ipxe even adds value here for the non-SB case.

Simon Quigley (tsimonq2) wrote :

Unsubscribing the Ubuntu Sponsors Team, as there are no debdiffs to sponsor.

Alkis Georgopoulos (alkisg) wrote :

I was thinking that the 20_ipxe code comes from Ubuntu, as grub-ipxe doesn't exist in Debian.
But on second look, it comes from the Debian's ipxe package.
So I've filed https://bugs.debian.org/927783 and I'm marking this issue as "invalid";
I believe that the fix will reach Ubuntu with some future import from Debian.

Changed in ipxe (Ubuntu):
status: New → Invalid
Brian Murray (brian-murray) wrote :

The bug is still valid in Ubuntu regardless of where the code comes from, subsequently I'm reopening the task and adding a bug watch for the debian bug.

Changed in ipxe (Ubuntu):
status: Invalid → Triaged
Changed in ipxe (Debian):
status: Unknown → New
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Patches

Remote bug watches

Bug watches keep track of this bug in other bug trackers.