Better detect Xen guest type + add container detection
CVE-2017-5754: when we see Xen but we're inside a container,
/proc/xen/capabilities isn't exposed and dmesg is the host's,
so dom0 vs PV DomU can't be told apart. Don't report VULN in
that case, but UNKNOWN instead, and ask to rerun the script on the host.
(cherry picked from commit 1211c21261)
Addresses issue #336: when running inside a VM (KVM, VMware, ESXi,
Hyper-V, VirtualBox), the hypervisor can present a fake CPUID and
microcode version to the guest, making the microcode up-to-date check
meaningless or misleading.
Changes:
- Add is_running_as_guest() to 370_hw_vmm.sh: detects VM guest status
by checking for the 'hypervisor' CPUID flag in /proc/cpuinfo, which
is exposed by KVM, VMware, Hyper-V, VirtualBox and most other
hypervisors. Result is cached in g_is_guest_vm / g_is_guest_vm_reason.
- Add "Running as VM guest: YES/NO" line to the CPU details block in
check_cpu() (400_hw_check.sh), shown for both x86 and ARM guests.
- Add a pr_warn block after the microcode-is-latest check in check_cpu()
advising the user to verify microcode information on the hypervisor
host when a VM guest is detected.
- Add minimal ARM CPU details block in check_cpu(): vendor, model name,
implementer(s), part(s), architecture(s), and VM guest status. ARM CPUs
previously got no output from check_cpu() due to the x86-only early
return guard.
- Expose guest VM status in JSON output (250_output_emitters.sh):
- system section: guest_vm (bool) and guest_vm_reason (string)
- cpu_microcode section: unreliable_in_vm (bool)
Stéphane Lesimple