While the flag bytes in Flash on the PS175 indicate which partition it is
desired the device boot, the device may actually boot something else
because it performs some kind of integrity check on firmware images before
booting them. If the image specified by the flag bytes fails validation,
the device instead boots partition 3 which should be treated as read-only.
The device provides a register on I2C that indicates which partition is
actually running, so probe that register rather than assuming the device
is running the image that the flag bytes specify.
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
Having a mutable global flash layout makes it difficult to reason about which
flash regions will be affected by any given flashrom operation. Make copies of
the layout from a template instead, and default-exclude regions from
operations.
If the device is on battery power, the device will have at least one inhibit
and be in FWUPD_DEVICE_FLAG_UPDATABLE_HIDDEN state.
It's still supported, and it's misleading to suggest there are no updates
available. Just check both flags.
Fixes the 3rd half (sic) of https://github.com/fwupd/fwupd/issues/3156
fu_dfu_tool_get_default_device returns a newly create FuDfuDevice
'device'; but since it is marked as g_autoptr, it is destroyed when
leaving the scope and the caller receives garbage.
So steal the pointer before leaving the scope.
,----
| ==697985== Invalid read of size 8
| ==697985== at 0x4B50F49: g_type_check_instance_is_fundamentally_a (gtype.c:4080)
| ==697985== by 0x4B3A988: g_object_unref (gobject.c:3421)
| ==697985== by 0x406CF3: glib_autoptr_clear_GObject (gobject-autocleanups.h:27)
| ==697985== by 0x406DD5: glib_autoptr_clear_FwupdDevice (gusb-autocleanups.h:17)
| ==697985== by 0x406E9C: glib_autoptr_clear_FuDevice (fu-device.h:18)
| ==697985== by 0x406EE3: glib_autoptr_clear_FuUsbDevice (fu-usb-device.h:22)
| ==697985== by 0x406F6A: glib_autoptr_clear_FuDfuDevice (fu-dfu-device.h:19)
| ==697985== by 0x406F88: glib_autoptr_cleanup_FuDfuDevice (fu-dfu-device.h:19)
| ==697985== by 0x40898D: fu_dfu_tool_read (fu-dfu-tool.c:577)
| ==697985== by 0x407518: fu_dfu_tool_run (fu-dfu-tool.c:162)
| ==697985== by 0x4097E0: main (fu-dfu-tool.c:959)
| ==697985== Address 0x67fbfe0 is 640 bytes inside a block of size 672 free'd
| ==697985== at 0x48430E4: free (vg_replace_malloc.c:755)
| ==697985== by 0x4BD124C: g_free (gmem.c:199)
| ==697985== by 0x4BEB76F: g_slice_free1 (gslice.c:1180)
| ==697985== by 0x4B4FDBB: g_type_free_instance (gtype.c:1993)
| ==697985== by 0x406CF3: glib_autoptr_clear_GObject (gobject-autocleanups.h:27)
| ==697985== by 0x406DD5: glib_autoptr_clear_FwupdDevice (gusb-autocleanups.h:17)
| ==697985== by 0x406E9C: glib_autoptr_clear_FuDevice (fu-device.h:18)
| ==697985== by 0x406EE3: glib_autoptr_clear_FuUsbDevice (fu-usb-device.h:22)
| ==697985== by 0x406F6A: glib_autoptr_clear_FuDfuDevice (fu-dfu-device.h:19)
| ==697985== by 0x406F88: glib_autoptr_cleanup_FuDfuDevice (fu-dfu-device.h:19)
| ==697985== by 0x407762: fu_dfu_tool_get_default_device (fu-dfu-tool.c:191)
| ==697985== by 0x408736: fu_dfu_tool_read (fu-dfu-tool.c:592)
| ==697985== Block was alloc'd at
| ==697985== at 0x484086F: malloc (vg_replace_malloc.c:380)
| ==697985== by 0x4BD4938: g_malloc (gmem.c:106)
| ==697985== by 0x4BEC1F4: g_slice_alloc (gslice.c:1069)
| ==697985== by 0x4BEC85D: g_slice_alloc0 (gslice.c:1095)
| ==697985== by 0x4B5511A: g_type_create_instance (gtype.c:1893)
| ==697985== by 0x4B3CB8C: g_object_new_internal (gobject.c:1939)
| ==697985== by 0x4B3E107: g_object_new_valist (gobject.c:2282)
| ==697985== by 0x4B3E63C: g_object_new (gobject.c:1782)
| ==697985== by 0x40B0CF: fu_dfu_device_new (fu-dfu-device.c:571)
| ==697985== by 0x407723: fu_dfu_tool_get_default_device (fu-dfu-tool.c:230)
| ==697985== by 0x408736: fu_dfu_tool_read (fu-dfu-tool.c:592)
| ==697985== by 0x407518: fu_dfu_tool_run (fu-dfu-tool.c:162)
`----
Unloading the GModule means that any GTypes registered by that plugin cannot be
queried.
Other plugins could unintentionally call methods like G_OBJECT_TYPE_NAME()
which makes the daemon explode. There's no need to actually close the module,
and so we're just making life diffult for ourselves for no good reason.
Fixes the other half of https://github.com/fwupd/fwupd/issues/3156
This can be used like this:
fwupdtool firmware-sign firmware.cab rhughes_signed.pem rhughes.key
Test signing certificates can be generated using the example script here:
https://github.com/hughsie/libjcat/blob/master/contrib/build-certs.py although
these certificates should not be used for enterprise use.
Open file description locks are Linux-specific. If fwupd is not built
for Linux, it should use the traditional UNIX record locks (F_SETLK).
Signed-off-by: Norbert Kamiński <norbert.kaminski@3mdeb.com>
If blues takes longer than 1500ms to successfully start, then we will call
fu_bluez_backend_connect_cb() with a freed FuBluezBackendHelper.
Hopefully fixes https://bugzilla.redhat.com/show_bug.cgi?id=1949491
sysfs paths don't have strong guarantees about semantics, so attempting
to parse an I2C bus number out of a sysfs path of some device is likely
to be fragile. Instead take advantage of the device layout to find the
I2C bus an LSPCON is on without trying to parse it out of paths.
The bus the device is on is a sibling device of type i2c-dev, so by
locating an i2c-dev device that is a sibling of the detected LSPCON
device, the /dev path of the bus can be found robustly.
Support for specifying an I2C bus by path rather than number is also
required in flashrom, implemented at
https://review.coreboot.org/c/flashrom/+/51967
Signed-off-by: Peter Marheine <pmarheine@chromium.org>
This function returns a list of sibling devices that have a chosen subsystem,
allowing callers to perform a limited walk of the device tree to locate related
devices.
The dependencies to generate the "updating..." splash screen are non-trivial, and
pointless in headless systems. Add an option to disable the generation entirely.
Don't look for cairo, fontconfig, and freetype libraries as this will
look for *target* libraries. The presence of these libraries is used as
a proxy for the gobject-introspection libraries being available for
the make-images.py script, but as this runs at build time we don't care
about target libraries at all.
Luckily there's another script, test-deps.py, which looks for the g-i
libraries so these dependencies can be removed.
