Xen based VM’s immune to Meltdown?

Humour me a moment - it would appear that the current stock Xen Paravirtualization is showing as not vulnerable to the Meltdown CVE-2017-5754 or Variant 3 attack.

So - what am I basing it on - well the stock test basically - have a look see for yourself:

root@meh [11:28:14] [~]
-> # ./check-m-and-s.sh

Spectre and Meltdown mitigation detection tool v0.31

Checking for vulnerabilities against running kernel Linux 3.10.0-714.10.2.lve1.4.77.el7.x86_64 #1 SMP Tue Dec 5 17:19:40 EST 2017 x86_64
CPU is Intel(R) Xeon(R) CPU E5-2630 v3 @ 2.40GHz

CVE-2017-5753 [bounds check bypass] aka 'Spectre Variant 1'
* Checking count of LFENCE opcodes in kernel: NO
> STATUS: VULNERABLE (only 21 opcodes found, should be >= 70, heuristic to be improved when official patches become available)

CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
* Mitigation 1
* Hardware (CPU microcode) support for mitigation
* The SPEC_CTRL MSR is available: NO
* The SPEC_CTRL CPUID feature bit is set: NO
* Kernel support for IBRS: NO
* IBRS enabled for Kernel space: NO
* IBRS enabled for User space: NO
* Mitigation 2
* Kernel compiled with retpoline option: NO
* Kernel compiled with a retpoline-aware compiler: NO
> STATUS: VULNERABLE (IBRS hardware + kernel support OR kernel with retpoline are needed to mitigate the vulnerability)

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): NO
* PTI enabled and active: NO
* Checking if we're running under Xen PV (64 bits): YES (Xen PV is not vulnerable)
> STATUS: NOT VULNERABLE (Xen PV 64 bits is not vulnerable)

A false sense of security is worse than no security at all, see --disclaimer

Which to me looking at that - well STATUS: NOT VULNERABLE there - so I headed over to Xen's documentation on the subject for reference and found this:

Only Intel processors are impacted by Meltdown (referred to as Variant 3 in Advisory 254). On Intel processors, only 64-bit PV mode guests can attack Xen using Variant 3. Guests running in 32-bit PV mode, HVM mode, and PVH mode (both v1 and v2) cannot attack the hypervisor using Variant 3. However, in 32-bit PV mode, HVM mode, and PVH mode (both v1 and v2), guest userspaces can attack guest kernels using Variant 3; so updating guest kernels is advisable.

Interestingly, guest kernels running in 64-bit PV mode are not vulnerable to attack using Variant 3, because 64-bit PV guests already run in a KPTI-like mode.

So - while I am waiting on OnApp for a Xen fix - the underlying HV appears to have halved the threat surface from the get-go - with the virtual machines patched where possible. Good news. Happy Happy Joy Joy.

Leave a Reply

Your email address will not be published. Required fields are marked *