A Massive Intel Hardware Bug May Be on the Horizon

Right I finished my simulation....

I fetched 4.15_rc6 & confirmed it had the generic x86 patch (the specific for not AMD isn't in the mainline).
I complied and booted with PTI=on,off and executed my model. Both runs took pretty much the same time, 23min +-30sec...

So cpu-bound does not seem to be impacted (or how ryzen handle memory means even this patch doesn't impact it). This would align with IO-bound being hit.
My next concern is my work laptop which has full disc encryption. How much is this going to slow down because this would also impact my simulations.

I also parse 10gig files... This could be seriously impacted... I might run a secondary test parsing some of these files
 
  • Like
Reactions: Meeho
like this
%30 performance hit or security hole? Size of that class action is going to be huge.

Indeed, considering that its been known about & ongoing for at least a decade. If my 6700K chip takes a dump, I'll be moving over to AMD.
 
I noticed AnandTech has been completely silent. They must be waiting for the official Intel fluff-job press release that they can post verbatim to explain that all of this is GOOD for us and we should want MOAR of it from Intel.
I've also noticed the loud silence from Anandtech.

mshckd.gif

lol, there is not one peep on their site!
 
That's bullshit.
I looked it up and must admit im surprised how large Microsoft's market share is.

We will have to see how Microsoft implements the patch. Im sure AMD is scuttling behind doors, but lets see how it releases.

At the end my argument is against showing EPYC performance and claiming its representative of anything. It will be properly patched for AMD on all platforms, and im sure AMD will make sure with haste.
 
Eagerly awaiting gaming benchmarks with frame times. Especially for multiplayer games, as networking should require more cpu time with this patch
 
  • Like
Reactions: erek
like this
Eagerly awaiting gaming benchmarks with frame times. Especially for multiplayer games, as networking should require more cpu time with this patch
CPU might not be hit as bad, IO-bound however....
 
Why is there a problem with Anandtech being "silent" on this issue? All the time I hear people complaining about clickbait and overreaction by the media and some of you want Anandtech to start spouting out stuff before we actually know the inner details of it. (With that said, that ArsTechnica article someone just posted, thats a good example of a article on the issue. Phoronix is also doing articles that aren't overreaction and clickbait., but actual testing, etc)

Here are some tweets from Anandtech's team:



 
This is bad, really bad.... My VM server is heavy on I/O and runs multiple DB's. If the Phoronix filesystem benches are anything to go by I've just waved goodbye to at least 40% of my server's total performance.

I had spare some capacity on it before this, post patch I won't = New Server = A fair wack of cash.

'Not Cool' doesn't cover it. Neither does 'Really Uncool'. I'm seriously pissed, enough to look at Epyc for it's replacement.

Yeah, I am going to have to wait and see how this impacts my Proxmox box to decide.

The truth is, I've wanted to upgrade my server for some time, but the high cost of DDR4 has kept me from doing so. I figure I'll need about 256GB of Registered RAM, and right now, that's just too much money. :(

Does anyone have a good enough understanding to detail the attack vector this vulnerability is susceptible to yet? I want to try to determine if my use case on my server makes it vulnerable or not.
 
on a side note ibm power 9 servers are on the horizen look pretty afordable (starting at 3k) and look sweet in prefermance. plus amd is finally on there game in the multithreaded option so there are many other options.

Can't wait to get me some of that sweet prefermance :p
 
Honestly, I wouldn't even consider an ITX build for main system.

Don't get me wrong. I have four ITX builds in my house, but three of them are HTPC's and one is my pfSense router.

For the desktop, the bigger the better. There is absolutely no benefit and many, many drawbacks in it being small.

I was an early-ish adopter of the SFF build back in 2009/2010 (can't remember now) when I got one of those Shuttle All in One SFF cases for my i7-920. I learned from that experience that you'll always be up against problems when you go small form factor. Less expansion, less space for cooling, more expensive components, etc. etc.

That and it isnt even a space saver. Instead of having a large case you rarely notice out of the way on the floor under your desk, you now have a - granted much smaller - case, but it is taking up precious space on the desk. I found I had LESS space when I went with an SFF case.

So, I was supremely disappointed with the SFF experience, and since then have adopted a "bigger is better" mentality. These days I couldn't imagine going smaller than a full tower. Even a mid tower is too small.


I switched to Intel because of the lack of high-end AMD ITX boards and look where it got me -- all my Intel machines now have defective/vulnerable CPUs.

I like your under-the-desk vs. on-the-desk comparison. On-desk ITX being closer to the user you also get more noise from spinners, so you have to go with SSDs. But if ITX is small case you can tuck it behind the screen. ITX is also more versatile, you can put it on-desk or move it to livingroom/bedroom as an HTPC, etc, and I certainly don’t want a tower in my bedroom. Tower-on-the-floor also needs wheels for moving, more hardware, heavier, longer cables, etc. It’s hard to justify an ATX with all slots empty.

Here's 3 of mine for inspiration: https://hardforum.com/threads/the-lian-li-gallery.703539/page-139#post-1043268021
 
Why is there a problem with Anandtech being "silent" on this issue? All the time I hear people complaining about clickbait and overreaction by the media and some of you want Anandtech to start spouting out stuff before we actually know the inner details of it. (With that said, that ArsTechnica article someone just posted, thats a good example of a article on the issue. Phoronix is also doing articles that aren't overreaction and clickbait., but actual testing, etc)

Here are some tweets from Anandtech's team:



First you defend Anandtech how they can't write an objective article this early and in the very next sentence point how others have managed. And they don't even have to write an article right away but they do have something called a news section on their front page and this is potentially the biggest news in tech in years!
 

Reuters has basically become a tabloid.

"AMD chips are also affected by variants of a security flaw also discovered in Intel chips, a person familiar with the matter told Reuters."

The 'person familiar with the matter' is the Intel press release writer.

AMD should consider a lawsuit.


Intel lying in their press release just demonstrates the kind of lows that their company is willing to go to.
 
Last edited:
Was wondering when the PR damage control would kick in. Intel isn't going to sit idly by and let the press rake them over the coals (deserved or not) without punching back.

I'm not going to lose any sleep over it unless its a bug that prevents pr0n or my games from loading. So, thinking its a moot point for most people. ;)
 
First you defend Anandtech how they can't write an objective article this early and in the very next sentence point how others have managed. And they don't even have to write an article right away but they do have something called a news section on their front page and this is potentially the biggest news in tech in years!

Good point.
 
  • Like
Reactions: Meeho
like this
Yeah, I am going to have to wait and see how this impacts my Proxmox box to decide.

The truth is, I've wanted to upgrade my server for some time, but the high cost of DDR4 has kept me from doing so. I figure I'll need about 256GB of Registered RAM, and right now, that's just too much money. :(

Does anyone have a good enough understanding to detail the attack vector this vulnerability is susceptible to yet? I want to try to determine if my use case on my server makes it vulnerable or not.

Its a privilege escalation route from any privilege rouge app direct to kernel level, something to do with the dumb ass CPU saying where its hiding the kernel in memory when asked (smashes it wide open for bit flipping). Reading has been proven, writing hasn't.... yet. Give it a few hours. Not good.
 

This link is very good.

I learned a few things from reading it.

1.) Patch has negligible gaming/general desktop performance

2.) Linux patch in 4.15 kernel impacts ALL x86 CPU's, but AMD is not at risk due to not speculatively computing ring3 cache data. AMD will be removed from patch in near future, but until then nopti kenel option can be passed to avoid slowdown. (nopti option can be passed to kernel on any Intel system as well, but then they will be at risk)

2.) 30% performance impact is not necessarily wrong, but only happens in very limited circumstances, with synthetic I/O benchmarks against fast NVMe devices. With real world tests against slower I/O devices the increase in latency is small compared to the latency of the I/O itself and is thus less noticeable.

3.) If your CPU has PCID compatibility (introduced in Westmere, present in ALL Sandy Bridge and later Intel chips) the impact is much smaller than the worst case above.

Based on this, I am less worried now than I was. My Dual Westmere-EP L5640's have PCID, and while they do do a fair share of I/O, I don't have any fast PCIe/NVMe SSD's.

Time will tell though.
 
AMD JUST RESPONDED TO INTEL SHOTS FIRED AMD FOUND ITS BACKBONE FRICKING FINALLY

"AMD Says ‘Near Zero Risk’ to Its Chips"

https://www.barrons.com/articles/amd-says-near-zero-risk-to-its-chips-1515016135


Curious wording in that statement:

"To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants."

This could be read as they are susceptible to none of them, OR as, they could be susceptible to as many as two of them.

I wonder if that was on purpose.
 
ok this is odd...

uname -a && cat /proc/cmdline

Linux fluidmotion 4.15.0-rc6 #1 SMP PREEMPT Wed Jan 3 16:07:25 GMT 2018 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux

BOOT_IMAGE=/vmlinuz-4.15.0-rc6 root=/dev/nvme0n1p2 ro video=uvesafb:1280x1024-32,mtrr:3,ywrap quiet splash libata.force=6.0 rootfstype=ext4 elevator=noop processor.max_cstate=5 pti=on


cat /proc/cpuinfo
...
bugs : sysret_ss_attrs null_seg cpu_insecure

so as expected bugs = cpu_insecure when pti=on is set YET...



uname -a && cat /proc/cmdline

Linux fluidmotion 4.15.0-rc6 #1 SMP PREEMPT Wed Jan 3 16:07:25 GMT 2018 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux

BOOT_IMAGE=/vmlinuz-4.15.0-rc6 root=/dev/nvme0n1p2 ro video=uvesafb:1280x1024-32,mtrr:3,ywrap quiet splash libata.force=6.0 rootfstype=ext4 elevator=noop processor.max_cstate=5 pti=off


cat /proc/cpuinfo
....
bugs : sysret_ss_attrs null_seg cpu_insecure



with pti=off the bug is still declared, its like it isn't being turned off in my test...
 
"Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits."

Look over there, a three headed monkey!

I prefer the full quote:

Recent reports that these exploits are caused by a “bug” or a “flaw” and are unique to Intel products are incorrect. Based on the analysis to date, many types of computing devices — with many different vendors’ processors and operating systems — are susceptible to these exploits.
 
https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html?m=1



We are posting before an originally coordinated disclosure date of January 9, 2018 because of existing public reports and growing speculation in the press and security research community about the issue, which raises the risk of exploitation. The full Project Zero report is forthcoming.

These vulnerabilities affect many CPUs, including those from AMD, ARM, and Intel, as well as the devices and operating systems running them.
 
Curious wording in that statement:

"To be clear, the security research team identified three variants targeting speculative execution. The threat and the response to the three variants differ by microprocessor company, and AMD is not susceptible to all three variants."

This could be read as they are susceptible to none of them, OR as, they could be susceptible to as many as two of them.

I wonder if that was on purpose.

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.
 
ok this is odd...

uname -a && cat /proc/cmdline

Linux fluidmotion 4.15.0-rc6 #1 SMP PREEMPT Wed Jan 3 16:07:25 GMT 2018 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux

BOOT_IMAGE=/vmlinuz-4.15.0-rc6 root=/dev/nvme0n1p2 ro video=uvesafb:1280x1024-32,mtrr:3,ywrap quiet splash libata.force=6.0 rootfstype=ext4 elevator=noop processor.max_cstate=5 pti=on


cat /proc/cpuinfo
...
bugs : sysret_ss_attrs null_seg cpu_insecure

so as expected bugs = cpu_insecure when pti=on is set YET...



uname -a && cat /proc/cmdline

Linux fluidmotion 4.15.0-rc6 #1 SMP PREEMPT Wed Jan 3 16:07:25 GMT 2018 x86_64 AMD Ryzen 5 1600 Six-Core Processor AuthenticAMD GNU/Linux

BOOT_IMAGE=/vmlinuz-4.15.0-rc6 root=/dev/nvme0n1p2 ro video=uvesafb:1280x1024-32,mtrr:3,ywrap quiet splash libata.force=6.0 rootfstype=ext4 elevator=noop processor.max_cstate=5 pti=off


cat /proc/cpuinfo
....
bugs : sysret_ss_attrs null_seg cpu_insecure



with pti=off the bug is still declared, its like it isn't being turned off in my test...

I think it's because the bug gets defined based on different logic, and then PTI is enabled or disabled based on the bug AND the command line options. Have you ran a benchmark to see if there is a perf difference?

You can use this to test: (I believe the below numbers are from a 6700k, but as you can see there is a huge relative difference so that is what to look for.)

Code:
#include <unistd.h>
#include <sys/syscall.h>
#include <stdio.h>


// gcc -Wall -O3 -o getpid getpid.c

/*
[    0.000000] Linux version 4.15.0-rc6-mainline (user@machine) (gcc version 7.2.1 20171128 (GCC)) #1 SMP PREEMPT Tue Jan 2 09:30:19 UTC 2018

[user@machine getpid]$ time ./getpid
1069

real    0m15.351s
user    0m6.900s
sys     0m8.447s
[user@machine getpid]$ time ./getpid
1130

real    0m15.349s
user    0m6.910s
sys     0m8.437s
[user@machine getpid]$ time ./getpid
1174

real    0m15.393s
user    0m7.022s
sys     0m8.365s
[user@machine getpid]$ time ./getpid
1211

real    0m15.424s
user    0m7.037s
sys     0m8.381s

*/

/*
[    0.000000] Linux version 4.14.8-1-ARCH (user@machine) (gcc version 7.2.1 20171128 (GCC)) #1 SMP PREEMPT Wed Dec 20 21:27:44 UTC 2017

[user@machine getpid]$ time ./getpid
1108

real    0m3.814s
user    0m1.266s
sys     0m2.525s
[user@machine getpid]$ time ./getpid
1123

real    0m3.814s
user    0m1.207s
sys     0m2.598s
[user@machine getpid]$ time ./getpid
1131

real    0m3.758s
user    0m1.178s
sys     0m2.579s
[user@machine getpid]$ time ./getpid
1146

real    0m3.790s
user    0m1.270s
sys     0m2.513s
*/

int main(void)
{
    long value;

    for (int i = 0; i < 100000000; i++)
        value = syscall(SYS_getpid);

    printf("%d\n", (int) value);


    return 0;
}
 
Last edited:
A warning regarding explanations about processor internals in this blogpost: This blogpost contains a lot of speculation about hardware internals based on observed behavior, which might not necessarily correspond to what processors are actually doing.

We have some ideas on possible mitigations and provided some of those ideas to the processor vendors; however, we believe that the processor vendors are in a much better position than we are to design and evaluate mitigations, and we expect them to be the source of authoritative guidance.

This is quoted from the Google Project Zero blog post.
 
We all know that, you have always loved Intel statements.

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

The POC's worked against Intel in a default state. Only worked against AMD in a non default state.

But that doesn't matter to an Intel Social Media influencer does it?
 
This could exceed Volkswagen Diesel in it's extend. Yeah, hang them hi', they knew exactly what they were selling, same "no mercy" now for the Intel Managers.

5-35% ?? you kiddin' me ?


What about VR, any latency introduced by the patch ? They tested like 5 Games, that is not really representative if it effects gaming or not. It says nothing tbh.
 
https://meltdownattack.com/

Which systems are affected by Meltdown?
Desktop, Laptop, and Cloud computers may be affected by Meltdown. More technically, every Intel processor which implements out-of-order execution is potentially affected, which is effectively every processor since 1995 (except Intel Itanium and Intel Atom before 2013). We successfully tested Meltdown on Intel processor generations released as early as 2011. Currently, we have only verified Meltdown on Intel processors. At the moment, it is unclear whether ARM and AMD processors are also affected by Meltdown.

Which systems are affected by Spectre?
Almost every system is affected by Spectre: Desktops, Laptops, Cloud Servers, as well as Smartphones. More specifically, all modern processors capable of keeping many instructions in flight are potentially vulnerable. In particular, we have verified Spectre on Intel, AMD, and ARM processors.

Meltdown


Meltdown breaks the most fundamental isolation between user applications and the operating system. This attack allows a program to access the memory, and thus also the secrets, of other programs and the operating system.

If your computer has a vulnerable processor and runs an unpatched operating system, it is not safe to work with sensitive information without the chance of leaking the information. This applies both to personal computers as well as cloud infrastructure. Luckily, there are software patches against Meltdown.

Spectre breaks the isolation between different applications. It allows an attacker to trick error-free programs, which follow best practices, into leaking their secrets. In fact, the safety checks of said best practices actually increase the attack surface and may make applications more susceptible to Spectre

Spectre is harder to exploit than Meltdown, but it is also harder to mitigate. However, it is possible to prevent specific known exploits based on Spectre through software patches.

Is there a workaround/fix?
There are patches against Meltdown for Linux ( KPTI (formerly KAISER)), Windows, and OS X. There is also work to harden software against future exploitation of Spectre, respectively to patch software after exploitation through Spectre .

Which cloud providers are affected by Meltdown?
Cloud providers which use Intel CPUs and Xen PV as virtualization without having patches applied. Furthermore, cloud providers without real hardware virtualization, relying on containers that share one kernel, such as Docker, LXC, or OpenVZ are affected.

Why is it called Meltdown?
The bug basically melts security boundaries which are normally enforced by the hardware.

Why is it called Spectre?
The name is based on the root cause, speculative execution. As it is not easy to fix, it will haunt us for quite some time.

From what I can gather, Meltdown is the headache for Intel (and maybe others) and is the problem the patches recently noted are intended for. Spectre from my ignorant glance seems to be a much wider problem for the industry in general.
 
Back
Top