Linux Firmware Security with fwupdmgr
Published August 20, 2026 • Updated August 20, 2026
Firmware security is easy to ignore because most Linux security tooling starts above the firmware layer. We routinely check packages, services, kernel configuration, firewall rules and file permissions, while the firmware underneath all of it is treated as something that simply works.
That is the gap that fwupd and its Host Security ID (HSI) reporting are trying to address.
The Firmware Security page in the KDE kinfocenter program provides a useful way to turn a fairly technical set of firmware and kernel checks into something that can be understood and acted upon. Underneath the graphical presentation is the same security model exposed by fwupdmgr security, where fwupd evaluates a collection of host security attributes and assigns an HSI level plus, when appropriate, a runtime suffix. The HSI specification is intended to provide an end-user-verifiable view of platform firmware security rather than simply trusting vendor marketing claims. (kinfocenter)
On a client system, the initial assessment looked like this:
HSI-4
✔ SMAP: Enabled
✘ Encrypted RAM: Disabled
Runtime Suffix -!
✔ CET OS Support: Supported
✔ fwupd plug-ins: Untainted
✔ UEFI db: Not found
✘ Linux kernel lockdown: Disabled
✘ Linux swap: Unencrypted
✘ Linux kernel: Tainted
✘ UEFI secure boot: Disabled
This system has HSI runtime issues.
» https://fwupd.github.io/hsi.html#hsi-runtime-suffix
Host Security Events
2026-08-07 20:25:49: ✔ BIOS rollback protection changed: Disabled → Enabled
2026-08-07 20:25:49: ✔ Suspend-to-idle changed: Disabled → Enabled
2026-05-30 08:49:20: ✘ Suspend-to-idle changed: Enabled → Disabled
2026-05-17 17:10:50: ✔ TPM v2.0 changed: Not found → Found
2026-04-03 18:38:18: ✘ Kernel is tainted
The HSI number represents the core firmware security level. The runtime suffix represents security conditions that can change while the operating system is running. fwupd explicitly separates those two concepts: the core HSI level does not change simply because the OS configuration changes, but the runtime suffix can. (Fwupd)
What HSI-4 means
fwupd defines HSI-4 as its “Secure State”. At this level the platform has a robust collection of firmware protections, including hardware-assisted encryption and execution protections where the platform supports them.
In the client’s case, the HSI-4 result was accompanied by:
✘ Encrypted RAM: Disabled
The fwupd HSI specification describes DRAM memory encryption as using technologies such as Intel TME or AMD SME to protect data on the external memory bus. Where supported, this can reduce the risk of an attacker extracting memory contents through physical access to the memory subsystem. fwupd considers successful detection and activation of the feature a requirement for HSI-4 on systems where the test applies. (Fwupd)
The client’s system reported:
Runtime Suffix -!
The exclamation mark means that fwupd detected a runtime security issue. The current HSI specification lists several conditions that can produce it, including Secure Boot being disabled, an untrusted or tainted kernel, kernel lockdown being disabled, unencrypted swap, and modified fwupd plug-ins. (Fwupd)
That makes the runtime section particularly valuable for Linux administrators because it connects firmware security with the configuration of the currently running operating system.
In other words, a machine can have reasonably strong firmware protections and still have a weaker runtime security posture.
How I reviewed the findings
For the kernel taint state, I checked the kernel’s exported taint value:
cat /proc/sys/kernel/tainted
and then looked at the kernel log for the reason:
dmesg | grep -i taint
dmesg | grep -Ei 'module|firmware|unsigned|taint'
The issue was then identified as the integrated webcam driver. It was signed when secure boot was enabled. After secure was disabled on the system, the driver was untrusted:
Kubuntu 26
│
├── Secure Boot originally enabled
│ └── MOK "dof-7340 Secure Boot Module Signature key"
│
├── Secure Boot subsequently disabled
│
└── IPU6 DKMS installed
│
└── ov02c10.ko
│
├── out-of-tree → O taint
└── signature not being trusted/required → E taint
For swap, I checked what was active:
swapon --show
cat /proc/swaps
The fwupd Linux Swap plugin checks the currently available swap partitions and files and records whether they are encrypted. (Fwupd)
In this case the system used “swap to file” and as the filesystem was unencrypted this was expected.
A dedicated swap partition used for hibernation functionality would also be flagged here if unencrypted.
Kernel lockdown was connected to the trusted boot configuration and was addressed as part of restoring Secure Boot.
The missing UEFI db result had to be interpreted in the context of the Secure Boot configuration.
Encrypted RAM was enabled in the BIOS.
The host security event history is useful too
The event history gave a useful timeline.
It is more useful than a single snapshot because firmware security is not static.
For example, the TPM state changed from “Not found” to “Found”, BIOS rollback protection changed, and the suspend mode changed over time. That makes the history a primitive audit trail for platform-security configuration.
Conclusion
The value of the Firmware Security page is that it provides a starting point for investigating the security of the machine beneath the operating system. It provides firmware details that are normally buried in UEFI setup menus: rollback protection, Secure Boot, TPM state, memory protections, SPI protections, recovery and platform trust. It also shows normal Linux runtime state: kernel lockdown, kernel taint, swap encryption and the trustworthiness of fwupd itself. These features make it a useful addition to a system security audit and to fix issues that are relevant to your threat model.