Is this for real? They are literally recommending not to use if statement. WTF.
Yes. And this advice will be permanent, btw. Spectre 1 is the only one of these new vulns that cannot be fixed without throwing away almost all of the performance of modern CPUs.
And the scope isn't if statements in general, it's specifically using control flow alone to guard data that is not supposed to be accessible. A good example of this would be the javascript engine in browsers doing a boundary check on array access. Traditionally, this might be something like:
Code:
int checked_get(size_t len, size_t index, int *array){
if (index < len) return array[index];
//if index > len, and that is rare in the program, the wrong value past the end of the array is speculatively returned.
//since this was supposed to prevent a javascript program accessing things like cryptographical keys that can reside
//in the same address space, this is a problem.
//something else to deal with overflow
}
In the brave new world, this is not safe, and cannot be made safe by changes to cpus alone. Note that if statements are not the only flow control that is affected, things like Liskov substitution has also been successfully attacked. (That is, using multiple different subclasses of a superclass with different implementations, and leaking information by tricking the cpu to speculatively use the wrong subclass on the data of a different subclass.)
In the future, to protect data that is not supposed to be available, you need to use arithmetic or non-control-flow logic operations. Modifying our earlier example:
Code:
int checked_get(size_t len, size_t index, int *array){
//make bitmask. works if len is a power of two
size_t mask = len + len -1;
if (index < len) return array[index & mask];
// this way, if index is greater than len, it will speculatively return the wrong value but from inside the values you could access anyway.
// no protection boundary is violated.
//something else to deal with overflow
}
In principle, this was one of the transformations that was actually done to make javascript safe again.
In future, this might mean we will get things like new, fast boundary checking instructions that do the above (or something else safe) that can be used instead. Even a fast scalar max() implemented as a single-cycle instruction that depended on both values and outputted the larger one would do the trick. But the primary problem, that you can leak data from speculative contexts using the cache, and that control flow is no longer a safe way to enforce protection boundaries, cannot and will not be fixed, and affects all fast CPUs going forward.