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>
* HwId for StarLite Mk IV
* coreboot GUID for StarLite Mk IV
* HwId for StarLite Mk II (under coreboot)
* coreboot GUID for StarLite Mk II
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
For a while we flirted with the idea of updating non-internal
libflashrom-derived devices but the impedance mismatch was just too
great.
We removed the extra unused subclasses of FuFlashromDevice, but never
removed the indirection we added for the writing.
Remove the unused code now that we agree on the longer term plan.
Add FirmwareSizeMax = 0x800000 for StarLite Mk II and Mk III to allow
switching from AMI to coreboot firmware.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
tristate features will automatically disable if dependencies marked
as required are missing.
Packagers can manually override using `auto_features`.
Link: https://mesonbuild.com/Build-options.html#features
Add a quirk for NovaCustom NV4x devices.
These laptops are running coreboot and are updatable using flashrom.
The HwId GUID matches to both previous Insyde firmware and the current
Dasharo firmware. The Dasharo GUID matches to the devices running
Dasharo firmware. This way the device can be switched from Insyde
to Dasharo using `fwupdmgr switch-branch`.
Homepage: https://configurelaptop.eu/nv40-series/
Signed-off-by: Michał Kopeć <michal.kopec@3mdeb.com>
At the moment a lot of the failures are only visible when running the
daemon in verbose mode, and the inhibit functionalit provides us a way
to unset FWUPD_DEVICE_FLAG_UPDATABLE from multiple places, as well as
setting the update error for the user to see why.
We were calling g_module_symbol() 2703 times, which is actually more
expensive than you'd think.
It also means the plugins are actually what we tell people they are:
A set of vfuncs that get run. The reality before that they were dlsym'd
functions that get called at pretty random times.
Resetting the CMOS before a write when switching branch will cause a lock on\
reboot which requires hard power off.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
