Massive security hole in CPU's incoming?Official Meltdown/Spectre Discussion Thread

[William Gaatjes]

Here is the link to the status list of anti-virus that have been updated to support the windows patch.

https://docs.google.com/spreadsheet...tckQxYiuirADzf3cL42FQ/htmlview?sle=true#gid=0

Yay !
I have been using ESET for years. I did not have any issues with the windows update.

 

[mattiasnyc]

The larger context isn't that this attack or that attack can affect a particular CPU. That's missing the forest for the trees. The larger context that all the fanboys (on both sides) are missing is that this opens a new attack vector that fundamentally affects how every CPU and GPU is designed. In order to mitigate these issues is going to require processor core and OS redesigns across the board.

This isn't an Intel vs. AMD thing as some are trying to make it out to be. This affects the fundamental aspects of speculative execution.

So what you're saying is that this fix applies to AMD? Because if you're not saying that, then you and others are just talking past each other. They'd be right in that if this fix slows down AMD CPUs it's not really "fair" to force users to adopt the fix, and you're right because in the long term a new attack might target AMD and it too needs to be fixed.

But for now everything I've read so far says that this fix is not needed for AMD. Is this not correct?

 

[jpiniero]

https://forums.aws.amazon.com/thread.jspa?threadID=269858

Guy complaining about a forced reboot and then lower performance. Notice the date, this was before the news broke.

 

[Dayman1225]

Google and Amazon say the performance hit from the 'Meltdown' and 'Spectre' fixes is overblown

There has been speculation that the deployment of KPTI causes significant performance slowdowns. Performance can vary, as the impact of the KPTI mitigations depends on the rate of system calls made by an application. On most of our workloads, including our cloud infrastructure, we see negligible impact on performance.

In our own testing, we have found that microbenchmarks can show an exaggerated impact. Of course, Google recommends thorough testing in your environment before deployment; we cannot guarantee any particular performance or operational impact.

 

[dahorns]

Google and Amazon say the performance hit from the 'Meltdown' and 'Spectre' fixes is overblown

I'd like to hear about someone with a real deal workload that was heavily impacted. It would be good to see what the practical outer bounds of negative impact is. I assume less than the 50% number seen in some synthetics, but I would be curious if any real workload shows more than 20% slowdown.

 

[goldstone77]

I believe everybody here who says AMD is safe, are talking about the meltdown variant, the bad one that everyone is most worried about, and the one that has a fix with a big performance penalty. Please specify which variant you are commenting about, otherwise it could be construed as trolling.

https://lists.opensuse.org/opensuse-security-announce/2018-01/msg00004.html
An update that fixes one vulnerability is now available.

Description:

This update for kernel-firmware fixes the following issues:

- Add microcode_amd_fam17h.bin (bsc#1068032 CVE-2017-5715)

This new firmware disables branch prediction on AMD family 17h processor
to mitigate a attack on the branch predictor that could lead to
information disclosure from e.g. kernel memory (bsc#1068032 CVE-2017-5715).

https://www.suse.com/security/cve/CVE-2017-5715/
Note from the SUSE Security Team
SUSE is aware of the Spectre Attack named side channel attack and will be publishing updates.

This is a Fix for AMD for Spectre.

 

[goldstone77]

https://www.amd.com/en/corporate/speculative-execution
AMD adds a new graphic to the security update page.

Information Security is a Priority at AMD

I think they are trying to say something here!

 

[Artorias]

So whens that 8700K price drop coming lol.

 

[Dayman1225]

So whens that 8700K price drop coming lol.

Probably never

 

[Malogeek]

More benchmarks will come out still showing negligible if no performance loss for most users and everyone will forget about it and move on.

 

[Jaskalas]

Cloud service providers may remember this five years from now, I'm willing to bet the end user will not.

 

[IEC]

I'd like to hear about someone with a real deal workload that was heavily impacted. It would be good to see what the practical outer bounds of negative impact is. I assume less than the 50% number seen in some synthetics, but I would be curious if any real workload shows more than 20% slowdown.

OLTP databases are going to see a significant impact. Redhat's testing has shown a hit of 8% to 19% running on Linux with the KPTI kernel patch. Sure that isn't the 50% number seen in some synthetics, but losing even 10% performance is going to be a nightmare for some sysadmins who don't have that headroom.

 

[goldstone77]

Hardware Unboxed, which I already linked in a previous post, has shown that there is very limited impact on 8700K with the windows patch. Only high I/O devices like NVME's were showing performance losses, and the rest of the test including games were within margin of error.

 

[Dayman1225]

Apple has responded.

Security researchers have recently uncovered security issues known by two names, Meltdown and Spectre. These issues apply to all modern processors and affect nearly all computing devices and operating systems. All Mac systems and iOS devices are affected, but there are no known exploits impacting customers at this time. Since exploiting many of these issues requires a malicious app to be loaded on your Mac or iOS device, we recommend downloading software only from trusted sources such as the App Store. Apple has already released mitigations in iOS 11.2, macOS 10.13.2, and tvOS 11.2 to help defend against Meltdown. Apple Watch is not affected by Meltdown. In the coming days we plan to release mitigations in Safari to help defend against Spectre. We continue to develop and test further mitigations for these issues and will release them in upcoming updates of iOS, macOS, tvOS, and watchOS.

 

[Markfw]

Hardware Unboxed, which I already linked in a previous post, has shown that there is very limited impact on 8700K with the windows patch. Only high I/O devices like NVME's were showing performance losses, and the rest of the test including games were within margin of error.

For people like me, where all my boot (and ONLY) device is an NVME, that would be a big hit. Except all of those are AMD right now. If MS forces a patch on AMD, then it would hurt a lot, otherwise I would be OK.

 

[Malogeek]

If MS forces a patch on AMD, then it would hurt a lot, otherwise I would be OK.

Well they're not. It's disabled on AMD.

 

[goldstone77]

Kaiser security holes will devastate Intel’s marketshare
Analysis: This one tips the balance toward AMD in a big way
Jan 4, 2018 by Charlie Demerjian

Charlie is just blasting away with a double barrel!

 

[William Gaatjes]

Anybody compiled the spectre example code from the spectre pdf and tested it on windows 10 ?

 

[Asterox]

...................

https://semiaccurate.com/forums/sho...PU-design-flaw&p=296564&viewfull=1#post296564

 

[William Gaatjes]

You know what the fun part might be.
For full security , context switches will be costly now.
I wonder if this will result in a different and many many many but simpler cores architecture for servers.
Many many many cores means that there has to be switched less often.
This issue might boost the amount of cores that future server cpu's will have.
Dedicated cores.

 

[Markfw]

Kaiser security holes will devastate Intel’s marketshare
Analysis: This one tips the balance toward AMD in a big way
Jan 4, 2018 by Charlie Demerjian

Charlie is just blasting away with a double barrel!

Here is what I like so far about that article.

What AMD didn’t spell out in detail is a minor difference in microarchitecture between Intel and AMD CPUs. When a CPU speculatively executes and crosses a privilege level boundary, any idiot would probably say that the CPU should see this crossing and not execute the following instructions that are out of it’s privilege level. This isn’t rocket science, just basic common sense.

AMD’s microarchitecture sees this privilege level change and throws the microarchitectural equivalent of a hissy fit and doesn’t execute the code. Common sense wins out. Intel’s implementation does execute the following code across privilege levels which sounds on the surface like a bit of a face-palm implementation but it really isn’t.

 

[Artorias]

Probably never

Hey you never know, this security issue affects nearly every relevant Intel CPU from that last 10 years.

Their stocks is tumbling and AMD will be right on their heels.

This might just fire up the CPU race again.

 

[William Gaatjes]

Here is what I like so far about that article.

I find this very extremely idiotic if correct :

What saves Intel is that the speculative execution goes on but, to the best of our knowledge, is unwound when the privilege level changes a few instructions later. Since Intel CPUs in the wild don’t crash or violate privilege levels, it looks like that mechanism works properly in practice. What these new exploits do is slip a few very short instructions in that can read data from the other user or privilege level before the context change happens. If crafted correctly the instructions are unwound but the data can be stashed in a place that is persistent.

The instructions can execute with the wrong privilege level. ring 3 acts as ring 0 on Intel cpu's.

 

[noneis]

Intel worst nightmare:
https://twitter.com/never_released/status/948996493280731139

 

[William Gaatjes]

I just do not like this.
This is from the spectre pdf paper.

We have also verified the attack’s applicability to AMD Ryzen CPUs .

Experiments were performed on multiple x86 processor architectures, including Intel Ivy Bridge (i7-3630QM), Intel Haswell (i7-4650U), Intel Skylake (unspecifiedXeon on Google Cloud), and AMD Ryzen. The Spectre vulnerability was observed on all of these CPUs.

As the attack involves currently-undocumented hardware effects, exploitability of a given software program may vary among processors. For example, some indirect branch redirection tests worked on Skylake but not on Haswell. AMD states that its Ryzen processors have “an artificial intelligence neural network that learns to predict what future pathway an application will take based
on past runs” [3, 5], implying even more complex speculative behavior.

https://www.amd.com/en/corporate/speculative-execution

AMD says there is a near zero risk. Yet the researchers where able to do the attack, but to what extent ?
At least it is fascinating to read what they do :

Exploiting Conditional Branches. To exploit conditional branches, the attacker needs the branch predictor
to mispredict the direction of the branch, then the processor must speculatively execute code that would not be
otherwise executed which leaks the information sought
by the attacker. Here is an example of exploitable code:
if (x < array1_size)
y = array2[array1[x] * 256];
In this example, the variable x contains attackercontrolled data. The if statement compiles to a branch
instruction, whose purpose is to verify that the value
of x is within a legal range, ensuring that the access to
array1 is valid.
For the exploit, the attacker first invokes the relevant
code with valid inputs, training the branch predictor to
expect that the if will be true. The attacker then invokes
the code with a value of x outside the bounds of array1
and with array1 size uncached. The CPU guesses
that the bounds check will be true, the speculatively executes the read from array2[array1[x] * 256] using
the malicious x. The read from array2 loads data into
the cache at an address that is dependent on array1[x]
using the malicious x. The change in the cache state is
not reverted when the processor realizes that the speculative execution was erroneous, and can be detected by
the adversary to find a byte of the victim’s memory. By
repeating with different values of x, this construct can be
exploited to read the victim’s memory.

Exploiting Indirect Branches. Drawing from returnoriented programming (ROP) [33], in this method the attacker chooses a gadget from the address space of the
victim and influences the victim to execute the gadget
speculatively. Unlike ROP, the attacker does not rely on
a vulnerability in the victim code. Instead, the attacker
trains the Branch Target Buffer (BTB) to mispredict a
branch from an indirect branch instruction to the address
of the gadget, resulting in a speculative execution of the
gadget. While the speculatively executed instructions are
abandoned, their effects on the cache are not reverted.
These effects can be used by the gadget to leak sensitive
information. We show how, with a careful selection of a
gadget, this method can be used to read arbitrary memory
from the victim.
To mistrain the BTB, the attacker finds the virtual address of the gadget in the victim’s address space, then
performs indirect branches to this address. This training
is done from the attacker’s address space, and it does not
matter what resides at the gadget address in the attacker’s
address space; all that is required is that the branch used
for training branches to use the same destination virtual
address. (In fact, as long as the attacker handles exceptions, the attack can work even if there is no code mapped
at the virtual address of the gadget in the attacker’s address space.) There is also no need for a complete match
of the source address of the branch used for training and
the address of the targetted branch. Thus, the attacker
has significant flexibility in setting up the training

I guess this text explains what the branch prediction firmware from suse for AMD zen (17h) is trying to prevent.