2 hours ago, FlightSimmer68 said:

Nobody knows *exactly* what any patch will do. So far it's just pure FUD which teh interweb will love and speculate about endlessly, even in spite of any facts that may emerge.

People do - the Linux kernel patches are starting to appear. They'll need to do a TLB flush when switching from user-mode code to the kernel, which will slow down that switch since they'll need to reload page table entries.

Bottom line on the effect is it depends on how much time your code spends in the kernel. You can probably take a look in Task manager to get a rough idea.

Cheers!

Every Intel CPU is affected. In normal use there will be a very small performance loss - not a big deal. BUT, the "up to 40% impact" is mostly measured on heavy IO loads, with is (again, as far as I know) a big deal for flight simmers. The sim reads a lot of data. So this could be a major issue for us. Time will tell, I hope Im wrong...

11 minutes ago, Humpix said:

BUT, the "up to 40% impact" is mostly measured on heavy IO loads, with is (again, as far as I know) a big deal for flight simmers. The sim reads a lot of data.

No, it doesn't. It's primarily CPU and GPU dependent - this is why SSDs don't affect the frame rate much, if at all. In the MS world, you'll primarily see the impact in initial load.

Cheers!

 

Hmm, I already have troubles to load the autogen and terrain while flying, so I always thought that the SSD is the bottlenek. For sure, the task manager shows less load on the SSD, but it does not cover the IO load, only the overall MB/s load.

But anyway - this makes some hope. Hopfully im wrong. - we will know more next week when the patch is out...

7 hours ago, Adrian123 said:

just downloaded the Intel test tool. yep, vulnerable. 7700k

 

 

This is for different bug and not relevant in this case. Perhaps the link could be removed as it appears to be misleading people?

No wonder I was holding off on a new system.

I have been ready to buy a "Mother of All PC's" for 8 months now, but for whatever reason I had a "red alert" to hold off and wait, but I did not know why. Nevertheless, my current PC is doing great until that red alert goes away.

So bottom line with the verification tool is that this, risk assessment tool (Intel-SA-00086-GUI.exe ) is not checking for the current problem, Kernel Page Table Isolation (KPTI), there is no risk assessment tool for this yet.

(Intel-SA-00086-GUI.exe) It is checking the code for MEI and TXEI code issues, so your Verification Vulnerability reports showing green "not Vulnerable" output are only for the below vulnerabilities

Intel® Management Engine Interface (Intel® MEI) driver 
or
Intel® Trusted Execution Engine Interface (Intel® TXEI) driver

Its going to be a bumpy ride, and we will not like the medicine the boffins plan to treat this (KPTI) cancer with. It all amounts to Intel corner cutting for market supremacy over AMD. Intel's Speculative Code Execution shortcuts certainly speed up code execution but expose the Kernel to User code security violation. But we can all see now this was a big mistake and we must bear the performance loss with the fix they propose to close the hole. (@#$% cowboys).

 

 

Disregard.

9 hours ago, Nyxx said:

i7 4790K = NOT Vulnerable

Allelujah. Balking at early adoption pays off again!

Question. For all those vulnerable.  Does OC bypass the issue?

How many more times? The test tool linked here earlier is NOT for this issue. 

 

10 minutes ago, fppilot said:

Allelujah. Balking at early adoption pays off again!

The tool that was linked and all results from it are not relevant for this latest bug, so you are definitely not in the clear.

Most reports seem to implicate all Intel CPUs in the past 10 years, and possibly much older. While AMD systems don't seem to be vulnerable, ARM processors appear to be (think Android phones).

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/

30 minutes ago, goates said:

The tool that was linked and all results from it are not relevant for this latest bug, so you are definitely not in the clear.

Most reports seem to implicate all Intel CPUs in the past 10 years, and possibly much older. While AMD systems don't seem to be vulnerable, ARM processors appear to be (think Android phones).

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/

I am attempting to process all of this. Meanwhile my system churns along according to specs, without outside influence....

Hi Frank,

1 hour ago, fppilot said:

Meanwhile my system churns along according to specs, without outside influence....

Yes your current Intel CPU will continue to churn along happily passing potentially damaging code intercepted by malware or hacker from User directly at the Kernel then back to the User, unbeknown to the user because Kernel memory is supposed to be protected from such security risk. The problem comes with Intel's speculative approach to the exchange, by design a critical flaw un-noticed until the Linux guys questioned the process because of some unusual data exchange between secure Kernel and User (not as secure) pre-emptivley caching data that may or may not be correct according to an algorithm (which is usually correct about what to cache and send on back to the user), but it is exactly this vulnerability which can be easily exploited.
Between User Mode and Kernel Mode and back to User Mode, parsed stamped and patted on the backside goes the data, back and fourth with nary a security check from Intel's speculative process, on all Intel CPU's for the last decade.
The problem for the PC user, comes later on with the OS patch side. To fix the gaping security hole they must nobble your processor by creating a man in the middle Kernel to User isolation cache (PTI) (Page Table Isolation) as a workaround for current Intel processors. The fix provided for the Operating System is where we may see performance drop up to 30% simply because of the extra time it will take the (PTI) man in the middle cache, to exchange the data between both parties.

It appears that the next generation Intel CPU's will not have this design flaw, and will not need the K(PTI) man in the middle OS software patch.

The only thing about the whole debate in the linked articles on the interweb, at least for me is the constant reference to (x86) 32bit process I'm assuming this also refers to x86 CPU's  rather than a x64 CPU's 64bit process. hmmmmm... I am wondering if we might be ok afterall.

Another way to look at this would be that this "flaw" is a method to improve performance, and it was probably introduced by Intel in good faith a long time ago.

What is bugging me is, that we have to spend money, time, disk space and quite a few processor cycles just because some people don't understand the difference between right and wrong. Imagine how well a computer could be humming along if we didn't have to care about some word not allowed breaking it.

Best regards

Coincidence? Don't think so

https://www.fool.com/investing/2017/12/19/intels-ceo-just-sold-a-lot-of-stock.aspx