[Bug 1891718] Re: [Regression] breaks GRUB install on an nvme device

[dann frazier]

TLDR; I've convinced myself that the first patch can be safely dropped,
so I've re-uploaded without it.

I attempted to demonstrate the problem I mentioned in Comment #3 that
0001-Fix-the-error-path-in-set_disk_and_part_name.patch addresses.
Basically, what would happen if I passed in a device that
set_disk_and_part_name() did not know about, causing it to incorrectly
report no error while leaving dev->disk_name/dev->part_name
uninitialized in the caller. Turns out, the answer is "nothing awful". I
used the following test on a system where nvme0n1 was a nvme-subsys
device, which focal's set_disk_and_part_name() would not recognize:

#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <sys/types.h>
#include <efivar/efiboot-creator.h>

extern int efi_set_verbose(int verbosity, FILE *errlog);

int main() {
  int err;
  efi_set_verbose(1, stderr);
  err = efi_generate_file_device_path_from_esp(NULL, 0,
					       "/dev/nvme0n1", 1,
					       "\\EFI\\debian\\grub.efi",
					       EFIBOOT_ABBREV_EDD10,
					       0x80);
}


Even though neither name was set, the pointer value happens to be zeroed out:

linux.c:387 device_get(): dev->disk_name: (null)
linux.c:388 device_get(): dev->part_name: (null)

And everything between that and the next error check seems to handle a
NULL pointer well, so we safely bail at the next check:

linux.c:392 device_get(): readlink of /sys/block/(null)/device failed

That's great if they *are* zero'd out - but is that guaranteed? Yes -
the dev is allocated using calloc, which always sets allocated memory to
0.

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to efivar in Ubuntu.
https://bugs.launchpad.net/bugs/1891718

Title:
  [Regression] breaks GRUB install on an nvme device

Status in Efivar:
  New
Status in efivar package in Ubuntu:
  Fix Released
Status in efivar source package in Focal:
  In Progress
Status in efivar source package in Groovy:
  Fix Released

Bug description:
  [Impact]
  Grub fails to install on systems with nvme-subsys storage when installing focal, or upgrading from bionic to focal. As symptom of the latter is shown below:

  ┌───────────────────────┤ Configuring shim-signed ├────────────────────────┐
    │                                                                          │
    │ GRUB failed to install to the following devices:                         │
    │                                                                          │
    │ /dev/nvme0n1p1                                                           │
    │                                                                          │
    │ Do you want to continue anyway? If you do, your computer may not start   │
    │ up properly.                                                             │
    │                                                                          │
    │ Writing GRUB to boot device failed - continue?                           │
    │                                                                          │
    │                    <Yes>                       <No>

  [Test Case]
  On a system with an EFI System Partition residing on an nvme-subsys block device, run grub-install:

  $ sudo /usr/sbin/grub-install
  Installing for x86_64-efi platform.
  /usr/sbin/grub-install: warning: Internal error.
  /usr/sbin/grub-install: error: failed to register the EFI boot entry: Operation not permitted.

  Also, regression test on a system with a non-nvme-subsys NVMe device.

  [Regression Potential]
  There's a risk that a parsing bug will introduce a regression to other systems - most at risk are systems with NVMe block devices. Supposedly nvme-fabrics systems were not previously supported and, as a side-effect of this backport, will now be. However, it's possible - like was the case with bionic/nvme-subsys - that nvme-fabrics *used* to happen to work, and now will work differently or even break. Ideally we'd be able to test on such a system, but I don't know where to find that hardware.

  This fix has been in groovy since just after beta (minus an innocuous
  debug statement that upstream requested during review), and the same
  patches apply cleanly to focal, which should help mitigate the risk by
  way of some real world exposure.

To manage notifications about this bug go to:
https://bugs.launchpad.net/efivar/+bug/1891718/+subscriptions