It must be serious when stock of this size goes 5% down now...
https://www.google.com/search?q=intel+stock
Edit: AMD 8% up: https://www.google.com/search?q=amd+stock
Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
221–230 of 567 posts
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#222"Intel has a bug that lets some software gain access to parts of a computer’s memory that are set aside to protect things like passwords." Seems like very little got through to the media about the details regarding this flaws effects and costly workaround.
Bloomberg is not going to focus on technical detail too much (at all) given their readership. Follow the link to the register for more detail.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#223Earlier quoted context omitted.
Superficially, it seems like the performance hit mostly scales with IOPS or transactions per second, which might have some pretty serious implications for performance/dollar in the kinds of intensive back-end applications where Intel currently dominates and AMD is trying to make inroads with EPYC.
As I mentioned in the other thread yesterday database and database like applications are going to be hit particular hard. Even more so on fast flash storage. Double whammy compared to apps just doing network IO. And while databases try to minimize the number of syscalls they still end up doing a lot of them for read, writeout, flush.
Do we have a performance estimate? I can eat 20 or 30%, but I can't eat 90%.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#224Here are some numbers quantifying the problem. Big caveats apply as they are very preliminary, but the hit due to the software patches looks extremely significant: https://www.phoronix.com/scan.php?page=article&item=linux-41...
Phoronix strikes again! I admire Michael's consistency and dedication and their benchmarks have certainly gotten better over the years as PTS has matured, but everything on Phoronix still needs to be taken with a generous helping of salt. New readers generally learn this after a few months; it applies not only to their benchmarks, but also their "news".
The most obvious issue with this benchmark is that Phoronix is testing the latest rcs, with all of their changes, against the last stable version [EDIT: I misread or this changed overnight, see below] that doesn't have PTI integrated, instead of just isolating the PTI patchset. The right way to do this would be to use the same kernel version and either cherry-pick the specific patches or trust that the `nopti` boot parameter sufficiently disables the feature. That alone makes the test worthless.
There is no way this causes a universal 30% perf deduction, especially not for workloads that are IO-bound (i.e., most real-world workloads). This is a significant hit for Intel, but it's not going to reduce global compute capacity by 30% overnight.
EDIT: Looking at the Phoronix page, the benchmark actually appears to use 4.15-rc5 as "pre" and 4.15-some-unspecified-git-pull-from-Dec-31-that-isn't-called-rc6 as "post". I thought I had read 4.14.8 there last night, but may not have. Regardless, the point stands -- these are different versions of the kernel and the tests do not reflect the impact of the PTI patchset.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#225Is there any real danger for desktop users? We should be allowed to skip this patch if we dont want it, I would rather take the risk than the performance hit.
For desktop users there should not be any noticeable performance degradation. But they are also likely the ones in the most danger, since they execute random code in their web browsers.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#226Earlier quoted context omitted.
Looks like Krzanich sold $39.4M of stock on 11/28. Hard to say when the top brass knew about this flaw. https://finance.yahoo.com/quote/INTC/insider-transactions?p=...
The article that started most of the discussion listed the first publicly seen patches at middle of november from Microsoft, and one would assume that a bug that could cause major performance impacts like this makes its way upstairs pretty quickly to Intel. https://twitter.com/aionescu/status/930412525111296000
Intention to sell has to be registered with the SEC 6 months in advanced right?
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#227Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#228This isn't really too far out of proportion with normal daily fluctuations of AMD stock this year.
this year
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#229Earlier quoted context omitted.
A lot of people have noticed that High Sierra is slower than Sierra, specifically for filesystem operations with APFS. I wonder if Apple knew about this ahead of time and this explains the overhead?
Probably not. APFS just does a lot more then HFS, so there is a huge performance impact on disk related issues before this change goes in. This is a all hands on deck kind of situation. Apple doesn't usually do well with security firedrills like this.
I hope somebody on Twitter has informed Apple about this.
Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw
#230Earlier quoted context omitted.
As a billion other people have already said, that all depends on their workloads. This isn't a 30% clockspeed deduction.
As i understand the problem, this isn't about clockspeed reduction, now it is the software's responsibility to check if the page is a kernel page/user page. So, the impact is significant. So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower.
> So, every time either pages are touched/accessed this check needs to be triggered, which causes it to be much slower.
Not to be mean, but that's not what is being changed.
You're right on the bug - userlevel code can now read any memory regardless of privilege level. However the fix isn't to manually check the privileges on each access - that would be extremely slow and wouldn't actually fix the problem.
The fix is to unmap the kernel entirely when userspace code is running. Because the kernel will no longer be in the page-table, the userspace code can no longer read it. The side-effect of this is that the page-table now needs to be switched every-time you enter the kernel, which also flushes the TLB and means that there will be a lot more TLB misses when executing code, which slows things down a lot.
So, to be clear, it is not accessing pages that is being slowed down, it is the switch from the kernelspace to the userspace.