Asking the user for the UID mapping isn't working very well, as it requires lots
of manual handholding. It also doesn't work very well when the device vendor
does not actually have a PCI ID or if the vendor has split into two entities.
Just use the OUI address as an additional VendorID and match any of the device
IDs against any of the metadata-supplied values.
Some vendors really really want 1.5.x in newer RHEL versions, but the version
of curl is too old. Add #ifdefs so that we can emulate (somewhat imperfectly)
the 'new' CURLU functonality.
The former drags on glib-networking and then gsettings-desktop-schemas, which
add over 5Mb to the minimal IoT and CoreOS composes. Everything already uses
libcurl (even NetworkManager!) and so this is an easy way to reduce image size.
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 is installed by default, but means it can be excluded from the minimal
CoreOS image. It's highly unlikely that anything running CoreOS has anything
unlocked that can be flashed using flashrom.
This drops inclusion of dmidecode, libftdi, pciutils-libs and flashrom as hard
dependencies from the package set.
This is installed by default, but means it can be excluded from the minimal
CoreOS image. It's highly unlikely that anything running CoreOS has mobile
broadband hardware attached.
This drops inclusion of libmbim, libqmi and ModemManager-glib as hard
dependencies from the package set.
Newer version of libgusb has g_usb_device_get_configuration_index which
will be used by cros-ec plugin.
Skip bumping this dependency on Debian and Ubuntu as of this commit date,
they don't know about 0.3.5 yet.
We ship 4 *tiny* python scripts that are useful for ODMs and other people
working with low level firmware blobs.
These helper utilities do not warrant dragging Python onto the CoreOS image.
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
