Meltdown and Spectre

Meltdown and Spectre exploit critical vulnerabilities in modern processors. These hardware design vulnerabilties allow programs to potentially steal data which is currently being processed on the computer. While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs. This might include your passwords stored in a password manager or browser, your personal photos, emails, instant messages, business-critical documents, or the contents of a separate virtual machine or secure container.

In a modern processor, to keep pipelines full and use registers and cache most efficiently, most every  processor supports out-of-order execution (Intel, AMD, others)    Out-of-order and speculative execution is a key feature for high performance processors to improve performance.  In concept, the processor should, and does, throw away results that are speculatively executed and not needed, but researchers have confirmed such execution affects the cache, and creative coders can access and exploit confidential information via the cache “side-channel”  While most of memory is protected, certain data, accessed at the right time in the cache is not.

These flaws have been around for 20+ years, but no one had quite coded up an exploit until recently.  I worked on many of these Performance Architecture designs in college and at Intel in the 90’s — pipelining, super-pipelining, and speculative execution.  Also did lots of performance analysis of processor caching and sizing especially comparing performance between .  Interestingly, I was also on the front-lines answering support calls in the 90’s when Intel had it’s FDIV Pentium flaw — 

Access and dumping such data from the cache has significant implications for applications running in shared environments especially in environments using containers such as Docker.

It is definitely unfair in the market that AMD saw an initial stock bump (on subsequently taken back comments they weren’t vulnerable) while Intel stock was penalized by more than 5% drop.  While there has always been some trade-offs of security versus performance — we place a great deal of trust in the underlying processor hardware.  Stocks have stabilized today, but billions of $ exchanged hands.

I wasn’t a fan of Intel’s initial press-releases on the issue but later releases better, and their follow-on analysis papers have more meat and detail, and Intel and vendors seem on track to patch these issues hopefully without a huge performance penalty.

Technical Details

Lots of technical detail and the full research papers are here:    Intel supported this research with it’s Bug Bounty program and the release of the information should have all been done by “responsible disclosure” but appeared to leak out a little earlier before all players had patches in place.

Reading Privileged Memory through a Side Channel (Google Project Zero) –

Intel has done a deep analysis of speculative execution side-channels:

More on Meltdown (wikipedia) – 

Info on Spectre (wikipedia) –

Industry Response

Google Mitigations against the attack –

Google More Mitigations Deployed –

Amazon Advisory Bulletin –

Okta Security Bulletin –

ARM whitepaper –

Apple Response –

Microsoft Azure Update –

Suse Linux Patches –

VMWare –

Zen Explanation –

Future Mitigations

Some of the deeper technical changes being proposed by Intel include:

  1. Insertion of a LFENCE instruction periodically in code.
  2. New interfaces between system software and processor including capabilities such as Indirect Branch Restricted Speculation; Single Thread Indirect Predictors, and Indirect Branch Predictor Barrier.
  3. Return Trampoline
  4. Rogue Data Cache Load Mitigation.

Plus Hardware features that exist of are coming including:

  1. Intel OS Guard aka Supervisor-Mode Execution Prevention – limits which memory addresses can be accessed for cahce based side chancel
  2. Execute Disable Bit – clasifies areas of memory where application code can’t execute, even speculatively
  3. Control Flow Enforcement Technology
  4. Protection Keys

Leave a Reply

You must be logged in to post a comment.