Don't parse load options if invoked from removable media path

[julian-klode]

No description provided.

[julian-klode]

There is a question whether is_removable_media_path() should move to load-options.c / become non-static and we then do the exit in parse_load_options() which would also allow us to test that bit, but shuffles code around a bit more.

Then we could also dump the load options even when ignoring it, and play around with machines and improve our parsing code for firmware generated entries.

[steve-mcintyre]

Hey @julian-klode

Just wondering about the effects of this change - won't this totally block anybody using the RM path from doing EFI capsule updates?

[julian-klode]

So if you just install to the removable media path, you are busted and can't boot anything else via it. That's why you have to make sure to always install a shimx64.efi alongside a bootx64.efi.

My understanding of the situation is that in Debian and Ubuntu, we always install shimx64.efi to the vendor directory, and that's how fwupd is loaded, so things should just work. The code to fallback to using bootx64.efi in fwupd is disabled by default, but, yes, will be broken with that change enabled.

Other people might have other requirements, and it might not work for them, so they'd not enable this option and get hit with a 2s timeout and fallback from #393 if misparsing happened.

[steve-mcintyre]

So if you just install to the removable media path, you are busted and can't boot anything else via it. That's why you have to make sure to always install a shimx64.efi alongside a bootx64.efi.

My understanding of the situation is that in Debian and Ubuntu, we always install shimx64.efi to the vendor directory, and that's how fwupd is loaded, so things should just work. The code to fallback to using bootx64.efi in fwupd is disabled by default, but, yes, will be broken with that change enabled.

Right. I'm worried about the (too-large!) number of people who still have to rely on the RM path due to firmware or system setup issues.

[julian-klode]

So if you just install to the removable media path, you are busted and can't boot anything else via it. That's why you have to make sure to always install a shimx64.efi alongside a bootx64.efi.
My understanding of the situation is that in Debian and Ubuntu, we always install shimx64.efi to the vendor directory, and that's how fwupd is loaded, so things should just work. The code to fallback to using bootx64.efi in fwupd is disabled by default, but, yes, will be broken with that change enabled.

Right. I'm worried about the (too-large!) number of people who still have to rely on the RM path due to firmware or system setup issues.

You think they'll end up in a situation where they can set arguments for bootx64.efi, but not for shimx64.efi?

[haobinnan]

Exception occurred after using patches 393-1 / 393-2 / 399-1 / 399-2. And I got following messages after replacing \EFI\Microsoft\Boot\bootmgfw.efi with shimx64.efi:
Falled to open \EFI\Microsoft\Boot\S - Invalid Parameter
Failed to load image \EFI\Microsoft\Boot\S: Invalid Parameter
start_image() returned Invalid Parameter, falling back to default loader

@julian-klode

[julian-klode]

@haobinnan Just to clarify - seems I missed this: Are you saying that if you just apply only 393 and 399, you see that issue, and it does not happen without those specific patches? I don't see them adding code that would cause parsing issues. What happens if you apply just 393 or 399?