Does having no 'if' blocks in code mitigate side-channel attacks?

Question

Looking through descriptions of Spectre and Meltdown it seems that speculative execution - the basis for these attacks - occurs only with branched code. Therefore, it seems logical to conclude that having no if statements would preclude speculative execution and consequently, the side-channel attacks. Is this a correct statement?

Answer 1

Not just if.

You will have to remove all functions, methods, lambdas, classes, loops, whiles, exceptions, polling, switch, if, lookup tables, jump tables.

You will then have no need for tests, counters, maths, polls, conditionals, environment queries, any other form of input, including keyboards, mice, ram, rom, or other forms of storage. (You can have input streams)

Basically, remove branching and you remove computers.

Despite what is said above, even DSP (those that do FFT and stuff like that) have branches in them. I guess you might be able to construct an ADC or a DAC - but only a very primitive one.

Try having a light circuit at home that doesn’t have switches!

On intel about 15% of all instructions (by popularity, not by count) involve branches of some sort; and intel has a disproportionately high demand for moves. On most other CPUs there are a correspondingly greater proportion of branches.

Answer 2

Removing branching would probably mitigate these problems. But so what? If you remove branching you essentially remove the need for a general purpose computer, and you're left with something that can do more or less static set of operations on some data.

Such computers are very common in the form of DSP's, but they're not general purpose computers.

Removing branching on a x86 cpu (which is the family hit by meltdown and spectre) is throwing the baby out with the bathwater.

Answer 3

Unfortunately, even aside from the other issues mentioned, compilers can produce conditional execution even in cases where you did not explicitly write a conditional. This most commonly arises from compiler optimizations, but can also result from e.g. ABI calls to emulate missing features.

For instance:

#include <stdint.h>

uint64_t foo(uint64_t x, uint64_t y) {
    return x % y;
}

On Clang 11.0.1 on ARMv7a, this compiles to

foo:
  push {r11, lr}
  bl __aeabi_uldivmod
  mov r0, r2
  mov r1, r3
  pop {r11, lr}
  bx lr

This generally results in conditional execution within __aeabi_uldivmod. For instance, in the Clang toolchain, you have

__aeabi_uldivmod:

DEFINE_COMPILERRT_FUNCTION(__aeabi_uldivmod)
[...]
bl SYMBOL_NAME(__udivmoddi4)

which then calls into __udivmoddi4:

COMPILER_RT_ABI du_int __udivmoddi4(du_int a, du_int b, du_int *rem) {
  [...]
  if (n.s.high == 0) {

...and now you suddenly have conditional execution.

Ditto, under the as-if rule a C compiler can translate e.g.

uint64_t foo(bool b, uint64_t x, uint64_t y) {
    return b*(x%y); /* in C a bool cast to int is 0 or 1 */
}

into

uint64_t foo(bool b, uint64_t x, uint64_t y) {
    if (b) {
        return x % y;
    }
    return 0;
}

...which may be advantageous if branching is cheap compared to remainder (which is often the case). And now suddenly you have conditional execution.

Etc, etc.

(You're not immune to this even if you drop down to assembly, by the way. For instance, unaligned access on AArch32, which isn't natively supported on all platforms, is occasionally handled by an abort handler that emulates the instruction. This, of course, involves conditional execution to parse the instruction / emulate it / etc.)

Answer 4

There is no IF statement at the CPU level and it is unclear which programming language with if statements you refer to. But depending on the programming language various statements will result in conditional branches (and thus speculative execution), i.e. various loops with conditions like ranges, ternary operator ...

Answer 5

If you access any memory address that is not already known by the attacker, information can be leaked through the cache.

Consider the following function:

char get_secret_message_byte(int index) {
    return secret_code_table[encoded_secret_message[index]];
}

If the cache is not populated before this function is called, then part of secret_code_table will be loaded into the cache, leaking information about the value of encoded_secret_message[index], which is useful to an attacker.

Also, part of encoded_secret_message will be loaded into the cache, leaking information about the value of index. If the attacker already knows index, it's not useful to them.

Answer 6

The trick is to remove branches from those parts of the code where the pattern of branches taken gives the attacker useful information.

Usually, these are areas where "carefully crafted" input can leak single bits of secret data, and where repeated calls can then reveal additional information.

In practice, that is often avoided by chaining constant-time cryptographic operations so that the first branch afterwards is a general "passed checks" test -- so for example you'd send an encrypted and signed packet, and implement both decryption and verification to be branch-free, then an attacker would, without knowledge of the signing key, only be able to generate packets that are rejected at the exact same point.

Actually parsing the received packets would not necessarily have to be branch-free if the attacker doesn't gain anything there anymore -- most likely they are more interested in extracting secret key material (because that allows exploitation in the future), not reading single messages (which may have immediately observable effects anyway).