Semantically it is the desire of the security attribute, not the bios
attribute, i.e. you could imagine that a specific attribute would have
to be *foo or bar or baz* for HSI-1 and *only foo* for HSI-2
Also make it easier to add possible BIOS attribute target values in
plugin code.
This means we don't need to worry about changing multiple
implementations if the HSI levels change for a specific ID.
It also means we can fake HSI results in the future without having
to also store the 'correct' level in the input file.
We tried to solve this by matching the org.fwupd.hsi AppStream ID, but
in some cases the resolution depends on what actually failed.
Add "the action the user is supposed to do" as flags so that the
front-end can translate this in the appropriate way, for instance,
using a different string for log events and HSI dialogs.
TSME and SME can technically both be enabled at the same time, but
there is no use in reporting one as enabled and the other disabled.
They share the same attribute, and so if one is enabled, obsolete
it in the other plugin.
Granted; this is a bit of a confusing experience. You have two attributes
that mean similar but not the same things. You can technically have SME
and TSME both enabled at the same time, or both disabled at the same time.
This method does not indicate whether the kernel has enabled encryption.
That information is only visible from the kernel log at this time.
Continue to read the MSRs though, because if/when we get a method for the
kernel to export it we may use these as a basis of "support" but not a
indication of it being enabled.
encrypted:
```FuPluginMsr SME/SEV check MSR: eax 01000f, ebx 016f
FuPluginMsr PCI_MSR_AMD64_SYSCFG: 0f40000, sme_is_enabled=1
FuPluginMsr PCI_MSR_AMD64_SEV: 00, sev_is_enabled=0
```
not_encrypted:
```
FuPluginMsr SME/SEV check MSR: eax 01000f, ebx 016f
FuPluginMsr PCI_MSR_AMD64_SYSCFG: 0f40000, sme_is_enabled=1
FuPluginMsr PCI_MSR_AMD64_SEV: 00, sev_is_enabled=0
```
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.
I'm finding errors in a crostini container that the MSR plugin tries
to run and fails later. The plugin just shouldn't be passing startup
if /dev/cpu isn't present.
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.
There are now two 'backends' of device plug/unplug events, and there is about
to become three. Rather than just adding two more vfuncs for every backend type
define common ones that all providers can use.
Also fix up the existing in-tree plugins to use the new vfunc names and filter
on the correct GType.
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>
This is much more efficient than parsing hundreds of lines of /proc/cpuinfo
and also causes hundreds of thousands less allocations at startup. For systems
with dozens of virtual CPUs the deduplication of device objects was increasing
start up time considerably.
Use the msr plugin to read the microcode version as this is not obtained using
CPUID, as it is instead being provided in an MSR.
