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.
This also means we do the right thing when plugins call fu_device_add_flag()
directly, instead of just from a quirk file.
For instance, now `Flags = ~updatable` is a valid and useful thing to have and
allows us to remove the `Flags = None` hack.
This is nice in theory, until you need to look at the bootloader status of the
parent, or of a different device entirely. Handle this in plugins for the few
cases we care about and stop setting or clearing IS_BOOTLOADER manually just to
get the vfuncs to be run.
Note: I do not think we want to use cleanup() for attaching devices not in
bootloader states -- as cleanup is only run at the end of the composite update.
We use the ParentGuid quirk key to logically 'tie-together' different discrete
devices into one logical device, for instance making the USB soundcard in a hub
the child of the USB controller on the same PCB.
Setting the discrete child is sometimes correct, for instance when rebooting
the hub, the audio device also goes away -- but it's also sometimes wrong.
If we set the child for a discrete device and the parent does *not* go away
then we get to a situation where the child reference may no longer be valid
if it comes back as a different object.
When we try to remove this no-longer-valid device with the removal timeout the
daemon segfaults. This is realy bad.
Continue to allow using fu_device_add_child() in plugins, where we know the
child lifecycle is is matched by the the parent. In the engine just set the
parent ID directly and let the client use this information to show the tree of
logical devices correctly. There's no benefit to setting up the children as
referenced objects anyway.
Sometimes plugins need to retry various commands send to hardware, either due
to unreliable transfers (e.g. using USB bulk) or from slightly quirky hardware.
Between them they seem to get various things wrong; either the error messages
are repeated and thus difficult to parse, or they just get the memory handling
of `g_propagate_prefixed_error()` wrong.
Providing sane helpers we can reduce the amount of boilerplate. Additionally
we can support a 'reset' function that can try to automatically recover the
hardware for specific error domains and codes.
Sometimes we only want to add the instance ID to get the quirk matches, and it
is confusing to see the "fake" IDs in the 'fwupdmgr get-devices' output.
A Jcat file can be used to store GPG, PKCS-7 and SHA-256 checksums for multiple
files. This allows us to sign a firmware or metadata multiple times (perhaps
by the OEM and also then the LVFS) which further decentralizes the trust model
of the LVFS.
The Jcat format was chosen as the Microsoft catalog format is nonfree and not
documented. We also don't want to modify an existing .cat file created from WU
as this may make it unsuitable to use on Windows.
More information can be found here: https://github.com/hughsie/libjcat
Quite a few plugins use HID commands to communicate with the hardware. At the
mement we have ~6 implementations of SET_REPORT and are soon to add one more.
Move this into common code.
If we do not ->open() the device (e.g. because it uses a parent device to proxy
writes) then the child never gets a DeviceID which causes all kinds of issues.
When CPU microcode is distributed it typically is versioned in
hexadecimal in all tools. Converting it to any of the existing version
formats provides an unexpected result that requires converting back to
hexadecimal.
If the measurements are missing but it's a UEFI system, it's a good indication
that the user has secure boot turned off.
Notify the user on the UEFI device through a non-fatal `UpdateMessage`
To accomplish this, move fu-uefi-vars into the plugin library for other plugins to use
Use xb_builder_source_add_simple_adapter instead
xb_builder_source_add_adapter to avoid sniffing MIME type for output xml
contents
Signed-off-by: Daniel Campello <campello@chromium.org>
Change-Id: I123c37339720b5844351f85a5aeb9cec4928785c
Replace fu_common_cab_build_silo() with an actual GObject that can hold parsing
state. This cleans up the code a lot, and means we can add additional
functionality in the future without breaking ABI or API.
The long term plan is to verify the metadata and payload signatures when
parsing FuCabinet, rather than much later in _check_requirements().
This of course requires passing in a keyring context (which we don't yet have)
and would mean we can stop setting the various confusing 'fwupd::ReleaseBlob'
XbNode extra data.
No logic changes for now, just a lot of moving things into sane places.
If we say that the version format should be the same for the `version_lowest`
and the `version_bootloader` then it does not always make sense to set it at
the same time.
Moving the `version_format` to a standalone first-class property also means it
can be typically be set in the custom device `_init()` function, which means we
don't need to worry about *changing* ther version format as set by the USB and
UDev superclass helpers.
In 1de7cc we checked the version format when checking for update, but there are
many other places that are doing verfmt-insensitive comparisons. For instance,
the predicates in <requires> all fail if the device version format is plain.
his breaks updating some NVMe drives where the `ne` requirements are not
semantic versions.
To avoid trying to catch all the bugs in different places, and in case we have
a future verfmt that should be treated another way, refactor this out in to a
common function and deprecate the old function.
Sometimes the plugin will want to influence the subclassed device, for instance
by reading a per-plugin config file. At the moment there's no way to do this,
as even _device_registered() is explicitly designed for devices *not* created
by the plugin itself.
Even if _device_registered() was changed to include the plugin creating the
object it would still happen well after the device has done _probe() and/or
_setup() and would probably be too late to do anything useful.
In some hardware there are two identical USB hubs with different firmware.
One is upstream, and one is downstream, making up to 7 user-available ports.
Use the 'removable' bitfield to target the proper firmware to the correct
device, on the logic that the setting will be different on upstream (removable)
and downstream (non-removable, as on the same PCB) hubs.
There's no reason to prevent NULL, and doing so means the caller has to check
before setting the value. Only one subclassed type was actually doing this...
Some hardware does not handle upgrading from version 1.2.2 to 1.2.4 and instead
needs to be upgraded from 1.2.2->1.2.3->1.2.4 so that on-device metadata can be
migrated correctly.
Add a new per-device flag `install-all-releases` which causes the daemon to not
skip directly to the newest release. This is designed to be set from a quirk
file.
This can obviously only be used for devices that can apply firmware "live" and
thus do not need a reboot or system shutdown to actually apply the firmware.
This also needs the cabinet archive to ship multiple versions of the firmware,
and for the metainfo.xml file to refer to multiple release objects.
Dell does not include the first byte in the ESRT value, ignoring it. Using a
`quad` means we get versions like `0.1.4.0` rather than `1.4.0` which confuses
both users comparing versions to the vendor website, and also anyone trying to
do analysis on the firmware.
Add various fixes to enable us to build a selection of useful USB plugins.
Also, skip tests that don't make sense on WIN32 or that will not work.
With much help from Mario Limonciello <mario.limonciello@dell.com> -- Thanks!
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.
This splits out all development files, including headers into their
own packages where relevant.
Notably absent is `fu-hash.h` which is used for determining taint.
Out of tree developed plugins should still taint the daemon.
