A Massive Intel Hardware Bug May Be on the Horizon

Wired article. Rundown (at least for someone non-technical like me) on Meltdown. Not much on Spectre.

Although both attacks are based on the same general principle, Meltdown allows malicious programs to gain access to higher-privileged parts of a computer's memory, while Spectre steals data from the memory of other applications running on a machine. And while the researchers say that Meltdown is limited to Intel chips, they say that they've verified Spectre attacks on AMD and ARM processors, as well.

Ben Gras, a security researcher with Vrije Universiteit Amsterdam who specializes in chip-level hardware security, says that the attacks represent a deep and serious security breach. "With these glitches, if there's any way an attacker can execute code on a machine, it can’t be contained anymore," he says. (Gras was clear that he hadn't participated in any research that unearthed or reproduced the vulnerability, but he has watched the revelations of Intel's vulnerability unfold in the security community.) "For any process that’s untrusted and isolated, that safety is gone now," Gras adds. "Every process can spy on every other process and access secrets in the operating system kernel."

Prior to the official revelation of Meltdown and Spectre on Wednesday, Erik Bosman, a colleague of Gras in Vrije Universiteit Amsterdam's VUSEC security group, successfully reproduced one of the Intel attacks, which take advantage of a feature in chips known as "speculative execution." When modern Intel processors execute code and come to a point in an algorithm where instructions branch in two different directions, depending on input data—whether there's enough money in an account to process a transaction, for instance—they save time by "speculatively" venturing down those forks. In other words, they take a guess, and execute instructions to get a head start. If the processor learns that it ventured down the wrong path, it jumps back to the fork in the road, and throws out the speculative work.

VUSEC's Bosman confirmed that when Intel processors perform that speculative execution, they don't fully segregate processes that are meant to be low-privilege and untrusted from the highest-privilege memory in the computer's kernel. That means a hacker can trick the processor into allowing unprivileged code to peek into the kernel's memory with speculative execution.

"The processor basically runs too far ahead, executing instructions that it should not execute," says Daniel Gruss, one of the researchers from the Graz University of Technology who discovered the attacks.

Retrieving any data from that privileged peeking isn't simple, since once the processor stops its speculative execution and jumps back to the fork in its instructions, it throws out the results. But before it does, it stores them in its cache, a collection of temporary memory allotted to the processor to give it quick access to recent data. By carefully crafting requests to the processor and seeing how fast it responds, a hacker's code could figure out whether the requested data is in the cache or not. And with a series of speculative execution and cache probes, he or she can start to assemble parts of the computer's high privilege memory, including even sensitive personal information or passwords.

Many security researchers who spotted signs of developers working to fix that bug had speculated that the Intel flaw merely allowed hackers to defeat a security protection known as Kernel Address Space Layout Randomization, which makes it far more difficult for hackers to find the location of the kernel in memory before they use other tricks to attack it. But Bosman confirms theories that the bug is more serious: It allows malicious code to not only locate the kernel in memory, but steal that memory's contents, too.
Click to expand...
 
During the course of our research, we developed the following proofs of concept (PoCs):

A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.
A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]
A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)
A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache​

Only AMD FX and AMD Pro are vulnerable to variant 1 which is easily patched with negligible effect. Variant 3 is the one that causes the slowdown and it currently only affects Intel.

https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
 
So it seems like the current patches (with current performance penalties quoted) belong to Intel only.

The entire industry is impacted by Spectre, and there is no workaround yet tested.

Fun times.
 
juanrga said:
I quoted the full statement, because he forgot to mention this relevant part "Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect."

And now Google devs confirm that AMD CPUs are also affected: "These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them." ;)
Click to expand...
The specific problem discussed in the thread does not affect AMD as stated by Linux developers, AMD itself and various security researchers.

But please continue making a clown of yourself.
 
knowom said:
Honestly x86 would benefit a lot if a bit of FPGA was integrated into them...they could be used to fix these sorts of hardware flaws by leaving a bit of re-programmable headroom.
Click to expand...
It sounds difficult to me to integrate enough fpga area and wire it generically to various parts of a processor so that it could be repurposed on the fly. That's valuable area being taken up. It's also valuable trace length and capacitance. You would also have trouble reprogramming a part that must run at high frequencies onto an FPGA since FPGA fabric is usually not tuned for frequencies as high as processors run at. I don't have enough experience to say it's flat out a bad idea, but my gut reaction is that it wouldn't be that useful.

There are processors with FPGA logic integrated, however, the FPGA logic is used like another component that the cpu can communicate with:
(see xilinx zynq SoC for example or altera/intel stratix or arria SoC)
 
Meeho said:
The specific problem discussed in the thread does not affect AMD as stated by Linux developers and AMD itself.

But please continue making a clown of yourself.
Click to expand...

Is he really a clown when that "specific problem" you talk about wasn't even conclusively identified (and was embargoed) until literally an hour ago, and is in fact, 2 major problems with major differing solutions?
 
Meeho said:
The specific problem discussed in the thread does not affect AMD as stated by Linux developers, AMD itself and various security researchers.

But please continue making a clown of yourself.
Click to expand...

This starts to sound a lot of as the thread about the Zen bug and lots of poster denying the existence of the bug. It is only a problem with cheap mobos they said. There is no bug they said.
 
SighTurtle said:
Is he really a clown when that "specific problem" you talk about wasn't even conclusively identified (and was embargoed) until literally an hour ago, and is in fact, 2 major problems with major differing solutions?
Click to expand...
Yes, he is and yes, it was. We now have the name and mentions of other vulnerabilities, but the original one was known, explained and specified which architectures it does and doesn't affect.
 
SighTurtle said:
Is he really a clown when that "specific problem" you talk about wasn't even conclusively identified (and was embargoed) until literally an hour ago, and is in fact, 2 major problems with major differing solutions?
Click to expand...

The specific problem is reading (and possibly writing into) privileged data by a non-privileged process. That much we knew before the embargo lifted due to the nature of the kernel patches. So this specific problem, which is a much larger security concern than the one we didn't know about until now, is Intel only. Trying to point to the other problem and saying "See AMD is lying!! They're affected too" is a red-herring.
 
juanrga said:
And Google just confirmed AMD and ARM CPUs affected as well.
Click to expand...

juanrga said:
This starts to sound a lot of as the thread about the Zen bug and lots of poster denying the existence of the bug. It is only a problem with cheap mobos they said. There is no bug they said.
Click to expand...

Your being a little misleading, there are two problems here. One, the Meltdown problem that so far seems to be affecting Intel only (and which the patches previously mentioned are intended for), and the Spectre problem, something I have not seen any specific patches or fixes for, but which AMD, ARM, etc are known to be affected by.
 
SighTurtle said:
Your being a little misleading, there are two problems here. One, the Meltdown problem that so far seems to be affecting Intel only (and which the patches previously mentioned are intended for), and the Spectre problem, something I have not seen any specific patches or fixes for, but which AMD, ARM, etc are known to be affected by.
Click to expand...

From what I understand, AMD Pro and FX are only affected by variant 1 under Linux and there's already a patch with no loss of performance. Variant 2 and variant 3 are Intel. There's the infamous performance costing patch for variant 3, but no known method to fix variant 2.
 
SighTurtle said:
Your being a little misleading, there are two problems here. One, the Meltdown problem that so far seems to be affecting Intel only (and which the patches previously mentioned are intended for), and the Spectre problem, something I have not seen any specific patches or fixes for, but which AMD, ARM, etc are known to be affected by.
Click to expand...
Meltdown was what was discussed here and on every other site and patches for it were being benchmarked. His comments were in the context of Meltdown and claiming it affects AMD too, which it doesn't. Now another vulnerability has been made known and he's trying to crawl from his BS by using it as a scape goat.
 
SighTurtle said:
Your being a little misleading, there are two problems here. One, the Meltdown problem that so far seems to be affecting Intel only (and which the patches previously mentioned are intended for), and the Spectre problem, something I have not seen any specific patches or fixes for, but which AMD, ARM, etc are known to be affected by.
Click to expand...

I am considering the three variants of the security problem. It doesn't make sense to me to discuss only one variant and ignore the others. Moreover, it is not confirmed that Meltdown only affects Intel. From the link yourself gave one page ago: "At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown."
 
juanrga said:
I am considering the three variants of the security problem. It doesn't make sense to me to discuss only one variant and ignore the others. Moreover, it is not confirmed that Meltdown only affects Intel. From the link yourself gave one page ago: "At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown."
Click to expand...

The 3 variants aspect is not widely known. The Intel press release you reply to does not even make that distinction. In the context of pages and pages of talk around the patches to Linux, Windows (and now known to be intended for Meltdown) that were theorized to produce performance impacts to Intel, AMD products, not making that distinction is misleading, especially if Meltdown (and its performance impacting patches) could still apply to AMD as you suggest.
 
SighTurtle said:
The 3 variants aspect is not widely known. The Intel press release you reply to does not even make that distinction. In the context of pages and pages of talk around the patches to Linux, Windows (and now known to be intended for Meltdown) that were theorized to produce performance impacts to Intel, AMD products, not making that distinction is misleading, especially if Meltdown (and its performance impacting patches) could still apply to AMD as you suggest.
Click to expand...
I didn't suggest that as from all reports it can't affect their architecture. Intel's press release and all the discussions were about Meltdown, variant 3, as evidenced by the flaw description and Intel's problem solving with patches. It was the problem that raised hell an up to 30% hit and prompted the PR response.

Spectre is another issue and affects everybody and there are no patches available and maybe never will be and new HW will be required.
 
Last edited:
Let us summarize:

  1. There are a huge security problem split into three known variants. Those variants are collected into two codenames: Spectre and Meltdown.
  2. Spectre is confirmed to affect CPUs from AMD, ARM, and Intel.
  3. Meltdown is confirmed to affect CPUs from Intel. The situation with AMD and ARM CPUs "is unclear".
 
juanrga said:
Let us summarize:

  1. There are a huge security problem split into three known variants. Those variants are collected into two codenames: Spectre and Meltdown.
  2. Spectre is confirmed to affect CPUs from AMD, ARM, and Intel.
  3. Meltdown is confirmed to affect CPUs from Intel. The situation with AMD and ARM CPUs "is unclear".
Click to expand...

How about no.

The document EXPLICITLY states that the POC's worked against Haswell in default and non default configs.

Only POC 1 worked against AMD, and only in a non default configured kernel.

So stop being a twit about this.
 
juanrga said:
The more interesting to me is how we move fast from the initial reports about AMD CPUs not being affected. Never! to the recent "Due to differences in AMD's architecture, we believe there is a near zero risk to AMD processors at this time"

"believe" + "near-zero risk" + "this time" is a very interesting combination.

"Believe" means they cannot confirm the security.

"near zero risk" means the risk exists even if it small. How much near zero means "near" is not stated.

"this time" means that the issue has not been completely explored by AMD and partners and tomorrow things could be completely different.
Click to expand...


This goes for all hardware and software.

Using the scientific method you can never prove a negative. That counts even more when anything software is involved.

That's why we have our system of exploit discovery and patching.

This could simply mean that they are as reasonably certain as they could ever be that their products are unaffected, but that there is always some risk with all products no matter how small.

I don't know for sure, and neither do you.
 
Last edited:
https://www.phoronix.com/scan.php?page=news_item&px=Linux-Tip-Git-Disable-x86-PTI
Update: Linus Torvalds has now ended up pulling the latest PTI fixes that also include the change to disable page table isolation for now on all AMD CPUs. The commit is in mainline for Linux 4.15 along with a few basic fixes and ensuring PAGE_TABLE_ISOLATION is enabled by default.

Kernel developer Thomas Gleixner wrote in the pull request of disabling KPTI on AMD hardware, "Not necessarily a fix, but if AMD is so confident that they are not affected, then we should not burden users with the overhead."
Click to expand...
 
Arstechnica article. Spectre:
Owners of AMD and ARM systems shouldn't rest easy, though, and that's thanks to Spectre. Spectre is a more general attack, based on a wider range of speculative execution features. The paper describes using speculation around, for example, array bounds checks and branches instructions to leak information, with proof-of-concept attacks being successful on AMD, ARM, and Intel systems. Spectre attacks can be used both to leak information from the kernel to user programs, but also from virtualization hypervisors to guest systems.

Moreover, Spectre doesn't offer any straightforward solution. Speculation is essential to high performance processors, and while there may be limited ways to block certain certain kinds of speculative execution, general techniques that will defend against any information leakage due to speculative execution aren't known.

Sensitive pieces of code could be amended to include "serializing instructions"—instructions that force the processor to wait for all outstanding memory reads and writes to finish (and hence prevent any speculation based on those reads and writes)—that prevent most kinds of speculation from occurring. ARM has introduced just such an instruction in response to Spectre, and x86 processors from Intel and AMD already have several. But these instructions would have to be very carefully placed, with no easy way of identifying the correct placement.
Click to expand...
 
erek said:
BENSALEM, Pa.--(BUSINESS WIRE)--Law Offices of Howard G. Smith announces an investigation on behalf of Intel Corporation (“Intel” or the “Company”) (NASDAQ: INTC) investors concerning the Company and its officers’ possible violations of federal securities laws.

INTC INVESTOR ALERT: Law Offices of Howard G. Smith Commences Investigation on Behalf of Intel Corporation Investors

Intel was aware of the chip vulnerability when its CEO sold off $24 million in company stock
Click to expand...

And given the context and duration of the flaw, they would have known about it forever and a day. Krzanich saying he didn't know shit is a giant crock when they've been cheating at speculation for a decade.
 
Cyph said:
During the course of our research, we developed the following proofs of concept (PoCs):

A PoC that demonstrates the basic principles behind variant 1 in userspace on the tested Intel Haswell Xeon CPU, the AMD FX CPU, the AMD PRO CPU and an ARM Cortex A57 [2]. This PoC only tests for the ability to read data inside mis-speculated execution within the same process, without crossing any privilege boundaries.
A PoC for variant 1 that, when running with normal user privileges under a modern Linux kernel with a distro-standard config, can perform arbitrary reads in a 4GiB range [3] in kernel virtual memory on the Intel Haswell Xeon CPU. If the kernel's BPF JIT is enabled (non-default configuration), it also works on the AMD PRO CPU. On the Intel Haswell Xeon CPU, kernel virtual memory can be read at a rate of around 2000 bytes per second after around 4 seconds of startup time. [4]
A PoC for variant 2 that, when running with root privileges inside a KVM guest created using virt-manager on the Intel Haswell Xeon CPU, with a specific (now outdated) version of Debian's distro kernel [5] running on the host, can read host kernel memory at a rate of around 1500 bytes/second, with room for optimization. Before the attack can be performed, some initialization has to be performed that takes roughly between 10 and 30 minutes for a machine with 64GiB of RAM; the needed time should scale roughly linearly with the amount of host RAM. (If 2MB hugepages are available to the guest, the initialization should be much faster, but that hasn't been tested.)
A PoC for variant 3 that, when running with normal user privileges, can read kernel memory on the Intel Haswell Xeon CPU under some precondition. We believe that this precondition is that the targeted kernel memory is present in the L1D cache​

Only AMD FX and AMD Pro are vulnerable to variant 1 which is easily patched with negligible effect. Variant 3 is the one that causes the slowdown and it currently only affects Intel.

https://googleprojectzero.blogspot.co.uk/2018/01/reading-privileged-memory-with-side.html
Click to expand...


What on earth is an AMD Pro? Did I miss something?
 
thesmokingman said:
And given the context and duration of the flaw, they would have known about it forever and a day. Krzanich saying he didn't know shit is a giant crock when they've been cheating at speculation for a decade.
Click to expand...

Do you have any particular reason to believe that they themselves were aware that their method of speculative execution was vulnerable this entire time?

I don't question that Krasnick didn't know when he sold his stock. He must have, given how long this recent patching frenzy has been going on for, but you suggest they were aware since day one in - what - 1996? It could have been a simple error. We all know our software and hardware are all full of these 0 days waiting to be exploited.
 
Zarathustra[H] said:
Do you have any particular reason to believe that they themselves were aware that their method of speculative execution was vulnerable this entire time?

I don't question that Krasnick didn't know when he sold his stock. He must have, given how long this recent patching frenzy has been going on for, but you suggest they were aware since day one in - what - 1996? It could have been a simple error. We all know our software and hardware are all full of these 0 days waiting to be exploited.
Click to expand...

That's like asking if a doctor knows what the Hippocratic oath is? You don't cheat on speculative execution allowing user mode to access kernel mode by accident. What's that say about Intel if they didn't fundamentally know this? How can you rationalize it?
 
thesmokingman said:
That's like asking if a doctor knows what the Hippocratic oath is? You don't cheat on speculative execution allowing user mode to access kernel mode by accident. What's that say about Intel if they didn't fundamentally know this? How can you rationalize it?
Click to expand...

These are highly complex systems. Even in highly hardened validated software we expect 0-days to come along every now and then. This obviously was not as simple of an exploit as you suggest, or it wouldn't have taken over 20 years for someone to find it.

Don't get me wrong, I am highly skeptical of Intel and their practices, but in this particular instant it doesn't reek of intent to me.
 
You must log in or register to reply here.
Back
Top