FWUPD 1.6.2 Released With Exciting Improvements For Hardware Firmware Updates On Linux

[phoronix]

Phoronix: FWUPD 1.6.2 Released With Exciting Improvements For Hardware Firmware Updates On Linux

While FWUPD 1.5.12 released last week with expanded support for Poly web cameras, FWUPD 1.6.2 is out today as the newest feature release in their latest series. FWUPD 1.6.2 brings several significant improvements for advancing open-source firmware update capabilities on Linux...

https://www.phoronix.com/scan.php?page=news_item&px=FWUPD-1.6.2

[uid313]

Why haven't Canonical, Red Hat or Linux Foundation created their own UEFI Secure Boot keys?
It could be used to sign nightly builds of the Linux kernel.

Does any company or manufacturer have their own keys?
Or is everyone just using Microsoft keys only?

[chenxiaolong]

Why haven't Canonical, Red Hat or Linux Foundation created their own UEFI Secure Boot keys?
It could be used to sign nightly builds of the Linux kernel.

Does any company or manufacturer have their own keys?
Or is everyone just using Microsoft keys only?

I know at least Dell has their own keys. I had to add their certificate to my Secure Boot "DB" list for the UEFI updater to run (I use custom keys).

I was curious about your last question though and took a look. Seems like Fedora, CentOS, and Ubuntu are signed with the Microsoft key only and openSUSE is signed with their own key + the Microsoft key. I'm not sure if any OEMs include openSUSE's CA cert by default.

Fedora 34:

# sbverify --list /boot/efi/EFI/fedora/shimx64.efi
warning: data remaining[803648 vs 928592]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
   issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
   issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root

CentOS Stream 8

$ sbverify --list EFI/BOOT/BOOTX64.EFI
warning: data remaining[1112400 vs 1244496]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root

Ubuntu 20.04:

# sbverify --list /boot/efi/EFI/ubuntu/shimx64.efi
warning: data remaining[1170360 vs 1289424]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/OU=MOPR/CN=Microsoft Windows UEFI Driver Publisher
   issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
   issuer: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root

openSUSE Tumbleweed:

$ sbverify --list EFI/BOOT/bootx64.efi
warning: data remaining[808656 vs 934024]: gaps between PE/COFF sections?
signature 1
image signature issuers:
 - /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
image signature certificates:
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Windows UEFI Driver Publisher
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
 - subject: /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation UEFI CA 2011
   issuer:  /C=US/ST=Washington/L=Redmond/O=Microsoft Corporation/CN=Microsoft Corporation Third Party Marketplace Root
signature 2
image signature issuers:
 - /CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/[email protected]
image signature certificates:
 - subject: /CN=openSUSE Secure Boot Signkey/C=DE/L=Nuremberg/O=openSUSE Project/[email protected]
   issuer:  /CN=openSUSE Secure Boot CA/C=DE/L=Nuremberg/O=openSUSE Project/[email protected]

[bash2bash]

I still can't find a single thing to update...

I tried 5-6 desktop PCs.... no updates detected... tried several older DELL XPS laptops, again not a single update...

Rather disappointing...

[furtadopires]

I still can't find a single thing to update...

I tried 5-6 desktop PCs.... no updates detected... tried several older DELL XPS laptops, again not a single update...

Rather disappointing...

Would blow my mind if we could use fwupd to update legacy bios boards like those old intel ones. But it's the expected from a software that depends on the vendors to support it, and doesn't have the influence power of Microsoft to push it.

[F.Ultra]

Why haven't Canonical, Red Hat or Linux Foundation created their own UEFI Secure Boot keys?
It could be used to sign nightly builds of the Linux kernel.

Does any company or manufacturer have their own keys?
Or is everyone just using Microsoft keys only?

I think that back in the day when e.g Canonical bought their key from Microsoft there where boards where you could not install a 3d party key so by having your key signed by Microsoft ensured that Ubuntu could install and run on those boards using secure boot.

[hughsie]

> Would blow my mind if we could use fwupd to update legacy bios boards like those old intel ones

No vendor wanted to support that. Being brutally honest, there's nothing in it from them, only QA expense. If you want a vendor to do something you either have to stop them selling to someone they've sold to before, or allow them to sell to someone that they've never sold to before. Very few vendors care about your hardware after it's EOL.

[hughsie]

I still can't find a single thing to update...

Check the list here: https://fwupd.org/lvfs/devices/

[uid313]

I think that back in the day when e.g Canonical bought their key from Microsoft there where boards where you could not install a 3d party key so by having your key signed by Microsoft ensured that Ubuntu could install and run on those boards using secure boot.

Yeah, using the Microsoft key is great!
I love that Canonical is signing Ubuntu with the Microsoft key because it makes it so easy to use since the Microsoft key is already preloaded when you buy a motherboard.

I was more thinking why distribution, foundation or company had their own key because then they could sign nightly builds of the kernels or sign it with Microsoft's key in addition to their own key.

[mlau]

Or is everyone just using Microsoft keys only?

Yes because it's the one key that the board manufacturers are going to install no matter what.