Info Meltdown and Spectre Vulnerabilities Information

[goldstone77]

I'm surprised nobody has commented on this:

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).

Is there some reason we don't believe that disabling branch prediction is going to plant a tremendous foot on the back of performance? I mean, the whole POINT of branch prediction IS increased performance, right? I think there are probably a LOT of little tidbits like this that are likely important, but are not getting the kind of publicity that some of these other stunts and statements are getting due to simply being overlooked.

I mean, great, you removed the problem. Maybe. But you completely removed branch prediction from ALL ZEN processors, so how's that not going to seriously affect performance? Or am I reading this wrong?

Intel's fix for Spectre I'm sure is going to have a performance impact as well.

The CPU microcode for Haswell-X, Skylake-X and Broadwell-X chipsets was
updated to report both branch prediction control via CPUID flag and
ability to control branch prediction via an MSR register.

 

[Darkbreeze]

Is there some reason we don't believe that disabling branch prediction is going to plant a tremendous foot on the back of performance?

Since branch prediction is required to boost performance in loops, chained list, parsing, manipulating tree structures and countless everyday algorithms, I'd expect outright disabling branch prediction to have a severe impact on performance if it does exactly what it sounds like it does.

Without branch prediction, those 96+ slots in the reorder queue aren't going to see much use and could be cut down to 32 or so or the thread count per core increased to four to help fill it.

I'll add this to my bucket of reasons not to upgrade my PC this year.

 

[Darkbreeze]

I think ALL of these processors, every one, is going to have to disable branch prediction to mitigate the vulnerability and THAT is almost certainly going to cut out between 15-35% of performance exactly like they said it would from the moment they started reporting this fiasco.

And that's on top of whatever performance hit we see due to the patches for the OTHER vulnerability unless completely removing branch prediction wipes both out in one shot.

Furthermore, does this mean branch prediction can NEVER be used on future architectures? Or will they need to completely redesign branch prediction methods from the ground up and hope to god that doesn't create new ones?

We might all be back to P4 level performance before long.

 

[goldstone77]

My bet is that they will find a way to isolate privileged and non-privileged data in branched chain speculation if there is a big impact to performance since shrinking the process node isn't getting any easier.

 

[goldstone77]

One thing that stands out is the fact that all the players involved have known since June. How many CPU's and computer systems have been sold while known hardware flaws existed?

Since Google first discovered these holes in June, 2017, there have been patches pushed up to various Linux kernel and related repositories. The first one SemiAccurate can find was dated October 2017 and the industry coordinated announcement was set for Monday, January 9, 2018 so you can be pretty sure that the patches are in place and ready to be pushed out if not on your systems already.

 

[Turb0Yoda]

It seems proven that Intel knowingly released flawed CPUs, with the CEO selling the stocks off around the time the information was provided you given to them.

Also, to stop the JavaScript hack in chrome:
https://support.google.com/chrome/answer/7623121?hl=en-GB


Isolates all processes for chrome at the cost of memory overhead.


This sucks for big companies and people like me who run bare metal hypervisor's at home.


I made a quick write up yesterday at... Midnight and most of it has already been covered but I'll put it in spoilers here.

Spoiler

A lot of people have been writing posts about not getting Intel CPUs due to the exploit(meltdown) being in the news. Unfortunately, there were two exploits found, one of which affects all processors...


The first is Meltdown. This ONLY affects Intel CPUs(besides from Atom and Itanium CPUs). AMD is not affected because they handle memory allocation differently.


Atom is not affected since... Well, it never supported KPTI since it was too weak. Itanium uses IA-64 Which is completely different from x86/64.


The second is Spectre, which affects AMD, Intel, ARMA, powerPC, IBM Z-series and a few more.


Both are fairly devastating. Meltdown should have a patch soon, but at the cost of performance loss(mainly with syscall operations like virtualization).

Spectre will take longer, since it's much harder to fix than a software patch.

Without going too much into depth(seeing as it's almost past midnight and I have to wake up at 6 AM tomorrow, here's some links with more info on how exactly the exploits work.



LINKS:

Has info on the two exploits with links to the white papers:
https://spectreattack.com/

One of the three or so teams that found the exploits:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

Redhat write-up:
https://access.redhat.com/security/vulnerabilities/speculativeexecution

Torvald's comment on Intel with Meltdown:
https://lkml.org/lkml/2018/1/3/797

Another write-up:
http://pythonsweetness.tumblr.com/post/169166980422/the-mysterious-case-of-the-linux-page-table


CVE:
"CVE-2017-5753 and CVE-2017-5715 are the official references to Spectre.
...
CVE-2017-5754 is the official reference to Meltdown"
- https://spectreattack.com/

http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5715
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5753
http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=2017-5754


TL;DR - Intel is not the only CPU company affected from recent exploits announced.

I have next week to set up a lab environment to test the exploits... Part of a security competition I'm in, and they will most likely throw this at us now.


Edit: Also AMD is technically correct. Ryzen and EPYC/TR aren't vulnerable... Anything before is... Google only tested fx and earlier, but it seems that Ryzen doesn't have the issue. Maybe because the fixed it while Intel said "nah" and released the new chips with faults?

 

[randomizer]

https://newsroom.intel.com/news-releases/intel-issues-updates-protect-systems-security-exploits/

Curious that Intel claims to have rendered systems immune to Spectre considering nobody else thinks it's possible. I'm still looking for the asterisk.

 

[Turb0Yoda]

"Intel has already issued updates for the majority of processor products introduced within the past five years. By the end of next week, Intel expects to have issued updates for more than 90 percent of processor products introduced within the past five years. "

First sentence seems to be a lie.. that's been proven wrong.

Second... Mmmmhm



KPTI Linux benchmarks:
https://www.phoronix.com/scan.php?page=article&item=linux-kpti-pcid&num=1

https://www.phoronix.com/scan.php?page=article&item=linux-kpti-kvm&num=1

 

[goldstone77]

List of Meltdown and Spectre Vulnerability Advisories, Patches, & Updates
By Lawrence Abrams
January 3, 2018 09:52 PM
This is a link to most of the major players public statements.

 

[goldstone77]

https://www.bleepingcomputer.com/news/software/google-chrome-63-released-for-android-linux-mac-and-windows/

Stable Channel Update for Desktop
Thursday, January 4, 2018
The stable channel has been updated to 63.0.3239.132 for Windows, Mac and Linux which will roll out over the coming days/weeks.
To update Chrome type: chrome://settings/help and after update click relaunch

https://www.bleepingcomputer.com/news/google/heres-how-to-enable-chrome-strict-site-isolation-experimental-security-mode/
Here's How to Enable Chrome "Strict Site Isolation" Experimental Security Mode

Google’s site isolation feature improves security for Chrome browser users. When you enable site isolation, content for each open website in the Chrome browser is always rendered in a dedicated process, isolated from other sites. This creates an additional security boundary between websites.
The feature is not enabled for all users by default. The reason is that Google is still working on improving Site Isolation, and says that if users turn it on in Chrome 63, they "will increase memory usage by approximately 10–20%."

If this is not an issue for some of our readers, these are the two easiest ways to enable Site Isolation right now.

Via a Chrome flag
Step 1: Type chrome://flags and press Enter.
Step 2: Scroll down the page and find "Strict site isolation" and press the Enable button. Alternatively, copy and access the following URL to take you to the Site Isolation flag directly: chrome://flags/#enable-site-per-process
Step 3: Restart the Chrome browser.

Via a command line flag
Step 1: Find your Google Chrome icon/shortcut and double-click on it.
Step 2: Select Properties from the drop-down menu.
Step 3: Select the Shortcut tab.
Step 4: In the Target field, add the following text "--site-per-process" at the end of the shortcut path and hit Save.

 

[-Fran-]

I found a problem with the way Mr. Larabel tested: he didn't use mixed workloads. Apache being the best "mixed" workload, since it represents web load, is best indicative on how it will affect mix workloads with the patch in effect.

We will need more benchmarks that actually explore mixed workloads behaviour so assess proper impact. Particularly, most servers do more than just one thing at a time, so I'm not really talking from the consumer standpoint

Cheers!

 

[gamerk316]

https://www.phoronix.com/scan.php?page=article&item=linux-kpti-pcid&num=2

Minimal performance difference on Linux after the KPTI changes went in.

 

[gamerk316]

I'm surprised nobody has commented on this:

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).

Is there some reason we don't believe that disabling branch prediction is going to plant a tremendous foot on the back of performance? I mean, the whole POINT of branch prediction IS increased performance, right? I think there are probably a LOT of little tidbits like this that are likely important, but are not getting the kind of publicity that some of these other stunts and statements are getting due to simply being overlooked.

I mean, great, you removed the problem. Maybe. But you completely removed branch prediction from ALL ZEN processors, so how's that not going to seriously affect performance? Or am I reading this wrong?

Intel's fix for Spectre I'm sure is going to have a performance impact as well.

The CPU microcode for Haswell-X, Skylake-X and Broadwell-X chipsets was
updated to report both branch prediction control via CPUID flag and
ability to control branch prediction via an MSR register.

Unlike the KPTI fix, disabling branch prediction WILL affect gaming performance in noticeable ways. That's a rather drastic change.

Also, the class-action against Intel is going to go nowhere; there's no way to plaintiffs are going to be able to show harm if the fix doesn't affect performance in a measurable way.

 

[-Fran-]

This is an interesting quote, taken from an insider RedHat benchmark article:

Well, I won't copy it here, but it says the performance drops may be from minimal for workloads bypassing the kernel, to 2-5% for HPC uses, 3-7% for some workloads including Java, and up to 8-12% for DBs and netperf.

So there is a hit in applications that have a mixed workload nature (and heavy I/O dependency). Intel is getting hit where the money is and, like I read somewhere, AMD was granted the IPC difference in a golden plate. Also, take note at "netperf". Network operations ARE I/O in nature, so Intel based desktop will get hit when doing network stuff: i.e. Multiplayer games. I think that is going to be an interesting can of worms to open. Also, I've read that Mac users have noticed the slowdown in their machines after Apple released the patches. So, there's that as well.

This seems fitting to use:

Spoiler

Cheers!

 

[randomizer]

I found a problem with the way Mr. Larabel tested: he didn't use mixed workloads.

I think this is simply a limitation of the Phoronix Test Suite. There are only test profiles for specific applications and there is no support for running multiple tests concurrently while recording results. Parallel test execution is only supported for stress testing.

 

[goldstone77]

VM Performance Showing Mixed Impact With Linux 4.15 KPTI Patches
Written by Michael Larabel in Software on 3 January 2018.

The VRM performance took a hit.

 

[-Fran-]

I found a problem with the way Mr. Larabel tested: he didn't use mixed workloads.

I think this is simply a limitation of the Phoronix Test Suite. There are only test profiles for specific applications and there is no support for running multiple tests concurrently while recording results. Parallel test execution is only supported for stress testing.

Oh, yes. I get that completely. I didn't know he already tested VM performance in a previous article (or forgot, actually), so he's been looking at mixed workloads indirectly as well.

The numbers are all over the place, so no clear conclusions can be made yet (so many kernel versions and patch combinations, ugh). I will wait until Mr. Larabel (I hope) does a big summary and definite article that talks and aggregates all the tests he has done showing the key aspects of the slowdowns (again, I hope).

I passed the message up the chain of command to ask our Linux provider (can't provide this info, lol) about the performance hit, 'cause here we're running too close to the capacity limit and these findings are actually worrying. Incurring in an infrastructure upgrade cost for big companies is not something that can be done from one day to the other (hence the anger at this from big players) and the right conversations need to happen. We'll probably just eat the performance hit, but we need to at least understand the impact when we get angry calls from clients saying they're not getting their stuff as fast.

Fun times!

Cheers!

 

[goldstone77]

Testing Windows 10 Performance Before and After the Meltdown Flaw Emergency Patch
By Steven Walton on January 4, 2018

Spoiler

Where we see a significant difference is when looking at the 4K read result, here we see a very large 23% reduction in performance going from a throughput of 44 MB/s to 34 MB/s. The random 4K write performance though, well that goes unchanged so it’s just the random 4K reads that are significantly down.

Interestingly though the 4K-64 thread read and write performance is improved with the patch, the write performance here has been boosted by 17%, so it’s certainly not all bad news though I’d argue that the 4K read result is a more serious. Read access time was also 14% lower before the update, the write access time though is much the same.

Spoiler

Moving on we find CrystalDiskMark confirms what was seen when testing with AS SSD Benchmark. Here the 4K read performance has been reduced by 23% after the patch. The rest of the margins though are 5% or less so nothing really worth noting.

Spoiler

The Cinebench R15 score is based on an average of three runs and here we see a slight variation in performance but nothing to be alarmed about. The multi-threaded score is reduced by 2% while the single thread score was increased by a percent, so margin of error stuff here.

Spoiler

 

[juanrga]

That is a fix for:

Spectre Attack named side channel attack

https://www.suse.com/security/cve/CVE-2017-5715/

It is a fix for CVE-2017-5715 attacks on Zen CPUs.

CVE-2017-5715 = "branch target injection" version of Spectre atack.

The versions of the attacks (CVE-2017-5753, CVE-2017-5715, CVE-2017-5754) have been discussed before in this thread.

 

[juanrga]

I'm surprised nobody has commented on this:

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).

Is there some reason we don't believe that disabling branch prediction is going to plant a tremendous foot on the back of performance? I mean, the whole POINT of branch prediction IS increased performance, right? I think there are probably a LOT of little tidbits like this that are likely important, but are not getting the kind of publicity that some of these other stunts and statements are getting due to simply being overlooked.

I mean, great, you removed the problem. Maybe. But you completely removed branch prediction from ALL ZEN processors, so how's that not going to seriously affect performance? Or am I reading this wrong?

One has to choose between performance and security. Server guys are choosing security. The same happens with the Meltdown fix for Intel CPUs, performance is affected.

 

[juanrga]

Red Hat confirms that IBM is also affected for security flaws (I guess they mean some version of the Spectre attack). Systems affected are Power 8 and Power 9 and Z-series.

 

[juanrga]

Hardware unboxed and Guru3D have measured the impact of patched windows on Intel CPUs. Performance penalty is close to zero. Hardware Unboxed only tested games. Guru3D testing is more complete.

http://www.guru3d.com/articles-pages/windows-vulnerability-cpu-meltdown-patch-benchmarked,1.html

 

[YoAndy]

Some people are protecting AMD like furious body guards, .I just don't get, is just another company like any other.
Initial reports on Wednesday said that the flaw, which could allow hackers to steal confidential information like passwords, only affected Intel’s chips(LIE) sent the company’s stock price plunging 7% while competitor Advanced Micro Devices shares jumped 6%. Reports that a software fix would slow the performance of affected PCs contributed to the strong reaction.

IT WAS A LIE, Everyone is affected, Intel Says Major Security Bug Also Affects Competitors ARM and AMD. But in a mid-afternoon statement, Intel (INTC, -1.39%) said the early reports were wrong. And mobile chip designer ARM Holdings said its chips were also affected and that it was working with Intel and AMD (AMD, +5.89%) on a fix. That helped Intel shares claw back some of the drop and the stock closed down only 3%, while AMD ended with a 5% gain.

Now ARM, which is owned by SoftBank Group, said in a statement: “ARM have been working with Intel and AMD to devise mitigation for a new method identified by security researchers that can exploit certain high-end processors, including ours…Software mitigation measures have already been shared with our partners. ARM takes all security threats seriously and we encourage individual users to ensure their software is up-to-date and always practice good security hygiene.”AMD said its chips were affected by some but not all of a series of related security exploits uncovered by researchers. AMD has already developed a simple software fix for its chips that will not impact PC performance, an AMD spokesman said."

Intel Says Major Security Bug Also Affects Competitors ARM and AMD and Intel already begun distributing software fixes to eliminate the issue and denied that the patches would noticeably hamper the performance of affected systems. “Contrary to some reports, any performance impacts are workload-dependent, and, for the average computer user, should not be significant and will be mitigated over time,” Intel said.

 

[-Fran-]

This is from Linus, read it well Andy:

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 CPU's, 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 CPU's 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.

Please talk to management. Because I really see exactly two possibibilities:

- Intel never intends to fix anything

OR

- these workarounds should have a way to disable them.

Which of the two is it?

Linus

The problem with Intel here is the usual way "it's not us" attitude they've had with this issue. They even said it's "working as intended". For crying out loud, so it's "intended" for Intel to allow malicious code exploitation in their CPU designs? That is where most of the anger stems from. Not because of the bug, not because it's Intel... Well, it's because Intel is behaving like Intel.

This might seem like an over-stretch, but did your parents ever tell you "no, just deny you did anything wrong and keep saying you're not the only one at fault; instead try to blame it on others as well".

Cheers!

 

[goldstone77]

Intel's white paper
https://newsroom.intel.com/wp-content/uploads/sites/11/2018/01/Intel-Analysis-of-Speculative-Execution-Side-Channels.pdf