0

For packages in Debian's repositories, hashes and signatures are checked as described here (and questions linked there) to ensure the integrity of the software to at least some degree (under development).

But how is the integrity of firmware ensured on GNU/Linux?

I think there broadly would only be one way to reliably ensure integrity: the firmware being open source and reproducible, the reproducible hashsums of the files being public and a reliable way to check the local firmware against these hashsums. I don't think this currently is the case - nevertheless, less optimal ways could also go a long way to help ensure security.

How is the integrity of firmware currently ensured and how can it be ensured manually?
With firmware I'm referring to preinstalled firmware on components of the computer (including things connected to it) and updates of firmware using fwupd (fwupdmgr update).

I don't know of tools to update nonspecific PC firmware on GNU/Linux other than fwupd but maybe there are some more. On Debian11/KDE by default the firmware updates are separate to the package manager. One can only configure the KDE package manager "Discover" to also show (prompt the user) and carry out these updates. I wondered if it's still not part of the package managers by default because the integrity of the downloaded update files is not checked in a way as secure as other packages that can be installed from the package managers (like Apper for example).

mYnDstrEAm
  • 4,275
  • 14
  • 57
  • 118
  • 1
    There are a number of different issues here. The authentication and integrity of downloaded firmware and the integrity of installed firmware. Firmware Integrity Measurement (FIM) is typically implemented via a chain of trust starting at a Root of Trust (RoT) and ending at the OS bootloader with a log of measurements being written to a tamper-resistant log. – fpmurphy Feb 07 '22 at 20:05
  • Thanks for elaborating; the current answer only explains current ways for firmware updates to some degree, but not installed firmware. So maybe this should be a separate question or I should revisit it once I learned more about it. FIM only seems to be done if Secure Boot is enabled. Also there are probably additional ways integrity gets or could get verified. – mYnDstrEAm Feb 07 '22 at 23:12
  • Secure Boot is not the same as secure boot, trusted boot or measured boot. It and Windows Measured Boot are Microsoft-specific. – fpmurphy Feb 08 '22 at 21:46
  • I'm not sure what you're saying but this question is about GNU/Linux; also secure boot is possible on G/L. – mYnDstrEAm Feb 09 '22 at 18:17
  • Agreed. However in your previous comment you mentioned Secure Boot - which is basically a Microsoft technology. You are aware that to use Secure Boot with GNU/Linux, a shim binary signed by Microsoft is used? – fpmurphy Feb 09 '22 at 20:38

1 Answers1

1

Firmware updates made available through fwupd, KDE Discover or GNOME Software are provided through the Linux Vendor Firmware Service.

Updates are signed by the LVFS; it is assumed that vendor access is tightly controlled and that files uploaded by vendors are trustworthy. The installation tools (ultimately, fwupd) will refuse to install a firmware package whose signature fails to validate.

Many devices will refuse firmware updates that don’t validate in some way or other, but that’s independent of the tools used to apply the updates. (This also applies to CPU microcode updates shipped by your distribution.)

Stephen Kitt
  • 434,908
  • I couldn't find info about how the hashsums are validated there. The current ways seem insufficient. I created an issue about improving this here: https://github.com/fwupd/fwupd/issues/4260 Requiring some form validation for updates within the firmware sounds useful / like a promising approach but I couldn't find any info/details about that either. – mYnDstrEAm Feb 08 '22 at 13:25
  • Why do you want to validate hashsums? Which hashsums? The authenticity of the download from LVFS is verified by the signature (GPG or PCKS#7), there’s no need for additional hashsums. – Stephen Kitt Feb 08 '22 at 13:29
  • For instance, because a mechanism of all firmware is signed with one GPG key each does not address that the one GPG key may have signed malicious software (wittingly or unwittingly or not done by the person publicly associated with the key) or that malicious software was also signed by some GPG keys and uploaded. With hashsums I also meant a way that ensures the local downloaded firmware file is the correct one. A hypothetical reliable way for this is not unlikely to include the use of hashsums. – mYnDstrEAm Feb 08 '22 at 16:18
  • Where do you get “reliable” hashsums? – Stephen Kitt Feb 08 '22 at 16:21
  • Put another way, the advantage of key-based verification over hashsums is that the former provide out-of-band verification. If you ship the public key with the tool that does the verification, then a simple compromise of the download site will be detected; successful compromise requires both taking over the download site and the private key. If you rely on hashsums, then either you end up vulnerable to any tampering on the download site, or you need to provide some other way of shipping the hashsums. – Stephen Kitt Feb 08 '22 at 16:26
  • I never said it would rely on hashsums only. Maybe I should have clarified it better: for example the hashsums need to be signed in some way, especially until they're reproducible. – mYnDstrEAm Feb 09 '22 at 18:15
  • A GPG or PKCS#7 signature guarantees integrity, there’s no need for a hashsum in addition to that. – Stephen Kitt Feb 09 '22 at 18:46
  • I don't think that "A GPG or PKCS#7 signature guarantees integrity" - see my 2nd comment above. Furthermore, it's not about any kind of / plain integrity but integrity of the installed firmware. – mYnDstrEAm Feb 10 '22 at 21:43
  • There must be something I’m not aware of then. How can you verify firmware with a hashsum, in a way you can’t with a signature? – Stephen Kitt Feb 10 '22 at 21:55
  • That's the second part of your comment which may or may not be a separate issue. What I said is that (concerning intend) having/making one signature is insufficient. Moreover, I didn't say that a hashsum on its own (for example without forms of signatures) would be sufficient. – mYnDstrEAm Feb 10 '22 at 22:27