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
