As some as you may know, there might be firmware security support in the next versions of Plymouth, GNOME Control Center and GDM. This is a great thing, as most people are running terribly insecure hardware and have no idea. The great majority of these systems can be improved with a few settings changes, and the first step in my plan is showing people what’s wrong, giving some quick information, and perhaps how to change it. The next step will be a “fix the problem” button but that’s still being worked on, and will need some pretty involved testing for each OEM. For the bigger picture there’s the HSI documentation which is a heavy and technical read but the introduction might be interesting. For other 99.99% of the population here are some pretty screenshots:
To facilitate development of various UIs, fwupd now supports emulating different systems. This would allow someone to show dozens of supported devices in GNOME Firmware or to showcase the firmware security panel in the GNOME release video. Hint hint. :)
To do this, ensure you have fwupd 1.8.3 installed (or enable the COPR), and then you can do:
sudo FWUPD_HOST_EMULATE=thinkpad-p1-iommu.json.gz /usr/libexec/fwupd/fwupd
Emulation data files can be created with ./contrib/generate-emulation.py file.json in the fwupd source tree and then can be manually modified if required. Hint: it’s mostly the same output as fwupdmgr get-devices --json and fwupdmgr security --json and you can run generate-emulation.py on any existing JSON output to minimize it.
To load a custom profile, you can do something like:
sudo FWUPD_HOST_EMULATE=/tmp/my-system.json /usr/libexec/fwupd/fwupd
As a precaution, the org.fwupd.hsi.HostEmulation attribute is added so we do not ask the user to upload the HSI report. The emulated devices are also not updatable for obvious reasons. Comments welcome!
As long as this panel can be disabled on hw that is so old the the manufacturer does not provide any firmware updates then that’s fine. To be honest for home users secure boot/TPM are a waste of time, indeed firmware updates are of limited use past a year or so of the hw launch as manufacturers usually don’t release firmware feature fixes/updates after that date. Most updates after that are CPU fixes for spectre, retbleed type cockups etc that only really affect the cloud computing freeloaders.
I think there’s a whole industry of security professionals that would disagree with that…
Good thing.
Sadly the first thing I do is turning off Secure Boot. Only then fwupd is able to apply UEFI-Updates on my ThinkPad. I requires a lot additional code (UEFI ->Secure Boot -> Shim -> Grub 2 -> Kernel…) which causes problems. It is not just sad irony. This is what happens when things are made unnecessarily complicated and error prone.
The good stuff?
* IOMMU-Protection
* The NX-Bit
* DMA-Protection
* UEFI/BIOS-Password
* And Hardware-based full disk encryption (FDE)
The first three are important and usually turned on. The later two are usually off but are crucial to protect hardware from access and manipulation! And luckily the UEFI/BIOS-Password and hardware-encryption (FDE) are transparent to the operating-system, seldom cause trouble and doesn’t influence performance. Both together are also simply mitigating what Secure Boot should prevent without the complexity of Certificates.
PS: Some older Samsung SSDs (Evo 840) weren’t fully secure with FDE. Even in that case you could add software-encryption on top. Crucial also struggled but they fixed that with an firmware-update. Which brings us back to the venerable fwupd ️
there is norhing secure about secure boot unless you could reliably disable all uefi builtin certificates except your own.
most security professionals sell snakeoil, better to follow security experts or scientists