This allows the backend to identify the specific device for a specific phase.
For instance, there might be a pre-update runtime, a bootloader and a
post-update runtime and allowing tags to be saved to the backend object allows
us to identify each version of the same physical device.
This takes us one step closer to emulating a complete byte-perfect end-to-end
update without actual hardware installed.
This allows the backend to identify the specific device for a specific phase.
For instance, there might be a pre-update runtime, a bootloader and a
post-update runtime and allowing tags to be saved to the backend object allows
us to identify each version of the same physical device.
This takes us one step closer to emulating a complete byte-perfect end-to-end
update without actual hardware installed.
This feature adds support for platform capability BOS descriptors which allows
the device itself to ship quirk data.
Use `sudo fwupdtool get-devices --save-backends=FILENAME` to save fake backend
devices to a file. This allows easy creation of self tests that do not require
physical hardware.
The thunderbolt plugin reads in 0x80 bytes if we just want to know if a
firmware is native, and 0x224 if we just want the DIGITAL section. The reason
we do this is that reading the entire NVM is really slow.
If we can see the firmware is smaller than the ARC section, read all the
expected data and return success without adding a payload.
By moving the attribute loading into udev it was loading too late
and plugins couldn't use it. Move the loading to earlier in the
daemon and ignore add events if we already have attributes loaded.
Fixes: #4979
This is being used for other products, e.g. USB4 docks.
If non-Intel firmware is being used (e.g. ASMedia) then the explicit
calls to `fu_intel_thunderbolt_nvm_new()` can be changed to something
like `fu_firmware_new_from_gtypes()` with all the formats listed.
This needs to be handled by the daemon so that all GUI clients will
be able to load translations as well.
The translations will be distributed with fwupd, and any GUI client
should look up the translations.
A user can place a JSON file in /etc/fwupd/bios-settings.d/ with
the default desired policy for the machine.
fwupd will load this policy on startup to ensure BIOS settings
are set as desired by the system administrator.
These are currently used interchangeably since there was indecisiveness
which to use as the feature was being developed.
As outward facing it will be named with "settings", change all uses
in the code to match this.
The `--verbose` output for getting BIOS setting info is very noisy
on Lenovo systems due to a mismatch for the driver behavior and
kernel API.
Hide most of it behind an optional environment variable
`FWUPD_BIOS_SETTING_VERBOSE`.
The only information that is secret is the `current_value`.
Augment the d-bus call to determine whether the caller needs this
information.
* If `fwupdmgr` is launched as root it will be provided.
* If `fwupdmgr` is launched with `--authenticate` it will be requested
and PK will be engaged.
The firmware from both Dell and Lenovo actually blocks this, but the
error message is pretty confusing.
```
$ sudo fwupdtool set-bios-setting SecureBoot Disable
17:39:40:0249 FuBiosAttrs KERNEL BUG: thinklmi doesn't export a 'type' attribute
Loading… [- ]
failed to write 7 bytes to 17: Invalid argument
```
Semantically it is the desire of the security attribute, not the bios
attribute, i.e. you could imagine that a specific attribute would have
to be *foo or bar or baz* for HSI-1 and *only foo* for HSI-2
Also make it easier to add possible BIOS attribute target values in
plugin code.
This identifier can be used by plugins or the daemon to disambiguate
behavior between two different drivers.
Set it up so that plugins don't NEED to use it, but optionally can
find attributes by either name or ID
When support was added for falling back to SMBIOS data from the kernel
in /sys/class/dmi, we inadvertently stopped caring about the data parsed
directly from DMI tables as first priority. This caused a regression in
hwids from some OEMs that relied upon IDs that could only be properly built
from DMI tables, not the kernel /sys/class/dmi interface.
Link: https://bugs.launchpad.net/ubuntu/+source/fwupd/+bug/1982103
Fixes: 464425fb5 ("SMBIOS: try reading from /sys/class/dmi if direct access fails")
Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
We want to allow all the device hotplug events to be processed before
marking the update as completed. Otherwise, we might have a situation
where we have a child device attached to a parent, where we want to
update the parent, then the child. e.g.
1. Add parent
2. Add child
3. Update parent
4. Attach parent
5. Wait for parent
...some time passes...
6. Parent re-appears
7. Update finishes, client indicates success
...child update is scheduled...
...which returns with failure as it does not exist...
8. Add child
The child should have been added *before* the update completed to avoid
the caller from needing an unspecified delay as a *workaround*.
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
This means we don't need to worry about changing multiple
implementations if the HSI levels change for a specific ID.
It also means we can fake HSI results in the future without having
to also store the 'correct' level in the input file.
Some parsers are ignoring the magic when using _FLAG_IGNORE_CHECKSUM
(which is wrong; fuzzers have no problem with enforcing a static prefix)
and other either disregard the offset or check the magic in an unsafe
way. Also, use FWUPD_ERROR_INVALID_FILE consistently for magic failure.
Add a vfunc, and move all the clever code into one place.
It is weird to do this when constructing the object, and it allows us
to match PossiblePlugin quirk matches on potentially better instance
IDs added by the superclass.
