Add support for kernels compiled with CONFIG_EFI_ZBOOT

Bug #2002226 reported by Heinrich Schuchardt
14
This bug affects 1 person
Affects Status Importance Assigned to Milestone
grub2 (Ubuntu)
Fix Released
Medium
Unassigned
Focal
Invalid
Undecided
Unassigned
Jammy
Invalid
Undecided
Unassigned
Lunar
Invalid
Undecided
Unassigned
grub2-unsigned (Ubuntu)
Fix Released
Medium
Mate Kukri
Focal
Invalid
Undecided
Mate Kukri
Jammy
Invalid
Undecided
Mate Kukri
Lunar
Invalid
Undecided
Mate Kukri
linux (Ubuntu)
Fix Released
Wishlist
Unassigned
Focal
Invalid
Undecided
Unassigned
Jammy
Invalid
Undecided
Unassigned
Lunar
Invalid
Undecided
Unassigned

Bug Description

[Impact]
Arm64 kernels compiled with CONFIG_EFI_ZBOOT=y don't use the ARM64_IMAGE_MAGIC ('ARM\x64') but LINUX_PE_MAGIC (0x818223cd) in the PE Header. Our GRUB fails to boot such a kernel.

We should eliminate the following check:

grub-core/loader/efi/linux.c:75:
  if (lh->magic != GRUB_LINUX_ARCH_MAGIC_SIGNATURE)
    return grub_error(GRUB_ERR_BAD_OS, "invalid magic number");

This will allow any EFI binary to be run using the linux command.

[Test plan]
* check that grub and EFI based ARM64 machines boot
* check that MAAS deployment works

[Where problems could occur]
* Non-EFI bootloaders want to boot with regular vmlinuz.gz. If one is using piboot, u-boot, abootimg likely one still wants to build Image.gz and have CONFIG_EFI_ZBOOT disabled.

Revision history for this message
Heinrich Schuchardt (xypron) wrote :

See upstream patch
69edb3120560 ("loader/arm64/linux: Remove magic number header field check")
by Ard Biesheuvel

affects: grub2 (Ubuntu) → grub2-unsigned (Ubuntu)
description: updated
Revision history for this message
Julian Andres Klode (juliank) wrote :

I'm not sure this is correct, fwiw, we do not use the upstream arm64 loader but the rhboot loader, which calls into the kernel using just:

  hf = (handover_func)((char *)kernel_addr + handover_offset + offset);
  hf (grub_efi_image_handle, grub_efi_system_table, kernel_params);

I see it got merged in https://github.com/rhboot/grub2/commit/71d05e4b19d62dc35e79c92732b5405e6bd24b71 but I'm not sure if we need any other patches too.

Revision history for this message
Heinrich Schuchardt (xypron) wrote (last edit ):

Obviously this rhboot code assuming a fixed offset to the kernel entry point is not UEFI compliant.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

Reading our grub code, I believe this needs to be a dual fix:
1) fix arm64 secureboot code path
2) fix riscv64 non-secureboot code path

(separtely in mattermost Need to merge https://github.com/rhboot/grub2/commit/9752abcb38119b8fa52ba06e651e220c750e26c1 I think was also mentioned by juliank)

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

This is resolved correctly in grub2-2.12~rc1. Once that hits mantic, we will be able to upgrade most of our arm64 kernels to that (generic, cloud).

Kernels that use u-boot (direct), abootimg, piboot will have to stay as they are - unless they gain zboot image format boot support.

summary: - Support for kernels compiled with CONFIG_EFI_ZBOOT
+ Add support for kernels compiled with CONFIG_EFI_ZBOOT
Revision history for this message
Dimitri John Ledkov (xnox) wrote :
Changed in linux (Ubuntu):
importance: Undecided → Wishlist
Changed in grub2-unsigned (Ubuntu):
importance: Undecided → Medium
Changed in grub2 (Ubuntu):
importance: Undecided → Medium
Changed in linux (Ubuntu):
status: New → Triaged
Changed in grub2-unsigned (Ubuntu):
status: New → Triaged
Changed in grub2 (Ubuntu):
status: New → Triaged
Revision history for this message
Heinrich Schuchardt (xypron) wrote (last edit ):

>> Kernels that use u-boot (direct), abootimg, piboot will have to stay as they are - unless they gain zboot image format boot support.

Hello Dimitri,

zboot kernels are regular EFI binaries. Where did you see problems in booting them with U-Boot's bootefi command?

Best regards

Heinrich

tags: added: patch
Revision history for this message
Julian Andres Klode (juliank) wrote :

This should be fixed in our 2.12 builds.

Changed in grub2-unsigned (Ubuntu):
status: Triaged → Fix Released
Changed in grub2 (Ubuntu):
status: Triaged → Fix Released
description: updated
description: updated
Mate Kukri (mkukri)
Changed in grub2-unsigned (Ubuntu):
assignee: nobody → Mate Kukri (mkukri)
Mate Kukri (mkukri)
Changed in grub2-unsigned (Ubuntu Focal):
assignee: nobody → Mate Kukri (mkukri)
Mate Kukri (mkukri)
Changed in grub2-unsigned (Ubuntu Jammy):
assignee: nobody → Mate Kukri (mkukri)
Changed in grub2-unsigned (Ubuntu Lunar):
assignee: nobody → Mate Kukri (mkukri)
Revision history for this message
Mate Kukri (mkukri) wrote :

Do we use ZBOOT kernels anywhere in old releases where this is really necessary?

Is this something we really want in older GRUBs at all?

Removing the magic number check is easy enough, but I am not sure of the ramifications of allowing random signed EFI binaries through the linux codepath with those old loaders.

Revision history for this message
Dimitri John Ledkov (xnox) wrote :

@mate I agree with that concern w.r.t. sending random pe binaries to linux code path.

Separately in Mantic we are reverting zimg boot image format. Kernel itself fails to kexec it correctly. And mantic kexec tools do not support this image format correctly. Thus at this point grub 2.12 has best support for this anyway. And kernel itself & kexec-tools need work. If/when this gets re-enabled again, breaks will be used to ensure that grub2 of better than 2.12 is desired to get this going again, likely in 24.04.

Changed in linux (Ubuntu):
milestone: none → later
Changed in linux (Ubuntu Focal):
status: New → Invalid
Changed in linux (Ubuntu Jammy):
status: New → Invalid
Changed in linux (Ubuntu Lunar):
status: New → Invalid
Changed in grub2-unsigned (Ubuntu Focal):
status: New → Invalid
Changed in grub2-unsigned (Ubuntu Jammy):
status: New → Invalid
Changed in grub2-unsigned (Ubuntu Lunar):
status: New → Invalid
Changed in grub2 (Ubuntu Focal):
status: New → Invalid
Changed in grub2 (Ubuntu Jammy):
status: New → Invalid
Changed in grub2 (Ubuntu Lunar):
status: New → Invalid
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 6.5.0-7.7

---------------
linux (6.5.0-7.7) mantic; urgency=medium

  * mantic/linux: 6.5.0-7.7 -proposed tracker (LP: #2037611)

  * kexec enable to load/kdump zstd compressed zimg (LP: #2037398)
    - [Packaging] Revert arm64 image format to Image.gz

  * Mantic minimized/minimal cloud images do not receive IP address during
    provisioning (LP: #2036968)
    - [Config] Enable virtio-net as built-in to avoid race

  * Miscellaneous Ubuntu changes
    - SAUCE: Add mdev_set_iommu_device() kABI
    - [Config] update gcc version in annotations

 -- Andrea Righi <email address hidden> Thu, 28 Sep 2023 10:19:24 +0200

Changed in linux (Ubuntu):
status: Triaged → Fix Released
Benjamin Drung (bdrung)
tags: removed: foundations-todo
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote :

This bug is awaiting verification that the linux-azure-6.5/6.5.0-1007.7~22.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-azure-6.5' to 'verification-done-jammy-linux-azure-6.5'. If the problem still exists, change the tag 'verification-needed-jammy-linux-azure-6.5' to 'verification-failed-jammy-linux-azure-6.5'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: kernel-spammed-jammy-linux-azure-6.5-v2 verification-needed-jammy-linux-azure-6.5
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote :

This bug is awaiting verification that the linux-aws-6.5/6.5.0-1008.8~22.04.1 kernel in -proposed solves the problem. Please test the kernel and update this bug with the results. If the problem is solved, change the tag 'verification-needed-jammy-linux-aws-6.5' to 'verification-done-jammy-linux-aws-6.5'. If the problem still exists, change the tag 'verification-needed-jammy-linux-aws-6.5' to 'verification-failed-jammy-linux-aws-6.5'.

If verification is not done by 5 working days from today, this fix will be dropped from the source code, and this bug will be closed.

See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you!

tags: added: kernel-spammed-jammy-linux-aws-6.5-v2 verification-needed-jammy-linux-aws-6.5
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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