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

121–130 of 567 posts

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

#121

Post by zvrba »

rayiner wrote: post #109
DannyB2 wrote: post #72

Earlier quoted context omitted.

There is this thing called "return oriented programming". You write your program as a series of addresses that are smashed onto the stack through some other type of vulnerability. When the current function returns, it returns to an address of your choosing. That address points to the tail end of some known existing function, such as in the C library and other libraries. When the tail end of that function returns, it…

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…

More importantly, it also switches stacks so user-mode code cannot modify the return addresses on the kernel's stack.

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

#122

Post by Avshalom »

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

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

#123

Post by dannyw »

Abishek_Muthian wrote: post #79

I'm worried about the performance impact on low end intel chips like Atom/Celeron found in Chromebooks.30% hit will make computing on those platforms miserable. Talking about chromeOS, is there any speculation about the impact of bug? Does it's hardened sand-boxing techniques put it in a better position even if KASLR is compromised?

The bug isn't really KASLR, it's more about reading kernel memory from userspace through side channel attacks of speculative execution.

KASLR is/was the cover for the kernel patches, to avoid disclosing the real bug.

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

#124

Post by innagadadavida »

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.

But why do AMD chips not have similar issues? To me it looks like Intel tried to micro optimize something and screwed up.

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

#125

Post by InTheArena »

api wrote: post #111
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...

A lot of people have noticed that High Sierra is slower than Sierra, specifically for filesystem operations with APFS. I wonder if Apple knew about this ahead of time and this explains the overhead?

Probably not. APFS just does a lot more then HFS, so there is a huge performance impact on disk related issues before this change goes in.

This is a all hands on deck kind of situation. Apple doesn't usually do well with security firedrills like this.

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

#126

Post by yborg »

bla2 wrote: post #68

The bottom of https://danluu.com/cpu-bugs/ suggests that AMD isn't any better, so this is likely just short term.

This specific issue is very relevant to cloud providers, who are the guys that buy thousands of CPUs, and doesn't affect AMD's current generation. I don't know what Intel's profit breakdown is, but I suspect it is heavily weighted to the high-end server chips where they have had no real competition for many years.

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

#127

Post by 0x0 »

mikeash wrote: post #86
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…

If “reading secret data out of kernel memory” translates into “read the page cache from a stranger’s VM that happens to be on the same cloud server” then this could be worse than Heartbleed.

Or maybe random javascript in the browser can stroll upon your ssh private key in the kernel's file cache... and so on.

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

#128

Post by leoc »

innagadadavida wrote: post #124
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.

But why do AMD chips not have similar issues? To me it looks like Intel tried to micro optimize something and screwed up.

Maybe the answer lies in Intel’s feted IPC advantage over AMD? Or is it the case that AMD has simply been relatively lucky so far?

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

#129

Post by userbinator »

bo1024 wrote: post #117
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 don't think we even know what the bug is yet, just lots of informed speculation...

Ironically, "lots of informed speculation" seems to be exactly what the bug is about. ;-)

The thing is, AMD probably very narrowly just missed this one --- if they did more aggressive speculative execution, they would be the same.

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

#130

Post by mikeash »

0x0 wrote: post #127
mikeash wrote: post #86

Earlier quoted context omitted.

If “reading secret data out of kernel memory” translates into “read the page cache from a stranger’s VM that happens to be on the same cloud server” then this could be worse than Heartbleed.

Or maybe random javascript in the browser can stroll upon your ssh private key in the kernel's file cache... and so on.

Excellent point, I didn't think about the implications for stuff like JavaScript.
Post reply on HN