New fwupd 1.8.4 release

Today I tagged fwupd 1.8.4 which adds a few nice features and bug fixes. One specific enhancement I wanted to shout about is that we’re now supplying translated summary, description text and suggested actions for each HSI security failure. Two of the most common criticisms of the new GNOME security panel were “but what does it mean” and also “and what should I do” which ironically were fixed long before all the hubbub erupted. If you want to see both new bits of data then make sure you’re using gnome-control-center from the main branch and then install the new fwupd version – although if you’re stuck on a distro version of fwupd GNOME will still fallback to the single-line summary line as before.

One additional new feature that might accidentally fix another criticism with the panel is that fwupd now reads your system BIOS settings, and has the ability to change them if the user desires (and has authorization to do). This means we have to match the HSI failure (e.g. IOMMU disabled) with the BIOS setting, which isn’t standardized at all between vendors. We currently support this on modern Lenovo and Dell platforms via the firmware-attributes kernel interface; other vendors just have to add the kernel WMI bridge and it should mostly magically start to work.

As we now know what the failure is, what we need to change, and how to change it, we can actually ask the user if they want to change the setting automatically in the fwupdmgr security command line. This would allow us to add a “JFDI” action in the new GNOME device security panel rather than asking the user to manually change a firmware setting in the BIOS. We won’t do this for GNOME 43 as we need a few months of real-world testing to see what attributes are 100% safe to change on actual user systems, but for GNOME 44 the panel could be a whole lot more helpful than it is now.

A new tantalizing features then become available when using fwupd, as we can now read and change firmware settings. One is the ability to emulate the BIOS settings of another machine, which is fairly uninteresting to end users, but allows us the developers to reproduce bugs much easier now that we’re doing cleverer things. One more interesting deployment feature is that we also support reading out a file from /etc and applying those firmware settings at startup. This means you can now deploy a machine using something like Ansible, and have the firmware settings set up in the same way you set up the local machine state. There are lots of docs on how this all works and I encourage you to try this out and let us know how it goes. One caveat is that this doesn’t work if you have a password set on your BIOS settings, but we’re working on this for the next version.

Needless to say, please tell us about any problems with the new release. As always, comments welcome.

Published by

hughsie

Richard has over 10 years of experience developing open source software. He is the maintainer of GNOME Software, PackageKit, GNOME Packagekit, GNOME Power Manager, GNOME Color Manager, colord, and UPower and also contributes to many other projects and opensource standards. Richard has three main areas of interest on the free desktop, color management, package management, and power management. Richard graduated a few years ago from the University of Surrey with a Masters in Electronics Engineering. He now works for Red Hat in the desktop group, and also manages a company selling open source calibration equipment. Richard's outside interests include taking photos and eating good food.

7 thoughts on “New fwupd 1.8.4 release”

  1. I’m not able to test the GNOME parts yet, but looking at the example terminal output, even for someone who’s comfortable going through /sys and ~/src/linux, it *still* tells me nothing about what the action is supposed to be. Like, is suspend-to-idle a good thing or a bad thing? Will changing the value to “Windows10” enable suspend-to-idle instead of S3 sleep (and if so, what’s the impact to battery life), will it disable suspend-to-idle in favor of S3 sleep (and if so, what’s the impact on…), or will it prevent the system from suspending completely in the name of physical security (and if so, what happens if the lid is closed and the system is put in a bag)? From the description implying that s2idle is kinda bad because the RAM can be removed, my only understanding is basically “this is trying to scare me into disabling sleep support, probably”.

    1. Yep. This is a well meant but this very example is unfortunate?

      Probably this text tries to explain that even when hardware full-disk-encryption is in use, the data in the main-memory is not encrypted. And advanced attacker could theoretically remove your RAM, keeping it powered and/or frozen and plug it into some special device to read the memory cells. I can imagine that this is doable in full powered state, Supend-To-Idle and Suspend-To-RAM.

      0. Full Powered State
      1. Suspend-To-Idle STI # a energy saving state were the computer is actually still on, in an optimistic case it could be as low as Suspend-To-RAM
      2. Standby # let us ignore that here
      3. Suspend-To-RAM STR # minimal power, fast resume
      4. Suspend-To-Disk STD # powered off, no power, requires huge swap space on disk, very slow resume

      Modern ThinkPads use power setting “Windows” in the UEFI to default to Suspend-To-IDLE and “Linux” to Suspend-To-RAM. Linux (Kernel-Upgrades) and Lenovo (UEFI-Updates) initially didn’t supported Suspend-To-IDLE and a half year ago it didn’t worked for me. Actually Linux can always decided a runtime if it want to use Suspend-To-Idle or Suspend-To-RAM. Furthermore Lenovo did had some issues about high power drain in the idle/suspend state. This depends on your UEFI-Firmware.

      Therefore I see this actually as user preference. Where “Linux” (i.e. Suspend-To-RAM) is the well working default. And “Windows” (i.e. Suspend-To-Idle) a possible alternative which could be more convenient.
      Avoiding all low power state except Suspend-To-Disk could be in theory even more secure. If you see yourself in this group you likely need to turn off also your phone when not used and remove the battery (baseband firmware could remain active).

      https://01.org/linuxgraphics/gfx-docs/drm/admin-guide/pm/sleep-states.html

  2. I like this feature. I had the IOMMU (VT-d) enabled already in my firmware but, on Fedora Silverblue, had to additionally add intel_iommu=on to the kernel command line (with rpm-ostree kargs –append=intel_iommu=on) before actually getting the IOMMU protection. That was the only thing I was missing to get from HSI level 1 to HSI level 2. Currently Fedora doesn’t set CONFIG_INTEL_IOMMU_DEFAULT_ON (https://src.fedoraproject.org/rpms/kernel/blob/aff6e8acdaa437e9f06ef4166ca2209071223f8d/f/kernel-x86_64-fedora.config#_2769) and I’m wondering if maybe it should. There seem to be some reports of system freezes when that’s enabled though, so maybe not. Alternatively perhaps fwupd could offer to add intel_iommu=on to kernel command line arguments? I suspect on many systems that’s going to be the only thing needed to get to HSI level 2.

  3. I’ve run fwupdmgr security on my Fedora 36 laptop. It indicates that my swap is unencrypted, which isn’t really correct as I have LUKS on the physical volume of my LVM volume group. My swap partition is an LV of that VG.

    It seems fwupdmgr only detects swap as encrypted if it’s listed on its own in crypttab?

  4. Will you need to install on the metal for these tests to work or can it read the configuration using a live system (ie. a live Fedora ISO)?

Comments are closed.