Also allow 32MiB images for the coreboot firmware
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Recently we had an update that changed the system-defined Platform Key, and
we've certainly had updates in the past that changed the Boot#### variables.
Store some core ACPI and UEFI system integrity state from before and after the
update which can be used to mark (waivable) test failures on the LVFS.
* plugins/{flashrom,superio]: Add GUIDs for StarBook Mk VI - Intel
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
* plugins/{flashrom,superio]: Add GUIDs for StarBook Mk VI - AMD
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
* plugins/{flashrom,superio]: Add GUIDs for Byte Mk I - AMD
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
A harmless error shows up in debian packages at build time:
```
dpkg-shlibdeps: warning: cannot find library libfwupdplugin.so needed by debian/fwupd/usr/lib/x86_64-linux-gnu/fwupd-1.8.6/libfu_plugin_flashrom.so (ELF format: 'elf64-x86-64' abi: '0201003e00000000'; RPATH: '')
```
This doesn't cause a functional problem because libfwupdplugin has already
been loaded by the daemon by the time these libraries are loaded.
In case the `dpkg-shlibdeps` checker becomes more stringent in the future
fix the warning.
This would allow us to convert more easily to a built-in plugin in the future
and means we match the source style used in 97% of the other plugins.
No logic changes.
Saving the quirks in the GResource section worked well, but it made the build
system very complicated and also meant the .data section was duplicated in
both `fwupd` and `fwupdtool` -- negating a lot of the hard-fought savings.
Simplify this feature so that we just `cat` all the quirk files together, then
gzip them into a single file. This means that at startup fwupd only needs to
check the mtime of one file, and weirdly it's actually faster to load a smaller
compressed file from disk that it is to load multiple uncompressed files.
Add the HwId for the Star LabTop Mk III when using coreboot firmware,
as this differs to AMI.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Set BcrAddr to 0x0 for all coreboot devices, so that the check of
BIOS Control is skipped as coreboot won't forcibly set this.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
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.
Now incorporate is fixed to copy across the properties we need in the
superclass, we don't need to do the subclass ->probe().
Note, we still need to do the subclassed ->probe() when using
FU_UDEV_DEVICE_FLAG_VENDOR_FROM_PARENT or when looking at properties
on the parent device.
This also removes the spurious 'already set GType to FuVliUsbhubDevice,
ignoring FuVliUsbhubDevice' messages when running the daemon.
This avoids possible reading IFD multiple times and fixes a memory leak
of layout on errors and an unconditional leak in
fu_flashrom_device_prepare(), which didn't call
flashrom_layout_release().
Notice that flashrom_layout_set() call does NOT transfer ownership.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Created only if intel_spi plugin indicates that the region exists by
creating its own device for it.
Signed-off-by: Sergii Dmytruk <sergii.dmytruk@3mdeb.com>
Some plugins were creating local versions (which were not attached to
the daemon progress in any way) as a workaround as they needed to do
actions that took a long time to complete.
Flashrom is primarily used with coreboot, which has a pair version number
currently 4.16. As such, chance the default to pair so that fewer quirks
are required.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
