Currently, HSI only has a numerical level, such as HSI 0~1 and each
number represents a security state from insecure to secure. If we
only show the number to the user, the user may confuse and try to
find the document to realize the meaning of the number or just ignore
them immediately. So, a readable name for each HSI level can catch
users' eyes and let them explicitly know the security status.
Signed-off-by: Kate Hsuan <hpa@redhat.com>
It's actually quite hard to build a front-end for fwupd at the moment
as you're never sure when the progress bar is going to zip back to 0%
and start all over again. Some plugins go 0..100% for write, others
go 0..100% for erase, then again for write, then *again* for verify.
By creating a helper object we can easily split up the progress of the
specific task, e.g. write_firmware().
We can encode at the plugin level "the erase takes 50% of the time, the
write takes 40% and the read takes 10%". This means we can have a
progressbar which goes up just once at a consistent speed.
More than one person has asked about 'why call fu_plugin_update() for a
reinstall or downgrade' and I didn't have a very good answer.
The plugin API is not officially stable, and we should fix things to be
less confusing. Use the same verbs as the FuDevice vfuncs instead.
Until gi-docgen is declared stable support either of them.
This effectively means that hand builds and CI builds will use
gi-docgen, but distro builds use gtk-doc-tools.
Add the IFD regions as child devices and set the region access on the child
devices. Also add read-only SPI descriptor as an HSI attribute and require
FLOCKDN on Intel hardware.
Use the hidden PCI 00:1f.5 device to set the SPIBAR automatically and generate
the quirk file automatically to support more hardware.
This allows us to 'nest' firmware formats, and removes a ton of duplication.
The aim here is to deprecate FuFirmwareImage -- it's almost always acting
as a 'child' FuFirmware instance, and even copies most of the vfuncs to allow
custom types. If I'm struggling to work out what should be a FuFirmware and
what should be a FuFirmwareImage then a plugin author has no hope.
For simple payloads we were adding bytes into an image and then the image into
a firmware. This gets really messy when most plugins are treating the FuFirmware
*as* the binary firmware file.
The GBytes saved in the FuFirmware would be considered the payload with the
aim of not using FuFirmwareImage in the single-image case.
The logic here is that the attestation is more than just the PCR0 value, and
multiple device firmware (such as EC, ME, etc.) needs to be included to validate
the system.
By the same logic, updates for the system firmware do not tell the whole story,
and confuse HSI as a specification. Remove them.
For instance, we can tell the user that UEFI UpdateCapsule is disabled in the
system firmware, or that efivarfs is not mounted. This is much better than
creating "dummy" devices which are really just hacks around the problem because
no better API existed. THe dummy devices cause as many problems as they solve.
Plugins have to set FWUPD_PLUGIN_FLAG_USER_WARNING if a warning should be shown
to the user, and only one warning will be shown of each failure type.
It is expected that GUI clients like gnome-software and gnome-firmware would use
this API to notify the user the localized message for why firmware updates are
not being shown.
Fixes https://github.com/fwupd/fwupd/issues/2456
Firsly, that HSI isn't expected for embedded devices and then secondary how we
require SecureBoot to be available for HSI:1
At the moment we get a runtime failure if it is disabled. Making SB a part of
`HSI:1` makes this requiremnt explicit and prevents us getting `HSI:2!` if it
is not available.
We don't actually need either of the things it provides (looking up in source
and built, and converting to an absolute path) so just replace it with
g_build_filename() instead.
This also has the advantage that it does the right thing on Windows.
