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).

Improve this question
5
  • 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 7, 2022 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 7, 2022 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 8, 2022 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 9, 2022 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 9, 2022 at 20:38

1 Answer 1

Reset to default
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.)

Improve this answer
10
  • 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: 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 8, 2022 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 8, 2022 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 8, 2022 at 16:18
  • Where do you get “reliable” hashsums?
    – Stephen Kitt
    Feb 8, 2022 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 8, 2022 at 16:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .