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.
Correctly attach into the alternate mode after the update has completed.
The vendor was appending two files to make LVFS distribution 'easier' but I'd
much rather use the same deliverables as Windows. This also allows us to
simplify the firmware loading.
