With the recent release of new microcode updates (MCUs) to mitigate Microarchitectural Data Sampling (MDS) vulnerabilities, Intel dropped plans to support older generation processors like Nehalem and Westmere. These were supported for L1TF, Spectre and Meltdown vulnerabilities. If you are a Dell shop then these are 11G servers (R610, R710), or G7 servers for HPE. Please review SA00233-microcode-update-guidance to make sure your environment is covered.
Impact of not having the MCU
Microarchitectural Data Sampling (MDS), name given to a collective group of vulnerabilities:
- Microarchitectural Store Buffer Data Sampling (MSBDS) aka Fallout Attack – CVE-2018-12126
- Microarchitectural Fill Buffer Data Sampling (MFBDS) aka ZombieLoadAttack – CVE-2018-12130
- Microarchitectural Load Port Data Sampling (MLPDS) aka RIDL – CVE-2018-12127
- Microarchitectural Data Sampling Uncacheable Memory (MDSUM) – CVE-2019-11091
These attack allow local attackers that are able to execute code to access portions of recently written or loaded data by using speculative execution information leak methods. They are 2 attack vectors
- Single thread, same core or what VMware refers to as Sequential-context attack vector
- Cross Hyper thread or what VMware refers to as Concurrent-context attack vector
Both of these attack vectors have another category when dealing with virtualization:
- Intra-VM – attack vector in the context of the same Virtual Machine
- Inter-VM – attack vector in the context of VM-to-VM and VM-to-Host
For full understanding and step by step guide in mitigating MDS please follow directions from VMware KB articles.
All 4 MDS vulnerabilities require CPU microcode/firmware to mitigate and to fully protect a VMware infrastructure 2 things are needed:
- ESXi Patched which delivers the new MCU
- Enabling the ESXi Side-Channel-Aware Scheduler. This scheduler will then schedule on only one Hyperthread of a Hyperthread-enabled core, with potentially significant consequences as hyperthreading is essentially no longer used. With the release of ESXi 6.7 U2 a new version of this scheduler is supported, please refer to VMware article by Bob Plankers that covers this topic extensively.
Do note that by enabling the ESXi Side-Channel-Aware Scheduler you’re essentially eliminating the Cross Hyper thread (Concurrent-context attack vector) attack surface, for MDS this means that you’re being protected against MSBDS and MFBDS.
Intel makes the distinction that by disabling HT alone does not provide protection against MDS, because you are still vulnerable to the single thread attack vector and here is where the new MCU is critical. The new MCU mitigates this by providing special software sequences called “MD_CLEAR” that flushes the internal CPU buffer and other structures at certain times so that critical data is no longer visible to an attacker.
So systems without the MCU are vulnerable because they don’t have the CPUID MD_CLEAR to carry out the mitigation of flushing the CPU buffers.
Mitigation and Validation
The mitigation guidelines form VMware focuses on Inter-VM as Intra-VM are Operating System-Specific Mitigations. These are applied to guest operating systems which are provided by your OS vendor.
The Inter-VM mitigation process for MDS is divided into three phases (taken from https://kb.vmware.com/s/article/67577)
To validate the state of protection I have 2 test environments
- Test VM running on ESXi 6.5 with Intel Broadwell family CPU
- Test VM running on ESXi 6.0 with Intel Westmere family CPU
All the vSphere environment fully remediated as outlined by the flowchart above
- vCenter patched
- ESXi Patched
- ESXi Side-Channel-Aware Scheduler enabled
On the Guest VM side, both are Windows 2012 R2, both patched and mitigations enabled (Registry keys applied) and power cycled.
Validate VMs using MDS tool from RIDL team
Broadwell CPU VM – has MDS MCU available
Note the following:
- CPU is vulnerable to MDS
- MD_CLEAR CPUID present so this means the ESXi has the new MCU and the Hypervisor-Assisted Guest Mitigations is in place exposing the hardware feature to the VM
Running the Microsoft PowerShell module Get-SpeculationControlSettings to validate mitigation compliance in the guest OS
The result confirms that the VM is being protected against MDS
Westmere CPU VM – What intel IS NO LONGER RELEASING
Note the following:
- CPU is vulnerable to MDS
- MD_CLEAR CPUID NOT present. ESXi fully patched but since there is no available MCU for this CPU family, then there is no support for MD_CLEAR
Running the Get-SpeculationControlSettings module reveals the following:
OS support for MDS mitigation is present, but since the MD_CLEAR CPUID instruction is not available then MDS cannot be mitigated even if the registry keys are in place.
What MCUs are available
As of this writing Intel has released production MCUs supporting all systems manufactured recently (last 5 yrs.), from a server perspective what is still pending is Sandy Bridge family (servers manufactured in ~2012). Dell advisory has an expected release date for the new BIOS version at 09/2019, these are all 12G servers. The VMware VMSA-2019-0008 security advisory makes this distinction as well: “These patches contain updated microcode. At the time of this publication Sandy Bridge DT/EP Microcode Updates (MCUs) had not yet been provided to VMware. Customers on this microarchitecture may request MCUs from their hardware vendor in the form of a BIOS update. This microcode will be included in future releases of ESXi.”
Basically if you are running Ivy bridge and above in your server environment you are covered from a MCU perspective. Sandy Bridge you need to wait for new MCU, Westmere or older, no plans for new MCUs.
If you are running Westmere or Nehalem platforms like Dell R710/R610/m610 or HPE Gen7, YOU ARE NO LONGER IN A SUPPORTED CONFIGURATION BY INTEL. For MDS mitigation you will have to make a business case for new hardware and upgrade to ESXi 6.7 where you can also benefit from the v2 of the scheduler.
If you need more information about MDS, here are some articles to look at: