How fwupd updates works under the hood?

[korpe1]

Are all UEFI updates performed with the uefi-capsule? During updates, the uefi-capsule will be perfomed at early boot stage, UEFI is set to run uefi-capsule instead of the bootloader (excluding the case of secure boot and shim) and it does the hard work?

Why BIOS updates can be done writed to flash during the system is up with flashrom utility and then just reboot?

[superm1]

Yes they are. The SPI is typically write protected in a properly secured system after UEFI hands off control to the OS.

[korpe1]

So, is the reason for need to this in UEFI security practices? BIOS doesn't protect SPI from the OS?

How executing the uefi-capsule.efi bin differs from executing the grubx64.efi bin for the perspective of UEFI? And AFAIK in the case of a secure boot shim.efi will be used. The same binary that boots the OS. If UEFI give control to shim, how can it determine that shim doesn't give it further to the OS?

[superm1]

The SPI is write protected even when fwupdx64.efi runs. The way it works is that EFI application calls the UpdateCapsule API.

This will stage the payload in a secure location and power cycle the system. The next boot after that is when it's actually flashed.

[korpe1]

The SPI is write protected even when fwupdx64.efi runs. The way it works is that EFI application calls the UpdateCapsule API.

Okay, why the OS can't update with calls to the UpdateCapsule API?

Why BIOS can be updated during system on but UEFI not? Altought, the both flash the update during boot.

[superm1]

It's mostly history to match how windows does it to avoid bugs.

You're absolutely right that UpdateCapsule is a RT services API not BootServices API.

But early on we found some vendors it doesn't work if you call after ExitBootServices().

That's obviously a bug, but it was prevalent enough that we didn't want to base a new design on it.

[korpe1]

Sorry, I haven't read the source code of these. I assume that UEFI perform ExitBootServices() function to disable BootService API before it gives the control to further programs. How it differ if the OS runs with only RunTimeService API than fwupd.efi? And the both of these are anyway usually performed after shim. Or is the case that Linux kernel spesifically closes BootService API and shim, fwupd, etc not?

[korpe1]

Another question, why fwupdx64.efi is located /usr/libexec/fwupd/efi/? How can UEFI find it when it doesn't be on uefi system partition (typically mounted on /boot/efi)?

[superm1]

What @hughsie is meaning is this part of sudo fwupdtool esp-list --verbose output:

FuUefiCapsulePlugin:
  Name:                 uefi_capsule
  Flags:                measure-system-integrity
  Order:                1
  FuUefiBackendLinux:
    Name:               uefi
    Enabled:            true
    DoneSetup:          false
    CanInvalidate:      false
  DeviceGType:          FuUefiNvramDevice
  BgrtSupported:        false

On this system I captured it, it uses NVRAM devices which means it uses UpdateCapsule() API like we've been talking about.
capsule on disk is another API that is supported on some systems, but it's relatively rare today. If we detect it we'll use that instead. Basically we stage the file on the ESP, set a flag and BIOS finds it on the reboot. So we don't boot into shimx64.efi followed by fwupdx64.efi to call UpdateCapsule().

It's described here: https://uefi.org/specs/UEFI/2.10/08_Services_Runtime_Services.html#delivery-of-capsules-via-file-on-mass-storage-device

[korpe1]

What @hughsie is meaning is this part of sudo fwupdtool esp-list --verbose output:

FuUefiCapsulePlugin:
  Name:                 uefi_capsule
  Flags:                measure-system-integrity
  Order:                1
  FuUefiBackendLinux:
    Name:               uefi
    Enabled:            true
    DoneSetup:          false
    CanInvalidate:      false
  DeviceGType:          FuUefiNvramDevice
  BgrtSupported:        false

The output of sudo fwupdtool esp-list --verbose on my system doesn't look like that, it's:

$ sudo fwupdtool esp-list --verbose
15:40:42.657 FuDebug              verbose to info (on console 1)
15:40:42.657 FuEngine             starting fwupd 1.9.10…
Selected volume: /org/freedesktop/UDisks2/block_devices/nvme0n1p1
/boot/efi/EFI/BOOT/BOOTIA32.EFI
/boot/efi/EFI/BOOT/BOOTX64.EFI
/boot/efi/EFI/BOOT/fbia32.efi
/boot/efi/EFI/BOOT/fbx64.efi
/boot/efi/EFI/fedora/grub.cfg
/boot/efi/EFI/fedora/BOOTIA32.CSV
/boot/efi/EFI/fedora/BOOTX64.CSV
/boot/efi/EFI/fedora/gcdia32.efi
/boot/efi/EFI/fedora/gcdx64.efi
/boot/efi/EFI/fedora/grubia32.efi
/boot/efi/EFI/fedora/grubx64.efi
/boot/efi/EFI/fedora/mmia32.efi
/boot/efi/EFI/fedora/mmx64.efi
/boot/efi/EFI/fedora/shim.efi
/boot/efi/EFI/fedora/shimia32.efi
/boot/efi/EFI/fedora/shimx64.efi
/boot/efi/EFI/Dell/logs/diags_previous.xml
/boot/efi/EFI/Dell/logs/diags_current.xml
/boot/efi/System/Library/CoreServices/SystemVersion.plist
/boot/efi/mach_kernel

So we don't boot into shimx64.efi followed by fwupdx64.efi to call UpdateCapsule().`

What? Boot of shimx64.efi doesn't ever follow (be after) fwupdx64.efi, right?

[superm1]

The output of sudo fwupdtool esp-list --verbose on my system doesn't look like that, it's:

Try running with a second verbose sudo fwupdtool esp-list --verbose --verbose

What? Boot of shimx64.efi doesn't ever follow (be after) fwupdx64.efi, right?

• For UpdateCapsule() the flow when under secure boot is Linux->reboot->shimx64->fwupdx64->UpdateCapsule().
• For UpdateCapsule() the flow when not under secure boot is Linux->reboot->fwupdx64->UpdateCapsule().
• For CoD the flow is Linux->reboot->BIOS takes over.

[korpe1]

Try running with a second verbose sudo fwupdtool esp-list --verbose --verbose

16:06:22.183 FuDebug              verbose to debug (on console 1)
16:06:22.183 FuEngine             starting fwupd 1.9.10…
16:06:22.184 GLib-GIO             Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)
16:06:22.184 GLib-GIO             Using cross-namespace EXTERNAL authentication (this will deadlock if server is GDBus < 2.73.3)
16:06:22.189 FuVolume             device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: [deleted for privacy], internal: 1, fs: ext4
16:06:22.191 FuVolume             device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: [deleted for privacy],internal: 1, fs: crypto_LUKS
16:06:22.193 FuVolume             device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: [deleted for privacy], internal: 1, fs: vfat
16:06:22.198 FuVolume             device /org/freedesktop/UDisks2/block_devices/nvme0n1p2, type: [deleted for privacy, internal: 1, fs: ext4
16:06:22.199 FuVolume             device /org/freedesktop/UDisks2/block_devices/nvme0n1p3, type: [deleted for privacy], internal: 1, fs: crypto_LUKS
16:06:22.201 FuVolume             device /org/freedesktop/UDisks2/block_devices/nvme0n1p1, type: [deleted for privacy], internal: 1, fs: vfat
16:06:22.202 FuContext            no volumes of type [deleted for privacy]

What? Boot of shimx64.efi doesn't ever follow (be after) fwupdx64.efi, right?

For UpdateCapsule() the flow when under secure boot is Linux->reboot->shimx64->fwupdx64->UpdateCapsule().
For UpdateCapsule() the flow when not under secure boot is Linux->reboot->fwupdx64->UpdateCapsule().
For CoD the flow is Linux->reboot->BIOS takes over.

So it was just type?

For CoD the flow is Linux->reboot->BIOS takes over.

CoD?

[superm1]

Try running with a second verbose sudo fwupdtool esp-list --verbose --verbose

Oh we must not have started to show the extra information until later version than 1.9.10. I see it on 1.9.14.

CoD?

CoD = capsule on disk.