Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

bloomberg.com

Post reply on HN
Print view View original

41–50 of 567 posts

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

#41

Post by whack »

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…

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 machinery by as much as 30 percent, according to the report."

"discovered a problem with how early versions of Intel’s Pentium chip calculated numbers... Intel had to recall some chips and took a charge of more than $400 million."

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

#43

Post by wyager »

dsign wrote: post #19

This is a clusterf /big deal. Beyond the security implications, it means that all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses for the same amount of CPU, assuming that they can just scale up their infrastructure. I know that bugs happen and that there was nothing intentional on this one, but at times like this is hard to held at bay the temptation of claiming…

> I know that bugs happen

This isn’t an excuse for Intel consistently having terrible verification practices and shipping horrendous hardware bugs. From 2015: https://danluu.com/cpu-bugs/ There have been more since then.

I’ve talked to multiple people who work in intel’s testing division and think “verification” means “unit tests”. The complexity of their CPUs has far surpassed what they know how to manage.

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

#44

Post by blattimwind »

marmaduke wrote: post #39
willvarfar wrote: post #12

Earlier quoted context omitted.

in this particular case, will the generalization help their readership? I actually think it will - it would be easy to give more accurate details that cause many readers to glaze over.

That was my reaction. How to ELI5 the risk in multitenant VM environment? It could steal passwords

> How to ELI5 the risk in multitenant VM environment? Some other guy paying EC2 steals your customers passwords by sheer force of will

> How to ELI5 the risk in desktop PC? A piece of JavaScript in some 0x0 pixel iframe in a tab you're not even looking at stealing your passwords and SSH keys

(Although nothing is proven in the latter regard, I wouldn't be per se surprised to see something in that direction once the exact nature of the issue is more widely known)

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

#45

Post by tetraodonpuffer »

FBISurveillance wrote: post #16
db48x wrote: post #4

Earlier quoted context omitted.

If all Intel CPUs get 30% slower overnight, then there will be some fallout in the real world.

They might be 30% slower in virtualization and should be about 5-7% slower in real world usage. As a heavy user of the cloud I'm worried about my infra more than about my laptop: if my cloud setup gets even 7% slower overnight it won't be good to say the least, especially with lower-clock 2Ghz Skylake GCP CPUs. Those 5--7% will make me feel like I'm powered by Atom and it will be even worse for single-core bounded wo…

there's other real world usage (DAWs, for example, where there is a ton of I/O for sample-based virtual instruments) which will likely be as significantly impacted as virtualization likely...

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

#46

Post by glebm »

rocqua wrote: post #23
Waterluvian wrote: post #17

Earlier quoted context omitted.

Hm. Do cloud providers need to provide up to 30% more capacity for the same price, or do customers need to purchase up to 30% more capacity to get the same speed?

Unless demand is fully inelastic, if you up the price fewer people will buy. As such, this should hit the cloud provider profits.

*fully elastic

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

#48

Post by sooheon »

mindcrime wrote: post #29
dzink wrote: post #20

Didn’t the Intel CEO just sell half of his shares/options? If he knew about these issues isn’t that illegal?

Seems debatable. From what I recall, at least some news about this issue was already public before he sold his shares. And what would be illegal would be trading based on information that isn't public. OTOH, since details are still dribbling out, you could possibly argue that the Intel CEO had more complete information than the public. The sell could also have been scheduled in advance, which would - AFAIK - not viol…

Unless the advance scheduling is completely binding, I don't see why that should sidestep insider trading. What's to stop these guys from always having a cascading series of sells and buys 6 mo. in advance, and just cancelling them?

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

#50

Post by colanderman »

cjbprime wrote: post #30
BoorishBears wrote: post #21

Earlier quoted context omitted.

This bug doesn’t magically chop all CPU performance down by almost a third.

What does it do, then? That is approximately what the mitigation patch does, according to early averages of perf changes.

Syscall-heavy workloads are affected to a much greater degree than CPU-heavy workloads. (This is a direct consequence of the fact that the workaround involves a per-syscall overhead.)
Post reply on HN