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

311–320 of 567 posts

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

#311

Post by cornholio »

throwaway613834 wrote: post #281
cornholio wrote: post #178

Earlier quoted context omitted.

It depends on how they handle user compensation. Going by the FDIV precedent, they should typically replace all defective products for free, and they will be in the clear. What I meant was that the presence of the bug itself is not a valid cause, for example you can't claim that due to the error you lost 1 trillion dollars via a software hack - even if it's true. If Intel can prove they acted ethically when disclosin…

How do they replace defective products? Or more specifically how do you get your laptop CPU replaced if Intel offers a replacement for free?

Presumably, by visiting an agreed service center in your western, sue-happy country, or sending the computer to the nearest one on your expense in the rest of the world. If the CPU is not replaceable or no longer in service, you would get a voucher for the lost value of the CPU/computer that is now 30% slower. Something like 10-20$ for anything older than 3 years, so most people won't bother. If Apple can do it, surely Intel will manage, but it will cost them in the billion order of magnitude, a non-negligible fraction of their yearly profit.

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

#312

Post by djsumdog »

zouhair wrote: post #69
wyager wrote: post #43

Earlier quoted context omitted.

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

This is typically what happens when you go for a long time without real competition. You get way too comfortable and bad habits start to pile up.

There are people looking to deploy ARM servers now. However I wish there had been more server competition. Many companies write their backend services in Python, JVM (Java/Scala/Groovy), Ruby, etc. Stuff that would run fine on Power, ARM or other architectures. There are very few specialized libraries that really require x86_64 (like ffmpeg and video-transcoding)

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

#313

Post by cookiecaper »

ricardobeat wrote: post #267
cookiecaper wrote: post #224

Earlier quoted context omitted.

Phoronix strikes again! I admire Michael's consistency and dedication and their benchmarks have certainly gotten better over the years as PTS has matured, but everything on Phoronix still needs to be taken with a generous helping of salt. New readers generally learn this after a few months; it applies not only to their benchmarks, but also their "news". The most obvious issue with this benchmark is that Phoronix is t…

So you’re saying that the latest RCS, without the patch, was supposed to be slower than stable by at least 10%? How often do companies release performance downgrades of that scale? That’s also very unlikely.

>So you’re saying that the latest RCS, without the patch, was supposed to be slower than stable by at least 10%?

I'm saying that it's not a reliable measurement of the impact of the PTI patchset. There was a PgSQL performance anecdote [0] (actually tested with the real boot parameters instead of entirely different versions of the kernel) that showed 9% performance decrease posted to LKML, which Linus described as "pretty much in line with expectations". [1]

Quoting further from that mail:

> Something around 5% performance impact of the isolation is what people are looking at.

> Obviously it depends on just exactly what you do. Some loads will hardly be affected at all, if they just spend all their time in user space. And if you do a lot of small system calls, you might see double-digit slowdowns.

So in general, the hit should be around 5%, and "[y]ou might see double-digit slowdowns" seems like the hit on a worst-case workload is hovering closer to the 10% range than 30%. That's also what the anecdote from LKML shows, unlike Phoronix which shows 25%-30% or worse.

This is more of an attrition thing than a staggering loss. With people saying MS patched this in November, it would be interesting to see if people saw a similar 5-10% degradation in Windows benchmarks since that time.

>How often do companies release performance downgrades of that scale?

I don't know which "company" you're referring to here, but substantial changes in kernel performance characteristics are pretty common during the Linux development/RC process, and yes, definitely some workloads will often see changes +/- 10% between the roughly bi-monthly stable kernel releases.

If you're surprised that Linux development is so "lively", you're not alone. That's one of the selling points of other OSes like FreeBSD.

[0] https://lkml.org/lkml/2018/1/2/678

[1] https://lkml.org/lkml/2018/1/2/703

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

#314

Post by edraferi »

adornedCupcake wrote: post #306
thraweigh666 wrote: post #301

Earlier quoted context omitted.

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

Why?

More diverse population—> lower trust —> less social will to support each other.

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

#315

Post by exabrial »

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…

Yep, I'm still wondering how this affects ARM and if it can be corrected in microcode on that platform.

I'm also wondering if/hoping for a fix that involves increased memory usage instead of the speed.

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

#316

Post by djsumdog »

kabdib wrote: post #235
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…

Man, you should see the errata for some ARM-based SOCs. It's amazing that they work at all. Vendor, in conversation: "We're pretty sure we can make the next version do cache coherency correctly." Me (paraphrased): "Don't let the door hit you in the ass on the way out." Management chain chooses them anyway, I spend the next year chasing down cache-related bugs. Fun.

ARM is such a shitstorm. At least the PC with UEFI is a standard. With every ARM device, you have to have a specialized kernel rom just for that device. There have been efforts made on things like PostmarketOS, but still in general, ARM isn't an architecture. It's random pins soldered to an SoC to make a single use pile of shit.

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

#317

Post by exabrial »

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…

There's also latency though :/ it seems that programs that make a lot of syscalls will be affected more than programs that are doing in-process calculations

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

#318

Post by yorick »

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…

A patch is in the works for ARM chips as well (http://lists.infradead.org/pipermail/linux-arm-kernel/2017-N...), but I am not clear on whether it's enabled by default. It seems like a good idea to have this, independent of current ARM vulnerability.

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

#319

Post by uniformlyrandom »

throwaway613834 wrote: post #253

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.

From the merge commit:

  +#ifdef CONFIG_PAGE_TABLE_ISOLATION
  +# define DISABLE_PTI		0
  +#else
  +# define DISABLE_PTI		(1
PS - MSFT has not published relnotes, so we do not know yet. We'll find out soon enough.

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

#320

Post by [deleted] »

pixl97 wrote: post #295
throwaway613834 wrote: post #253

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.

[deleted]
Post reply on HN