Downloaded and ran the spectre-meltdown-checker.sh
$ spectre-meltdown-checker.sh
Spectre and Meltdown mitigation detection tool v0.39+
Checking for vulnerabilities on current system
Kernel is Linux 4.15.0-33-generic #36-Ubuntu SMP Wed Aug 15 16:00:05 UTC 2018
x86_64
CPU is Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz
Hardware check
* Hardware support (CPU microcode) for mitigation techniques
* Indirect Branch Restricted Speculation (IBRS)
* SPEC_CTRL MSR is available: YES
* CPU indicates IBRS capability: YES (SPEC_CTRL feature bit)
* Indirect Branch Prediction Barrier (IBPB)
* PRED_CMD MSR is available: YES
* CPU indicates IBPB capability: YES (SPEC_CTRL feature bit)
* Single Thread Indirect Branch Predictors (STIBP)
* SPEC_CTRL MSR is available: YES
* CPU indicates STIBP capability: NO
* Speculative Store Bypass Disable (SSBD)
* CPU indicates SSBD capability: YES (Intel SSBD)
* L1 data cache invalidation
* FLUSH_CMD MSR is available: YES
* Enhanced IBRS (IBRS_ALL)
* CPU indicates ARCH_CAPABILITIES MSR availability: NO
* ARCH_CAPABILITIES MSR advertises IBRS_ALL capability: NO
* CPU explicitly indicates not being vulnerable to Meltdown (RDCL_NO): NO
* CPU explicitly indicates not being vulnerable to Variant 4 (SSB_NO): NO
* Hypervisor indicates host CPU might be vulnerable to RSB underflow (RSBA):
NO
* CPU microcode is known to cause stability problems: NO (model 0x2d family
0x6 stepping 0x7 ucode 0x1 cpuid 0x206d7)
* CPU microcode is the latest known available version: NO (latest known
version is 0x714 according to Intel Microcode Guidance, August 8 2018)
* CPU vulnerability to the speculative execution attack variants
* Vulnerable to Variant 1: YES
* Vulnerable to Variant 2: YES
* Vulnerable to Variant 3: YES
* Vulnerable to Variant 3a: YES
* Vulnerable to Variant 4: YES
* Vulnerable to Variant l1tf: YES
CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Mitigated according to the /sys interface: YES (Mitigation: __user pointer
sanitization)
* Kernel has array_index_mask_nospec: YES (1 occurrence(s) found of x86 64
bits array_index_mask_nospec())
* Kernel has the Red Hat/Ubuntu patch: NO
* Kernel has mask_nospec64 (arm64): NO
> STATUS: NOT VULNERABLE (Mitigation: __user pointer sanitization)
CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigated according to the /sys interface: YES (Mitigation: Full generic
retpoline, IBPB, IBRS_FW)
* Mitigation 1
* Kernel is compiled with IBRS support: YES
* IBRS enabled and active: YES (for kernel and firmware code)
* Kernel is compiled with IBPB support: YES
* IBPB enabled and active: YES
* Mitigation 2
* Kernel has branch predictor hardening (arm): NO
* Kernel compiled with retpoline option: YES
* Kernel compiled with a retpoline-aware compiler: YES (kernel reports
full retpoline compilation)
> STATUS: NOT VULNERABLE (Full retpoline + IBPB are mitigating the
> vulnerability)
CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Mitigated according to the /sys interface: YES (Mitigation: PTI)
* Kernel supports Page Table Isolation (PTI): YES
* PTI enabled and active: YES
* Reduced performance impact of PTI: YES (CPU supports PCID, performance
impact of PTI will be reduced)
* Running as a Xen PV DomU: NO
> STATUS: NOT VULNERABLE (Mitigation: PTI)
CVE-2018-3640 [rogue system register read] aka 'Variant 3a'
* CPU microcode mitigates the vulnerability: YES
> STATUS: NOT VULNERABLE (your CPU microcode mitigates the vulnerability)
CVE-2018-3639 [speculative store bypass] aka 'Variant 4'
* Mitigated according to the /sys interface: YES (Mitigation: Speculative
Store Bypass disabled via prctl and seccomp)
* Kernel supports speculation store bypass: YES (found in /proc/self/status)
> STATUS: NOT VULNERABLE (Mitigation: Speculative Store Bypass disabled via
> prctl and seccomp)
CVE-2018-3615/3620/3646 [L1 terminal fault] aka 'Foreshadow & Foreshadow-NG'
* Mitigated according to the /sys interface: YES (Mitigation: PTE Inversion;
VMX: conditional cache flushes, SMT vulnerable)
> STATUS: NOT VULNERABLE (Mitigation: PTE Inversion; VMX: conditional cache
> flushes, SMT vulnerable)
It shows that the microcode is not updated, and reports vulnerability.
If I understand correctly, the Linux VM should not install the
microcode, but report the microcode features of the host.
* CPU indicates STIBP capability: NO
Obviously stibp is not passed to the guest.
Is there any other/better way to pass the host cpu capabilities to the
VM?
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5753
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5754
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-3615
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-3639
** CVE added: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2018-3640
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1788665
Title:
Low 2D graphics performance with Windows 10 (1803) VGA passthrough VM
using "Spectre" protection
Status in QEMU:
New
Bug description:
Windows 10 (1803) VM using VGA passthrough via qemu script.
After upgrading Windows 10 Pro VM to version 1803, or possibly after
applying the March/April security updates from Microsoft, the VM would
show low 2D graphics performance (sluggishness in 2D applications and
low Passmark results).
Turning off Spectre vulnerability protection in Windows remedies the
issue.
Expected behavior:
qemu/kvm hypervisor to expose firmware capabilities of host to guest OS - see
https://docs.microsoft.com/en-us/virtualization/hyper-v-on-windows/CVE-2017-5715-and-hyper-v-vms
Background:
Starting in March or April Microsoft began to push driver updates in
their updates / security updates. See https://support.microsoft.com
/en-us/help/4073757/protect-your-windows-devices-against-spectre-
meltdown
One update concerns the Intel microcode - see
https://support.microsoft.com/en-us/help/4100347. It is activated by
default within Windows.
Once the updates are applied within the Windows guest, 2D graphics
performance drops significantly. Other performance benchmarks are not
affected.
A bare metal Windows installation does not display a performance loss
after the update. See https://heiko-sieger.info/low-2d-graphics-
benchmark-with-windows-10-1803-kvm-vm/
Similar reports can be found here:
https://www.reddit.com/r/VFIO/comments/97unx4/passmark_lousy_2d_graphics_performance_on_windows/
Hardware:
6 core Intel Core i7-3930K (-MT-MCP-)
Host OS:
Linux Mint 19/Ubuntu 18.04
Kernel: 4.15.0-32-generic x86_64
Qemu: QEMU emulator version 2.11.1
Intel microcode (host): 0x714
dmesg | grep microcode
[ 0.000000] microcode: microcode updated early to revision 0x714, date =
2018-05-08
[ 2.810683] microcode: sig=0x206d7, pf=0x4, revision=0x714
[ 2.813340] microcode: Microcode Update Driver: v2.2.
Note: I manually updated the Intel microcode on the host from 0x713 to
0x714. However, both microcode versions produce the same result in the
Windows guest.
Guest OS:
Windows 10 Pro 64 bit, release 1803
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1788665/+subscriptions
