Otherwise the following build error happens:
../fwupd-1.5.6/plugins/system76-launch/fu-system76-launch-device.c:117:9: error: ‘G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER’ undeclared (first use in this function)
117 | G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../fwupd-1.5.6/plugins/system76-launch/fu-system76-launch-device.c:133:11: error: ‘G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER’ undeclared (first use in this function)
133 | G_USB_DEVICE_CLAIM_INTERFACE_BIND_KERNEL_DRIVER,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This plugin supports reading the keyboard firmware version at runtime and
rebooting the keyboard to USB DFU mode. Tested with firmware uploaded to
embargo-system76.
The coreboot plugin never actually gained the ability to write. As it stands a
coreboot system now adds *two* system-firmware devices (from both flashrom and
coreboot) which isn't ideal.
Just allow flashrom to enumerate quirked devices and add coreboot-specific
metadata as required. If we require some kind of cbfs parsing then we can do
that in FuFlashromDevice->prepare_firmware().
For fuzzing we want to exclude libcurl support as it depends on other very heavy
libraries like OpenSSL or libtasn which make the fuzzing binary much larger if
linked statically.
This is not complete enough for LVFS-usage, but good enough to use with commands
such as fwupdtool. It's likely newer kbd and tp firmware will be required to
integrate with the fwupd in all required ways.
This plugin is only enabled when coreboot isn't detected.
It intentionally does not check for EFI to be disabled at startup
since it can also notify the user that UEFI capsule updates are
disabled on the system even if running in UEFI mode.
The kernel patches are a log way from being upstreamed, so disable this until
there is even a chance the user might be running it.
This removes the obsoletes line from *every* system running 'fwupdmgr security'.
We can read this from userspace even when SB is turned on and with the kernel
locked down. The kernel securityfs patches are still in-progress, but will take
significant time to get upstream.
The kernel patches are needed when the PCI device is hidden from userspace.
The HSI specification is currently incomplete and in active development.
Sample output for my Lenovo P50 Laptop:
Host Security ID: HSI:2+UA!
HSI-1
✔ UEFI dbx: OK
✔ TPM: v2.0
✔ SPI: Write disabled
✔ SPI: Lock enabled
✔ SPI: SMM required
✔ UEFI Secure Boot: Enabled
HSI-2
✔ TPM Reconstruction: Matched PCR0 reading
HSI-3
✘ Linux Kernel S3 Sleep: Deep sleep available
HSI-4
✘ Intel CET: Unavailable
Runtime Suffix -U
✔ Firmware Updates: Newest release is 8 months old
Runtime Suffix -A
✔ Firmware Attestation: OK
Runtime Suffix -!
✔ fwupd plugins: OK
✔ Linux Kernel: OK
✔ Linux Kernel: Locked down
✘ Linux Swap: Not encrypted
The kernel interface for force power doesn't support tracking the state
of the device, and so this had to be tracked by fwupd.
Unfortunately due to system and thunderbolt controller firmware behavior
on some systems the thunderbolt controller /still/ didn't return even
when force power state was accurately tracked.
The device model for the uevent related to the device removal being ignored
doesn't really fit into the current fwupd architecture anymore either.
Lastly this is a very legacy feature at this point. Thunderbolt3 controllers
distributed in the last 3 years all operate in 'native' mode meaning that
they will always be powered and use runtime power management.
USB4 controllers won't have a concept of being force powered.
USB4 reimers will have this concept, but the state will be tracked by the
kernel and obfuscated from userspace.
So with all that said, tear out all of the force power related code.
These are visually similar to Intel hex files, but different enough to demand
their own parser. Multiple images can be stored in one firmware file, with the
`addr` set to the SiliconID and the `idx` set to the position in the file.
This also lets us remove the call to dfu_device_wait_for_replug() which was
causing a deadlock due to unsafe main context usage. Splitting the code allows
us to use the device list to watch for replug, without adding even more Jabra-
specific plugin code to the DFU plugin.
Looking at this with a 40,000ft view, the Jabra runtime really doesn't have
much in common with DFU and the reason it was originally all lumped together
was that the daemon couldn't "change" plugins between detach and update.
It's unfortunate that we have to include a sleep() in the DFU code after the
DFU probe, but this is specified by Jabra themselves. Attempting to open the
device without waiting reboots the hub back into runtime firmware mode, so we
can't even retry the failing setup action.
