Write the firmware to the usb device, first finding which section to
write to, then breaking into blocks (based on maximum pdu size),
and then into chunks, which are transferred to the device using bulk transfers.
The register specifications have been taken as a superset of the coreboot
documentation as different flags were documented in more detail on various
different platforms.
Having this new data allows us to add future tests and make the current tests
much easier to understand.
This makes perfect sense, because the 'initiator' starts the transaction and
the 'target' is the addressee of the transaction. Even the I²C spec defines the
'master' as 'initiating' the transaction.
This is the same nomenclature now used by the Glasgow project too.
This was an overloaded use of UpdateMessage that didn't make sense.
It doesn't affect the functionality of updating, just the security.
Hints about why the TPM PCR0 reconstruction failed should go
to the wiki page not the device.
We'll instead check this when the user tries to run an update. This
allows them to sign a bootloader after the daemon starts (or remove
a signed bootloader after starting)
Fixes: #2219
Trying to explain why ICL thunderbolt isn't updatable doesn't help
people. It just causes fwupdmgr and fwupdtool to show the device
front and center with a confusing message.
Instead don't populate the message and by the default device filter
it will be hidden.
See #2212 for background.
Reading the sysfs file seemed to have also eaten the `\n` as mentioned
on a bug.
```
├DW5821e Snapdragon X20 LTE:
│ Device ID: fa707b9af86ff44bc17316b6c3e5ea82aab3ce86
│ Summary: Mobile broadband device
│ Current version: T77W968.F1.0.0.4.2.GC.010
│ Vendor: Dell Inc. (USB:0x413c
│ )
│ GUIDs: 64da2d58-8d1b-5e5b-b793-f88ba5a25a8f
│ 761d6124-0002-5185-b767-9adf67bf1a5e
│ 795e079d-093b-5503-aa59-35b832480e95
│ Device Flags: • Updatable
```
This allows delaying the activation of Thunderbolt firmware until
shutdown/reboot or when the dock is unplugged.
This functionality requires features in the kernel:
https://lore.kernel.org/linux-usb/20200622143035.25327-1-mario.limonciello@dell.com/T/#t
Matrix of cases to support:
* Distro Old Linux kernel (doesn't support authenticate on disconnect)
- WD19TB: Should have `skips-restart` flag set
No flush or activate features called in `thunderbolt` plugin.
`dell_dock` plugin will activate at end of composite update
- All other devices: Shouldn't have flags set
Should authenticate in Thunderbolt plugin.
`1 > nvm_authenticate`
* Distro New Linux kernel (supports authenticate on disconnect)
- WD19TB: Should have `usable-during-update` flag set but not `skips-restart`
Should flush image to SPI in `thunderbolt` plugin
`2 > nvm_authenticate_on_disconnect`
Should configure TBT device for authenticate on disconnect
`1 > nvm_authenticate_on_disconnect`
`dell_dock` plugin will configure dock for authenticate on disconnect
- All other devices: Shouldn't have flags set
Should authenticate in `thunderbolt` plugin.
`1 > nvm_authenticate`
* ChromeOS (supports authenticate on disconnect)
- `thunerbolt.conf` will have `DelayedActivation=true`.
- WD19TB: Should have `usable-during-update` flag set but not `skips-restart`
Should flush image to SPI in `thunderbolt` plugin
`2 > nvm_authenticate_on_disconnect`
Should configure device for authenticate on disconnect
`1 > nvm_authenticate_on_disconnect`
`dell_dock` plugin will configure dock for authenticate on disconnect
- All other devices: Should have both `usable-during-update` and `skips-restart` set
Should flush image to SPI in `thunderbolt` plugin
`2 > nvm_authenticate`
Will activate upon logout/shutdown/reboot
`1 > nvm_authenticate`
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.
Unfortunately module type has more than I previously realized.
The meanings that previously were applied fortunately worked for
the most important case (130-180W TBT) but didn't for single C, dual
C or small power (45W) cases.
Since composite_prepare was trying to read and interpret these, it
causes failures when these other ones are encountered.
I reproduced this on a 130W adapter plugged into a single C (type 0x4).
This meant the update wouldn't install since NULL was returned for the
type.
In case a new module ID is added later, also return an "unknown" for
the metadata.
Add two new vfuncs that can be used to collect report metadata from devices
both before and after the update has run. This means we can remove the hacks
where we set add 'global' metadata entries and just hope that there is only one
device from the same plugin that is updated.
This also allows us to collect debugging metadata from devices after an offline
update has been run.
As both hub devices share a FuVliUsbhubDeviceClass instance we cannot 'hijack'
the vfuncs depending on object type. This allows the downstream hub to proxy to
the upstream hub where a GPIOB reset can be performed.
We can have multiple FuVliPdDevice objects registered with the daemon, but they
will all share the FuVliPdDeviceClass instance. If one device requries a
silicon workaround, do not 'hijack' the vfunc for all devices of this type.
This means we do the right thing when updating both the one that requires the
workaround, and the 'normal' one.
Provide the following metadata:
"Dirty firmware" bit
Protocol version
Header type
Maximum PDU Size
Flash protection status
Raw version string
Key Version
Minimum rollback
This should do the bulk transfers using protocol 6.
The output here is now equivalent to the output of
usb_updater2 -d 18d1:501a -f
fwupdtool --plugin-whitelist cros_ec get-devices --verbose
Servo Micro
DeviceId: 84d0e3f2a0f8b2328f7995767b23ebb40494723f
Guid: 8e2f7625-a164-55d7-8f09-f193c8ec33f1 <- USB\VID_18D1&PID_501A&REV_0100
Guid: 13564257-c649-586d-b4e4-4f048d480f36 <- USB\VID_18D1&PID_501A
Serial: CMO653-00166-040491U00771
Summary: Servo Micro (aka "uServo") Debug Board
Plugin: cros_ec_usb
Flags: registered
Vendor: Google Inc.
VendorId: USB:0x18D1
Version: servo_micro_v2.4.17-df61092c3
VersionFormat: plain
Created: 2020-05-20
PhysicalId: usb:03:00:02
Although they normally work, some failures have been reported in the field
related to the MST hub not responding in the MST plugin.
When these failures have occurred the dell_dock plugin also fails to
enumerate.
So rather than allow some people who don't have dell_dock compiled to
update their MST hub using synaptics_mst, perform ALL updates for
mst hub via dell_dock.
```
18:06:24:0324 FuPluginSynapticsMST no device found on drm_dp_aux1: VMM5331 inside Dell dock is only supported by dell_dock
```
See also: https://github.com/fwupd/fwupd/issues/2119
Reported-by: Anton Farygin <rider@altlinux.org>
Based on a patch by Gleb Fotengauer-Malinovskiy <glebfm@altlinux.org>
Fixes cross compilation for arm with clang which provides cpuid.h
but helpfully has this error:
```
#if !(__x86_64__ || __i386__)
#error this header is for x86 only
#endif
```
Fixes: #2131
To do this, rely on the AppStream ID to map to a translated string (providing a
fallback for clients that do not care) and switch the free-form result string
into a set of enumerated values that can be translated.
This fixes some of the problems where some things have to be enabled to "pass"
and other attributes have to be some other state. For cases where we want the
user to "do" something, provide a URL to a wiki page that we update out-of-band
of fwupd releases.
This only checks that it was available from the CPU.
To be complete an additional check should be made to show that it
was actually enabled from the firmware.
This will require a kernel modification though because MSR access
will be forbidden from userland while in kernel lockdown.
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.
On a system that is not at all locked down running an old kernel several
of the items are a bit confusing.
```
Runtime Suffix -!
✔ fwupd plugins: OK
✔ Linux Kernel: OK
✘ Linux Kernel: Could not open file
✘ Linux Swap: Not encrypted
```
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
This exports FuSecurityAttrs into libfwupdplugin so that we can pass the plugins
this object rather than a 'bare' GPtrArray. This greatly simplifies the object
ownership, and also allows us to check the object type before adding.
In the future we could also check for duplicate appstream IDs or missing
properties at insertion time.
This change also changes the fu_plugin_add_security_attrs() to not return an
error. This forces the plugin to handle the error, storing the failure in the
attribute itself.
Only the plugin know if a missing file it needs to read indicates a runtime
problem or a simple failure to obtain a specific HSI level.
MATEKF722SE has unconvetional behavior for dfu protocol, where the sector size
isn't specified and sector type is shiffted left by 1. This happens only for
one sector.
Sector parsing from MATEKF722SE:
* `016Kg`
* `64Kg`
* `128Kg`
* `048 e`
* `528e`
* `004 e`
This flag is used internally by plugins to indicate that they will
skip the phase of firmware installation that power cycles a device.
It is intended to be set by quirks or other environment settings.
New enough hardware to have this feature isn't going to be in the marketplace
for a while. To use that newer hardware requires a very recent kernel (5.6 at
least, although it will probably be at least 5.9 by the time the hardware is
released).
The CET status will be used in future functionality.
There was some regression between 1.4.0 and now that prevented updates
containing a Thunderbolt controller from finishing. They would just
sit pending Thunderbolt replug without ever finishing.
Remove the old hack for replug and instead push activation to the end
of the composite steps.
This is to avoid the device tree from changing significantly during
the update process.
This still isn't really ideal, we want to be able to add the flag
usable-during-update to the thunderbolt controller, but this requires
some extra work in the kernel.
Thunderbolt images brought in from the SPI don't have a FARB header.
Thunderbolt update images do.
So these two types of images need to be handled separately from the
firmware parser.
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.
Remove it's references to it's own GUdevclient and instead use
FuUdevDevice.
Some intentional casualties of the move:
* Plugin metadata around native and safe mode dropped.
- These haven't been useful in debugging anything and aren't relevant
on new hardware
* Extra GUID for 2 host controllers in same system dropped
- Although this was normally static information BIOS operations like
turning off PCI-E SD card reader or LAN controller changed things.
* The NVM version is parsed directly instead of through gudev to prevent
cached data breaking change events.
Remaining TODO:
* Force power w/ thunderbolt-power doesn't work
USB4 Controllers were showing up like this:
USB4 Controller:
Device ID: 3df660bc4bdb67fd6fc101b34c6fd8cd235e3f97
Summary: Unmatched performance for high-speed I/O
Current version: 00.00
Update Error: Device is in safe mode
GUID: 4d86f168-e1cc-5995-afd3-ae9df6a14f5e -> TBT-safemode
Device Flags: Internal device
Requires AC power
As a consequence, the version number is also set in the event that the silicon
or firmware app-id is not set, which also seems like the right thing to do.
The idea here is that the device would not come back after it was restarted,
and skipping the attach in the engine was only working around the fact that the
ebitdo did not split out an ->attach() function.
We can't really blame it; we only decoupled the _IS_BOOTLOADER requirement
for ->attach() recently...
The USB 2.0 controller is used as a 'backup' in case the USB 3.0 firmware fails
to start. Set USB 3 hubs as a greater priority so that the USB 2 ones do not
not get added if the USB 3 firmware is working.
These are a regression of 9e755e2a5 when devices are asleep.
However due to the current kernel and daemon architecture, logitech devices
are not checked again at any time so if the device isn't awake when
fwupd is started or the unifying dongle is plugged in it won't be present.
This will be changed in the future when the kernel has change events
associated with devices waking up.
Fixes: #1973
This also means we do the right thing when plugins call fu_device_add_flag()
directly, instead of just from a quirk file.
For instance, now `Flags = ~updatable` is a valid and useful thing to have and
allows us to remove the `Flags = None` hack.
This is nice in theory, until you need to look at the bootloader status of the
parent, or of a different device entirely. Handle this in plugins for the few
cases we care about and stop setting or clearing IS_BOOTLOADER manually just to
get the vfuncs to be run.
Note: I do not think we want to use cleanup() for attaching devices not in
bootloader states -- as cleanup is only run at the end of the composite update.
Doing this unconditionally means we accidentally 'bleed' one device mode into
another in a non-obvious way. For instance, a device might have two operating
modes with different GUIDs. If firmware is supplied for both modes in the same
cabinet archive then we might accidentally match the 'wrong' firmware when
the daemon has observed a mode switch and added the counterpart GUIDs.
We only really need the counterpart GUIDs when switching between Jabra, 8bitdo
and DFU devices where the DFU bootloader VID:PID is not manually tagged with
`CounterpartGuid` in a quirk file. In the general case lets keep it simple to
avoid difficult to find bugs.
The cleanup action for the FuVliUsbhubPdDevice is correct, but was not
conditionalized in the composite cleanup, which meant we would reboot twice
for a normal USB hub update.
Move the parent reboot into the right place, although this does mean we might
reboot twice in the rare event of scheduing a FuVliUsbhubPdDevice *and*
FuVliUsbhubDevice update in the same transaction -- but resetting the device
state between updates is arguably correct anyway...
The VID:PID of the device in HPI mode is shared between multiple vendors, and
so we need to use both the silicon ID and the application ID to match specific
firmware updates.
This allows the PCI topology to change, but assumes that thunderbolt host controllers
are enumerated in the same order every time.
It won't matter if the first controller jumped from bus 5 to 7 and consequently the
second from 65 to 71, but rather that the first was enumerated followed by the second.
