Description

ReLIFE9527

opened on Aug 25, 2020

Issue body actions

Phenomenon

This happened in the implementation of LinuxBoot on QEMU-ARM64.
When I replace UEFI shell with my Linux kernel Image, I found a weird Phenomenon:

Succeed:  UEFI(DT) ------> Kernel+U-root (Image) ---kexec---> Ubuntu

Fail: UEFI(ACPI) ------> Kernel+U-root (Image) ---x---> Ubuntu

Succeed: UEFI(ACPI) --grub--> Ubuntu --kexec--> Kernel+U-root (Image) --kexec--> Ubuntu

• The UEFI -->Kernel+U-Root means UEFI directly boot Kernel after BDS phase by EFI_stub.
• When I used the UEFI that use ACPI to config kernel, the first kernel would fail to boot Ubuntu by kexec, without any message.
• But when I first boot Ubuntu, then boot my little kernel ( I put the kernel Image in a virtual disk so Ubuntu can find this file ), then boot Ubuntu again, it would work well.

Reason

When UEFI using ACPI to config kernel, the kernel will generate an empty DT which contains some EFI map messages, command line, physical address for Linux, etc.

However, when Ubuntu is booted by grub, the fdt file (empty DT) it generated contains a node called "uefi-secure-boot", which cannot be generated by the kernel built by my own.

Thus, when my Linux with u-root is booting Ubuntu by kexec, Ubuntu cannot find the "uefi-secure-boot" node from the fdt, and consequently goes wrong.

Temporary solution

I commented the line blow in the source code of Ubuntu, then reinstalled Ubuntu.

UEFI_PARAM("Secure Boot Enabled", "linux,uefi-secure-boot", secure_boot)

Thus Ubuntu would not try to find this node and could be successfully booted by my Linux kernel.

Suggestion

The true solution to this problem is supposed to be modifying the source code of Linux kernel built on my own, to generate an additional "uefi-secure-boot" node.

This problem is important for LinuxBoot because it means we have to customize the Linux kernel in firmware to adapt to various target Runtime OS like Ubuntu and CentOS.

I just discovered the problem when I implemented LinuxBoot on ARM64. I hope this group could take it into consideration and come out with a good solution.

Activity

1. rjoleary commented on Sep 9, 2020

   

   rjoleary

   on Sep 9, 2020

   Member

   More actions

   Just for the record, what kernel version is your image and which version of Ubuntu and Ubuntu's kernel?

   Sometimes when you don't see any prints, it's because the kernel doesn't know where to find the serial device (a result of not being able to get the ACPI tables). For debugging, you can hard-code the location of the serial device into the kernel command line with:

   earlycon=pl011,0x<addr>
   

   Where is something you can extract from qemu with:

   qemu-system-aarch64 -machine virt -cpu cortex-a57 -machine dumpdtb=dtb.dtb
   fdtdump dtb.dtb
   

   Additionally, I'm curious if this path works:

   UEFI(ACPI) ------> Kernel+U-root (Image) ---kexec---> Kernel+U-root (Image)
   

   I am of course curious why a vanilla Linux kernel can't generate the uefi-secure-boot node and whether Ubuntu has some special patches.

   Reacted by ReLIFE9527
2. ReLIFE9527 commented on Nov 11, 2020

   

   ReLIFE9527

   on Nov 11, 2020

   Author

   More actions

   I used the linux-5.4 for the Linuxboot, and the version of Ubuntu is also linux-5.4.
   As for the problem that I couldn't see any print, I ended up finding (with GDB) it's because the kernel gets panic before the initialization of console. The detail of this process you can find here.

   UEFI(ACPI) ------> Kernel+U-root (Image) ---kexec---> Kernel+U-root (Image)
   For this path, I actually made a virtual disk to store the Image file, which contains the linux-5.4 and u-root.
   So at first the Linuxboot firmware(contains the UEFI and the Image file) could run the kernel in the firmware, and then I could mount the virtual disk to find the Image file, thus I could run the kernel in the virtual disk by kexec.

   For the 3rd question, I have to say, Ubuntu indeed has some special patches. :)

Issue actions