Xen and the mysterious meltdown vulnerability

Oh, oh dear. Well, that is not the best. I had just updated the Meltdown and Spectre checker script I had been using up to this point to answer a question for a colleague regarding a paravirtualization (PV) platform running Xen. My understanding regarding Xen and Meltdown / Variant 3 / CVE-2017-5754 is now pretty much cut off at the legs. Here are two outputs of the script for two different versions of the script:

Version 0.31

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)

Version 0.34

CVE-2017-5754 [rogue data cache load] aka 'Meltdown' aka 'Variant 3'
* Kernel supports Page Table Isolation (PTI): NO
* PTI enabled and active: NO
* Running as a Xen PV DomU: YES
> STATUS: VULNERABLE (Xen PV DomUs are vulnerable and need to be run in HVM, PVHVM or PVH mode)

WTF and FML right there. Okay, so this was based on seeing the following presented by Xen themselves regarding issues.

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.

However, keep in mind that a successful attack on the hypervisor can still be used to recover information about the same guest from physical memory.

So while a non-patched guest can be abused regarding THAT GUEST - a non-patched guest cannot be used as a backstage pass to the entire host with multiple guests. This being said - the guest I am testing the above on would certainly be 64bit given the fact we are 2018 now and everything.

I have contacted the platform vendor and await clarification.

[UPDATE Thursday 8th February 2018]

Okay - so the above in green apparently holds water. The clarity comes when you realise that they do not run all VM's the same way:

"We launch linux VMs in PV but Debians and Windows in HVM mode on Xen." -- OnApp

Do where does that leave us - as the response is usually to 'see this document' - and you are left going through that with a fine-toothed comb looking for joy. In summary, today, there is no mitigation patch for Xen. Not right now anyway.

"All security patches will be applied to 5.0, 5.5 and 5.7 versions. As soon as Xen provides patches they are applied to our cloud boot images after some tests." -- OnApp

So the catch-all / ready reckoner for right here, right now, to prevent further occurrences of 'are we nearly there yet?' is here in five points - if you read nothing else - read this:

1. Patch your host. Period. Unless it is running CloudLinux7;

2. Debian and Windows VM's run in HVM - so are not protected from meltdown by implication by the Xen kernel;

3. Other Linux VM's - run as PV - and will by implication are offered protection against Meltdown by the Xen kernel;

4. CloudLinux 7 - really struggling to get a viable Xen 4 kernel with patch operable. May not be possible, at all, may be possible on newer versions.

5. Spectre will not go away unless you change your CPU - so look - SQUIRREL!

Now go - be free - live long, and prosper.