We were calling g_module_symbol() 2703 times, which is actually more
expensive than you'd think.
It also means the plugins are actually what we tell people they are:
A set of vfuncs that get run. The reality before that they were dlsym'd
functions that get called at pretty random times.
The fact that it currently lives in uefi-capsule is a historical
accident, and it doesn't really belong to tpm-eventlog either.
Fixes some of https://github.com/fwupd/fwupd/issues/3901
This indicates the GUID in some way contributed to the result decided.
It also allows us to match the submitted HSI results back to a firmware
stream on the LVFS, which allows us to allow vendors to see a subset of
results for uploaded devices.
There are now multiple plugins using drm_dp_aux_dev interface which
may potentially be combined with an amdgpu. Prevent exercising this
interface with any plugin using DP aux unless a new enough kernel is
installed.
There is a lot of code in fwupd that just assigns a shared object type to
a FuPlugin, and then for each device on that plugin assigns that same shared
object to each FuDevice.
Rather than proxy several kinds of information stores over two different levels
of abstraction create a 'context' which contains the shared *system* state
between the daemon, the plugins and the daemon.
This will allow us to hold other per-machine state in the future, for instance
the system battery level or AC state.
When this is done, include:
* Including the hash
* Including anything that is not ABI stable in plugins yet
Suggested-by: Simon McVittie <smcv@debian.org>
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.
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
