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.
If the measurements are missing but it's a UEFI system, it's a good indication
that the user has secure boot turned off.
Notify the user on the UEFI device through a non-fatal `UpdateMessage`
To accomplish this, move fu-uefi-vars into the plugin library for other plugins to use
In theory, these should always match the reported PCRx values from the TPM.
If the reconstructed event log checksum does not match the TPM value then
something is either implemented wrongly, or something bad has happened.