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

141–150 of 567 posts

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

#141

Post by userbinator »

Avshalom wrote: post #122
rayiner wrote: post #52

Can someone help me understand why this is such a big deal? This doesn’t seem to be a flaw in the sense of the Pentium FDIV bug where the processor returned incorrect data. It doesn’t even seem to be a bug at all, but a side channel attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it. And it doesn’t seem like it can be used for privilege esca…

I have no idea how or if this is a big deal but: >>attack that would be almost expected in a processor with speculative execution unless special measures were taken to prevent it. if you're going to put in features with expected attacks you should definitely be putting in features to prevent it , and if it is an expected attack it shouldn't be special measures it should just be an inherent part in introducing the fea…

When speculative execution (and caches) were invented and put into widespread use, no one thought about timing attacks, nor was the practice of running untrusted code on one's own machine common.

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

#142

Post by Havoc »

sooheon wrote: post #48
mindcrime wrote: post #29

Earlier quoted context omitted.

Seems debatable. From what I recall, at least some news about this issue was already public before he sold his shares. And what would be illegal would be trading based on information that isn't public. OTOH, since details are still dribbling out, you could possibly argue that the Intel CEO had more complete information than the public. The sell could also have been scheduled in advance, which would - AFAIK - not viol…

Unless the advance scheduling is completely binding, I don't see why that should sidestep insider trading. What's to stop these guys from always having a cascading series of sells and buys 6 mo. in advance, and just cancelling them?

>Unless the advance scheduling is completely binding

It gets filed with the SEC so should be suitably permanent

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

#144

Post by mtgx »

spdy wrote: post #77
zouhair wrote: post #69

Earlier quoted context omitted.

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.

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…

I think that could also have been the "official reason".

The same reason could have been used to give the NSA some legroom for instance, but tell everyone that's why they won't do so much verification in the future.

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

#145

Post by mtanski »

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.

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.

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

#146

Post by m3kw9 »

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…

Cloud services may not need to worry about the issue depending on the OS the customer choose to use, the patched or non patched version.

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

#147

Post by userbinator »

valleyer wrote: post #138
rayiner wrote: post #109

Earlier quoted context omitted.

Thanks for the explanation. But I don't understand this part: > If you could know all of the addresses of important kernel routines, you could potentially execute a "return oriented programming" attack against the kernel with kernel privileges. Without modifying or injecting any kernel level code. The user kernel transition is mediated (on x86-64) with the SYSCALL instruction, which jumps to a location specified by a…

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.

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

#149

Post by ajasmin »

m3kw9 wrote: post #146
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…

Cloud services may not need to worry about the issue depending on the OS the customer choose to use, the patched or non patched version.

For the cloud providers it's the security of the hypervisor that's at stake.

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

#150

Post by frik »

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…

The other issue here is what MS does regarding Windows 7. It would not surprise me in the least if they tried a clever/efficient patch for Windows 10 and a simpler (and slower) bodge-job for Windows 7/8. Still, I guess we'll find out soon enough. They'd also better make sure that the changes only apply to Intel machines. I don't want MS to arbitrarily slow down my AMD PC as a result of this - you'll note that AMD submitted a Linux patch to ensure their CPUs weren't caught up in this, will MS do the same? Afterall, there is a reason this partnership is called "Wintel", both know it's in their best interest not to screw each other over.
Post reply on HN