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

321–330 of 567 posts

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

#321

Post by philipov »

mizzack wrote: post #275
ehsankia wrote: post #211

Earlier quoted context omitted.

I don't understand this attitude that "top brass might not know about it". He's the CEO, isn't his entire job to know what's going on in the company? I know we get this idea that rich people just sit back and take in the money, but isn't the reason they are paid so much in the first place because they have in theory a big responsibility on what happens in the company?

You're putting words in my mouth. I didn't say he didn't know about it. I said we don't know WHEN he first knew about it, which is important in the context of insider trading.

Even if he knew about it, if it was more than 6 months in advance and he follows all the legally-mandated protocols for setting up a regulated stock trade, isn't he safe?

The marvel is that somehow the news was kept from hitting the media until he had finished his trade, and then was revealed immediately after the transaction was complete. I wonder how that coincidence happened.

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

#322

Post by hinkley »

kakarot wrote: post #249
hinkley wrote: post #237

Earlier quoted context omitted.

It's a good thing.

What is a good thing...?

Martha Stewart did jail time for insider trading. Turns out the SEC isn't messing around, and they don't hand out community service, probation and fines for this stuff.

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

#323

Post by ajross »

devcpp wrote: post #304
rbanffy wrote: post #270

Earlier quoted context omitted.

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

Very very few highly tuned "peak performance" workloads are dominated by syscall overhead like the test that produced that 30% number was. It's best to hold off on the hyperbole.

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

#324

Post by djsumdog »

ComodoHacker wrote: post #233
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…

Forgive me my ignorance, but I fail to see how this is such a big deal. Even 50% performance hit/cost increase would be... bearable, computations are rather cheap today. ML and other intensive calculations aren't done on CPU anyway. It's not like technical progress of our civilization is slowed down by 30% or something... On the other hand, shrinking Intel's market share due to bad PR and thus adding some competition…

Have you worked in a company where you've hit CPU performance limits. At my last job, we'd have some services run in 25 containers in parallel and we'd have to optimize as much as we could for performance bottlenecks. We'd literally get thousands of assets per minute some mornings, and had a ton of microservices to properly index tag, thumbnail and transcode them.

Our ElasticSearch nodes all had 32GB of ram and we had 10 of them and they were all being pushed to the max.

Something like this would be a massive hit, requiring a lot more work into identifying new bottlenecks and scaling up appropriately.

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

#325

Post by devit »

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 depends on whether it's an attack against HVM hypervisors or not.

If it, like it seems, is just an attack on OS kernels and PV hypervisors, you can simply turn off the mitigation, since nowadays kernel security is mostly useless (and Linux is likely full of exploitable bugs anyway, so memory protection doesn't really do that much other that protecting against accidental crashes, which isn't changed by this).

Even if it's an attack against hypervisors any large deployment can simply use reserved machines and it won't have a significant cost.

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

#326

Post by theoh »

bogomipz wrote: post #309
rbanffy wrote: post #270

Earlier quoted context omitted.

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"?

Presumably, for a certain important class of application, CPU is not used "densely", i.e. continually. Instead it's used intermittently, like a gas rather than a solid... Hence compressibility. Such applications are far from being CPU-bound, in other words.

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

#329

Post by alanfalcon »

Retric wrote: post #208
Sean1708 wrote: post #188

Earlier quoted context omitted.

> Well, if I rent a VPS with x performance, I still expect x performance after this flaw is patched. Are there any providers that state you will get x performance? Most that I've seen say you will m processors, n memory, and p storage but don't make any guarantees about how well those things will perform.

Last I checked Amazon AWS has a virtual processor metric not actual hardware metric. This is most noticeable in their lowest power instances which don't get a full modern CPU core.

If the virtual metric is tied to real performance then it could mean a drop in performance while maintaining the same power rating... It will be interesting to see if vendors directly address this.

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

#330

Post by dingo_bat »

ihsw2 wrote: post #85
rwmj wrote: post #5

AMD must be pretty happy about this patch: https://lkml.org/lkml/2017/12/27/2

Not quite -- without his patch, the performance penalty will hit them too. Tom is proposing to be excluded from the proposed solution as it would hit AMD with collateral damage from the `X86_BUG_CPU_INSECURE` fix. I'm sure there are frantic emails claiming that AMD shouldn't be punished for Intel's mistake. EDIT: actually the fix will go out with 4.14.12 and 4.15rc7, both `X86_BUG_CPU_INSECURE` and AMD's addendum to…

Maybe it's just me but that name is just too general. Is there no other conceivable way an x86 CPU can ever be "insecure"? Why'd they use something so vague? Is this part of the redaction?
Post reply on HN