Eh, probably just an NSA backdoor got discovered and now has to be hastily patched...... 

Hi Uteman,

Pardon my dumb sounding question, but having read the linked articles, I could not tell wether the exploit causes the potential 30% performance drop, or is it the KPTI (Kernel Page Table Isolation) fix to the OS through MS updates, that may create a 30%  intel CPU performance drop for any intel CPU going back a decade?
If I'm understanding correctly the fix would create a Kernel Page Table memory (Kernel mode) separate to the (User Mode) memory and that is where the slowdown occurs (in the handoff and handback between modes) when an instruction is issues by a program unsecured speculative code pageing can be intercepted then exploited (therein lies the problem to be fixed) or buy another new model CPU at you own expense which does not have the exploit built in.

If I'm reading it correctly this makes all Intel CPU users at risk of kernel code exploits, but not the AMD users, but we will all be subject to unreliable MS patch Tuesdays for any foreseeable fix. I wonder how this potentially unreliable MS update patch will work for Win10 users and us holdouts still using Win7 Win8 where updates have all but ceased.

I thought the Linux kernel team showed great restraint when quoting the acronym used to describe how the felt about the cockup. I can't use the actual acronym (it will get filtered by forum software) but here is the long version in the below quote Bolded and Hashed ## , just take the first letter from each word. or read the article directly via the link.

Quote: from this article https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/
Impact
It is understood the bug is present in modern Intel processors produced in the past decade. It allows normal user programs – from database applications to JavaScript in web browsers – to discern to some extent the layout or contents of protected kernel memory areas.

The fix is to separate the kernel's memory completely from user processes using what's called Kernel Page Table Isolation, or KPTI. At one point, Forcefully Unmap Complete Kernel With Interrupt Trampolines, aka F###WIT, was mulled by the Linux kernel team, giving you an idea of how annoying this has been for the developers.

If it happens that my current 5 year old rig (which I had planned to be my last) with i74770k + Win7/64Pro is affected without a possible update fix, I believe I'll go back to banging to wooden sticks together for fun, and just give this computer swindle away for good.

 

Hi Jethro,

The articles start with a specific test which references Skylake as being affected as indicated above.  We won't have long to wait to find out whether the problem has been worked over and its impact reduced to the best figure I have read so far which is 5%.

Don't know if you want to get into the nuts and bolts of it I don't, I read the lead in article here:

https://www.postgresql.org/message-id/[email protected]

and that leads one to a more technical and detailed (and confusing for me) explanation here:

https://lwn.net/SubscriberLink/741878/eaff7b24627c41a2/

That's why I am sitting in the corner with my fingers crossed. I am hoping this post is bombarded with more posts stating nothing to worry about, move on - after the event.

Hi Uteman,
Thanks for those new links, I'll give them a read through, but like many this level of tech knowledge is likely way over my head. I get the general idea but CPU Kernel and CPU architecture is all a foreign language to me.

Edit: Read the first linked article, it seems that its the unavoidable fix that will cause a performance drop. The fix is absolutely needed to resolve the potential code interception / code security exploit during the Kernel mode / User mode operations of the Intel CPU.

Fingers crossed its a non issue, but I have my skip bin ready and (wooden sticks v1.0) with ultra HD will be not far from my grasp. I might even take up the drums, I've heard 2 wooden sticks are great for that. Ha ha

The Register is hardly a credible tech source and is prone to wild exaggeration and hyperbole.

2 hours ago, Uteman said:

I certainly want to be positive as you are though the report referenced in the Register article directly refers to tests that show Skylake versions being affected by 17 to 23% in that specific loop test. The article also references in the link a possible ability to turn off the command at boot up. It reads that they have been working on/ been aware of the issue since October

as for gaming - simming....

 

+1 think positive....

 

 

In a "specific loop test" though. I'll try and find time to read that later. But "specific" might be the important bit, as in specific to that application, but maybe not for what you and I would use our PC's for. Just speculating, till I read it.

14 hours ago, suchw said:

I smell a class action law suit 

I look forward to my $25.

9 hours ago, Jethro said:

If I'm reading it correctly this makes all Intel CPU users at risk of kernel code exploits, but not the AMD users, but we will all be subject to unreliable MS patch Tuesdays for any foreseeable fix. I wonder how this potentially unreliable MS update patch will work for Win10 users and us holdouts still using Win7 Win8 where updates have all but ceased.

IIRC there is a submitted Linux kernel patch that checks the processor manufacturer before enabling the workaround - it's a two-line patch. It shouldn't be significantly more difficult for MS to implement such a fix as well.

Cheers!

 

8 hours ago, jabloomf1230 said:

The Register is hardly a credible tech source and is prone to wild exaggeration and hyperbole.

It's made BBC News.

http://www.bbc.co.uk/news/technology-42553818

They all are picking up leaked info from The Register. I'm not saying it's false, but rather it won't be as bad as The Register makes it out to be.

Given the mad rush to patch the kernel, the willingness to tolerate a 30% performance hit without question, and AWS and Azure rushing forced reboots across tens of thousands of hosts over the next few days? It's bad.

These are people who have forgotten more about the inner workings of x86 processors in the past week than you or I will ever know. If you believe that the problem won't be as bad as made out, I'd be interested in hearing why based on your understanding of how these processors work.

 

51 minutes ago, jabloomf1230 said:

They all are picking up leaked info from The Register. I'm not saying it's false, but rather it won't be as bad as The Register makes it out to be.

Here's some better info.

https://security.googleblog.com/2018/01/todays-cpu-vulnerability-what-you-need.html

https://arstechnica.com/gadgets/2018/01/whats-behind-the-intel-design-flaw-forcing-numerous-patches/

Mike Magee keeps founding magazines/websites that are termed "Tabloid Tech". The Register --> The Inquirer--> Tech Eye. Every so often one them gets a scoop right. Let's hope that it's not this one.

3 minutes ago, jabloomf1230 said:

Mike Magee keeps founding magazines/websites that are termed "Tabloid Tech". The Register --> The Inquirer--> Tech Eye. Every so often one them gets a scoop right. Let's hope that it's not this one.

The Google researchers who found it seem to think it's pretty bad. Especially for the likes of Amazon AWS and Microsoft Azure, or anyone else hosting VMs.

Quote

The Project Zero researcher, Jann Horn, demonstrated that malicious actors could take advantage of speculative execution to read system memory that should have been inaccessible. For example, an unauthorized party may read sensitive information in the system’s memory such as passwords, encryption keys, or sensitive information open in applications. Testing also showed that an attack running on one virtual machine was able to access the physical memory of the host machine, and through that, gain read-access to the memory of a different virtual machine on the same host.

 

Surely this vulnerability is only exploitable if external sites have unrestricted access to your system (no firewall or antivirus/malware protection installed).

As with many of these bugs, they're discovered under quite specific conditions in a controlled environment but the vulnerability is usually considerably more difficult to exploit in the real world. The manufacturer is then forced to issue a fix to protect the lowest common denominator: the person who runs an unprotected system. It would be interesting to find out if any hackers have actually exploited this vulnerability which would appear to have been around for many years.