Intel And The Meltdown And Spectre Vulnerabilities Explained

Summary

• In this article, we go over the newly discovered Meltdown and Spectre vulnerabilities that affect Intel-based CPUs, explain how they work, and what can be done to mitigate the problem.
• We then look at AMD and ARM based CPUs to see if they are also vulnerable.
• Finally, we discuss how this blow to Intel can be an opportunity for AMD.

(Spectre and Meltdown Logos from MeltdownAttack.com.)

On January 3, 2018, Jann Horn from Google's Project Zero published a blog post explaining two vulnerabilities in the architecture of modern CPUs that their team has found. These vulnerabilities have been dubbed Meltdown and Spectre. This article will explain these vulnerabilities and their impact on Intel (INTC), Advanced Micro Devices (NASDAQ:AMD), and other CPU vendors.

Background

To better understand these vulnerabilities we first need a little bit of background. We will look at the way modern operating systems work and how Virtual Private Servers (VPS) work. These concepts are integral to understanding Meltdown and Spectre and why these will be very difficult vulnerabilities to fix quickly.

(Photo of Storage Units from Pixabay.com.)

This is a very complex and technical subject. To explain it, I am going to use a physical world analogy of a storage locker company to make this subject a little less theoretical. In this imagined storage company, users can rent one or more storage lockers and access them at any time but the access to the lockers is controlled by the manager of the facility. It's the best analogy I could come up with, and it might make this highly technical subject more understandable. Let me know in the comments if I succeeded.

Modern Operating Systems

(Diagram of a Linux OS from TutorialsPoint.com.)

The best way to think of an operating system (OS) is as a low-level program that allows you to run other programs. In our analogy, the OS is the storage company. Extremely simplified, an operating system consists of a kernel, a shell, and some UserLand software.

The kernel is a program that directly interacts with the hardware of the computer. Drivers for the CPU, GPU, keyboard, wifi modem, and all the other hardware live in the kernel. The idea behind the kernel is to provide an obstruction layer to the rest of the OS. Your word processor doesn't need to know how to interact with the keyboard or the screen because the kernel provides that functionality. In our analogy, this is the company that operates the storage facility.

If the Kernel is the management company, then the shell is more like the individual manager on duty who is supervising user access to the individual storage units. Basically, the shell is the program that runs on top of the kernel and allows you to launch other programs. In Windows and macOS, it's the Desktop you see when you log in, in Linux it's the command prompt shell.

Finally, UserLand is the group of software that you run on your computer. Your browser, mail program, etc. In our analogy, these would be the individual customers who rent the storage units.

Virtual Private Servers

Computers are really powerful nowadays and renting out an entire individual computer is inefficient. Companies like Amazon (AMZN) rent out a portion of a computer to customers using various computer virtualization methods. Each virtual computer is known as a Virtual Private Server. Each VPS looks to all of the UserLand software exactly like a normal computer, but in reality, many separate VPSs can be hosted on a single computer and they all share the same physical resources and the same kernel (in most cases).

(Illustration of a VPS from HostSlim.eu.)

To map this concept to our analogy, imagine that a very large storage facility has a business model where it allows other companies to rent out large blocks of lockers in their facility to operate their own storage businesses. Kind of like a contractor and sub-contractor model.

Meltdown

OK, now that we have a basic understanding of how OSs and VPSs work, let's talk about the actual Meltdown vulnerability. Every program on a modern operating system runs in its own memory space in the random access memory (RAM). The basic security presumption is that one program cannot read another program's memory and none of the programs can read the kernel's memory. In our analogy, one customer is not supposed to be able to have access to the stuff in the locker belonging to another customer, and most certainly, he is not supposed to have access to the lockers containing records of the company operating the facility.

The Meltdown vulnerability breaks this basic presumption by abusing a hardware optimization technique called speculative execution. Let's see how it would work using our storage locker company analogy:

You, as a customer of the storage company, go in and ask to have access to your locker. The manager looks up that you indeed own that locker and grabs the key for it. But before going, the manager asks: "Hey, do you have any other lockers you own that you want access to?" In our analogy, this is the speculative execution. The manager is speculating that you may need access to other lockers that also belong to you. You give him another locker number for a locker that does NOT belong to you.

The manager does NOT check right away that you are indeed the owner of the second locker as well, instead he grabs the keys for both. He goes to the first locker, opens it for you, then he goes to the second locker, opens it, then looks on his clipboard, screams "Hey, wiseguy, you are not the owner of this second locker!!!" and slams the door shut. But before he gets a chance to slam the door, you take a snapshot of the contents with your camera phone. That last bit with the camera is done in the CPU using a side channel technique called "Flush+Reload," the complexity of that technique is beyond our simplistic analogy and the scope of this article.

OK, so the above analogy breaks down a little since all you get is a snapshot of the contents of that second locker, but in the digital world, that's all you need. Further, no reasonable manager would trust you again after a trick like that, but an Intel CPU will, over and over again, till you have snapshots of all the contents of all of the lockers in the facility, including the lockers belonging to the facility operator itself.

Spectre

The Spectre attack works in a similar manner. Again, you are a customer who owns 10 lockers in a row in a storage facility. You ask the manager to open them for you. Both of you go to the aisle where the storage lockers are located. You show the manager the paperwork for the first locker and he opens it for you. You repeat the process for the next nine lockers. The manager gets so used to the process that he opens the 11th locker by habit before he realizes that you don't own it. He slams the door shut, but it's too late. You already took a snapshot of the contents. Again, in this method in real world, you would use well understood "Flush+Reload" or "Evict+Reload" side channel techniques far beyond the scope of this paper in complexity.

The Spectre vulnerability requires a lot more resources to execute, is a lot slower, and does not allow access to kernel memory. However, it is effective against Intel, AMD, and ARM-based processors.

Know Your Customer

You might wonder if a simple solution to this problem is to simply know your customer. In our analogy, don't rent to people you don't trust, or in the real world, don't run the code you don't trust on your computer. Well, it's not that simple. Remember those VPSs we talked about. Most computing nowadays is cloud computing where you have little control over who else is renting resources from the same computer your software happens to be running on at the moment.

Further, in the Spectre research paper, the researchers were able to construct a JavaScript program that was able to exfiltrate private data from the memory belonging to the browser running it. The page you are on right now loads dozens of JavaScript programs without your knowledge. In 2018, it's virtually impossible to navigate the internet without JavaScript on.

Comparison of Meltdown and Spectre

Meltdown:

• CPU Targeted: All modern Intel CPUs. Intel is very aggressive at speculative execution and allows kernel memory access during speculative execution. ARM's upcoming Cortex-A75 is also apparently impacted.
• Trigger: Speculative Execution.
• Side Chanel: Flush+Reload.
• Impact: Read Access to Memory of Other Programs and Kernel.
• Speed of RAM Read: Up to 503 KB/s according to the research paper.
• Mitigation: Kernel Level Patches for the underlying operating systems.

Spectre:

• CPU Targeted: Intel, AMD, and ARM. All are affected.
• Trigger: Speculative Execution.
• Side Chanel: Flush+Reload or Evict+Reload.
• Impact: Read Access to Memory of Other Programs and Kernel.
• Speed of RAM Read: Roughly 10 KB/s according to the research paper.
• Mitigation: Kernel Level Patches for the underlying operating systems are currently in the works, but none are deployed yet. This is a far more complicated problem to mitigate for various technical reasons outside the scope of this article.

Intel's Reaction

At the time of publication, Intel's response to this crisis was less than reassuring. Here is a quote from Linus Torvalds, the author of the Linux Kernel, used on the majority of the world's cloud computers, reacting to Intel's response:

Why is this all done without any configuration options?

A *competent* CPU engineer would fix this by making sure speculation
doesn't happen across protection domains. Maybe even a L1 I$ that is
keyed by CPL.

I think somebody inside of Intel needs to really take a long hard look
at their CPUs, and actually, admit that they have issues instead of
writing PR blurbs that say that everything works as designed.

... and that really means that all these mitigation patches should be
written with "not all CPUs are crap" in mind.

Or is Intel basically saying "we are committed to selling you shit
forever and ever, and never fixing anything"?

Because if that's the case, maybe we should start looking towards the
ARM64 people more.

Investor Takeaway

(

(AMD vs. Intel picture from wccftech.com.)

The Meltdown vulnerability affects only the Intel processors at the moment. The vulnerability exploits the Speculative Execution feature. This feature is one of the key advancements in CPU architecture in the recent years and is, in fact, one of the main CPU speed drivers currently. While initial estimates of 30% slowdown post vulnerability patch might be overblown, there will be a performance penalty to all Intel-based CPUs. This is due to the fact that the very feature that was making them faster than the competition is the key to the vulnerability.

This might be a huge opportunity for AMD to match Intel in performance and beat them on price. Further, if AMD spins it right, it can also claim to be more dedicated to security.

This is also a huge opportunity for Qualcomm (QCOM). While ARM-based server architecture is still in its infancy, it has power advantages and now could be even closer on speed to Intel's architecture.

Spectre affects all architectures and all will suffer equally from the patches introduced to deal with this vulnerability.

Summary

Intel should recover from this blow in the short term, but in the long term, it may have lost yet another advantage compared to AMD. Meanwhile, AMD is catching up in the desktop, server, and GPU space. While I wouldn't go as far as shorting INTC, the old giant still has fight in him, I would open a position in AMD. With the right execution, AMD can really benefit from this opportunity.

Disclosure: I am/we are long AMD. I wrote this article myself, and it expresses my own opinions. I am not receiving compensation for it (other than from Seeking Alpha). I have no business relationship with any company whose stock is mentioned in this article.