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

181–190 of 567 posts

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

#181

Post by jk563 »

olfactory wrote: post #162
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…

> all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses Well, if I rent a VPS with x performance, I still expect x performance after this flaw is patched. The company providing the virtual machine will perhaps have to pay 30% more to provide me with the same product I've been getting. Since most VPS offerings arbitrage shared resources, this will not increase costs…

Well if you use m5.xlarge instances from AWS you were getting 4 vCPUs for your money. I don't expect you'll now get 5...

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

#182

Post by cma »

zelos wrote: post #25
cma wrote: post #6

This isn't really too far out of proportion with normal daily fluctuations of AMD stock this year.

Quiet, you're spoiling the narrative we're imposing on semi-random, chaotic events.

To add another point: NVDA is up 5% and doesn't have the same direct competitive narrative. If money has to be spent rectifying the issue with new or more CPUs due to performance loss, that's less money available for spending on Nvidia GPUs. It might tip a few marginal applications in favor of eating the development costs to migrate to GPGPU, but that effect isn't likely nearly as high, especially if applications with lots of system calls are affected the most.

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

#183

Post by golfer »

cornholio wrote: post #178
golfer wrote: post #168

Earlier quoted context omitted.

Anyone can sue anyone else at any time. If you think Intel isn't going to be sued for this, you're wrong.

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…

Good call. Will be fascinating to see how this plays out!

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

#184

Post by surajrmal »

mtanski wrote: post #145
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.

As I mentioned in the other thread yesterday database and database like applications are going to be hit particular hard. Even more so on fast flash storage. Double whammy compared to apps just doing network IO. And while databases try to minimize the number of syscalls they still end up doing a lot of them for read, writeout, flush.

Don't flash devices use nvme (eg userspace queues) now and avoid the kernel all together for read and write operations? Shouldn't they have no impact?

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

#185

Post by olfactory »

jk563 wrote: post #181
olfactory wrote: post #162

Earlier quoted context omitted.

> all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses Well, if I rent a VPS with x performance, I still expect x performance after this flaw is patched. The company providing the virtual machine will perhaps have to pay 30% more to provide me with the same product I've been getting. Since most VPS offerings arbitrage shared resources, this will not increase costs…

Well if you use m5.xlarge instances from AWS you were getting 4 vCPUs for your money. I don't expect you'll now get 5...

No, but the underlying hardware that perviously hosted two m5.xlarge instances may instead host one M5.xlarge and one M5.medium, so that performance is not degraded.

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

#186

Post by rincebrain »

userbinator wrote: post #147
valleyer wrote: post #138

Earlier quoted context omitted.

Basically, let's say there's a syscall that takes a user buffer and size and copies it into kernel stack for processing. (This is common.) If you overflow that buffer, you can overwrite the return address in the kernel stack, which you can then launch into ROP.

If you overflow that buffer, you can overwrite the return address in the kernel stack, which you can then launch into ROP. The crucial point here being that there must already be an existing overflow vulnerability in the kernel. Knowing all the addresses is no use if you can't force execution to go to them.

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 JavaScript which may be unrelated

- there exists a Xen security embargo that expires Thursday that might be unrelated

- AWS and Azure have scheduled reboots of many things for maintenance in the next week, which seems unlikely to be unrelated to the Xen embargo

- a feature that appears to be geared toward preventing a side-channel technique of unknown power has been rushed into Linux for Intel-only (both x86_64 and ARM from Intel)

- a similar class of prevention technique has been landed in Windows since November for both Intel and AMD x86_64 chips (no idea about ARM)

- the rush surrounding this, and people being amazingly willing to land fixes that imply a 5-30% performance impact, strongly suggest that unlike almost every major CPU bug in the last decade, you can't fix or even work around this with a microcode update for the affected CPUs, which is _huge_. The AMD TLB bug, the AMD tight loop bug that DFBSD found, even the Intel SGX flaws that made them repeatedly disable SGX on some platforms - all of them could be worked around with BIOS or microcode updates. This, apparently, cannot. (Either that or they're rushing out fixes because there's live exploit code somewhere and they haven't had time to write a microcode fix yet, but O(months) seems like they probably concluded they outright can't, rather than haven't yet.)

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

#187

Post by eptcyka »

0xcde4c3db wrote: post #82
dsign wrote: post #49

Here are some numbers quantifying the problem. Big caveats apply as they are very preliminary, but the hit due to the software patches looks extremely significant: https://www.phoronix.com/scan.php?page=article&item=linux-41...

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.

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

#188

Post by Sean1708 »

olfactory wrote: post #162
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…

> all companies paying for computing resources will have to pay roughly 30% more overnight on cloud expenses Well, if I rent a VPS with x performance, I still expect x performance after this flaw is patched. The company providing the virtual machine will perhaps have to pay 30% more to provide me with the same product I've been getting. Since most VPS offerings arbitrage shared resources, this will not increase costs…

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

Post reply on HN