Massive CPU Security Flaws Revealed

That is the million-dollar question. The Motely Fool thought it was suspicious when it happened, and that was weeks before there was any inkling of this.

I do wonder how long it will take Intel to fix this on their end. It sounds like this is been a part of their CPU design for a long time. Cannon Lake is due out this year, and it’s basically shrinking down Skylake/Kaby Lake/Coffee Lake to 10nm. Is it too far in the oven to change? If so, then we’re looking at 2019 until they get around to resolving it on their end. And everyone is still gonna need new CPUs to get around the performance hit.

If I’m AMD, I’m pulling out all the stops for Ryzen 2 and, more importantly, their new server CPU.

Sorry, I think 1999 was the last time eeking out CPU performance was relevant to me.

I don’t see how it could possibly not be insider trading. He certainly will have to answer SEC questions about sale.

Every service you use will be slower, Tim. They will pass their hardware costs down to you. One article said a simple database select exhibited a 23% slowdown, which is, well, cataclysmic.

I’m already in the kitchen when I run a vBulletin search. I can just make an extra plate of snacks. No problem.

Obviously I meant personal computers. I’m perfectly willing to panic over this when the time comes.

Interesting that both VMWare and Intel Stock are both higher today, as well as in after-hours trading. Not sure this has filtered to institutional investors yet, but if that 23% slowdown information is correct, it could actually kill the virtualization markets.

It depends, he could have filed plans a very long time back to exercise those options and sell them.

Possible, but then why would he choose to sell the maximum number permissible? Might not be a rat, but it smells like one.

When I was there VP’s and above were encouraged to have fixed plans to sell stock every 3,6, or 12 months. Plus at the middle management level, there were a couple of times we were told you will not sell any stock until this CPU bug issue has been resolved.

If Krzanich was stupid enough to sell stock because of this, he will almost certainly get punished.

Aside from forums and reddit, the only story so far is from The Register. But a couple of the Mac news sites are reporting the Register story, which means it may get more momentum tomorrow.

If I’m Intel, it may be time to lay the cards on the table. The rumors and speculation are only going to avalanche from here.

Probably because it’s better to diversify your investments instead of putting all of your eggs in one basket? It’s guaranteed the sell-off was pre-planned months+ ago with forms filed with the SEC. It’s a requirement.

It will be interesting to see if the performance hit is done in a way that AMDs are not affected. Epyc is already showing signs of being very good for data center usage and this could push people that are on the fence over.

If the hit is really 20 or 30 percent on certain tasks, amd will have a window where they are very competitive.

Won’t affect AMD at all.

https://lkml.org/lkml/2017/12/27/2

if (c->x86_vendor != X86_VENDOR_AMD) setup_force_cpu_bug(X86_BUG_CPU_INSECURE);

AMD is not affected. After the linux kernel workaround patch for this issue was made, they made a rather smug linux kernel commit to exempt their own processors

https://lkml.org/lkml/2017/12/27/2

That’s good to see but concerning that the patch came from AMF themselves. Hopefully they are talking with Microsoft to ensure windows doesn’t degrade performance for AMD if it’s not needed

Just came across this :

https://www.phoronix.com/scan.php?page=news_item&px=x86-PTI-Initial-Gaming-Tests

That was for Linux. And yes, of course they are.

It’s not going to kill virtualisation generally, it’s not like we are going back to running one service/app per physical host ever.

Enterprise virtualised server farms generally run 60-70% or less utilsation to cover DR/host failure/dynamic resource scheduling/maintenance, etc, etc. This may just shift that numbers around a bit, and obviously change design considerations for certain workloads, but the commercial fundamentals of x86 virtualisation are still well and truly sound compared to going back to one app per host.

This is also arguably less a security issue for on-prem deployments. This presents higher risk when sharing hardware with other tenants (customers) on a public cloud, as compared to on-prem where you own and control all the hardware and apps and security postures. Still not no risk, by any means and still a significant bug, but an attacker would at least need to penetrate your perimeter to leverage an exploit, as opposed to just rent a VM on a shared public infrastructure. I’d argue if an attacker has already past the on-prem perimeter, there are far easier exploits to enable propagation than this in any case, since generally enterprises do a poor job of east-west security in the DC.

Service Providers, on the other hand, over-subscribe shared resources, so this could put a serious, serious dent public cloud adoption rate as customers balk at potential price increases, performance decreases, bad publicity raises perceived risk and they choose instead to wait and see what the fall out will be.

Sadly, Intel can’t blame the slowdown on aging batteries.

Major news outlets starting to report on this. Intel needs to come clean, because they’re all waving around reports of huge slowdowns.

Intel stock has dropped 3.8% this morning. AMD is up 7.2%!!!

Is the (client-side) fix just going to be a question of updating Windows/OSX, or is it going to need manual motherboard patching?

It can only be fixed at the OS level.