At the moment at startup we're calculating the attrs so we can export the HSI
string property on the D-Bus interface. Running `fwupdtool security` actually
gets all the security attributes at least twice!
The idea here is that we can show the user both a string and an optional
line-art image when the update has completed. The line art is often more well
understood for non-English speakers.
Newer versions of libxmlb do not auto-cache XbNodes, and we have to opt-into
this beahviour for the _set_data() and _get_data() to work.
Although this is a behaviour change which also increases complexity, it lowers
our RSS usage by 200kB which is about a quarter of the total RSS used...
fmap is a Google flash layout format that is used in several of Google's
firmware projects, including Chrome OS Embedded Controller and the Chrome OS
coreboot firmwares. Introduce it as a firmware format in libfwupdplugin.
Force the FuDevice parent to have the largest of the child removal delays.
This avoids each plugin enumerating the children (which may not even be added
yet) to increase the length of the allowed parent delay.
Add two new vfuncs that can be used to collect report metadata from devices
both before and after the update has run. This means we can remove the hacks
where we set add 'global' metadata entries and just hope that there is only one
device from the same plugin that is updated.
This also allows us to collect debugging metadata from devices after an offline
update has been run.
See also: https://github.com/fwupd/fwupd/issues/2119
Reported-by: Anton Farygin <rider@altlinux.org>
Based on a patch by Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
To do this, rely on the AppStream ID to map to a translated string (providing a
fallback for clients that do not care) and switch the free-form result string
into a set of enumerated values that can be translated.
This fixes some of the problems where some things have to be enabled to "pass"
and other attributes have to be some other state. For cases where we want the
user to "do" something, provide a URL to a wiki page that we update out-of-band
of fwupd releases.
This exports FuSecurityAttrs into libfwupdplugin so that we can pass the plugins
this object rather than a 'bare' GPtrArray. This greatly simplifies the object
ownership, and also allows us to check the object type before adding.
In the future we could also check for duplicate appstream IDs or missing
properties at insertion time.
This change also changes the fu_plugin_add_security_attrs() to not return an
error. This forces the plugin to handle the error, storing the failure in the
attribute itself.
Only the plugin know if a missing file it needs to read indicates a runtime
problem or a simple failure to obtain a specific HSI level.
The HSI specification assigns a simple text ID to the current state of firmware
security. As new vulnerabilities are found, and as protection measures are
updated, new requirements will be added to the required firmware behaviours for
each HSI value.
The HSI specification is currently incomplete and in active development, and
so the --force flag is required in all command line tools. The current ID value
will probably change on a given platform so please do not start using the result
for any kind of compliance requirements.
We're planning to ship fwupd 1.4.x in RHEL 8 and so it makes sense to have a
stable branch to do point releases. I don't intend to release versions 1.5.x
any time soon, so moderately-agressive backporting to 1_4_X is okay.
The kernel interface for force power doesn't support tracking the state
of the device, and so this had to be tracked by fwupd.
Unfortunately due to system and thunderbolt controller firmware behavior
on some systems the thunderbolt controller /still/ didn't return even
when force power state was accurately tracked.
The device model for the uevent related to the device removal being ignored
doesn't really fit into the current fwupd architecture anymore either.
Lastly this is a very legacy feature at this point. Thunderbolt3 controllers
distributed in the last 3 years all operate in 'native' mode meaning that
they will always be powered and use runtime power management.
USB4 controllers won't have a concept of being force powered.
USB4 reimers will have this concept, but the state will be tracked by the
kernel and obfuscated from userspace.
So with all that said, tear out all of the force power related code.
The returned ID is the result of the SHA1 hash of the actual device ID. This
does not match anything found by the client, and so the install fails.
The symbol is exported as I think the device ID is an important identifier and
used in various fwupd tools.
When backported to the stable branch the verification should just be a static
function in src/fu-engine.c rather than a new symbol.
This means we do not have to manually set the quirks for each child, and means
we get the quirk set at object construction before any instance IDs are set.
