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.
This is nice in theory, until you need to look at the bootloader status of the
parent, or of a different device entirely. Handle this in plugins for the few
cases we care about and stop setting or clearing IS_BOOTLOADER manually just to
get the vfuncs to be run.
Note: I do not think we want to use cleanup() for attaching devices not in
bootloader states -- as cleanup is only run at the end of the composite update.
Sometimes the plugin will want to influence the subclassed device, for instance
by reading a per-plugin config file. At the moment there's no way to do this,
as even _device_registered() is explicitly designed for devices *not* created
by the plugin itself.
Even if _device_registered() was changed to include the plugin creating the
object it would still happen well after the device has done _probe() and/or
_setup() and would probably be too late to do anything useful.
