vmlinuz/initrd.img symlinks do not point to signed versions on kernel updates of secure boot UEFI machines

[Ubfan]

Kernel updates on a UEFI pc with secure boot enabled have the vmlinuz and initrd.img symlinks updated, but they point to the unsigned versions of the kernel instead of the signed ones. The pc was set up with secure boot on, has never been booted with secure boot off, and no runtime problems have been noted from the wrong symlinks. Having the links to the signed versions is highly desirable, in order to set up a USB stick with its own EFI directory to boot Ubuntu, and not have to worry about changing the USB stick's grub.cfg files.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Dimitri John Ledkov (xnox)]

Which version of ubuntu is this?
How did you check that it points to an unsigned image?
You can use:
sbattach --detach /tmp/signature /vmlinuz && ls -la /tmp/signature

To check if there is signature present in the vmlinuz.

[Ubfan (ubfan1)]

Ubuntu 12.10, updated several times, getting kernels ...17, ...26, and ...27. The symlinks in / were examined with "ls -l" and the output indicated that the link was to the /boot/vmlinuz....-generic file, NOT the /boot/vmlinuz...-generic.efi.signed file.
Applying the sbattach command to the /vmlinuz (and to the actual /boot/vmlinuz-3.5.0-27-generic file) produced a zero length output with the warnings:
warning: file-aligned section of .text extends beyond end of the file
warning: checksum areas are greater than image size. invalid section table?

Applying the sbattach command to the /boot/vmlinuz...-generic.efi.signed file produced no errors, and output of length 1911.
I conclude that the kernels in /boot ending in ".efi.signed" are the signed versions, and the ones ending in ".generic" are not -- with the symlinks in "/" pointing to the unsigned versions.

The file /etc/kernel-img.conf contains symlinks=yes, and bootloader=no

[Dimitri John Ledkov (xnox)]

One option is to generate /vmlinuz.efi.signed symlinks. Would that be sufficient?

[Colin Watson (cjwatson)]

The kernel packaging manages these symlinks.

[Andy Whitcroft (apw)]

I am not aware of anything which consumes these links when generating grub configurations. Therefore that they point to the non-signed images does not seem likely to trigger issues here. Where are you seeing issues from this missmatch. What tool is consuming them and generating bad usb sticks ?

[Ubfan (ubfan1)]

Bug 1091464 affects me (grub unable to chainload Windows), so as a workaround, I have a separate ESP on a USB stick. The stick boots Ubuntu 12.10 off the hard disk, and the stick is not mounted in the filesystem. I had been updating the stick's EFI/ubuntu/grub.cfg as each kernel update occurred, but thought I would instead just use the root symlinks, and avoid future grub updates to the stick. That is when I noticed that the symlinks' targets were the unsigned versions of the kernel, and reported the bug.
  Now grub WILL boot the unsigned kernels off the existing symlinks, and I can see no differences when signed vs. unsigned kernel is used, but I don't know how the symlinks are used by other programs, so something may break if the symlinks don't target the running kernel.

[Andy Whitcroft (apw)]

I don't think we can do much about this at this stage for Raring. As this is only affecting non-default software at this point I am pushing this out for consideration in S.

[Joseph Salisbury (jsalisbury)]

Given the number of bugs that the Kernel Team receives during any development cycle it is impossible for us to review them all. Therefore, we occasionally resort to using automated bots to request further testing. This is such a request.

We are approaching release and would like to confirm if this bug is still present. Please test again with the latest development kernel and indicate in the bug if this issue still exists or not.

You can update to the latest development kernel by simply running the following commands in a terminal window:

    sudo apt-get update
    sudo apt-get dist-upgrade

If the bug still exists, change the bug status from Incomplete to Confirmed. If the bug no longer exists, change the bug status from Incomplete to Fix Released.

Thank you for your help, we really do appreciate it.

[Ubfan (ubfan1)]

Downloaded the Sept 20 desktop 64 bit ISO, and on a Secure Boot UEFI laptop running 13.04, created USB install media, and installed to another USB set up with gpt and an EFI partition. Booting the target USB worked in secure mode, with the signed kernel being used, but the symlink for the kernel is still to the unsigned kernel. As an aside here, to be entered into another bug, note that the above straightforward procedure left the laptop unbootable, with the grub.cfg file on the hard disk's EFI reset to the uuid of the USB stick, (and an additional unnecessary NVRAM boot entry added).

[Joseph Salisbury (jsalisbury)]

This bug was nominated against a series that is no longer supported, ie saucy. The bug task representing the saucy nomination is being closed as Won't Fix.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.