This allows us to load sets of different host security attributes
for testing the various front end tools we have now. e.g.
sudo FWUPD_HOST_EMULATE=thinkpad-p1-iommu.json.gz fwupd
or, using a non-compressed absolute path:
sudo FWUPD_HOST_EMULATE=/tmp/test/thinkpad-p1-iommu.json fwupd
Data can be created with `./contrib/generate-emulation.py file.json`
and then can be manually modified if required. Running the script on
a file that already exists will just strip out any unneeded data, as
well as piping content into it using stdin.
As a precaution, the org.fwupd.hsi.HostEmulation attribute is added
so we do not ask the user to upload the HSI report. It also allows
the LVFS to ignore any HSI reports with this attribute for clients
that upload HSI reports regardless.
See https://github.com/fwupd/fwupd/discussions/4832
Using `sudo FWUPD_PROFILE=10 ./src/fwupd --verbose` will print a
dump of startup times onto the console so that we can debug which
plugin is slowing down system startup. For example:
../src/fu-engine.c:5409:plugins-coldplug [108.55ms]:
../plugins/amt/fu-plugin-amt.c:437:amt [27.14ms]:
:create-context [12.66ms]
:get-version [8.44ms]
:add-device [3.95ms]
This adds support for optionally using a UNIX domain socket where a
D-Bus daemon may not be running.
To use this, launch the daemon and clients with something like
`FWUPD_DBUS_SOCKET=/var/run/fwupd.sock fwupdmgr get-devices`
We were calling g_module_symbol() 2703 times, which is actually more
expensive than you'd think.
It also means the plugins are actually what we tell people they are:
A set of vfuncs that get run. The reality before that they were dlsym'd
functions that get called at pretty random times.
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.
