Intel MDS Guidance – No plans to support Nehalem and Westmere Product Family

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


To validate the state of protection I have 2 test environments

  1. Test VM running on ESXi 6.5 with Intel Broadwell family CPU
  2. 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



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:

Posted in PowerShell

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Edgar Sanchez
%d bloggers like this: