Live data from Hacker News

Intel Confronts Potential ‘PR Nightmare’ With Reported Chip Flaw

bloomberg.com

431–440 of 567 posts

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

#431
post #5

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

Not so sure about that. I am reading the merge commit, and comments are pretty interesting: --- a/arch/x86/include/asm/processor.h +++ b/arch/x86/include/asm/processor.h + * On Intel CPUs, if a SYSCALL instruction is at the highest canonical + * address, then that syscall will enter the kernel with a + * non-canonical return address, and SYSRET will explode dangerously. + * We avoid this particular problem by prevent…

It's a completely unrelated bug. This DragonFlyBSD commit message does a pretty good job of explaining it: http://lists.dragonflybsd.org/pipermail/commits/2017-August/...

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

#432

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.

Please just don't. It isn't worth the pain and risk just to have a little faster system. Maybe you don't care about this patch, but you will need others that are dependent on it.

Just patch.

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

#433

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…

Their competitors are also affected. Also a 30% decrease is also equivalent to setting Moore's law back 7 months. A 5% loss is only setting it back 1 month. I know that's a bit of a naive calculation. But the point is computing power has long operated in an exponential domain. So big differences in absolute numbers aren't necessarily a big deal.

CPU speed hasn't followed Moore's law since 2003ish. (Number of transistors is still following Moore's law, but that doesn't necessarily directly help you when your program is suddenly 3-30% slower.)

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

#434

Intel response https://newsroom.intel.com/news/intel-responds-to-security-r...

> Intel believes these exploits do not have the potential to corrupt, modify or delete data. No, you can just read data you shouldn't be able to. > Intel is committed to product and customer security and is working closely with many other technology companies, including AMD, ARM Holdings and several operating system vendors, to develop an industry-wide approach to resolve this issue promptly and constructively. Let's…

I'd be curious to know which media reports Intel actually finds inaccurate. I'm sure there are some out there, but I suspect most reports aren't inaccurate in ways that significantly deviate from the overall message that Intel's products have a relatively serious security flaw. Making a blanket statement that implies all the reporting is inaccurate is very disingenuous.

Dragging AMD's and ARM's names into this is completely inexplicable to me however.

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

#435

Earlier quoted context omitted.

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…

If you run things efficiently you're eaking every ounce of performance out of this hardware. A 30% performance hit means a 30% cost increase. The bigger issue is for things that don't scale easily. That sql server that was at 90% capacity is suddenly unable to handle the load. Sure that could've happened organically, but now it happens (perhaps literally) overnight for everyone all at once. Expect a bunch of outages…

"A 30% performance hit means a 30% cost increase."

Just wanna point out that a 30% performance hit means a 43% cost increase.

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

#436
post #295

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.

Just don't do this if you have PII, HIPAA, or PCI data on your computer.

Even then and if they don't care about their own safety, they should patch for the rest of us. Who knows how long until their unpatched system will get pwned from some other vulnerability and end up in some botnet just spreading the pain.

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

#438
post #131
post #58

I don't know much about CPUs, so what prevents a fix via microcode update?

The bug seems to be revolving around speculative execution. It seems like that is a silicon thing, not a microcode thing.

The bug seems to be about the processor leaving speculatively read privileged data in some of the caches, even if execution failed [1].

If so, clearing all caches upon a failed privilege check sounds like something within the capabilities of microcode and without unreasonable performance penalties.

Unfortunately, that would not explain the complex in-kernel fix...

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

EDIT: what remains in cache is not "speculatively read privileged data" but more "unprivileged data whose address is correlated to speculatively read privileged data". Retrieving later such address allows one to infer what the privileged data was. Still, the point about clearing all caches as countermeasure holds...

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

#439
post #382

Earlier quoted context omitted.

If they really care about peak performance, I don't believe the PTI patch will affect them. If you can change your system in a way that the power-hungry part does not work on untrusted data, you can not with "nopti" and ignore it. Systems which both need lots of maxed-out CPUs and traffic directly from wild internet are pretty rare. They're unlikely to run on a virtualised systems either.

Systems which both need lots of maxed-out CPUs and traffic directly from wild internet are pretty rare. That's a good description of basically every cloud environment out there, from AWS on down. In other words they are extremely common.

The CPUs in cloud environments are not maxed out in general. There will be some area like batch processing and compute-specific VMs. For other cases, there's quite a bit of overcommitting of resources. And that's before you start doing scheduling that mixed workloads on a physical host for better utilisation. Source: worked on a public cloud environment.

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

#440
post #384

Earlier quoted context omitted.

Hmm. Since everyone that sells (Intel) CPU cycles for a living suffers the same loss of supply this boils down to pricing; the same demand chasing fewer cycles will drive up prices and the market will adapt. 30% is a big hit. I'm wondering if that isn't a bit exaggerated, or perhaps the consequence of a poorly optimized workarounds that will rapidly improve. I recall seeing figures on the order of 3% only a few days…

30% is a worst case for a workload optimized to hit the performance bug as hard as possible. How big it will be for your workload is a function of what your workload is. Benchmark if it is important to you.

[deleted]
Post reply on HN