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

41–50 of 104 posts

Re: I found a bug in Intel Skylake processors

#41

Post by nosefouratyou »

ihnorton wrote: post #13

> I worked from the executable provided by SIOU, first interactively under GDB (but it nearly drove me crazy, as I had to wait sometimes one hour to trigger the crash again), then using a little OCaml script that ran the program 1000 times and saved the core dumps produced at every crash. rr can often be a time-saver in situations by providing deterministic replays up to the point of a crash, whereas coredump analysi…

There's also UndoDB if you can pay for it. Not sure what the differences are between it and RR, but I know with UndoDB you can create a binary for the client that has the recorder built in, so it can automatically record failing states.

Re: I found a bug in Intel Skylake processors

#42

Post by rbehrends »

etatoby wrote: post #26
rbehrends wrote: post #23

Earlier quoted context omitted.

That's not what happened. You can reproduce what gcc does easily by trying to compile the following code: int f(int x) { return x | 256; } Gcc generates the following code: movl %edi, %eax orb $1, %ah ret In contrast, clang uses an orl instead of orb . The advantage of using orb is that it generates shorter code with an immediate operand. This is on an x86_64 architecture and does not involve 32-bit code.

My point is that binary executables for Microsoft OSes, and the entire market built around them, are the only reason something like %ah (which is an incredibly stupid and expensive thing to address and the actual source of the bug) is part of the x86_64 architecture in the first place.

That does not make sense. First, Windows in 64-bit mode does not even support running 16-bit applications. Second, there's plenty of 16-bit code that's completely unrelated to MS Office/Windows (such as MBRs; that's because the BIOS boot process requires real mode).

Re: I found a bug in Intel Skylake processors

#44

Post by hacktothefuture »

I've worked so far away from the metal for such a long time but I still find these types of articles so interesting even though I only understand a small fraction of the info. Its amazing to think the levels of abstraction which are in place from the code at this level which make my work possible.

Re: I found a bug in Intel Skylake processors

#45

Post by userbinator »

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.

Re: I found a bug in Intel Skylake processors

#46

Post by userbinator »

raverbashing wrote: post #3

GCC generates code that's smaller but it isn't optimal, because of the potential for partial register stalls (and just overall register renaming issues) It's of course not wrong, but using AH when you're dealing with RAX is a weird anachronism Clang does the obvious, correct thing.

"smaller but not optimal" is not really true. It depends on what you're optimising for. In my experience, optimising for size overall, and then speed in the really performance-critical parts (with some expected expansion), gives the best results. Even the non-performance-critical code will have a noticeable effect if its larger size causes more cache misses.

Making use of the "partial registers" (I see them more as separate smaller registers that can be grouped together) effectively can avoid many more instructions.

Re: I found a bug in Intel Skylake processors

#47

Post by wyldfire »

acdha wrote: post #19
raverbashing wrote: post #8

Earlier quoted context omitted.

It is obvious, though I meant "obvious and correct" not "obviously correct"

Have you looked at the actual GCC codebase? It's very easy to say something is obvious when you're looking at a problem which someone else has nicely isolated; it's much harder to dive into a complex codebase which has a very wide support matrix and say it's worth the effort to change working code instead of so many other things. More bluntly, before now wouldn't most people have said it was “obvious” that Intel woul…

I suppose the choice of word was to describe what code a human would intuitively/idomatically write for this situation. Whereas compiler passes are often wont to sum up to unintuitive/non-obvious code that is "correct" in that it's a valid lowering of the higher level code but not likely what a human would've written. This can sometimes be a pro or a con in terms of the resulting code's performance.

Re: I found a bug in Intel Skylake processors

#48

Post by raverbashing »

userbinator wrote: post #46
raverbashing wrote: post #3

GCC generates code that's smaller but it isn't optimal, because of the potential for partial register stalls (and just overall register renaming issues) It's of course not wrong, but using AH when you're dealing with RAX is a weird anachronism Clang does the obvious, correct thing.

"smaller but not optimal" is not really true. It depends on what you're optimising for. In my experience, optimising for size overall, and then speed in the really performance-critical parts (with some expected expansion), gives the best results. Even the non-performance-critical code will have a noticeable effect if its larger size causes more cache misses. Making use of the "partial registers" (I see them more as s…

I don't disagree with you, but then use EAX, not AH (which would also produce a smaller code as you don't need to use a 64-bit constant)

Optimizing for size is good, but what GCC did there made sense in the 32-bit days, but not that much today

Some code snippets use AH/AL as 2 separate registers hence the processor might rename them to different internal registers. But then when reading EAX the processor needs to update EAX accordingly as well.

Re: I found a bug in Intel Skylake processors

#49

Post by acdha »

raverbashing wrote: post #33
acdha wrote: post #19

Earlier quoted context omitted.

Have you looked at the actual GCC codebase? It's very easy to say something is obvious when you're looking at a problem which someone else has nicely isolated; it's much harder to dive into a complex codebase which has a very wide support matrix and say it's worth the effort to change working code instead of so many other things. More bluntly, before now wouldn't most people have said it was “obvious” that Intel woul…

The code produced by Clang is a direct translation of the C code. That's the obvious part of it Most people here are not familiar with x86 assembly and its caveats it seems. Reading the Intel and AMD optimization manuals might be a good start (and yes, the bug is not in GCC it's on the Intel processor)

> Most people here are not familiar with x86 assembly and its caveats it seems. Reading the Intel and AMD optimization manuals might be a good start.

Please don't make unsupported assertions that everyone but you is speaking out ignorance. It doesn't add anything to the conversation, especially when dealing with older codebases unless you can prove that this is and never has been the correct way to write that code. Otherwise it's just another way to say “CPU optimizations change over time and an open-source project doesn't have a team of experts tracking microbenchmarks to decide when to switch”.

Re: I found a bug in Intel Skylake processors

#50

Post by pjc50 »

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.
Post reply on HN