improve microcode handling

[stbuehler]

Opening yet another issue for this, and linking various other issues similar to this.

I'm using needrestart as part of my icinga monitoring, and checks with an unknown result are rather... sad. I can (and did) disable the microcode check completely, but if now firmware updates actually would become available I won't see them in the monitoring.

I think the unknown result (in nagios/icinga language) should be reserved for "missing tools / missing data" and potentially certain timeouts / too failures.

To achieve this I suggest adding an "unavailable" status (or whatever name to use), indicating that you don't need to install/setup additional stuff (which wouldn't count as error in icinga), and you simply aren't expected to do anything about it.

Such status could be used in these situations:

• Known platform without firmware in the first place (microcode check is currently skipped for vms/containers)
• Known platform with firmware installed, but none matching your processor
• Maybe simply ignore unknown platforms?

Especially the Intel uCode check shouldn't run on AMD platforms - is there any reason not to check for GenuineIntel the way the AMD code checks for AuthenticAMD?

Related issues:

• 149 - no microcode available for AMD cpu

• 220 - unsupported platform (ARM)

• 249 - 3 outputs: one without installed AMD microcode, one working, one with installed AMD microcode, but no microcode for the cpu in use.

[fritz-fritz]

@stbuehler would you mind looking over the pull requests i've submitted?

[anarcat]

@stbuehler i submitted #290 to avoid warning when there's no available microcode file and #288 to fix detection in the AMD case, let me know if that works for you, the former PR is marked as fixing this issue.

[fritz-fritz]

Bumped #284 with the suggested changes. It prevents Intel checks from being run on non-Intel platforms.

I think between this and #290 we will have addressed all outstanding related issues.