Make grub-ipxe work under UEFI

Sounds reasonable. Subscribing foundations, since it involves grub.

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

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.

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.

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

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

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

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.

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.

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

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.

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.

Passing by this bug after 180 days of no activity, no changes.

Yeah it's ready for upload but no Debian or Ubuntu developer seems to have time to upload it. :)

:-/

I have pinged on the Debian bug and took a note in the task that I have to merge a new ipxe for Ubuntu 20.04.
Thereby I'd hope that one or another way it should get into 20.04 at least.

I don't know if it helps, but I uploaded it as a merge proposal too:

https://code.launchpad.net/~alkisg/ubuntu/+source/ipxe/+git/ipxe/+merge/376817

It'd be nice to have it fixed for Focal, yeah. The new LTSP supports UEFI clients, so many people will use it.

Another issue was that 20_ipxe didn't call save_default_entry, to save the selected grub entry for subsequent reboots.

Since it was only a 2-line diff in the same spot, I added it as a second commit.

I also built the package in https://code.launchpad.net/~ts.sch.gr/+recipe/ipxe in case anyone needs it for previous Ubuntu versions.

Posted comments on:

https://salsa.debian.org/waldi/ipxe/merge_requests/1
https://code.launchpad.net/~alkisg/ubuntu/+source/ipxe/+git/ipxe/+merge/376817

"""
I have tested this change and it makes total sense. I haven't created a PXE boot entirely, but, instead, I sniffed the virtio interface of the VM using the EFI menu entry:

19:29:32.878687 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:dd:d0:18, length 406
19:29:32.878741 IP6 fe80::5054:ff:fedd:d018 > ff02::2: ICMP6, router solicitation, length 16
19:29:32.878768 IP6 fe80::216:3eff:fe3f:8b66 > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has ::, length 32
19:29:32.878777 IP6 fe80::216:3eff:fe80:bcd9 > ff02::1:ff00:0: ICMP6, neighbor solicitation, who has ::, length 32
19:29:32.878891 IP 10.250.99.1.67 > 10.250.99.220.68: BOOTP/DHCP, Reply, length 300
19:29:33.144534 IP6 fe80::5054:ff:fedd:d018 > ff02::2: ICMP6, router solicitation, length 16
19:29:33.693789 IP6 fe80::5054:ff:fedd:d018 > ff02::2: ICMP6, router solicitation, length 16
19:29:33.913529 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:dd:d0:18, length 406
19:29:33.913714 IP 10.250.99.1.67 > 10.250.99.220.68: BOOTP/DHCP, Reply, length 300
19:29:34.737371 IP6 fe80::5054:ff:fedd:d018 > ff02::2: ICMP6, router solicitation, length 16
19:29:35.945745 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 52:54:00:dd:d0:18, length 418
19:29:35.945973 IP 10.250.99.1.67 > 10.250.99.220.68: BOOTP/DHCP, Reply, length 300
19:29:35.946042 ARP, Request who-has 10.250.99.220 tell 10.250.99.220, length 28
19:29:36.769615 IP6 fe80::5054:ff:fedd:d018 > ff02::2: ICMP6, router solicitation, length 16
19:29:40.432536 IP6 fe80::216:3eff:fe3f:8b66 > ff02::2: ICMP6, router solicitation, length 16
19:29:40.834099 IP6 fe80::5054:ff:fedd:d018 > ff02::2: ICMP6, router solicitation, length 16
19:29:41.033953 ARP, Request who-has 10.250.99.220 tell 10.250.99.1, length 28
19:29:41.034082 ARP, Reply 10.250.99.220 is-at 52:54:00:dd:d0:18, length 30

And it got the IP but no file was offered (As I didnt offer one).

One thing to notice:

I had serial=console in my grub and it doesn't work with ttyS0 as output (I know its obvious, but, it looked like it didnt work in my setup in an initial look). After having a VNC graphics set, I could see the iPXE 20190109.133f4c47-0ubuntu3 (the version I created) in the console before the PXE attempt.
"""

I'm merging this fix together with fix for: LP: #1858374 in a new merge request, respecting credits, and link it here.

Current merge:

https://code.launchpad.net/~rafaeldtinoco/ubuntu/+source/ipxe/+git/ipxe/+merge/377540

Previous merge:

https://code.launchpad.net/~alkisg/ubuntu/+source/ipxe/+git/ipxe/+merge/376817

Related Bugs:

https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/1811496
https://bugs.launchpad.net/ubuntu/+source/ipxe/+bug/1858374

A PPA containing the binary package can be found at:

https://launchpad.net/~rafaeldtinoco/+archive/ubuntu/lp1858374

There is a MR already for this in salsa but it hasn't been looked yet. I have sent out a debdiff containing fixes for this bug AND LP: #1858374 altogether in:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=927783

This bug was fixed in the package ipxe - 1.0.0+git-20190109.133f4c4-0ubuntu3

---------------
ipxe (1.0.0+git-20190109.133f4c4-0ubuntu3) focal; urgency=medium

  [Alkis Georgopoulos]
  * d/tree/ipxe/etc/grub.d/20_ipxe: Make grub-ipxe work under UEFI
    (LP: #1811496)
    - Use ipxe.efi under UEFI
    - Save default entry when iPXE is selected
  [Sharon Dagan]
  - d/tree/ipxe/etc/grub.d/20_ipxe: Identify ipxe grub menu entry in
    an easier way (LP: #1858374)

 -- Rafael David Tinoco <email address hidden> Mon, 06 Jan 2020 18:59:25 +0000