Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I found a bug in Intel Skylake processors

gallium.inria.fr

Post reply on HN
Print view View original

71–80 of 104 posts

Re: I found a bug in Intel Skylake processors

#71

Post by qb45 »

userbinator wrote: post #45
hsnewman wrote: post #43

Can this be exploited for malicious code?

It's "unpredictable" what happens, so I think the best you're going to do is a DoS. I.e. if you could get the JS JIT in a browser to generate code like this and execute it repeatedly, you could crash a machine just by visiting a site.

It also is "unpredictable" what happens when you overrun a stack frame.

There is zero guarantee that the infamous Sufficiently Sophisticated Attacker couldn't predict it. Hardware is largely deterministic, even when it doesn't behave in the documented way. I wouldn't interpret this as literally unpredictable, it's just a generic slogan they always use in their errata. And they aren't going to say anything more for obvious reasons.

Patch this damn microcode.

Re: I found a bug in Intel Skylake processors

#72

Post by balls187 »

tvgggghh wrote: post #67
balls187 wrote: post #59

> That would not be the first time that GCC treats undefined behaviors in the least possibly helpful way, Oh compilers. Like VC++6.0 initializing uninitialized memory to 0xCDCDCDCD in DEBUG.

Err, that's on purpose? It's so you can tell your writes apart, which is helpful while debugging. They used to use, uh, more obvious patterns but the PC brigade called them on it so they settled on 0xcd.

0xDEADBEEF how I miss you.

Yea, I knew it was on purpose, but it had the unintended consequence of masking bugs that would only show up in release builds.

Re: I found a bug in Intel Skylake processors

#74

Post by raverbashing »

aij wrote: post #68
raverbashing wrote: post #15

Earlier quoted context omitted.

It might not, but the GCC code has a potential issue in how it does things https://stackoverflow.com/a/41574531 (curiously the question is about GCC not doing it, apparently not always)

It's a performance trade off. It's not really surprising that GCC would make different performance trade offs when optimizing for different microarchitectures. (let alone most likely across different versions of GCC) Why would you expect GCC to optimize for Pentium 4 (Netburst) in this day and age? (Especially given that the article is talking about Skylake.)

I don't expect it to optimize to P4, are you talking about this? (it's one of the answers to that answer)

> The quoted delay of 5 - 6 clocks is much better on later microarchitectures. For example from Sandy Bridge and Ivy Bridge, The Ivy Bridge inserts an extra μop only in the case where a high 8-bit register (AH, BH, CH, DH) has been modified

And you see that even on later architectures the point of avoiding AH makes sense (which is the opposite of what that GCC code does)

Re: I found a bug in Intel Skylake processors

#75

Post by Joeri »

piemonkey wrote: post #56

One amusing thing about this epic tale is Serious Industrial OCaml User disregarded direct, relatively easy to implement, very sound advice from Xavier Leroy about how to debug their system! I would like to think that, were I in a similar situation being advised by an expert of that calibre, I would at least humor his suggestions. Why seek the expert if not for his advice? It brings to mind people disregarding doctor…

Not saying this is what happened in this circumstance, but even an expert has to explain the 'why' of things. "Disable HT and try again" comes with a hint of "please go away", whereas "disable HT so we can eliminate a potential cause" smells more like "I really want to understand this thing."

Re: I found a bug in Intel Skylake processors

#76

Post by civilitty »

newusertoday wrote: post #73

I routinely see these bugs when the new hardware is still getting developed.

They're completely unavoidable short of having all of the world's entire computing power with which to do formal verification (and even then, there's no guarantee).

I've even seen, when developing standard cell libraries for a new fabrication process, bugs that occur because of unforeseen interactions between different semiconductor doping concentrations that occur when (due to pure statistics in fabrication) they overlap in the wrong way.

Re: I found a bug in Intel Skylake processors

#77

Post by insulanus »

balls187 wrote: post #59

> That would not be the first time that GCC treats undefined behaviors in the least possibly helpful way, Oh compilers. Like VC++6.0 initializing uninitialized memory to 0xCDCDCDCD in DEBUG.

0xCD is the interrupt instruction on X86. If you tried to execute out-of-bounds memory, you get a trap right away (handily, the instruction is one byte long).

http://www.mathemainzel.info/files/x86asmref.html#int

Before Intel processors had execute protection, this was a good way to catch bugs in your buggy C bugs. I mean programs.

Re: I found a bug in Intel Skylake processors

#78

Post by balls187 »

insulanus wrote: post #77
balls187 wrote: post #59

> That would not be the first time that GCC treats undefined behaviors in the least possibly helpful way, Oh compilers. Like VC++6.0 initializing uninitialized memory to 0xCDCDCDCD in DEBUG.

0xCD is the interrupt instruction on X86. If you tried to execute out-of-bounds memory, you get a trap right away (handily, the instruction is one byte long). http://www.mathemainzel.info/files/x86asmref.html#int Before Intel processors had execute protection, this was a good way to catch bugs in your buggy C bugs. I mean programs.

It was a "good" way to catch a certain class of bugs on X86, while introducing a different class of (arguably) harder to catch bugs.

With VS .NET (VC7.0), the C++ compiler no longer defaulted uninitialized memory in debug builds.

Our software didn't just run on x86 (windows/linux), but also SGI MIPS (Irix), VAX (VMS), DEC Alpha (Tru64), AND PowerPC (VxWorks), so across all those compilers, we ended up having portable and robust code.

Re: I found a bug in Intel Skylake processors

#79

Post by dom0 »

pjc50 wrote: post #50
etatoby wrote: post #14

I will be surely downvoted for this, but I would like to remind everyone how this bug is just one of the many consequences of Microsoft's evil policy of encouraging the sale and distribution of proprietary software in executable form. There is no other reason why a 64bit multi-core CPU developed in 2015, that makes heavy use of pipelining and other advanced and complicated code execution strategies, would need to sup…

Shipping software executable form? That ship has sailed, long, long ago. Shipping source is both of little use to the vast majority of non-huge customers, and a way of guaranteeing that your software will be pirated. In fact, the demands of getting paid are moving us more and more to SaaS.

Shipping source has many practical issues for software deployment, including security implications, which is why many are moving away from using things similar to "pip" and towards things like "docker" (among other reasons).

Re: I found a bug in Intel Skylake processors

#80

Post by FeepingCreature »

justin66 wrote: post #60
piemonkey wrote: post #56

One amusing thing about this epic tale is Serious Industrial OCaml User disregarded direct, relatively easy to implement, very sound advice from Xavier Leroy about how to debug their system! I would like to think that, were I in a similar situation being advised by an expert of that calibre, I would at least humor his suggestions. Why seek the expert if not for his advice? It brings to mind people disregarding doctor…

I know nothing of OCaml culture or why the author is deemed worthy of having his name italicized, but the doctor comparison is upsetting. If the guy who wrote this: I was tired of this problem, didn't know how to report those things (Intel doesn't have a public issue tracker like the rest of us), and suspected it was a problem with the specific machines at SIOU (e.g. a batch of flaky chips that got put in the wrong s…

No he wouldn't. Doctors are not obligated to write up case studies or submit them to medical publications.
Post reply on HN