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

301–310 of 567 posts

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

#301

Post by thraweigh666 »

qubex wrote: post #292

I’m not (yet) clear on if/how this impacts aarch64 (ARM architecture) chips, the distinction between how it affects Intel vs. doesn’t affect AMD reminds us of a fundamental lesson we seem to have conveniently forgotten: monocultures of anything are bad. We need diversity and diversification in order to have reasonable amount of robustness in the face of unknowable, unpredictable risks. I’m wondering whether ARM chips…

>We need diversity and diversification in order to have reasonable amount of robustness

Ironically, in human populations it produces the opposite effect.

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

#302

Post by agency »

j_s wrote: post #264
rincebrain wrote: post #186

Earlier quoted context omitted.

The hypothesis I've seen, and why people seem to be rushing to patch it without explaining, is that you might be able to not only leak addresses, but actual data, from any ring, into unprivileged code, at which point, your security model is burned to the ground. AIUI, the present circumstances are: - there exists a public PoC from some researchers of side-channel leaking kernel address information into userland via J…

Thanks for summarizing. Does anyone have time to link to more on the "side-channel leaking kernel address information into userland via JavaScript" ?

This isn't exactly that, but here[1] is a talk linked in the post from the other day which shows a PoC breaking ASLR in Linux from JavaScript running in the browser, via a timing attack on the MMU. There's a demo a half hour in.

EDIT: This post[2] discusses the specific speculative execution cache attack and claims there is a JavaScript PoC (but doesn't cite a source for that claim)

[1] https://www.youtube.com/watch?v=ewe3-mUku94

[2] https://plus.google.com/+KristianK%C3%B6hntopp/posts/Ep26AoA...

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

#303

Post by eximius »

HelloNurse wrote: post #164
spdy wrote: post #77

Earlier quoted context omitted.

Isn't why this problem even exits the exact opposite? Intel was losing on the mobile market and changed internal testing to iterate faster by cutting corners. Found a quote: "We need to move faster. Validation at Intel is taking much longer than it does for our competition. We need to do whatever we can to reduce those times… we can’t live forever in the shadow of the early 90’s FDIV bug, we need to move on. Our comp…

Obvious hypothesis: first complacency leads to incompetence, then starting to cut corners has catastrophic consequences. The two problems are wonderfully complementary. As other comments suggest, there might be a third stage, completely forgetting how to design and validate chips properly.

Or the system was designed poorly to begin with and now you're stuck with the design for backwards compatibility reasons.

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

#304

Post by devcpp »

rbanffy wrote: post #270
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…

It's a good thing CPU is fairly compressible. Unless you meter it very carefully, you'll see the performance hit and it'll not impact you that much. Very few of my physical boxes are over 70% CPU utilization on a daily average. It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Int…

Problem is, most companies that need a lot of power only care about one thing - peak performance. And they tune it carefully in order to not overspend while guaranteeing minimal downtime. This means that they'll have to pretty much scale their infrastructure up by exactly 30%. That's a LOT for these big clients.

Honestly, I'd just make sure the server firewalls are super tight and not take in the future patches. At least for now.

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

#305

Post by jlgaddis »

dnautics wrote: post #40
grendelt wrote: post #32

Earlier quoted context omitted.

> 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. Welcome to the world of business reporting.

I think it's pretty clear in this case. Plenty of people here in hn-land were talking about Intel/AMD short/long positions starting in the afternoon yesterday and word has gotten around.

Yes, I'm sure all those Wall Street finance folks are all scouring HN comment threads just waiting for the next great piece of investment advice that they can move on.

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

#306

Post by adornedCupcake »

thraweigh666 wrote: post #301
qubex wrote: post #292

I’m not (yet) clear on if/how this impacts aarch64 (ARM architecture) chips, the distinction between how it affects Intel vs. doesn’t affect AMD reminds us of a fundamental lesson we seem to have conveniently forgotten: monocultures of anything are bad. We need diversity and diversification in order to have reasonable amount of robustness in the face of unknowable, unpredictable risks. I’m wondering whether ARM chips…

>We need diversity and diversification in order to have reasonable amount of robustness Ironically, in human populations it produces the opposite effect.

Why?

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

#307

Post by eberkund »

paulmd wrote: post #257
DocSavage wrote: post #99

Earlier quoted context omitted.

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 throw…

It's not really a worst case scenario when you consider where the majority of Intel's revenue comes from: selling their high margin server chips for use in data centers, a significant portion of which are running some kind of database.

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

#308

Post by cypherpunks01 »

blattimwind wrote: post #55
lafar6502 wrote: post #36

But is the security Bug exploitable in any realistic way?

https://twitter.com/brainsmoke/status/948561799875502080

What does that output mean? He was able to look up an address that was used in a speculative execution or something?

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

#309

Post by bogomipz »

rbanffy wrote: post #270
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…

It's a good thing CPU is fairly compressible. Unless you meter it very carefully, you'll see the performance hit and it'll not impact you that much. Very few of my physical boxes are over 70% CPU utilization on a daily average. It's, however, really bad if you sell CPU cycles for a living. You just lost between 5 and 30% of your capacity. If you have a large building, you just lost part of your parking lot to the Int…

>"It's a good thing CPU is fairly compressible."

What do you mean by "compressible"?

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

#310

Post by Pottsy »

eptcyka wrote: post #187
0xcde4c3db wrote: post #82

Earlier 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.

It has very little to do with what kind of syscalls (I/O or other kinds) and all to do with how many syscalls a given application makes per given time period. Compute bound applications are already avoiding syscalls in their hotter parts. This will mostly be a blow to databases, caching servers and other such I/O limited applications.

Would it be fair to say that this might cause acceptation in the shift from on prem to the public cloud, where there are performance guarantees?
Post reply on HN