Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw • Hacker News Board

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#251

Post by csours » Wed, Jan 03, 2018, 5:57 PM UTC

emn13 wrote: post #27

This piece is (IMNSHO) trash. It's trying to stare into some crystal ball guessing at the cause of market fluctuations; but there's no real evidence they're right. Not to mention it's pretty misleading about technical stuff, saying e.g. "Chip design errors are exceedingly rare. More than 20 years ago, a college professor discovered a problem with how early versions of Intel’s Pentium chip calculated numbers." So, the…

> "So, they imply that chip design errors are once in a few decades kind of things; that's just complete nonsense. Chip design errors are common most just aren't this bad."

Many chip design errors are patched with microcode updates. There is speculation that this one cannot.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#252

Post by nopriorarrests » Wed, Jan 03, 2018, 5:57 PM UTC

zelos wrote: post #25

cma wrote: post #6

This isn't really too far out of proportion with normal daily fluctuations of AMD stock this year.

Quiet, you're spoiling the narrative we're imposing on semi-random, chaotic events.

+8.79% AMD & -4.44% INTC does not look like a semi-random event anymore. Seems like wider audience is waking up to the news.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#253

Post by throwaway613834 » Wed, Jan 03, 2018, 5:57 PM UTC

Will there be any way to disable or block the upcoming patches and keep the performance for those of us who really just don't have any reason to care about inter-process information leakage on our personal computers?

Edit: I'm (also) wondering about Windows, in case anyone knows yet.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#254

Post by someguydave » Wed, Jan 03, 2018, 5:57 PM UTC

emn13 wrote: post #64

whack wrote: post #41

Earlier quoted context omitted.

Major chip design errors, of this magnitude, are exceedingly rare. Especially in comparison to the software industry where bugs are released to production a couple orders of magnitude more frequently. How many other Intel hardware bugs can you point to that are comparable to the ones below? "All computers with Intel chips from the past 10 years appear to be affected... The security updates may slow down older machine…

That's what you're saying (and indeed what I said too!), but that's not what bloomberg published. What you're saying makes sense! But they didn't qualify this by major . And the qualification is important to the heart of the story, since the way they phrased it suggests that chip design is largely reliable and thus that this is an exceptional error, when in fact errors are common, and impact is merely exceptional. In…

Now you know how to weight the truth of mass media publications.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#255

Post by sli » Wed, Jan 03, 2018, 5:57 PM UTC

Splines wrote: post #192

rbjorklin wrote: post #172

Earlier quoted context omitted.

For some reason I can’t reply to ‘chrisper’ but I think ‘api’ is referring to going long in the stock market. https://www.investopedia.com/terms/l/long.asp

> For some reason I can’t reply to ‘chrisper’ HN doesn't let you do this to new comments to avoid back-and-forth commenting that is typical in flamewars.

Coming up on 9 years here and I'm still finding out new things about how this site works. I've been wondering recently why some comments aren't replyable.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#256

Post by nopriorarrests » Wed, Jan 03, 2018, 6:01 PM UTC

Can anyone with better knowledge ELI5 to me -- to fix this bug, are cloud providers have to patch only hypervisor machines, or guest boxes as well? And if fix is applied to hypervisor, will performance degrade on guest boxes as benchmark suggests? Thanks!

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#257

Post by paulmd » Wed, Jan 03, 2018, 6:01 PM UTC

DocSavage wrote: post #99

ashelmire wrote: post #81

Earlier quoted context omitted.

From what I've read, this slowdown only affects syscalls, which, since they aren't usually a huge percentage of processing in the first place, should not have such an effect. You're more likely looking at a few percent at most, which is not going to be enough to make AMD outperform Intel. Let's stop the fear mongering and wait for actual metrics.

Prelim benchmarks show a significant impact (~20%) on Postgresql benchmarks.

20% when running SELECT 1; over a loopback network interface, not in real-world workloads.

The other benchmark that has generated some consternation is running 'du' on a nonstop loop.

Both of these situations are pathological cases and don't reflect real-world performance. My guess is a 5-10% performance hit on general workloads. Still significant, but nowhere near as bad as some of the numbers that are getting thrown around.

And, databases are the worst case scenario, most real-world applications are showing 1% performance impact or less.

https://www.computerbase.de/2018-01/intel-cpu-pti-sicherheit...

https://www.hardwareluxx.de/index.php/news/hardware/prozesso...

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#258

Post by throwaway613834 » Wed, Jan 03, 2018, 6:01 PM UTC

lmm wrote: post #93

rayiner wrote: post #52

Can someone help me understand why this is such a big deal? This doesn’t seem to be a flaw in the sense of the Pentium FDIV bug where the processor returned incorrect data. It doesn’t even seem to be a bug at all, but a side channel attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it. And it doesn’t seem like it can be used for privilege esca…

If you can read kernel (and hypervisor) memory then it seems like a very small step from that to a local root vulnerability - e.g. forge some kind of security token by copying it. There's an embargoed Xen vulnerability that may be related to or combine with this one to mean that anyone running in a VM can break out and access other VMs on the same physical host. That would be a huge issue for cloud providers.

> If you can read kernel (and hypervisor) memory then it seems like a very small step from that to a local root vulnerability - e.g. forge some kind of security token by copying it.

This seems very wrong. I'm not aware of any privilege isolation in Windows relying on the secrecy of any value. Security tokens have opaque handles for which "guessing" makes no sense. Are you aware of anything?

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#259

Post by Cyph0n » Wed, Jan 03, 2018, 6:02 PM UTC

DSMan195276 wrote: post #230

prudhvis wrote: post #173

Earlier quoted context omitted.

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…

But doesn't the CPU enter kernelspace every time a syscall takes place? So based on what you've described, every time a syscall returns control back to userspace, the TLB will be flushed, which means slower page access times in general.

Re: Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

#260

Post by betterunix2 » Wed, Jan 03, 2018, 6:02 PM UTC

Havoc wrote: post #2

As a shareholder that's great. Concerned that this is a very fragile win though. I don't think there will be much real world fall out.

I am not so sure. Cloud providers will probably want to get this fixed and AMD would be a convenient alternative in the short term. I think the bigger risk is that rather than going with AMD, cloud providers will pursue a different CPU architecture altogether, especially in the long-term. There were plenty of things to dislike about x86 virtualization etc. before this mess.