Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Can branch prediction crash my program?

Going trough chapter 3 of this book called Computer Systems Architecture: A programmer's perspective, it is stated that an implementation like

testl %eax, %eax
cmovne (%eax), %edx

is invalid because if the prediction fails, then we'll have NULL dereferencing. It is also stated that we should use branching code.

Still, wouldn't using conditional jumps lead to the same result? For example:

.L1:
jmp *%eax

testl %eax, %eax
jne .L1

Is it possible to trick gcc to output something like that for an x86-32? Suppose I have an array of pointers to functions of which some are valid and some aren't and I call each one that's not NULL.

like image 206
Alex C Avatar asked Jul 07 '14 13:07

Alex C


1 Answers

No. You should not be able to detect out-of-order operand fetch of a jmp instruction if it is part of a speculative execution that proves invalid due to a test and jump.

The cmove__ instruction is precisely documented to cause a fault if a memory access operand would cause a fault, even if the condition is not met. In other words, this is not speculative execution. It's part of the instruction semantics. It's the move to desination that's conditional, not the fetch.

The jmp instruction is not so-documented.

I'm not getting the point of your example code because there is no condition on the memory operation *%eax. If %eax contains zero, certainly the fetch in the unconditional execution of jmp *%eax will cause a fault. This is correct behavior. If you test %eax and jump around the bad reference.

testl %eax, %eax
je .L1
jmp *%eax
.L1:

There can't be a problem. Speculative execution of the *%eax cannot cause a fault unless the speculation turns out to be valid, i.e. the true control path. This is similar to behavior for bad opcodes, division by zero and the like: normal program semantics are not affected by speculative execution.

Where out-of-order fetches and stores really do cause all kinds of interesting problems is in multi-processing. This article and also its first part in the preceeding issue are great discussions of this topic.

like image 165
Gene Avatar answered Nov 13 '22 05:11

Gene