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.
We were using 0x0 and 0xFFFF in different places, and only checking the
former in most cases. Just restrict the range to 0xFFFE and use 0x0 as
*invalid or not set* as before.
