This reverts commit 960b6141a6 as
fu_context_load_hwinfo() needs to load the HWID quirks, and we need to load the
plugins before the quirks otherwise we'll get warnings about quirk keys not
being registered.
The LVFS crept over this limit yesterday. I've put some emergency commits in
place that take it back down to 800KB, and I'll focus next week on getting it
much lower than that.
The real problem is that we thought that g_input_stream_read_bytes() was using
`count` as the chunk size, not the total size. Raise the total size to 32MB and
chunk in 32kB blocks to reduce the RSS peak when loading metadata.
Fixes https://github.com/fwupd/fwupd/issues/5173
This means we might be able to offer two versions of firmware for the same
device, where one has additional requirement such as a CHID.
The idea here is to allow OEMs to distribute thier own superset dbx updates on
the LVFS without having to invent an anti-CHID requirement type.
This adds 7 pointer-size blocks of wasted space for each modular plugin, and
three pointers for builtin plugins, but allows us to use the exact same vfuncs
when building plugins in either mode.
This will allow us to convert nearly all the plugins to being builtin.
We now have two plugins getting the ESP values, and we only allow hardcoding
the ESP in uefi_capsule.conf.
Make all this a lot simpler by moving the ESP+BDP code to `FuContext`, which
also means we can handle the override (via the config file) in the engine,
and the override (in the command line tools) using the same mechanism.
Also, automate the migration of the `OverrideESPMountPoint` -> `EspLocation`
when loading the engine.
Fixes https://github.com/fwupd/fwupd/issues/5042
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.
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.
The logic being that if we're emulating another system we're possibly
on a VM, and that's possibly going to report that it isn't a desktop.
I also think it makes sense to serialize out the FuSmbios object
to-and-from JSON, but that's a patch for another day.
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.
Dell and Lenovo use Enable or Enabled and Disable or Disabled which is confusing
to an end user.
Set up some heuristics to map positive values and negative values when passed
into the client.
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.
We used the firmware builder functionality to either build or modify
firmware images on the end-user system, e.g. copying the MAC address
from the old system image to the new system image.
Unfortunately running fwupd on the command line (e.g. ./src/fwupd)
leaves the tty connected and thus bubblewrap doesn't protect us from
installing malicious signed firmware. The firmware would have to have
been uploaded to the LVFS by a trusted vendor and signed before being
installed, which further decreases the severity of this problem.
As there was only one vendor who asked for this functionality (who have
yet to upload a single firmware to the LVFS...) just rip out this
functionality to reduce our attack surface and completely fix the bug,
and any like it.
Many thanks to Aaron Janse <aaron@ajanse.me> for discovering and
disclosing this issue to us.
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 makes it easier to debug, as this shows what the checksum would be
stored in the history database on successful update.
We're already generating them, and so it's really just being helpful.
We tried to solve this by matching the org.fwupd.hsi AppStream ID, but
in some cases the resolution depends on what actually failed.
Add "the action the user is supposed to do" as flags so that the
front-end can translate this in the appropriate way, for instance,
using a different string for log events and HSI dialogs.
