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.
If a plugin whitelist is set, the HSI value will be wrong.
```
$ sudo ./build/src/fwupdtool security --force --plugin-whitelist=tpm
Loading… [***************************************]
Host Security ID: HSI:1
HSI-1
✔ TPM: v2.0
Runtime Suffix -U
✘ Firmware Updates: No system device
Runtime Suffix -A
✘ Firmware Attestation: No PCR0s
Runtime Suffix -!
✔ fwupd plugins: OK
```
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.
The HSI specification assigns a simple text ID to the current state of firmware
security. As new vulnerabilities are found, and as protection measures are
updated, new requirements will be added to the required firmware behaviours for
each HSI value.
The HSI specification is currently incomplete and in active development, and
so the --force flag is required in all command line tools. The current ID value
will probably change on a given platform so please do not start using the result
for any kind of compliance requirements.
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.
