fix: zenbleed (CVE-2023-20593) handle the VM guest case (#488)

Zenbleed (CVE-2023-20593) is mitigated either by up-to-date CPU microcode
or by the host kernel setting FP_BACKUP_FIX (DE_CFG MSR 0xc0011029 bit 9).
Both are applied at the host level. Inside a Xen dom0/domU (or any VM
guest) the script can't read that MSR and can't trust the microcode
version the hypervisor presents, so it wrongly concluded "kernel too old
+ microcode not fixed" and reported VULN even though the host had applied
the microcode fix (passing on bare metal).

In live mode, when the verdict would be VULN and we're running as a guest,
report UNK instead, explaining the mitigation is host-level and not
observable from inside the guest. Bare metal is unchanged (still VULN),
offline analysis is unchanged, and a guest with positively-confirmed
fixed microcode still reports OK.

src/vulns/CVE-2023-20593.sh

@@ -103,13 +103,23 @@ check_CVE_2023_20593_linux() {
             fi
         fi
         if [ "$zenbleed_print_vuln" = 1 ]; then
-            pvulnstatus "$cve" VULN "Your kernel is too old to mitigate Zenbleed and your CPU microcode doesn't mitigate it either"
+            if [ "$g_mode" = live ] && is_running_as_guest; then
-            explain "Your CPU vendor may have a new microcode for your CPU model that mitigates this issue (refer to the hardware section above).\n " \
+                # Both Zenbleed mitigations are applied at the host level: an
-                "Otherwise, the Linux kernel is able to mitigate this issue regardless of the microcode version you have, but in this case\n " \
+                # up-to-date microcode, or the host kernel setting FP_BACKUP_FIX
-                "your kernel is too old to support this, your Linux distribution vendor might have a more recent version you should upgrade to.\n " \
+                # in DE_CFG. From inside a guest we can't read that MSR and can't
-                "Note that either having an up to date microcode OR an up to date kernel is enough to mitigate this issue.\n " \
+                # trust the microcode version the hypervisor presents, so we can't
-                "To manually mitigate the issue right now, you may use the following command: \`wrmsr -a 0xc0011029 \$((\$(rdmsr -c 0xc0011029) | (1<<9)))\`,\n " \
+                # confirm or deny the mitigation -- don't cry VULN (#488).
-                "however note that this manual mitigation will only be active until the next reboot."
+                pvulnstatus "$cve" UNK "Zenbleed mitigation can't be verified from inside a VM guest ($g_is_guest_vm_reason): it may be applied by the hypervisor host, but that isn't observable from here"
+                explain "Zenbleed is mitigated either by an up-to-date CPU microcode or by the host kernel setting the FP_BACKUP_FIX bit (DE_CFG MSR 0xc0011029 bit 9). Both are host-level: a guest can neither read that MSR nor trust the microcode version the hypervisor presents (see the VM note in the hardware section above). Re-run this script on the hypervisor host to get an accurate result."
+            else
+                pvulnstatus "$cve" VULN "Your kernel is too old to mitigate Zenbleed and your CPU microcode doesn't mitigate it either"
+                explain "Your CPU vendor may have a new microcode for your CPU model that mitigates this issue (refer to the hardware section above).\n " \
+                    "Otherwise, the Linux kernel is able to mitigate this issue regardless of the microcode version you have, but in this case\n " \
+                    "your kernel is too old to support this, your Linux distribution vendor might have a more recent version you should upgrade to.\n " \
+                    "Note that either having an up to date microcode OR an up to date kernel is enough to mitigate this issue.\n " \
+                    "To manually mitigate the issue right now, you may use the following command: \`wrmsr -a 0xc0011029 \$((\$(rdmsr -c 0xc0011029) | (1<<9)))\`,\n " \
+                    "however note that this manual mitigation will only be active until the next reboot."
+            fi
         fi
         unset zenbleed_print_vuln
     else